Hi Donald, For an EVPN reference, RFC 8365 which deals with EVPN VXLAN may be better than RFC 7432.
The current version of the INT spec is available at p4.org https://p4.org/p4-spec/docs/INT_v2_1.pdf Section 5.7 talks about how to carry INT headers of VXLAN GPE and Geneve. The other responses look good to me. Thanks, Anoop On Wed, Jul 28, 2021 at 9:16 PM Donald Eastlake <[email protected]> wrote: > Hi Anoop, > > Thank you for your very detailed review. :-\ > > See my responses below where I didn't exactly agree with your > suggestion. If I don't respond to a point it means I think your > comment is a reasonable change. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > [email protected] > > > On Tue, Jul 27, 2021 at 8:07 PM Anoop Ghanwani <[email protected]> > wrote: > > > > I support publication of the document. I have the following > > comments -- mostly editorial and around use of consistent > > terminology. > > > > == > > > > Section 2 > > - Expand first use of DT. > > Instead replace "design team", which occurs earlier in Section 2, with > "design team (DT)". > > > > Section 6.2.1 > > > > - "IP-address, or MAC-address" -> > > IP addresses, and MAC addresses. > > > > - It would be good to include a reference to INT and/or IOAM, so > > it's clear what is being discussed. > > > > > > Section 6.2.2 > > > > - "in some NVO3 extension" -> > > in an NVO3 extension > > > > - "This is nice" -> > > This is desirable. > > > > - "we don't need a separate UDP" -> > > we don't need a separate UDP port > > > > > > Section 6.2.3 > > > > - (section header) > > Group Base Policy -> > > Group Based Policy > > > > > > Section 6.3 > > > > - "NICs doing TCP offload" -> > > NICs implementing various TCP offload mechanisms > > > > > > Section 6.4 > > > > - "unnecessarily constrained" -> > > unnecessarily constrain > > > > - design team -> DT > > > > - "total extension header length selected" -> > > total extension header length specified > > > > - "Single Extension size" -> > > The size of an extension header" > > > > - "The maximum length of a single option" -> > > The maximum length of a single extension header > > > > > > Section 6.5 > > > > (Several of the subsections use extension, extension header, > > option, and TLV interchangeably. I have tried to use extension > > header in this section, but other sections also have similar > > issues. Would recommend editor search doc for "extension" and > > "option" and "TLV" and make sure usage is correct/consistent. > > In some cases it makes sense to use TLV, but there is almost no > > case where "option" or "extension" makes sense over "extension > > header".) > > I did some searching and replacing in the document but I probably > didn't change as many instances as you would have. > > > - (section header) > > Extension Ordering -> > > Ordering of Extension Headers > > > > - "one or a few extensions TLVs" > > a subset of the extension headers > > > > - "specific TLV" -> > > specific extension header > > > > - "order of TLVs" -> > > order of extension headers > > > > - "Transit devices doesn't" -> > > Transit devices don't > > > > - "process the options" -> > > process the extension headers > > > > - "they need to process only a small subset of options" -> > > they may need to process only subset of extension headers > > > > > > Section 6.6 > > > > - "bit-field approach" -> > > bit fields approach > > > > - "and support in the control plane such that" -> > > and support via the control plane a method such that > > > > - "they need more effort" -> > > some other method must be used. > > > > - "In a Bit fields" -> > > In a bit fields > > > > - "does a firewall" -> > > implements a firewall > > > > - "that allows different software" -> > > that allow different software modules > > > > - "to handle different options" -> > > to process different options > > > > > > Section 6.7 > > > > (Same issue with extension v extension headers. > > Also look for receiver v target v target NVE. > > Should we be using "egress NVE" per the framework?) > > I changed occurrences of "target" to "target NVE". > > > - "EVPN and others" > > provide reference. > > Added reference to RFC 7432. > > > - "they only care" -> > > it only cares > > > > - "only care about particular extensions" > > only support certain extensions > > The above two changes overlap resulting in > "it only supports certain extensions" > > > - "requested extensions" -> > > supported extensions > > > > - "cares about a few extensions" -> > > "supports only certain extensions" > > > > - "with minimal hardware requirements" -> > > with simplified hardware requirements > > for the target NVE. > > > > - "Note that in this approach" -> > > Note that with this approach > > > > - "enumerate the supported NVO3 extensions and their order" -> > > indicated the supported NVO3 extensions and their order, for > > each of encapsulations supported. > > > > > > Section 6.8 > > > > - Add reference to RFC 8394. > > > > - "Ether type" -> EtherType > > > > > > Section 7 > > > > - Add references to VXLAN and NVGRE docs. > > > > (Also doc uses VxLAN and VXLAN and VxLAN-GPE and VXLAN-GPE. > > Would recommend stick to VXLAN and VXLAN-GPE. Check throughout.) > > > > - "lack of header length" -> > > lack of a header length field > > > > - Another full doc check should be done for > > bit-fields vs bit fields vs Bit-field vs Bit field vs Bit Field. > > Recommend using "bit fields" everywhere. > > > > - "By using Geneve option" -> > > By using Geneve options > > > > - Security extension TLVs -> > > security extension TLVs > > > > - "There are implemented Geneve options today in production" -> > > There are already implementations of Geneve options deployed in > > production networks as of this writing. > > > > - Bullet 8 -- add reference to INT spec. > > I'm not sure how to find such a reference. > > > - "We recommend the following enhancements to Geneve to make it more > > suitable to hardware and yet provide the flexibility for software:" > > Indent and add quotations around following paragraph(s). > > Indenting OK but I think quotes are overkill for a relatively large > amount of text like this. > > > - "The Geneve draft could specify" -> > > The Geneve draft should specify > > > > > > Appendix > > > > - Check terminology usage "tunnel endpoint" vs NVE/egress NVE. > > > > > > On Thu, Jul 1, 2021 at 8:09 AM Bocci, Matthew (Nokia - GB) < > [email protected]> wrote: > >> > >> This email begins a two-week working group last call for > draft-ietf-nvo3-encap-06. > >> > >> > >> > >> Please review the draft and post any comments to the NVO3 working group > list. If you have read the latest version of the draft but have no comments > and believe it is ready for publication as an informational RFC, please > also indicate so to the WG email list. > >> > >> > >> > >> We are also polling for knowledge of any undisclosed IPR that applies > to this document, to ensure that IPR has been disclosed in compliance with > IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > >> > >> If you are listed as an Author or a Contributor of this document, > please respond to this email and indicate whether or not you are aware of > any relevant undisclosed IPR. The Document won't progress without answers > from all the Authors and Contributors. > >> > >> > >> > >> Currently there are no IPR disclosures against this document. > >> > >> > >> > >> If you are not listed as an Author or a Contributor, then please > explicitly respond only if you are aware of any IPR that has not yet been > disclosed in conformance with IETF rules. > >> > >> > >> > >> As a reminder, we are pursuing publication of this document in order to > permanently document the experience of one working group in choosing > between multiple proposed standards track encapsulation drafts. The idea > was that this would provide helpful guidance to others in the community > going forward. > >> > >> > >> > >> This poll will run until Thursday 15th July 2021. > >> > >> > >> > >> Regards > >> > >> > >> > >> Matthew and Sam > >> > >> > >> > >> _______________________________________________ > >> nvo3 mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/nvo3 >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
