Hi Sasha, Luc can jump in too, but there was a discussion about using a flag or a new behavior.
The decision was to define these new behaviors end.dt2u.reroute and end.dx2.reroute, because the semantics really didn’t match the existing behaviors. It is not only about “NRR” but also other procedures detailed in the draft, such us ignoring local bias, or bypassing non-DF blocking. Thanks. Jorge From: Alexander Vainshtein <[email protected]> Date: Wednesday, September 30, 2026 at 3:42 AM To: Gyan Mishra <[email protected]> Cc: [email protected] <[email protected]>; BESS <[email protected]>; Pablo Camarillo (pcamaril) <[email protected]>; Luc André Burdet <[email protected]>; Jorge Rabadan (Nokia) <[email protected]> Subject: RE: [EXTERNAL] Re: [bess] Re: Usage of End.DX2 SID in EVPN-VPWS CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Gyan, ++ Luc and Jorge. Lots of thanks for your email and for your interest in the subject. I would like to bring to our attention the latest EVPN Fast Reroute draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-fast-reroute-00> that addresses EVPN FRR over both IP/MPLS and SRv6 Underlay.\ In the case of EVPN-SRv6 it introduces new endpoint behaviors that are differentiated from already defined behaviors by using an advertised Argument Arg.FR2 that can be omitted or included in the Service SID depending on its intended usage. Proposed usage of Argument is quite different from the way Argument is used for Split Horizon Filtering in EVPN. IMHO the desired result could be provided in a much simpler way, e.g., by defining a No Reroute (NRR) flag in the Service SID Flags field of the SID Information Sub-TLV for SID with End.DX2 behavior. I will provide a detailed definition of my proposal in another email. Regards, Sasha From: Gyan Mishra <[email protected]> Sent: Wednesday, September 30, 2026 6:17 AM To: Pablo Camarillo (pcamaril) <[email protected]> Cc: Alexander Vainshtein <[email protected]>; [email protected]; BESS <[email protected]> Subject: [EXTERNAL] Re: [bess] Re: Usage of End.DX2 SID in EVPN-VPWS Hi Sasha I have read through the thread and agree with Pablo that RFC 8986 specifies the SRv6 data plane and all endpoint behaviors and related pseudocode for each type of endpoint processing. From a L2 VPN control plane perspective all route types and functionality defined in RFC 7432bis update rem Hi Sasha I have read through the thread and agree with Pablo that RFC 8986 specifies the SRv6 data plane and all endpoint behaviors and related pseudocode for each type of endpoint processing. From a L2 VPN control plane perspective all route types and functionality defined in RFC 7432bis update remain applicable and encoded in the data plane per RFC 9252 BGP overlay services for SRv6 and RFC 9819 specifying the ARG field Arg.FE2 signaling over SRv6 data plane for ESI filtering. All FRR mechanisms from other L2 EVPN specification as well as TI-LFA FRR are all addressed in those specifications relevant to SRv6. Kind Regards Gyan On Tue, Sep 29, 2026 at 12:46 PM Pablo Camarillo (pcamaril) <[email protected]<mailto:[email protected]>> wrote: Hi Sasha, RFC 8986 specifies the fundamental data-plane pseudocode/primitive endpoint behaviors under nominal operation where the SID and outgoing interface I are active and valid. Interface Failure and Protection: RFC 8986 intentionally does not embed protection, fast reroute (FRR), or multi-homing state machines into the base endpoint definition. Instead, interface failure handling and protection mechanisms are governed by the relevant service layer and fast-convergence specifications (such as EVPN multi-homing in RFC 9252 / BESS SRv6 EVPN and TI-LFA / Egress Protection frameworks). Rerouting / Backup Encapsulation: In an EVPN VPWS or multi-homed active-standby/all-active scenario where interface I fails, an implementation that supports local egress protection / bypass may pre-program a backup path in the FIB. When I goes down, the node can encapsulate the decapsulated Ethernet frame into an SRv6 policy toward the backup PE's Service SID (or alternate interface) prior to control-plane reconvergence. This is an application of standard service-layer protection/FRR on top of the base behavior and is fully compliant with the architecture. Hope this clarifies it. Let us know if you have any further questions. Cheers, Pablo. From: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Date: Tuesday, 15 September 2026 at 03:26 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: BESS <[email protected]<mailto:[email protected]>> Subject: [bess] Re: Usage of End.DX2 SID in EVPN-VPWS Hi all, A gentle reminder: I have not received feedback from the SPRING WG on my email sent 3 months ago, The question in this email can be re-formulated differently: Suppose that an SID with endpoint with behavior End. DX2 has been defined and associated with the outgoing interface I. As long as I is operationally UP, packets received with this SID as the Destination IPv6 address in the IPv6 header shall be processed as defined in the standard, i.e.: • IPv6 header and all extension headers will be stripped • The resulting Ethernet frame shall be sent "as is: via I The question: How will packets received with this SID as the Destination IPv6 address in the IPv6 header be processed if I is operationally DOWN? Can we say that such packets MUST be discarded? Regards, and lots of thanks in advance, Sasha From: Alexander Vainshtein Sent: Thursday, June 11, 2026 7:10 PM To: [email protected]<mailto:[email protected]> Cc: BESS <[email protected]<mailto:[email protected]>> Subject: Usage of End.DX2 SID in EVPN-VPWS Importance: High Hi, I have a question about usage of End.DX2 SID (as defined in Section 4.9 of RFC 8986<https://datatracker.ietf.org/doc/html/rfc8986#section-4.9>in EVPN-VPWS. • The definition of this endpoint behavior says that "The End.DX2 SID MUST be the last segment in an SR Policy, and it is associated with one outgoing interface I" • If the upper-layer header type is Ethernet, the IPv6 header and all extension headers are stripped, and the resulting Ethernet frame is forwarded to the outgoing interface I. EVPN-VPWS as defined in RFC 8214 is explicitly mentioned as one of possible applications in this section, and Section 6.1.2 of RFC 9252<https://datatracker.ietf.org/doc/html/rfc9252#section-6.1.2> explicitly mentions End.DX2 as one of possible behaviors of the SID signaled in per-EVI Ethernet A-D routes (along with End.X2V and End.DT2U). I think that End.X2 behavior as defined above is not compatible with one of the advantageous features of EVPN-VPWS as described in the last para of Section 5 of RFC 8214<https://datatracker.ietf.org/doc/html/rfc8214#section-5>: <quote> Finally, EVPN may employ data-plane egress link protection mechanisms not available in VPWS. This can be done by the primary PE (on local AC down) using the label advertised in the per-EVI Ethernet A-D route by the backup PE to encapsulate the traffic and direct it to the backup PE. <end quote> (For the reference, implementing fast egress protection against AC failure in "classic" VPWS has been defined in RFC 8104). What, if anything, did I miss? Do you think that a new Endpoint behavior should be defined? Regards, and lots of thanks in advance, Sasha Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. _______________________________________________ BESS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
