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

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 4 Feb 2022 15:18:57 -0800

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: "Rabadan, Jorge (Nokia - US/Sunnyvale)" <[email-masked]>
Date: Sat, 5 Feb 2022 06:41:17 +0000

Thank you Anoop. We will fix those in the next version.
Jorge

From: Anoop Ghanwani <[email-masked]>
Date: Saturday, February 5, 2022 at 12:19 AM
To: [email-masked] <[email-masked]>
Cc: BESS <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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.

Anoop

==

Multiple sections

Probably better to replace all uses of Ethernet Segment with ES rather than use them at random.

Section 1

will keeo following
->
will keep following

Section 2.2

A value of 01

On Wed, Jan 26, 2022 at 1:50 AM <[email-masked]<mailto:[email-masked]>> wrote:

Hello Working Group,

This email starts a two weeks Working Group Last Call on draft-ietf-bess-evpn-mh-split-horizon [1].

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.

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.

    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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 10 Feb 2022 16:10:54 -0500

I support publication.

Thanks

Gyan

On Sat, Feb 5, 2022 at 1:41 AM Rabadan, Jorge (Nokia - US/Sunnyvale) <
[email-masked]> wrote:

> *From: *Anoop Ghanwani <[email-masked]>
> *Date: *Saturday, February 5, 2022 at 12:19 AM
> *To: [email-masked] <[email-masked]>
> *Cc: *BESS <[email-masked]>, [email-masked]
> <[email-masked]>, [email-masked] <
> [email-masked]>
> *Subject: *Re: [bess] WGLC, IPR and implementation poll for
> draft-ietf-bess-evpn-mh-split-horizon
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Lizhenbin <[email-masked]>
Date: Fri, 11 Feb 2022 12:12:45 +0000

Hi All,
I support the publication.

Best Regards,
Zhenbin (Robin)

________________________________

李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: [email-masked]

发件人：slitkows.ietf <[email-masked]>
收件人：bess <[email-masked]>;draft-ietf-bess-evpn-mh-split-horizon <[email-masked]>
抄 送：bess-chairs <[email-masked]>
时 间：2022-01-26 17:50:33
主 题：[bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon

Hello Working Group,

    Thank you,

    Stephane & Matthew

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 11 Feb 2022 12:19:46 +0000

Support

Thanks,
              Jim Uttaro

From: BESS <[email-masked]> On Behalf Of Lizhenbin
Sent: Friday, February 11, 2022 7:13 AM
To: slitkows.ietf <[email-masked]>; bess <[email-masked]>; draft-ietf-bess-evpn-mh-split-horizon <[email-masked]>
Cc: bess-chairs <[email-masked]>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon

Hi All,

Best Regards,
Zhenbin (Robin)

李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: [email-masked]<mailto:[email-masked]>
发件人：slitkows.ietf <[email-masked]<mailto:[email-masked]>>
收件人：bess <[email-masked]<mailto:[email-masked]>>;draft-ietf-bess-evpn-mh-split-horizon <[email-masked]<mailto:[email-masked]>>
抄 送：bess-chairs <[email-masked]<mailto:[email-masked]>>
时 间：2022-01-26 17:50:33
主 题：[bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon

Hello Working Group,

    Thank you,

    Stephane & Matthew

    [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-split-horizon/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-split-horizon/__;!!BhdT!2X1n5F-7A5CbBVjcLQ7YltoO7bFQw9Gwc40Q5yvd-VAU7cbtOysuYLyDdU0$>

    [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!!BhdT!2X1n5F-7A5CbBVjcLQ7YltoO7bFQw9Gwc40Q5yvd-VAU7cbtOysuSvxwdVk$>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 15 Feb 2022 14:37:30 -0500

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 <[email-masked]> wrote:

>> *Cc: *BESS <[email-masked]>,
>> [email-masked] <
>> [email-masked]>, [email-masked] <
>> [email-masked]>

*Gyan Mishra*

*M 301 502-1347*

---

From: "Rabadan, Jorge (Nokia - US/Sunnyvale)" <[email-masked]>
Date: Wed, 16 Feb 2022 11:58:23 +0000

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 <[email-masked]>
Date: Tuesday, February 15, 2022 at 8:37 PM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]>
Cc: Anoop Ghanwani <[email-masked]>, BESS <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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.

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

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 <[email-masked]<mailto:[email-masked]>> wrote:

I support publication.

Thanks

Gyan

On Sat, Feb 5, 2022 at 1:41 AM Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Anoop. We will fix those in the next version.
Jorge

From: Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>
Date: Saturday, February 5, 2022 at 12:19 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: BESS <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
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.

Anoop

==

Multiple sections

Section 1

will keeo following
->
will keep following

Section 2.2

A value of 01

Hello Working Group,

    Thank you,

    Stephane & Matthew

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 16 Feb 2022 19:08:19 -0500

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) <
[email-masked]> wrote:

> 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.
>
>    - 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.
>
>
>
> 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 <[email-masked]>
> *Date: *Tuesday, February 15, 2022 at 8:37 PM
> *To: *Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]>
> *Cc: *Anoop Ghanwani <[email-masked]>, BESS <[email-masked]>,
> [email-masked] <[email-masked]>,
> [email-masked]>, [email-masked] <
> [email-masked]>
> I support publication of this document and have a few comments  thatT I
> 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
>
> *Network Solutions Architect *
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*