[spring] Re: [EXTERNAL] Re: [bess] Re: Usage of End.DX2 SID in EVPN-VPWS

[Luc André Burdet <[e-mail]>]

Hi Jorge, Sasha,

We discussed a flag and concluded it was not the best approach for service-layer protection:

  *
as Jorge says we are defining several behaviours for when an interface goes Down
  *
There was a concern over the ‘MUST be set to 0’ in rfc9252 which we didn’t want to ‘update’. (admittedly a weaker argument).


The proposed use is intentionally different than Arg.FE2 for split-horizon.

This is the goal  - the FRR document defines explicitly the behaviour of Arg.FR2 and how to use it (avoiding a situation like rfc9819 where it needs to be clarified).

I don't think they should be compared: Arg.FE2 and Arg.FR2 are different arguments to different SIDs / Routes ?

Regards,
Luc André

Luc André Burdet |  Cisco  |  [e-mail]  |  Tel: [phone]

From: Jorge Rabadan (Nokia) <[e-mail]>
Date: Thursday, October 1, 2026 at 04:08
To: Alexander Vainshtein <Alexander.Vainshtein=[e-mail]>; Gyan Mishra <[e-mail]>
Cc: [e-mail] <[e-mail]>; BESS <[e-mail]>; Pablo Camarillo (pcamaril) <[e-mail]>; Luc André Burdet <[e-mail]>
Subject: Re: [EXTERNAL] Re: [bess] Re: Usage of End.DX2 SID in EVPN-VPWS

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 <Alexander.Vainshtein=[e-mail]>
Date: Wednesday, September 30, 2026 at 3:42 AM
To: Gyan Mishra <[e-mail]>
Cc: [e-mail] <[e-mail]>; BESS <[e-mail]>; Pablo Camarillo (pcamaril) <[e-mail]>; Luc André Burdet <[e-mail]>; Jorge Rabadan (Nokia) <[e-mail]>
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 <[e-mail]>
Sent: Wednesday, September 30, 2026 6:17 AM
To: Pablo Camarillo (pcamaril) <[e-mail]>
Cc: Alexander Vainshtein <[e-mail]>; [e-mail]; BESS <[e-mail]>
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) <pcamaril=[e-mail]<mailto:[e-mail]>> 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 <Alexander.Vainshtein=[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 15 September 2026 at 03:26
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: BESS <[e-mail]<mailto:[e-mail]>>
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: [e-mail]<mailto:[e-mail]>
Cc: BESS <[e-mail]<mailto:[e-mail]>>
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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>