Hi Jorge I agree that having the classification of all IP tunnel that convey Ethernet Payload not limited to RFC 8365 as NVO tunnels so all inclusive of MPLSoGRE, MPLSoUDP, VXLAN, VXLAN-GPE, GENEVE, NVGRE
So now you would have 2 categories the NVO category above and the transport category which would include SRv6, MPLS and SR-MPLS. Kind Regards Gyan On Wed, Feb 16, 2022 at 11:12 AM Rabadan, Jorge (Nokia - US/Sunnyvale) < jorge.raba...@nokia.com> wrote: > Hi Gyan, > > > > Thank you for your feedback and support. > > > > The document attempts to address all tunnels that can be used in EVPN > Multi-homing PEs. In that respect, we should probably do a better job > defining what those tunnels are. > > The division at the moment is: non-IP MPLS, NVO tunnels, SRv6. > > - Where NVO tunnels are, in general, IP tunnels that can convey an > Ethernet payload – that includes the ones in RFC8365, but not limited to > the ones in RFC8365. > > > > In that sense, we can classify MPLSoGRE, MPLSoUDP, VXLAN, VXLAN-GPE, etc > all as NVO tunnels. > > > > If you agree with the above, we can make the necessary edits to make the > text consistent with that, as part of this WGLC. > > > > Thanks! > > Jorge > > > > *From: *Gyan Mishra <hayabusa...@gmail.com> > *Date: *Tuesday, February 15, 2022 at 8:37 PM > *To: *Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com> > *Cc: *Anoop Ghanwani <an...@alumni.duke.edu>, BESS <bess@ietf.org>, > bess-cha...@ietf.org <bess-cha...@ietf.org>, > draft-ietf-bess-evpn-mh-split-hori...@ietf.org < > draft-ietf-bess-evpn-mh-split-hori...@ietf.org>, slitkows.i...@gmail.com < > slitkows.i...@gmail.com> > *Subject: *Re: [bess] WGLC, IPR and implementation poll for > draft-ietf-bess-evpn-mh-split-horizon > > > > Hi Jorge & Authors > > > > I support publication of this document and have a few comments thatT 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 Architect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > *M 301 502-1347* > > > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *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
