Hi Mirja, Rev -15, that was just published, should address your comments: https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
Let me know if you have any further comment. Thanks, Fabio On 3/13/20, 4:19 AM, "Mirja Kuehlewind" <[email protected]> wrote: Hi authors, hi Deborah, Sorry for being super later on this but I was looking at this document again and I realised that there is still one open issue that needs fixing: I noticed that I also had a discuss point on guidance on DSCP which is not addressed yet. However, the more important and really critical point is that the doc talks about setting the 3-bit Type of Service (ToS) that does exist anymore: RFC1349 was obsoleted by RFC2474, so there is now only a 6-bit DSCP field. This is really a pain point in todays Internet and needs to be fixed! I also recommend to add a reference to RFC2474 (then this problem would maybe have been detected earlier). And still as my discuss says some more guidance on the use of DCSP would be good as well! Thanks! Mirja > On 10. Jan 2020, at 20:03, BRUNGARD, DEBORAH A <[email protected]> wrote: > > 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
