Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon

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.rabadan@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 <hayabusagsm@gmail.com>
> *Date: *Tuesday, February 15, 2022 at 8:37 PM
> *To: *Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.rabadan@nokia.com>
> *Cc: *Anoop Ghanwani <anoop@alumni.duke.edu>, BESS <bess@ietf.org>,
> bess-chairs@ietf.org <bess-chairs@ietf.org>,
> draft-ietf-bess-evpn-mh-split-horizon@ietf.org <
> draft-ietf-bess-evpn-mh-split-horizon@ietf.org>, slitkows.ietf@gmail.com <
> slitkows.ietf@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 <hayabusagsm@gmail.com> wrote:
>
>
>
> I support publication.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Sat, Feb 5, 2022 at 1:41 AM Rabadan, Jorge (Nokia - US/Sunnyvale) <
> jorge.rabadan@nokia.com> wrote:
>
> Thank you Anoop. We will fix those in the next version.
>
> Jorge
>
>
>
> *From: *Anoop Ghanwani <anoop@alumni.duke.edu>
> *Date: *Saturday, February 5, 2022 at 12:19 AM
> *To: *slitkows.ietf@gmail.com <slitkows.ietf@gmail.com>
> *Cc: *BESS <bess@ietf.org>, draft-ietf-bess-evpn-mh-split-horizon@ietf.org
> <draft-ietf-bess-evpn-mh-split-horizon@ietf.org>, bess-chairs@ietf.org <
> bess-chairs@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.ietf@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.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*