Hi Anoop, Thanks for the additional suggestions. I'll update the draft accordingly.
Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] On Thu, Jul 29, 2021 at 3:49 AM Anoop Ghanwani <[email protected]> wrote: > 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
