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://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" <[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://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> _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
