Hi Jorge & Authors I support publication of this document and have a few comments that I think will help clarify and improve the document.
The specification is clear on the solution with two new flags to indicate SHT type ESI or Local Bias for NVO use cases. Table 1 lists different tunnel encapsulations. What I did notice is that VXLAN GPE is not included which should be. https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe Also I noticed that RFC 7510 MPLSoUDP is included and that is an NVO tunnel and is not listed in RFC 8365 which does have VXLAN GPE. IANA codepoints table Value Name ----- ------------------------ 8 VXLAN Encapsulation 9 NVGRE Encapsulation 10 MPLS Encapsulation 11 MPLS in GRE Encapsulation 12 VXLAN GPE Encapsulation RFC 7510 MPLSoUDP is a not an NVO tunnel and is used for special use cases for UDP based ECMP or LAG. As well MPLS listed is transport technology and not NVO tunnels which MPLS based EVPN for NG L2 VPN RFC 7432 utilizes ESI label natively by default for PE-CE AC MPLS based underlay and is not an an NVO overlay. As well SRv6 listed is a transport technology and not NVO tunnels which uses MPLS based EVPN equivalent SRv6 L2 service SID TLV is encoded in BGP Prefix SID attribute per SRv6 BGP based services draft and utilizes ESI label natively by default for PE-CE AC MPLS based underlay and is not an an NVO overlay. MPLS and SRv6 should be in a separate table maybe as it’s not an an NVO tunnel or maybe mention that it’s a transport and can take advantage of SHT flag. I agree that SRv6 and MPLS transports should be included so they can take advantage of the SHT flag. The verbiage MPLS based NVO tunnel is clear and that would be in the NVO tunnel table be MPLSoGRE RFC 4023 and all other NVO tunnels are Non MPLS based. Many Thanks Gyan On Thu, Feb 10, 2022 at 4:10 PM Gyan Mishra <hayabusa...@gmail.com> wrote: > > I support publication. > > Thanks > > Gyan > > On Sat, Feb 5, 2022 at 1:41 AM Rabadan, Jorge (Nokia - US/Sunnyvale) < > jorge.raba...@nokia.com> wrote: > >> Thank you Anoop. We will fix those in the next version. >> >> Jorge >> >> >> >> *From: *Anoop Ghanwani <an...@alumni.duke.edu> >> *Date: *Saturday, February 5, 2022 at 12:19 AM >> *To: *slitkows.i...@gmail.com <slitkows.i...@gmail.com> >> *Cc: *BESS <bess@ietf.org>, >> draft-ietf-bess-evpn-mh-split-hori...@ietf.org < >> draft-ietf-bess-evpn-mh-split-hori...@ietf.org>, bess-cha...@ietf.org < >> bess-cha...@ietf.org> >> *Subject: *Re: [bess] WGLC, IPR and implementation poll for >> draft-ietf-bess-evpn-mh-split-horizon >> >> I support the publication of the draft as an RFC. >> >> >> >> Below are some minor editorial comments. >> >> >> >> Anoop >> >> >> >> == >> >> >> >> Multiple sections >> >> >> >> Probably better to replace all uses of Ethernet Segment with ES rather >> than use them at random. >> >> >> >> Section 1 >> >> >> >> Expand first use of "SID". >> >> >> will keeo following >> -> >> will keep following >> >> >> >> Section 2.2 >> >> >> A value of 01 >> indicates the intend to use >> -> >> A value of 01 >> indicates the intent to use >> >> >> A value of 10 indicates the intend to >> use >> -> >> A value of 10 indicates the intent to >> use >> >> >> >> On Wed, Jan 26, 2022 at 1:50 AM <slitkows.i...@gmail.com> wrote: >> >> Hello Working Group, >> >> >> >> This email starts a two weeks Working Group Last Call on >> draft-ietf-bess-evpn-mh-split-horizon [1]. >> >> >> >> This poll runs until *the 9th of Feb*. >> >> >> >> 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. >> >> >> >> There is no IPR currently disclosed. >> >> >> >> 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. >> >> >> >> We are also polling for any existing implementation as per [2]. >> >> >> >> Thank you, >> >> Stephane & Matthew >> >> >> >> [1] >> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-split-horizon/ >> >> [2] >> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw >> >> >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
