Thanks, Ali.
By the way, 7432bis has expired. Please consider refreshing it.
—John
> On Feb 11, 2024, at 2:49 PM, Ali Sajassi (sajassi) <saja...@cisco.com> 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 <j...@juniper.net>
> Date: Friday, February 9, 2024 at 1:18 PM
> To: bess@ietf.org <bess@ietf.org>
> Cc: Ali Sajassi (sajassi) <saja...@cisco.com>, nabil.bi...@nokia.com
> <nabil.bi...@nokia.com>, rshek...@juniper.net <rshek...@juniper.net>,
> wim.henderi...@nokia.com <wim.henderi...@nokia.com>, Alvaro Retana
> <aretana.i...@gmail.com>, Andrew Alston - IETF <andrew-i...@liquid.tech>,
> matthew.bo...@nokia.com <matthew.bo...@nokia.com>, slitkows.i...@gmail.com
> <slitkows.i...@gmail.com>, Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>,
> Gaurav Sinha <gsi...@juniper.net>, Jim Uttaro <jutt...@si.rr.com>, John Drake
> <je_dr...@yahoo.com>
> 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 <rfc-edi...@rfc-editor.org>
> > 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 <gsi...@juniper.net>
> >
> > 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
