Luc and all, Yet another comment regarding the way SRv6 SID for EVPN FRR for EVPN-VPWS can be signaled.
Figure 4 in Section 7.2.2 proposes advertising two different Service SIDs in the same L2 Service TLV in the BGP Prefix SID attribute. While such advertisement is not prohibited by RFC 9252, it looks somewhat unusual to me. A possible (from my POV) alternative could be advertisement of the SID used for FRR in a new IPv6 Address-specific Extended Community (RFC 5701): * The Lobal Administrator field of this EC 8 octets) would carry the SID itself (which is just an IPv6 address) * The Local Administrator field (2 octets) could carry the codepoint of the associated behavior. What do you think? Regards, Sasha From: Alexander Vainshtein Sent: Monday, July 6, 2026 9:55 AM To: Luc André Burdet <[email protected]> Cc: BESS <[email protected]>; [email protected] Subject: RE: Usage of End.DX2 SID in EVPN-VPWS Importance: High Luk, Lots of thanks for your email and apologies for the delayed response. I have read the SRv6-related section of the EVPN-FRR draft<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-fast-reroute-00.html#name-segment-routing-v6>, and I see the situation somewhat differently from what this draft proposes. From my POV 1. End.DX2 SID behavior as defined in Section 4.9 of RFC 8986<https://datatracker.ietf.org/doc/html/rfc8986#section-4.9> can be used by the "mate" PE that executes FRR as the exact analog of ERL in EVPN-MPLS: the PE that receives SRv6-encapsulated traffic with this SID always strips SRv6 encapsulation and forward the resulting Ethernet frame via its associated AC of a L2 service instance regardless of its status 2. There is no need for any special SID endpoint behavior in the case of "bridging" EVPN because: a. The "remote" PE that sends "known unicast" traffic to one of the "mate" PEs can use SID with End. DT2U b. The "mate" PE that receives traffic encapsulated with such SID strips SRv6 encapsulation and looks the Destination MAC address in the corresponding FDB c. The matching FDB entry could then point to a local AC or can use an SID with End.DX2 behavior advertised by another "mate" PE in the same way ERL is advertised in EVPN-MPLS 3. If we want to support EVPN-VRR for EVPN-VPWS, the "remote" PE should not send any traffic towards a multi-homed ES with the SID that has been advertised with End.DX2 behavior. It should use an SID advertised with a new endpoint behavior (say, End.DX2.Reroute?). Such an SID would be associated with a local AC of an EVPN-VPWS instance and would send decapsulated traffic via this AC is it is UP. Otherwise, the frame should be again encapsulated using an SID with End.DX2 behavior advertised by one of the "mate" PEs and send the resulting packet accordingly. Hopefully, these notes clarify my position on the subject. Regards, Sasha From: Luc André Burdet <[email protected]<mailto:[email protected]>> Sent: Thursday, July 2, 2026 10:07 PM To: Alexander Vainshtein <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: BESS <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL] Re: Usage of End.DX2 SID in EVPN-VPWS Hi Sasha, Do you mean a new Endpoint behaviour for EVPN-VPWS fast egress protection? That's the approach taken here with a new ARGument enabled behaviour : https://www.ietf.org/archive/id/draft-ietf-bess-evpn-fast-reroute-00.html#name-enddx2reroute-enddx2-with-f<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-fast-reroute-00.html#name-enddx2reroute-enddx2-with-f> Regards, Luc André Luc André Burdet [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.AsgBu6dXVYRMbzbuAgHDuucOHdZkBohsgs39CS-5uxSt7vIz1TevzLSVVnOfXQ1x22DK6LRYatq9Q59VCJ-O3sNQW8e1GYMiQ0eib8iNkmO8DDur1eWL_7hzVYKZecTwJDQdSXANy7kuYQy5Dqz4zl6kVic0IHy_hULd-VE77Y5F_vP-EJjoLnqvXazdiZJ4gyFt5KaPK3mtEmjVrQPyJV0pkC5ehGPivzHZ-efJCEsujL0s8qaWhGQ2dNEPeVioqvs1QZJq66AwQPPQTLL-oHNqtIRAKAiSfwb2qqWZWmm2xXzOOn6MDuKyyNe9JhBRS-ZZghhaaQ2rOyIMyR0uHA.rzuWe6awNMD8ydvH.2Qy3p6eBistL6D048YF-DSi1B2rLKhVlNQ_HkZaUi8BFUUQ00XYl5lHYytZ-_CuxiABBJNFNEbvI6yFNv_Jj16uktv7ymqr9Ry6_V4PrOQ5aRsoPYBEt8DneuqAunprDpp9uS2khm_nFZ45MNMEjRrxNPXBLz3Wp3DNUxCUZIrA9b-P24jDTqxGW0U9HAzH7eCyrb0W1vwsIg9NWe4_W8_d5xaQxyOKCwh4rGG7D6EsxZ95ImJWdKI9xg-0ezj3NtIUEpUYKoD6Skv65XpdyQyHiEl-cAG-O5kQnwt6pUrwz2PrDMZ_ckwWf-UV5MPo05yDk0ewuoB2KC5tl7uQv2usptBLHILKfuy6nLP4rrDvt5ZcQHN8iP18FLqyZkY6xWa61dHGSPNpUR1T0sbqPEs4_zfVGr8d0uMxf0Ee9hEleNPUAfRjpjUybV3GNCcC7NgClhISq4C-kyyDaMAdpyezJ6XWREIMaotUbhx2UaYtKzB90MPJldG-0My2W5gJ8Kpjf2y0npxvezY5_wh2n5gVAXUnb59wfD4izaKgjGTK09bbXCGyJwhXl1Y8bKajgOwfj-7H3pYHveEmCuXrW96fMm0zRIc5ZU8XcTnHU8PLtHBO3MwreDMTlWXrni9HPxDp3DdLNFKaXCcHuXKqT4AR30YecyEnDUm9uFgmPCkYO9g9MUmER-3BXTgU_3PpX6l1lcrqCaGW4lGEchpp_JjPeHfj7SuVVe8EjGUGi4mUEzwfQgjyaAnjxFXRuWodVlx_sb4mvDAMUHBWcZhNz6ofQZ8h1shBPZXn3ZjQFXi7EGyzzozkzi_pnTEtDgvo.RvgspEL33F3jRqp0GD3eRw%26redirect_uri%3Dhttps%3A%2F%2Freport.mimecastcybergraph.com%2Fcallback> CGBANNERINDICATOR Hi Sasha, Do you mean a new Endpoint behaviour for EVPN-VPWS fast egress protection? That's the approach taken here with a new ARGument enabled behaviour : https://www.ietf.org/archive/id/draft-ietf-bess-evpn-fast-reroute-00.html#name-enddx2reroute-enddx2-with-f<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-fast-reroute-00.html#name-enddx2reroute-enddx2-with-f> Regards, Luc André Luc André Burdet | Cisco | [email protected]<mailto:[email protected]> | Tel: +1 613 254 4814 From: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Date: Thursday, June 11, 2026 at 12:13 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: BESS <[email protected]<mailto:[email protected]>> Subject: [spring] Usage of End.DX2 SID in EVPN-VPWS 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]
