Thanks a lot! I believe all my comments are addressed but I’m also not an AD anymore…
> On 1. Jun 2020, at 07:55, Fabio Maino (fmaino) > <[email protected]> wrote: > > 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
