Luc, Jorge and all,
My apologies for a much-delayed response.
I have re-read the latest version of the draft, and I would like to clarify a
few points:
1. How are Arg. FR2 values allocated?
* For the reference, Arg.FE2 values for Split Horizon are allocated per
MH ES
* It seems that one Arg.FR2 value per PE should suffice – is this
correct? If so, any non-zero value should suffice
2. RFC 9252<https://www.rfc-editor.org/info/rfc9252/> imposes limitations on
advertisement of multiple SIDs in the same route:
* Section 7 says that if multiple instances of L2 service TLV appear in
the BGP Prefix SID, all but the first instance MUST be ignored. The same
limitation also applies to multiple L3 Service TLV instances
* The last para of section 3,1 says that if multiple instances of SID
Information sub-TLV is present in the L2/L3 Service TLV, the first instance of
this sub-TLV SHOULD be used, and this limitation MAY be overridden by a local
policy of the receiver.
* With these limitations in mind, it seems that the only way the EVPN
FRR SID can be advertised in an interoperable way: Include two SID Information
Sub-TLVs in the L2 Service TLV in the BGP Prefix SID of the per-EVI Ethernet
A-D route
i. The first
one will describe an SID with standard End.DT2U (or End.DX2) behavior and will
advertise it with AL=0. This SID will be recognized by all mate PEs
ii. The 2nd
one will advertise SID with End.DT2U.Reroute (or End.DX2.Reroute) behavior, the
same SID structure as the 1st one but with AL≠0 and the same LOC:FUNC as the
first one. This SID will be ignored by receives that do not support EVPN FRR
and will be used by the receivers that support it
Does the above make sense to you?
Regards,
Sasha
From: Luc André Burdet <[email protected]>
Sent: Monday, October 5, 2026 11:34 PM
To: Jorge Rabadan (Nokia) <[email protected]>; Alexander Vainshtein
<[email protected]>; Gyan Mishra <[email protected]>
Cc: [email protected]; BESS <[email protected]>; Pablo Camarillo (pcamaril)
<[email protected]>
Subject: Re: [EXTERNAL] Re: [bess] Re: Usage of End.DX2 SID in EVPN-VPWS
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 we
[Image removed by
sender.]<https://report.mimecastcybergraph.com/?magiclink=https%3A%2F%2Fapi.services.mimecast.com%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3Do20nRkVXf7VUVnANkXhoOwGytEwGN0YAlyeDJn7oBTGNl2kN%26state%3DeyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMjU2R0NNIn0.RTUtnWmrsmLWGf-Ii5sx7LCy7G7lWbmNzooOwrCNSCd4oogIk4u7cA-i6EBFHjwctA8f7tqPo4Gwv-uOUmmE0dhGzjWovkUy_gIEfZvW_8TfzdaXvMNJkcdRyftMbEvwMpFohpMf1ownRmTn1GCl0aGTlNxexsQ7xxheFQE_mtkNHKGGTB00eZ3qNqx0P3GkV98Wm2I1rUK57Iytx7WGVYYwROJ54pemsD60lSeRph0Yoqp_5wPcMWTEU-WuNol7wDuZ1hj4J_ja10sJc1P5ILfiRb-XPCuIPb7kqkzWKufZeDnO_QvKn9IvwmOQhl1V_4qa_2f_AXhTugmFle7m0A.4CwBUHp6-XlEXhCL.zCcx4GA7X2b0jN6_DtxoThQ4CMVNXk6N5F8_fkSdiSTi19TVl8Mz4NWnSTjNERRCExsPZ5QRhS3TZ6QaMTz0rRI3d8SwcNboc9QLL9mDC9FRsZukKz0qhgANwjEDQ2Tqdcqp5wgSEHpQiqfQxjkTwhJASMet3s4uKitUkG8ywZssI_KjKE0feQ3Kx8lJ_TMWGjGLe0mgUdiJlif_-V_7hrrkefgz_ogb4LdL3F8yyT_FPNeVxEyz3c-c0DBvsxSNt69ddnxmT2yUaGpMtUsE7ZYXNcbVTLQnlRTLLRCCzMlq0A2cGLcL5HKHO2SncVi62gMsKnRqFAy533t_ttwynwzk0QaNCpgpzdsaQ5gv4HbLnemczpcKruQdDRWqZiN3qWhfOjw5VUwo2YcLrv2fZOh4v9DTbXgcKfMDobQLtJhbOG9Z8Ii9WiGnkUfTINmjwdUEedRcFnGQ7Vyn_0xnnVdPY5kN3-bwiPBX_1GdMB0DZavO76bI19VEaz4Sos5CN9iODW5QCw6gMWoR7ZVt9T0pCQzZbiQmaa7nVJuhAp891du3sFIcx-k-vdRc4RSIcwuxTbNFU4ubqDwOtLQFBKXZEJmDSWLgsnSJhAuvBErjyAfB_Z2P-SObYuYkKbamLPSxX40BxC_jgxdsm7LPBN9y8KRaH9AnrdyOMxl8d2UHn_3qJdMPenb7ZfaBLJbk3RurgAavmLa7FOHer8UANcH-4AeKXyj_V0azUUoAubhJwme9-YbER2gwwIl-V17mMt2OC6vWcwxKYMBVZ5-tmnr4s-FX26Iavj0FumAylEksL4r6CUkowdbKfGU43l3VSi00ylYg_mBfkf_kW074IsCgwyPUfQX7.NQKFpPNJQNShzsZdqVNj-Q%26redirect_uri%3Dhttps%3A%2F%2Freport.mimecastcybergraph.com%2Fcallback>
CGBANNERINDICATOR
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 | [email protected] | Tel: +1 613 254 4814
From: Jorge Rabadan (Nokia) <[email protected]>
Date: Thursday, October 1, 2026 at 04:08
To: Alexander Vainshtein <[email protected]>; Gyan
Mishra <[email protected]>
Cc: [email protected] <[email protected]>; BESS <[email protected]>; Pablo Camarillo
(pcamaril) <[email protected]>; Luc André Burdet <[email protected]>
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 <[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]
