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. 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".) - (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?) - "EVPN and others" provide reference. - "they only care" -> it only cares - "only care about particular extensions" only support 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. - "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). - "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
