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
