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

[Mirja Kuehlewind <[e-mail]>]

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>