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

["BRUNGARD, DEBORAH A" <[e-mail]>]

Hi Mirja,

The plan is to Last Call the set of documents (gpe, bis's) and put on a future telechat. First, the author teams want to ensure they have addressed all the current Discusses/comments and they are working to get the documents ready.

Thanks all - the documents are much improved!
Deborah


-----Original Message-----
From: Mirja Kuehlewind <[e-mail]> 
Sent: Wednesday, January 08, 2020 5:22 AM
To: Fabio Maino (fmaino) <[e-mail]>; BRUNGARD, DEBORAH A <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Luigi Iannone <[e-mail]>
Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-lisp-gpe-05: (with DISCUSS and COMMENT)

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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
> .org_doc_draft-2Dietf-2Dlisp-2Drfc6830bis_&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQ
> icvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVl
> PPk33Nw&s=oRnVaMWUr_mvYyEiDEkkNTuBOAIOJ_vBnr3COsvsMrI&e=
> , https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dlisp-2Drfc6833bis_&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVlPPk33Nw&s=3I9q-AoB6EQNPtTNvKH36_EP-xCFPQESZPH7CeFoVuo&e=  ).
> 
> Could you please take a look at the latest rev -13 of https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dlisp-2Dgpe_&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVlPPk33Nw&s=BueHq0NVA0sDhX7r1hme2y4YHEnu52LCy7alSTn3nIc&e= , 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ies
>> g_statement_discuss-2Dcriteria.html&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg
>> &r=6UhGpW9lwi9dM7jYlxXD8w&m=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVlPPk33
>> Nw&s=LRs3yFVTl5Y1iOdjAu80URJVGsWHi2UmiUaeJ0j9Imw&e=
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
>> .org_doc_draft-2Dietf-2Dlisp-2Dgpe_&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg
>> &r=6UhGpW9lwi9dM7jYlxXD8w&m=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVlPPk33
>> Nw&s=BueHq0NVA0sDhX7r1hme2y4YHEnu52LCy7alSTn3nIc&e=
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> -
>> 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>