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 <[email protected]> Sent: Wednesday, January 08, 2020 5:22 AM To: Fabio Maino (fmaino) <[email protected]>; BRUNGARD, DEBORAH A <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; Luigi Iannone <[email protected]> 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) <[email protected]> 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" <[email protected]> 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> _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
