Pablo, Lots of thanks for a prompt and detailed response. >From my POV the marked text should appear at the beginning of Section 4 of >RFC8986 to avoid any misinterpretations by the developers.
I have noticed that Section 8.1 of RFC 9352<https://datatracker.ietf.org/doc/html/rfc9352#section-8.1> already provides a way to differentiated between "basic" and "protected" behaviors of the Sv6 SID with End.X behavior. IMHO and FWIW RFC 9252 should be augmented with a similar mechanism specifying whether a Service SID with specific endpoint behavior is - or is not - eligible for fast reroute. This can be done, e.g., by defining a No Reroute flag in the Service SID Flags field of the SRv6 SID Information Sub-TLV. Regards,, and, again, lots of thanks, Sasha From: Pablo Camarillo (pcamaril) <[email protected]> Sent: Tuesday, September 29, 2026 7:45 PM To: Alexander Vainshtein <[email protected]>; [email protected] Cc: BESS <[email protected]> Subject: [EXTERNAL] Re: Usage of End.DX2 SID in EVPN-VPWS 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 [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.TtrtXLaBH32wl4osMeTldAVPaGzH5nYNwU7vM085vpdswQPc4BSCJR1McBC-LbfjmPkwqbLckAeIp1vpgoYbGHPpWQUz1eQ5PeKf-3fL6Dr3o9twFXqhvzvNHnEleUYohU2G0DkvVLhXVBEKFEMN35VNFuJpRBSX6ow3wByF0w8XBeQKP-xHvXOIuJb_Uq3cIxjPOBPN-7zG_G5Hlgma-tYyuhrIH-GoNL3LVSMATVezR2cp1SVTWAQNYGJb5st4Mantto_yP4oReJY6GFVCL9-dvLFPov4z-2lZB9HnRpdkW_qrP77OHjKum8nxq3VTrtKhDWdTl-96rPv07XRPtQ.bpjQnn52uxDvgI75.usbLGxun6ar_MrFlcEaAOrsTVzK8N9PpUdPIYxSqjl3MBOkRMOZ8ihQ67VPLTJjg8UncMx0a8Xsq1i-sPtw_E5KfK4jtht3fz_DnKV9Y4nUNsU6VaKBWS5_AYYHNM2xyThH3LQcl4gAtJMU_l207wtue1OZofy5CnY0Jr7SgONKQfKcYTdO3VhJ7hsgnXapbGsHCiSrGnpVIm4BhFUZ0CzYLpUANj3iYLrgjljmrwLpziO8JyxNkBTvap3IRygn7MCyPoVj4IzLGfva8xgDs3ouD9T0ibLYpUDkJUE-3UQroAyoxVWupHo5Opv-WHu3wLcjkS1t9wzbvF94IaE6nXLeXelkw-4d2xxtJIzxd234MFp0TZek9BEOw9_sSMcIblWF1q8q-f4sCYKURtEAluEmw_FSad8K3FFJjM6bG4N8L9bgUew1csZdVX5SfkSW-ljNrJRrS_3hD84ytZ9hB2FWSgEDC-nYTALEyr7bxV0-7H4dKHdDfhnU24F4GaZ0fKYHDGhGYQRlZ7A1OIopCytZxyT1pdMGY440_Ae4zpHE6VKBZECBtyReuRv724dUPMS1PQcMDzuI_fq4zjVHLAN7T-sPUnn8AvJnMcpwufys8fDdvHmyzjXeoWU270VbP53LMDC_WZiIcChJAz2w_EOtxlYhubrCa1sD2jNKCoH-itTttq4NVuAVy_wQhDP2d0HlOFTcOxOrhqW0cEejjoDSrBS7_PpXOJWmXu8cy8VX_r7xgNGkUdIDOMJtSJHyB0Nb-P9ytg5Te56pyZo8DD00vXUioo0v2TvFHa1bkBathFodTEm7LsR_Wg9JPXffBU-T44CoviRbtGrE.AlKTlp3s4cmVGVqpZvewnw%26redirect_uri%3Dhttps%3A%2F%2Freport.mimecastcybergraph.com%2Fcallback> CGBANNERINDICATOR 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]> Date: Tuesday, 15 September 2026 at 03:26 To: [email protected] <[email protected]> Cc: BESS <[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] Cc: BESS <[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.
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
