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

[Gyan Mishra <[e-mail]>]

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]> 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]>
> *Date: *Tuesday, 15 September 2026 at 03:26
> *To: *[e-mail] <[e-mail]>
> *Cc: *BESS <[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]
> *Cc:* BESS <[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]
> To unsubscribe send an email to [e-mail]
>