Received: from usb-smtp-delivery-110.mimecast.com (usb-smtp-delivery-110.mimecast.com [170.10.153.110]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id 2A3234B for ; Wed, 30 Sep 2026 10:21:38 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=rbbn.com header.s=mimecast20240522 header.b=E37FC4ET; dmarc=pass (policy=reject) header.from=rbbn.com; spf=pass (mx.ietf.org: domain of alexander.vainshtein@rbbn.com designates 170.10.153.110 as permitted sender) smtp.mailfrom=alexander.vainshtein@rbbn.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20240522; t=1790763691; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=v33NmbbI51Gjl2clbDlb0/4p2itb8rm2diV5u7X9ku4=; b=E37FC4ETM5l3Gq2lpn3bwfbJxu6zmUkyB4H5bLIgxRByilpNOMvXbNXFzwftXZ0CDs6ZA4 B4o2wS9UF4mO8gR6ClEsGFNesToxEv4lK9IOsjs+8m/IZlPwQ7qraSiT831BPHTSZ0sXJC IeN2Tb1l2kPYNp7WwGP4YoRKcBhOkgiYpPYe8lWG3nMrNyNgeOtwvvEKqsp49bnkvyfQDo quMpI6AMA0SSLI0iA67FIkgUEIEF6kRYHlSsRJ9gQdDjc91qP4j4JicHmxeRjdHZdOrrG3 ZUgqRhrj4ramJsXuAk4bHsUBO9x6a/oWHkqlL+jV0IUOCbrzSOmGlRX/2z6Zgw== Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazon11022095.outbound.protection.outlook.com [40.93.195.95]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id usb-mta-38-5sGhWdbsMxS4t-nntlAnXQ-1; Wed, 30 Sep 2026 03:21:26 -0700 X-MC-Unique: 5sGhWdbsMxS4t-nntlAnXQ-1 X-Mimecast-MFC-AGG-ID: 5sGhWdbsMxS4t-nntlAnXQ_1790763684 Received: from SJ0PR03MB6925.namprd03.prod.outlook.com (2603:10b6:a03:41a::5) by MW4PR03MB6443.namprd03.prod.outlook.com (2603:10b6:303:122::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.15; Wed, 30 Sep 2026 10:21:20 +0000 Received: from SJ0PR03MB6925.namprd03.prod.outlook.com ([fe80::5fe9:bd9f:7e07:1003]) by SJ0PR03MB6925.namprd03.prod.outlook.com ([fe80::5fe9:bd9f:7e07:1003%5]) with mapi id 15.21.0451.026; Wed, 30 Sep 2026 10:21:20 +0000 From: Alexander Vainshtein To: "Pablo Camarillo (pcamaril)" Thread-Topic: Usage of End.DX2 SID in EVPN-VPWS Thread-Index: Adz5uPR7fUL5tRVIRvCZZdadAMF0WRKpxyFwAvRj1p0AJCO8UA== Date: Wed, 30 Sep 2026 10:21:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ0PR03MB6925:EE_|MW4PR03MB6443:EE_ x-ms-office365-filtering-correlation-id: e8478122-b4da-478b-b9ce-08df1edc9239 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|19092799006|6049299003|23010399003|10067099003|56012099006|11063799006|4143699003|3023799007|6133799003|22082099003|18002099003|8096899003|38070700021|4013099003|4053099003 x-microsoft-antispam-message-info: VZto20Qto9IQfjPFrWVAxfs+cNTLz7o9HLLRThp4qVmATr82EGwY+Jm5bx7aWQl2n7uTjrTJWC2qiuYLkkqc8NNxf9BZf++8pVeLBYue+s4rGh07hHWxnEtP8AGGRp+miK8frs1MjbEdtJP4f8Gq1zveswbKDYg9LZbgEoR2Y/P5Ve3Gxn5Vy6KWQFSOkG4kNoHXBPTvmCIv/rgtJTDEQHO7N7msbgbvmlACeL35yQpNOSwsZl5D+rS01nrColgO67iJ6b8NxHwVPjff/kEeBOEW/PcfqdLt/2A5nyu5PQwpTPUPEoHwgsZgcBuVsgcGGba7+OutiSP8/j2bSjeQkPm1qjZWl/lqCl2RpjRfBFS4IOrAU82IkHdKEaSUN2lI5ICmTFtdR0FaCOSZyeCPL6MNI5l/56VWVtaz9md2QCRyB4MupbFJb2/H20d8Zlu87XMVLRGtuxyRCfEkAD5j0Nfoo3NE8aoT6PQOty2PQs+nm5G0AI/vBGjD39DfX0BmO96/IRCbtp+THCPMLQQLtYMYn5G7LxGSVfLB40hE7C+fSsW9+SHoPw9r0V/RKHgCr5SRq+ed3hhIlMcNDzVrhwI1nyBNHZoM2i1IIbrC6nzCzHn7y95nr23E9jDiYAZPKr9QWyNCnWA1NgK5a36bcPEG9oPxMdRR5VwOvtfXILk= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ0PR03MB6925.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(19092799006)(6049299003)(23010399003)(10067099003)(56012099006)(11063799006)(4143699003)(3023799007)(6133799003)(22082099003)(18002099003)(8096899003)(38070700021)(4013099003)(4053099003);DIR:OUT;SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?zhOedsFblg0dsybklVBJLMJ/fFoZzHBYpCfFnMRgERUi14tG/ik3JHupKbGq?= =?us-ascii?Q?bf1/97ypk/lxNM/3VTqZHLtTa39kK3gkUS4r9D7FB1PitwzN4JV3v4gpOw3S?= =?us-ascii?Q?vhzosmafnmq7ZQkATz6KtogzZe0BAWsH8kZCMmyp6cDjDErxXdDExGPuATI+?= =?us-ascii?Q?n/NoTe/ahc3ITcnM+HIro6mo1dICWtYk1lOqRm+vM+jYac/cJ1KUPPDbh7WG?= =?us-ascii?Q?lNZbrjYPkSplzC2qAUzOZKpbBEnfOC8/truxqyrEn09os0I/Ia8gJRvUp0uA?= =?us-ascii?Q?FcMX6HPz0jBuA4rexdaT8UG/fA0/B+yXj6j+oLDaajwHjrhiOELYO7wlwS52?= =?us-ascii?Q?mJhX47RfKEL5yLsi+HC98djmPUilwJAm1LL+HVhKSOH+u4V5Haaalp8cX02L?= =?us-ascii?Q?stOTVGJkLJcurG3ZJOe9KPUiEl8wjiiEiOkAs2cyHqm35MF3R+/TuV8U+gSi?= =?us-ascii?Q?0KWu3woFI03EnVYElJMhR5c2RlGxgL7BtUj0GEpyg8x2OeB7AZc8GzOnd9xS?= =?us-ascii?Q?CKS5M3AtTGFwphdoWY2dnpJh+qXwN48KXrKsXBRrvjhJugFYDytF0EzkFXZa?= =?us-ascii?Q?1W4n6VU3ornT/NQNFyrG2meoyGkHLVabmlOMCzTy/i65WF4kWK0HShlx8gLu?= =?us-ascii?Q?Nh4C7+PEFHY+8xnu7N5kowK+34loSG/GUNfMUIl5Ymno2tvAmbg//i49C1xw?= =?us-ascii?Q?8GI9H2bQBOVVEqWv3kC6jFxHw9SuTPzRjxEoTntG0x/pAGUL3lsG9TvZ253l?= =?us-ascii?Q?uPcKfzNa7uCtRTvnAIZslviDkheA36DgIArb34kyWmM4xuEvrOKgFuGnaZxK?= =?us-ascii?Q?wkGd5vGCuBBMhHQPMgsIGorXqxvrDocDVodmxVSXhj3Pgi+uumVrQnaiAkLh?= =?us-ascii?Q?WC7itnyLN63S3G/2qGPkSnsrm9zOU0mcO18Bbfc/imAlp2d+MGq034egCvVy?= =?us-ascii?Q?Uq2cfWiAM4niCS2UnfATKev1kFr5OpQs1uIgjtJ5g2UZ0VR4aPTTDl7p94q/?= =?us-ascii?Q?UA+0CiRcyla47m9F6cOmOTA7wp1hIZ74OTNxZZiYRwzmjOJ3/zPD7pd7qlep?= =?us-ascii?Q?htZiI1ln6STA1OBezxS3eP/iCOEPXQY2g/KWS5+Afev9BqVA9n8HeixhQGd9?= =?us-ascii?Q?dqYPGGpbT2RzYITtSiCDzfWSmuKaE8D1x9DEa6zZuqU5aM91jomRLzRz6IDt?= =?us-ascii?Q?DCmuaBDLZrRGr9/5FdX5gHY9qVcE1bUp7lzJvRsPoC+84gXfj2fxVq4uE7LJ?= =?us-ascii?Q?gt+abEAtMj6opvDCi6VIz1yk33ujACY3VCQi2FlU2OBaCaH3nL6nVj5IeIXS?= =?us-ascii?Q?gccqCewskmjCqqDU9Ilc0UUjixAWJKs/3IlJi2c6uI6z9KBLoPKET0LXO64F?= =?us-ascii?Q?XhI4LPUdOLIhssPoBp0ONFa/s+v37QwgqRNS07HpnAveB/Jt2DFqp+TFAW5W?= =?us-ascii?Q?PZ5+FNiESU21hznord2hakOvF4B8dLZ3aRmfoFp54scCCHnUPFeDCrqRX/NF?= =?us-ascii?Q?9pFnXRDrHMsamL1f/yZ91fBFqH4SujI29IZXGEamAtTG2l9exdpDGm/4aNPj?= =?us-ascii?Q?23gPlG2VhMmcfU4tkfK3S3qj6cbN2VInkSaH8JPfZCvlOyNvOyNjkFyZDVF2?= =?us-ascii?Q?xa/+V9Lu7M4SYc/IMrypJOdIwTcOiDNN0UfT9m3ikU9iY+NCXYdi5UPN5a6V?= =?us-ascii?Q?51hBgzXuct3JNdHWBiSZfUjOR0W2pwl2B56+cJ6zc+QATLrC?= MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: PXMxEQAPjt33jWDDidViPtS0780MvJXfVbwbd/6wNMsD+eTinT6aUDUGnYYztd3hehUEiMWQ4kNHv1yWkYHbCc0pxeGHf5bg99liJF5QkWFuxoph8waiWd8c05HM4jAKlpd7LcnbTYYuNEl5DkL2q1SyXl2WuI7mIeDW+/eq4EQh/ms+b+7ryzxwX1/qQwD7P2/1mTTTWLysx4VmKatff7DfTQRkowBhbixt5am4+qYUwnys/QXA7jjKKWtNKy9EXdn/NonBE7nMOuaURRA6zs/S3NjQv3L9Qi2xfi920PaEOinv0/hC+VuidOrev80kIcbxTF15nZy8OzuV2WmauA== X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR03MB6925.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e8478122-b4da-478b-b9ce-08df1edc9239 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2026 10:21:20.4373 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3l7zVJOZUq3iCco0UWB2MnwsGLsjebA6KC5cSkrtKqDL95/KKXEKF26Zjb2w+swTW7WaF09Tj0IatO5WQrZxLA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6443 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: XlNP6pdKYB9AniEVrSmHKpXfG-fVZ8VtE_NcZ3TcdDY_1790763684 X-Mimecast-Originator: rbbn.com Content-Language: en-US Content-Type: multipart/related; boundary="_004_SJ0PR03MB6925ABBF96418956A235A373F68B2SJ0PR03MB6925namp_"; type="multipart/alternative" X-Spamd-Bar: - Message-ID-Hash: SV4VCXRITKRLABSZLITATGTZQAPGYSGI X-Message-ID-Hash: SV4VCXRITKRLABSZLITATGTZQAPGYSGI X-MailFrom: alexander.vainshtein@rbbn.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-spring.ietf.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: BESS , "spring@ietf.org" X-Mailman-Version: 3.3.10 Precedence: list Subject: [spring] Re: Usage of End.DX2 SID in EVPN-VPWS List-Id: "Source Packet Routing in NetworkinG (SPRING)" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_004_SJ0PR03MB6925ABBF96418956A235A373F68B2SJ0PR03MB6925namp_ Content-Type: multipart/alternative; boundary="_000_SJ0PR03MB6925ABBF96418956A235A373F68B2SJ0PR03MB6925namp_" --_000_SJ0PR03MB6925ABBF96418956A235A373F68B2SJ0PR03MB6925namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable 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 already provides a way to differentiated betwee= n "basic" and "protected" behaviors of the Sv6 SID with End.X behavior. IMHO and FWIW RFC 9252 should be augmented with a similar mechanism specify= ing 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 Rerout= e 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) Sent: Tuesday, September 29, 2026 7:45 PM To: Alexander Vainshtein ; spring@ietf.org Cc: BESS Subject: [EXTERNAL] Re: Usage of End.DX2 SID in EVPN-VPWS Hi Sasha, RFC 8986 specifies the fundamental data-plane pseudocode/primitiv= e endpoint behaviors under nominal operation where the SID and outgoing int= erface I are active and valid. Interface Failure and Protection: RFC 8986 i= ntentionally does not embed protection, fast reroute (FRR), or multi-homing [Image removed by sender.] CGBANNERINDICATOR Hi Sasha, RFC 8986 specifies the fundamental data-plane pseudocode/primitive endpoint= behaviors under nominal operation where the SID and outgoing interface I a= re active and valid. Interface Failure and Protection: RFC 8986 intentionally does not embed pro= tection, fast reroute (FRR), or multi-homing state machines into the base e= ndpoint definition. Instead, interface failure handling and protection mech= anisms are governed by the relevant service layer and fast-convergence spec= ifications (such as EVPN multi-homing in RFC 9252 / BESS SRv6 EVPN and TI-L= FA / Egress Protection frameworks). Rerouting / Backup Encapsulation: In an EVPN VPWS or multi-homed active-sta= ndby/all-active scenario where interface I fails, an implementation that su= pports local egress protection / bypass may pre-program a backup path in th= e 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 f= ully compliant with the architecture. Hope this clarifies it. Let us know if you have any further questions. Cheers, Pablo. From: Alexander Vainshtein Date: Tuesday, 15 September 2026 at 03:26 To: spring@ietf.org Cc: BESS 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 em= ail 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 a= nd associated with the outgoing interface I. As long as I is operationally UP, packets received with this SID as the Des= tination IPv6 address in the IPv6 header shall be processed as defined in t= he 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: spring@ietf.org Cc: BESS 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 8986in EVPN-= VPWS. * The definition of this endpoint behavior says that "The End.DX2 S= ID 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 a= ll extension headers are stripped, and the resulting Ethernet frame is forw= arded 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 explicitly mentions End.DX2= as one of possible behaviors of the SID signaled in per-EVI Ethernet A-D r= outes (along with End.X2V and End.DT2U). I think that End.X2 behavior as defined above is not compatible with one o= f the advantageous features of EVPN-VPWS as described in the last para of S= ection 5 of RFC 8214: 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. (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 sh= ould 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 proprie= tary for the sole use of the intended recipient. Any review, disclosure, re= liance or distribution by others or forwarding without express permission i= s strictly prohibited. If you are not the intended recipient, please notify= the sender immediately and then delete all copies, including any attachmen= ts. --_000_SJ0PR03MB6925ABBF96418956A235A373F68B2SJ0PR03MB6925namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

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 t= o avoid any misinterpretations by the developers.

 

I have noticed that= Section 8.1 of RFC 9352 already provides a way to differentiated betwee= n "basic" and "protected" behaviors of the Sv6 SID with= End.X behavior.

 

IMHO and FWIW RFC 9= 252 should be augmented with a similar mechanism specifying whether a Servi= ce 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, agai= n, lots of thanks,

Sasha

 

From: P= ablo Camarillo (pcamaril) <pcamaril=3D40cisco.com@dmarc.ietf.org>
Sent: Tuesday, September 29, 2026 7:45 PM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; spri= ng@ietf.org
Cc: BESS <bess@ietf.org>
Subject: [EXTERNAL] Re: Usage of End.DX2 SID in EVPN-VPWS=

 

Hi Sasha= , RFC 8986 specifies the fundamental data-plane pseudocode/primitive endpoi= nt behaviors under nominal operation where the SID and outgoing interface I are active and valid. Interface Failure a= nd Protection: RFC 8986 intentionally does not embed protection, fast rerou= te (FRR), or multi-homing

<= span style=3D"font-size:1.0pt;color:white">

Hi Sasha,

RFC 8986 specif= ies the fundamental data-plane pseudocode/primitive endpoint behaviors unde= r nominal operation where the SID and outgoing interface I are active and v= alid.

Interface Failu= re and Protection: RFC 8986 intentional= ly does not embed protection, fast reroute (FRR), or multi-homing state mac= hines into the base endpoint definition. Instead, interface failure = handling and protection mechanisms are governed by the relevant service layer and fast-convergence specificat= ions (such as EVPN multi-homing in RFC 9252 / BESS SRv6 EVPN and TI-LFA / E= gress Protection frameworks).

Rerouting / Bac= kup Encapsulation: In an EVPN VPWS or multi-homed active-standby/all-active= scenario where interface I fails, an implementation that supports local eg= ress protection / bypass may pre-program a backup path in the FIB. When I goes down, the node can encapsulate the d= ecapsulated Ethernet frame into an SRv6 policy toward the backup PE's Servi= ce 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 clari= fies it. Let us know if you have any further questions.

Cheers,<= o:p>

Pablo.

From: Alexander Vainshtein <Alexander.Vainshtein=3D40rbbn.com@dmarc.ietf.org&= gt;
Date: Tuesday, 15 September 2026 at 03:26
To: spring@ietf.org <spring@ietf.org>
Cc: BESS <bess@ietf.org>
Subject: [bess] Re: Usage of End.DX2 SID in EVPN-VPWS

Hi all,

A gentle reminder: I have not received feedback from the SPRING W= G 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 de= fined 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 a= ddress 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: A= lexander Vainshtein
Sent: Thursday, June 11, 2026 7:10 PM
To: spring@ietf.org
Cc: BESS <bess@ietf.org>
Subject: Usage of End.DX2 SID in EVPN-VPWS
Importance: High<= /span>

 

Hi,

I have a question about usage of End.DX2 SID (as defined in Section 4.9 of RFC 8= 986in EVPN-VPWS.

 

· = ;        The definition of this endpoint beh= avior 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 E= thernet, the IPv6 header and all extension headers are stripped, and the re= sulting Ethernet frame is forwarded to the outgoing interface I.

 

EVPN-VPWS as defined in RFC 8214 is explicitly mentioned as one o= f possible applications in this section,  and Section 6.1.2 of R= FC 9252 explicitly mentions End.DX2 as one of possible be= haviors 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 compat= ible with one of the advantageous features of EVPN-VPWS as described in the= last para of Section 5 of RFC 8214<= /span>:

<quote>

   Finally, EVPN ma= y employ data-plane egress link protection mechanisms

   not available in= VPWS.  This can be done by the primary PE (on local

   AC down) using t= he 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 A= C failure  in "classic" VPWS has been defined in RFC 8104).<= o:p>

 

What, if anything, did I miss? Do you think that a new Endpoint b= ehavior should be defined?

 

Regards, and lots of thanks in advance,

Sasha

 

 

Disclaimer=

This e-mail together with any attachments may contain info= rmation of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended r= ecipient. Any review, disclosure, reliance or distribution by others or for= warding without express permission is strictly prohibited. If you are not t= he intended recipient, please notify the sender immediately and then delete all copies, including any attachmen= ts.

--_000_SJ0PR03MB6925ABBF96418956A235A373F68B2SJ0PR03MB6925namp_-- --_004_SJ0PR03MB6925ABBF96418956A235A373F68B2SJ0PR03MB6925namp_ Content-Type: image/jpeg; name="~WRD0009.jpg" Content-Description: ~WRD0009.jpg Content-Disposition: inline; filename="~WRD0009.jpg"; size=823; creation-date="Wed, 30 Sep 2026 09:58:03 GMT"; modification-date="Wed, 30 Sep 2026 10:21:20 GMT" Content-ID: <~WRD0009.jpg> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_SJ0PR03MB6925ABBF96418956A235A373F68B2SJ0PR03MB6925namp_--