Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-gpe-05: (with DISCUSS and COMMENT)

["Fabio Maino (fmaino)" <[e-mail]>]

Thanks for the quick turnaround Mirja. 

I'll add text that refers to the Reserved field in the the next rev. 

Thanks,
Fabio



On 1/8/20, 2:22 AM, "Mirja Kuehlewind" <[e-mail]> wrote:

    Hi Fabio,
    
    Thanks for all the work. Changes look good to me and I think my discuss comments are addressed.
    
    One small comment/nit: I think you also should define the “Reserved” field in Figure 2. It’s not mention in the text, and even though the meaning is obvious, I assume it was an oversight that it's not described.
    
    Given the large set of changes, it’s good that another wg last call took place. I think given more or less whole document has changes, it could be approbate to also have another IETF last call and put it back on a future telechat agenda. But I let Deborah decide about this. 
    
    Deborah what's your plan here?
    
    Mirja
    
    
    
    > On 8. Jan 2020, at 00:02, Fabio Maino (fmaino) <[e-mail]> wrote:
    > 
    > Hi Mirja,
    > It took quite some time, but I think we are finally making progress with the review of draft-ietf-lisp-gpe and the related LISP RFCbis drafts (https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/
    > , https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ).
    > 
    > Could you please take a look at the latest rev -13 of https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/, and let us  know if we have addressed your comments?
    > 
    > Wrt lisp-gpe, compared with rev -05 that you last reviewed, we have done two main changes that might help addressing your DISCUSS: 
    > 1.	We have introduced the concept of shim header, along the line of what Mirja suggested in her comment. The chairs thought that the change was significant enough to require a new last call with the WG, that we did after Singapore
    > 2.	 We have introduced section 4 that, following what done in RFC8085 and RFC8086, defines the scope of applicability of LISP-GPE and makes considerations related with congestion control, UDP checksum, and ethernet payload encapsulation. 
    > 
    > Please, let me know if you have any further question or suggestion. 
    > 
    > I have attached a diff from rev -05 that is the one to which your ballot comments were referring to. 
    > 
    > Thanks,
    > Fabio
    > 
    > 
    > On 9/20/18, 1:22 PM, "Fabio Maino" <[e-mail]> wrote:
    > 
    >    Thanks for your notes Mirja.
    > 
    >    I'll publish an updated rev this evening to consolidate the changes that 
    >    I believe we have agreed upon, and then I'll work on those that are 
    >    still open.
    > 
    >    Please see below.
    > 
    > 
    >    On 9/19/18 12:42 PM, Mirja Kühlewind wrote:
    >> Mirja Kühlewind has entered the following ballot position for
    >> draft-ietf-lisp-gpe-05: Discuss
    >> 
    >> When responding, please keep the subject line intact and reply to all
    >> email addresses included in the To and CC lines. (Feel free to cut this
    >> introductory paragraph, however.)
    >> 
    >> 
    >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    >> for more information about IESG DISCUSS and COMMENT positions.
    >> 
    >> 
    >> The document, along with other ballot positions, can be found here:
    >> https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
    >> 
    >> 
    >> 
    >> ----------------------------------------------------------------------
    >> DISCUSS:
    >> ----------------------------------------------------------------------
    >> 
    >> Thanks for addressing the TSV-ART review (and Magnus for doing the review)! I
    >> assume that the proposed text will be incorporated in the next version. (Would
    >> have been even better if those (larger) changes would have been added before
    >> the doc was put on the telechat; please update as soon as possible so other AD
    >> can review that text as well).
    >> 
    >> However, I think the text still needs to say more about HOW the PCP should be
    >> mapped to DSCPs. RFC8325 doesn't provide guidelines but a mapping for 802.11.
    >> Is the same mapping applicable here?
    > 
    >    Agree. As pointed out by Magnus' latest email there's more investigation 
    >    needed here. I'll get back on this.
    > 
    >> 
    >> Also, I'm not an expert for that part, but I guess there also is further
    >> guidance needed on HOW to map the VID...?
    > 
    >    This is really straightforward, as the VID is a 12-bit field, and the 
    >    IID is 24-bit. Implementation that I'm aware of typically carve a 
    >    portion of the IID space to encode the VID.
    > 
    >> 
    >> 
    >> ----------------------------------------------------------------------
    >> COMMENT:
    >> ----------------------------------------------------------------------
    >> 
    >> Given this doc uses the last reserved bit in the lisp header, I would really
    >> like to see more discussion how the data plane lisp can still be extended. I
    >> think the solution is straight-forward (define a shim layer for the extension
    >> and announce this capability in the Map-Reply), however, spelling this out
    >> seems to be appropriate for this doc.
    > 
    >    Correct, that's the idea. I'll add a sentence that states that a 
    >    lisp-gpe next protocol header can be used to extend the lisp data-plane 
    >    functions.
    > 
    > 
    >    Thanks,
    >    Fabio
    > 
    >> 
    >> 
    > 
    > 
    > 
    > <Diff_ draft-ietf-lisp-gpe-05.txt - draft-ietf-lisp-gpe-13.txt.pdf>