Re: [bess] [Technical Errata Reported] RFC8365 (7735)
Thanks, Ali.
By the way, 7432bis has expired. Please consider refreshing it.
—John
> On Feb 11, 2024, at 2:49 PM, Ali Sajassi (sajassi) wrote:
>
> Hi John,
> RFC8365 relies heavily on base MPLS-EVPN RFC (i.e., RFC7432/RFC7432bis) and
> assumes the reader is very familiar with RFC7432/7432bis. ESI label as
> described in RFC7432/RFC7432bis is used for split-horizon filtering; however,
> VxLAN-EVPN (RFC8365) doesn’t use split-horizon filtering but instead uses
> local-bias procedure which doesn’t need ESI label. This has already been
> captured in RFC7432bis in section 7.5 (ESI Label Extended Community) that
> says:” The ESI label value MAY be zero if no split-horizon filtering
> procedures are required …”
> So, I don’t think we need to repeat that in RFC8365 because whatever changes
> needed to RFC7432/7432bis, has been explicitly captured in this RFC8365 and
> if it is not covered, then it is assumed applicability of RFC7432bis
> including RED field setting in ESI Label Extended Community.
> Regards,
> Ali
> From: John Scudder
> Date: Friday, February 9, 2024 at 1:18 PM
> To: bess@ietf.org
> Cc: Ali Sajassi (sajassi) , nabil.bi...@nokia.com
> , rshek...@juniper.net ,
> wim.henderi...@nokia.com , Alvaro Retana
> , Andrew Alston - IETF ,
> matthew.bo...@nokia.com , slitkows.i...@gmail.com
> , Jeffrey (Zhaohui) Zhang ,
> Gaurav Sinha , Jim Uttaro , John Drake
>
> Subject: Re: [Technical Errata Reported] RFC8365 (7735)
> Hi All,
>
> I started to look at this and pretty quickly got lost in a maze of twisty
> passages. RFC 8365 doesn’t mention the "ESI Label" Extended Community at all,
> I suppose it gets dragged in through the reliance on RFC 7432 as an
> underlying mechanism. Since the erratum proposes a new requirement ("The "ESI
> Label" field, in the "ESI Label" Extended Community, is set to all zeros in
> case of VxLAN encapsulation”) I think the most it can be verified as is Hold
> For Document update. Soliciting feedback.
>
> —John
>
> > On Dec 19, 2023, at 4:32 AM, RFC Errata System
> > wrote:
> >
> > The following errata report has been submitted for RFC8365,
> > "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)".
> >
> > --
> > You may review the report below and at:
> > https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7735__;!!NEt6yMaO-gk!DJ230uma4G4hxiFjp6qUOeiX8H6oLKgKOaS-1Tm7La77-DewSFRo0SzansDz_hUnOG9xGOaicVISO8JHw_lvGQ$
> >
> > --
> > Type: Technical
> > Reported by: Gaurav Sinha
> >
> > Section: 8.3.1
> >
> > Original Text
> > -
> > Since VXLAN and NVGRE encapsulations do not include the ESI label, other
> > means of performing the split-horizon filtering function must be devised
> > for these encapsulations.
> >
> > Corrected Text
> > --
> > The "ESI Label" field, in the "ESI Label" Extended Community, is set to all
> > zeros in case of VxLAN encapsulation.
> > Since even though the VXLAN and NVGRE encapsulations send the "ESI Label"
> > Extended Community, yet they do not set the "ESI label" field in it.
> > Therefore, other means of performing the split-horizon filtering function
> > must be devised for these encapsulations.
> >
> > Notes
> > -
> > It should be mentioned somewhere in this RFC document that the "ESI Label"
> > Extended Community is sent with VxLAN encapsulation too, just like it is
> > used with MPLS, but with the "MPLS Label" field set to all zeros in case of
> > VxLAN.
> >
> > Otherwise, it gives rise to the unanswered question in mind, about the
> > value of that field, given that there are no labels in VxLAN.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". (If it is spam, it
> > will be removed shortly by the RFC Production Center.) Please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > will log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC8365 (draft-ietf-bess-evpn-overlay-12)
> > --
> > Title : A Network Virtualization Overlay Solution Using
> > Ethernet VPN (EVPN)
> > Publication Date: March 2018
> > Author(s) : A. Sajassi, Ed., J. Drake, Ed., N. Bitar, R. Shekhar,
> > J. Uttaro, W. Henderickx
> > Category: PROPOSED STANDARD
> > Source : BGP Enabled ServiceS
> > Area: Routing
> > Stream : IETF
> > Verifying Party : IESG
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
Re: [bess] [Technical Errata Reported] RFC8365 (7735)
Hi John,
RFC8365 relies heavily on base MPLS-EVPN RFC (i.e., RFC7432/RFC7432bis) and
assumes the reader is very familiar with RFC7432/7432bis. ESI label as
described in RFC7432/RFC7432bis is used for split-horizon filtering; however,
VxLAN-EVPN (RFC8365) doesn’t use split-horizon filtering but instead uses
local-bias procedure which doesn’t need ESI label. This has already been
captured in RFC7432bis in section 7.5 (ESI Label Extended Community) that
says:” The ESI label value MAY be zero if no split-horizon filtering procedures
are required …”
So, I don’t think we need to repeat that in RFC8365 because whatever changes
needed to RFC7432/7432bis, has been explicitly captured in this RFC8365 and if
it is not covered, then it is assumed applicability of RFC7432bis including RED
field setting in ESI Label Extended Community.
Regards,
Ali
From: John Scudder
Date: Friday, February 9, 2024 at 1:18 PM
To: bess@ietf.org
Cc: Ali Sajassi (sajassi) , nabil.bi...@nokia.com
, rshek...@juniper.net ,
wim.henderi...@nokia.com , Alvaro Retana
, Andrew Alston - IETF ,
matthew.bo...@nokia.com , slitkows.i...@gmail.com
, Jeffrey (Zhaohui) Zhang , Gaurav
Sinha , Jim Uttaro , John Drake
Subject: Re: [Technical Errata Reported] RFC8365 (7735)
Hi All,
I started to look at this and pretty quickly got lost in a maze of twisty
passages. RFC 8365 doesn’t mention the "ESI Label" Extended Community at all, I
suppose it gets dragged in through the reliance on RFC 7432 as an underlying
mechanism. Since the erratum proposes a new requirement ("The "ESI Label"
field, in the "ESI Label" Extended Community, is set to all zeros in case of
VxLAN encapsulation”) I think the most it can be verified as is Hold For
Document update. Soliciting feedback.
—John
> On Dec 19, 2023, at 4:32 AM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC8365,
> "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)".
>
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7735__;!!NEt6yMaO-gk!DJ230uma4G4hxiFjp6qUOeiX8H6oLKgKOaS-1Tm7La77-DewSFRo0SzansDz_hUnOG9xGOaicVISO8JHw_lvGQ$
>
> --
> Type: Technical
> Reported by: Gaurav Sinha
>
> Section: 8.3.1
>
> Original Text
> -
> Since VXLAN and NVGRE encapsulations do not include the ESI label, other
> means of performing the split-horizon filtering function must be devised for
> these encapsulations.
>
> Corrected Text
> --
> The "ESI Label" field, in the "ESI Label" Extended Community, is set to all
> zeros in case of VxLAN encapsulation.
> Since even though the VXLAN and NVGRE encapsulations send the "ESI Label"
> Extended Community, yet they do not set the "ESI label" field in it.
> Therefore, other means of performing the split-horizon filtering function
> must be devised for these encapsulations.
>
> Notes
> -
> It should be mentioned somewhere in this RFC document that the "ESI Label"
> Extended Community is sent with VxLAN encapsulation too, just like it is used
> with MPLS, but with the "MPLS Label" field set to all zeros in case of VxLAN.
>
> Otherwise, it gives rise to the unanswered question in mind, about the value
> of that field, given that there are no labels in VxLAN.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --
> RFC8365 (draft-ietf-bess-evpn-overlay-12)
> --
> Title : A Network Virtualization Overlay Solution Using
> Ethernet VPN (EVPN)
> Publication Date: March 2018
> Author(s) : A. Sajassi, Ed., J. Drake, Ed., N. Bitar, R. Shekhar,
> J. Uttaro, W. Henderickx
> Category: PROPOSED STANDARD
> Source : BGP Enabled ServiceS
> Area: Routing
> Stream : IETF
> Verifying Party : IESG
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
Re: [bess] [Technical Errata Reported] RFC8365 (7735)
Hi All,
I started to look at this and pretty quickly got lost in a maze of twisty
passages. RFC 8365 doesn’t mention the "ESI Label" Extended Community at all, I
suppose it gets dragged in through the reliance on RFC 7432 as an underlying
mechanism. Since the erratum proposes a new requirement ("The "ESI Label"
field, in the "ESI Label" Extended Community, is set to all zeros in case of
VxLAN encapsulation”) I think the most it can be verified as is Hold For
Document update. Soliciting feedback.
—John
> On Dec 19, 2023, at 4:32 AM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC8365,
> "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)".
>
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7735__;!!NEt6yMaO-gk!DJ230uma4G4hxiFjp6qUOeiX8H6oLKgKOaS-1Tm7La77-DewSFRo0SzansDz_hUnOG9xGOaicVISO8JHw_lvGQ$
>
> --
> Type: Technical
> Reported by: Gaurav Sinha
>
> Section: 8.3.1
>
> Original Text
> -
> Since VXLAN and NVGRE encapsulations do not include the ESI label, other
> means of performing the split-horizon filtering function must be devised for
> these encapsulations.
>
> Corrected Text
> --
> The "ESI Label" field, in the "ESI Label" Extended Community, is set to all
> zeros in case of VxLAN encapsulation.
> Since even though the VXLAN and NVGRE encapsulations send the "ESI Label"
> Extended Community, yet they do not set the "ESI label" field in it.
> Therefore, other means of performing the split-horizon filtering function
> must be devised for these encapsulations.
>
> Notes
> -
> It should be mentioned somewhere in this RFC document that the "ESI Label"
> Extended Community is sent with VxLAN encapsulation too, just like it is used
> with MPLS, but with the "MPLS Label" field set to all zeros in case of VxLAN.
>
> Otherwise, it gives rise to the unanswered question in mind, about the value
> of that field, given that there are no labels in VxLAN.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --
> RFC8365 (draft-ietf-bess-evpn-overlay-12)
> --
> Title : A Network Virtualization Overlay Solution Using
> Ethernet VPN (EVPN)
> Publication Date: March 2018
> Author(s) : A. Sajassi, Ed., J. Drake, Ed., N. Bitar, R. Shekhar,
> J. Uttaro, W. Henderickx
> Category: PROPOSED STANDARD
> Source : BGP Enabled ServiceS
> Area: Routing
> Stream : IETF
> Verifying Party : IESG
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
Re: [bess] [Technical Errata Reported] RFC8365 (7735)
Hi John,
RFC8365 relies heavily on base MPLS-EVPN RFC (i.e., RFC7432/RFC7432bis) and
assumes the reader is very familiar with RFC7432/7432bis. ESI label as
described in RFC7432/RFC7432bis is used for split-horizon filtering; however,
VxLAN-EVPN (RFC8365) doesn’t use split-horizon filtering but instead uses
local-bias procedure which doesn’t need ESI label. This has already been
captured in RFC7432bis in section 7.5 (ESI Label Extended Community) that
says:” The ESI label value MAY be zero if no split-horizon filtering procedures
are required …”
So, I don’t think we need to repeat that in RFC8365 because whatever changes
needed to RFC7432/7432bis, has been explicitly captured in this RFC8365 and if
it is not covered, then it is assumed applicability of RFC7432bis including RED
field setting in ESI Label Extended Community.
Regards,
Ali
From: John Scudder
Date: Friday, February 9, 2024 at 1:18 PM
To: bess@ietf.org
Cc: Ali Sajassi (sajassi) , nabil.bi...@nokia.com
, rshek...@juniper.net ,
wim.henderi...@nokia.com , Alvaro Retana
, Andrew Alston - IETF ,
matthew.bo...@nokia.com , slitkows.i...@gmail.com
, Jeffrey (Zhaohui) Zhang , Gaurav
Sinha , Jim Uttaro , John Drake
Subject: Re: [Technical Errata Reported] RFC8365 (7735)
Hi All,
I started to look at this and pretty quickly got lost in a maze of twisty
passages. RFC 8365 doesn’t mention the "ESI Label" Extended Community at all, I
suppose it gets dragged in through the reliance on RFC 7432 as an underlying
mechanism. Since the erratum proposes a new requirement ("The "ESI Label"
field, in the "ESI Label" Extended Community, is set to all zeros in case of
VxLAN encapsulation”) I think the most it can be verified as is Hold For
Document update. Soliciting feedback.
—John
> On Dec 19, 2023, at 4:32 AM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC8365,
> "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)".
>
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7735__;!!NEt6yMaO-gk!DJ230uma4G4hxiFjp6qUOeiX8H6oLKgKOaS-1Tm7La77-DewSFRo0SzansDz_hUnOG9xGOaicVISO8JHw_lvGQ$
>
> --
> Type: Technical
> Reported by: Gaurav Sinha
>
> Section: 8.3.1
>
> Original Text
> -
> Since VXLAN and NVGRE encapsulations do not include the ESI label, other
> means of performing the split-horizon filtering function must be devised for
> these encapsulations.
>
> Corrected Text
> --
> The "ESI Label" field, in the "ESI Label" Extended Community, is set to all
> zeros in case of VxLAN encapsulation.
> Since even though the VXLAN and NVGRE encapsulations send the "ESI Label"
> Extended Community, yet they do not set the "ESI label" field in it.
> Therefore, other means of performing the split-horizon filtering function
> must be devised for these encapsulations.
>
> Notes
> -
> It should be mentioned somewhere in this RFC document that the "ESI Label"
> Extended Community is sent with VxLAN encapsulation too, just like it is used
> with MPLS, but with the "MPLS Label" field set to all zeros in case of VxLAN.
>
> Otherwise, it gives rise to the unanswered question in mind, about the value
> of that field, given that there are no labels in VxLAN.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --
> RFC8365 (draft-ietf-bess-evpn-overlay-12)
> --
> Title : A Network Virtualization Overlay Solution Using
> Ethernet VPN (EVPN)
> Publication Date: March 2018
> Author(s) : A. Sajassi, Ed., J. Drake, Ed., N. Bitar, R. Shekhar,
> J. Uttaro, W. Henderickx
> Category: PROPOSED STANDARD
> Source : BGP Enabled ServiceS
> Area: Routing
> Stream : IETF
> Verifying Party : IESG
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
