<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd">[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-bess-bgp-srv6-args-10" number="9819" consensus="true" ipr="trust200902"updates="9252"> <?xml-stylesheet 3type='text/xsl' href='rfc2629.xslt' ?> <?rfc toc="yes" ?> <?rfc symrefs="yes" ?> <?rfc sortrefs="yes" ?> <?rfc iprnotified="no" ?> <?rfc strict="yes" ?> <?rfc compact="yes" ?> <?rfc subcompact="no" ?>updates="9252" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"> <!-- [rfced] May we update the document title as follows to improve readability? Original: Segment Routing over IPv6 Argument Signaling for BGP Services Perhaps: Argument Signaling for BGP Services in Segment Routing over IPv6 (SRv6) --> <front> <title abbrev="SRv6 Argument Signaling for BGP Services">Segment Routing over IPv6 Argument Signaling for BGP Services</title> <seriesInfo name="RFC" value="9819"/> <author fullname="Ketan Talaulikar" initials="K" surname="Talaulikar"> <organization>Cisco Systems</organization> <address> <postal><street/><country>India</country> </postal> <email>ketant.ietf@gmail.com</email> </address> </author> <author fullname="Kamran Raza" initials="K" surname="Raza"> <organization>Cisco Systems</organization> <address> <postal><street/><country>Canada</country> </postal> <email>skraza@cisco.com</email> </address> </author> <author fullname="Jorge Rabadan" initials="J" surname="Rabadan"> <organization>Nokia</organization> <address> <postal><street/> <country>USA</country><country>United States of America</country> </postal> <email>jorge.rabadan@nokia.com</email> </address> </author> <author fullname="Wen Lin" initials="W" surname="Lin"> <organization>Juniper Networks</organization> <address> <postal><street/> <country>USA</country><country>United States of America</country> </postal> <email>wlin@juniper.net</email> </address> </author> <dateyear=""/> <area>Routing</area> <workgroup>BESS Working Group</workgroup>year="2025" month="July"/> <area>RTG</area> <workgroup>bess</workgroup> <keyword>BGP</keyword> <keyword>SRv6</keyword> <abstract><t>RFC9252<t>RFC 9252 defines procedures and messages for BGP Overlay Services for Segment Routing over IPv6(SRv6)(SRv6), including Layer 3 Virtual PrivateNetwork,Network (L3VPN), EthernetVirtual Private Network,VPN (EVPN), andGlobalglobal InternetRouting.routing. This document updatesRFC9252RFC 9252 and provides more detailed specifications for the signaling and processing of SRv6 SegmentIdentifiersIdentifier advertisements for BGP Overlay Service routes associated with SRv6 Endpoint Behaviors that support arguments.</t> </abstract> </front> <middle> <section anchor="INTRO"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>SRv6 refers to Segment Routing instantiated over the IPv6 data plane <xreftarget="RFC8402"/>.target="RFC8402" format="default"/>. An SRv6 Segment Identifier (SID) <xreftarget="RFC8402"/>target="RFC8402" format="default"/> can be associated with one of theservice specificservice-specific SRv6 EndpointbehaviorsBehaviors on the advertising Provider Edge (PE) router forLayer-3Layer 3 Virtual Private Network (L3VPN),Globalglobal InternetRouting,routing, and EthernetVirtual Private NetworkVPN (EVPN) services as defined in <xreftarget="RFC8986"/>.target="RFC8986" format="default"/>. Such SRv6 SIDs are referred to as SRv6 Service SIDs. <xreftarget="RFC9252"/>target="RFC9252" format="default"/> defines the procedures and messages for the signaling of BGP Overlay Services including L3VPN, EVPN, and Internet services using SRv6.</t> <t>For certain EVPN services, <xreftarget="RFC8986"/> (section 4.12)target="RFC8986" section="4.12"/> introduced the End.DT2M SRv6 Endpoint Behavior, which utilizes arguments (i.e., Arg.FE2). <xreftarget="RFC9252"/>target="RFC9252" format="default"/> subsequently specified the encoding and signaling procedures for the SRv6 SID and its associated argument via EVPN Route Type 3 and EVPN Route Type 1, respectively. However, during implementation and interoperability testing, it was observed that the specifications outlined in <xreftarget="RFC9252"/> lackedtarget="RFC9252" format="default"/> lack sufficient detail, leading to ambiguities in interpretation and implementation.</t> <t>This document updates <xreftarget="RFC9252"/>target="RFC9252" format="default"/> by providing additional details and clarifications regarding the signaling of SRv6 Service SIDs associated with SRv6 Endpoint Behaviors that utilize arguments. While the focus is primarily on the signaling of the End.DT2M SRv6 Endpoint Behavior via EVPN Route Types 1 and 3, the procedures described herein are also applicable to other similar endpoint behaviors with arguments that may be signaled using BGP.</t><t>Section<!-- [rfced] We updated "with argument" here to "with an argument". Let us know if it should be "with arguments" instead. Original: Section 6.3 of<xref target="RFC9252"/>[RFC9252] specifies that the SRv6 Service SID used in the data plane is derived by applying a bitwise logical-OR operation between the SID with argument signaled via Route Type 1 and the SID with the 'locator + function' components signaled via Route Type 3. Updated: Section 6.3 of [RFC9252] specifies that the SRv6 Service SID used in the data plane is derived by applying a bitwise logical-OR operation between the SID with an argument signaled via Route Type 1 and the SID with the 'Locator + Function' components signaled via Route Type 3. --> <t><xref target="RFC9252" section="6.3"/> specifies that the SRv6 Service SID used in the data plane is derived by applying a bitwise logical-OR operation between the SID with an argument signaled via Route Type 1 and the SID with the 'Locator + Function' components signaled via Route Type 3. However, this approach assumes a uniform SID structure across all SIDs advertised via EVPN Route Types 1 and 3. This assumption is not universally valid, and the procedures in this document remove this restriction, ensuring greater flexibility in SRv6 SID signaling.</t> <t>The descriptions and examples presented in this document do not utilize the Transposition Scheme (seesection 4 of<xreftarget="RFC9252"/>).target="RFC9252" section="4"/>). Consequently, the Transposition Offset (TPOS-O) and Transposition Length (TPOS-L) are set to zero, and references to MPLS label fields where the function or argument portions may be transposed are omitted. However, the same examples could be applied with the Transposition Scheme. This document does not introduce any modifications to the use of the Transposition Scheme in the signaling of EVPNRoutes.routes. Implementations are expected to adhere to the procedures and recommendations specified in <xreftarget="RFC9252"/>target="RFC9252" format="default"/> concerning the Transposition Scheme.</t> <section anchor="REQ"title="Requirements Language"> <t>Thenumbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <section anchor="SIDANDARGS"title="Advertisementnumbered="true" toc="default"> <name>Advertisement of SRv6 SID andArguments"> <t>Section 3.1 of <xref target="RFC8986"/>Arguments</name> <t><xref target="RFC8986" section="3.1"/> defines the format of an SRv6 SID as consisting of three components: Locator (LOC), Function (FUNC), and Argument (ARG). For SRv6 SIDs associated with SRv6 Endpoint Behaviors that do not support arguments, the ARG component is not present. Consequently, all bits following the FUNC portionMUST<bcp14>MUST</bcp14> be set to zero, and theargument length MUSTArgument Length (AL) <bcp14>MUST</bcp14> be zero.</t> <t>Certain SRv6 Endpoint Behaviors (e.g., End.DT2M) support arguments. As specified inSection 3.2.1 of<xreftarget="RFC9252"/>,target="RFC9252" section="3.2.1"/>, the SRv6 SID Structure Sub-Sub-TLVMUST<bcp14>MUST</bcp14> be included when signaling an SRv6 SID corresponding to an endpoint behavior that supports argument. This ensures that the receiving router can perform consistency verification of the argument and correctly encode the ARG value within the SRv6 SID.</t> <t>In certain use cases, the SRv6 SID can be signaled as a complete structure, with the LOC:FUNC:ARG components fully encoded within the SID. However, there are scenarios where the SRv6 SID, consisting only of the LOC:FUNC portion, is signaled in one advertisement, while the ARG value is either signaled through a separate advertisement or learned via an alternative mechanism. It is the responsibility of the SRv6Source Nodesource node to append the ARG component to the LOC:FUNC portion, thereby constructing the complete SRv6 SID (LOC:FUNC:ARG). Thisfully-formedfully formed SID can then be utilized in the data plane, either as the IPv6 destination address of a packet or as a segment within the Segment Routing Header (SRH) <xreftarget="RFC8754"/>,target="RFC8754" format="default"/>, as required.</t> <t>Since arguments may be optional, the SRv6Endpoint Nodeendpoint node that owns the SIDMUST<bcp14>MUST</bcp14> advertise the SRv6 SID Structure Sub-Sub-TLV along with the LOC:FUNC portion of the SRv6 SID to indicate whether arguments are supported for that specific SID. A zeroArgument Length (AL)AL value indicates that the node does not accept an argument for the given SRv6 SID. Conversely, a non-zero AL value specifies the size of the supported argument, along with the Locator Block Length (LBL), Locator Node Length (LNL), and Function Length (FL) parameters, which define the offset from which the node expects the ARG to be encoded. All bits beyond LBL + LNL + FL + ALMUST<bcp14>MUST</bcp14> be set to zero.</t> <t>The advertisement of the ARG value may be performed either by the node that owns the SRv6 SID and is advertising the LOC:FUNC portion of thatSID,SID or by another node/mechanism. The advertisement of the ARG valueMUST<bcp14>MUST</bcp14> specify the size of the argument, its value, and the associated SRv6 Endpoint Behavior of the SID. Additionally, the specification of the association of the ARG advertisement with the corresponding SID(s) for which the argument applies isREQUIRED.</t><bcp14>REQUIRED</bcp14>.</t> </section> <section anchor="EVPNESI"title="End.DT2Mnumbered="true" toc="default"> <name>End.DT2M Signaling for EVPN ESIFiltering">Filtering</name> <t>As specified in <xreftarget="RFC9252"/>,target="RFC9252" format="default"/>, the LOC:FUNC portion of the SRv6 SID with End.DT2M behavior is signaled via EVPN Route Type 3 (Inclusive Multicast Ethernet TagRoute),route), while the Ethernet Segment Identifier (ESI) Filtering ARG (denoted as Arg.FE2 in <xreftarget="RFC8986"/>)target="RFC8986" format="default"/>) is signaled via EVPN Route Type 1 (Ethernet Auto-Discovery per Ethernet Segment (A-D per ES)Route).route). The following subsections provide a more detailed specification of the signaling and processing mechanisms compared to <xreftarget="RFC9252"/>.</t>target="RFC9252" format="default"/>.</t> <t>ESI Filtering is a split-horizon mechanism used forMulti-Homingmultihoming <xreftarget="RFC7432"/>target="RFC7432" format="default"/> or Ethernet-Tree (E-Tree) procedures <xreftarget="RFC8317"/>.target="RFC8317" format="default"/>. ESI Filtering is not applicable in scenarioswhere:<list style="symbols">where:</t> <ul spacing="normal"> <li> <t>No E-Tree leaf Broadcast, Unknown Unicast, or Multicast (BUM) traffic exists,</t> </li> <li> <t>Nomulti-homingmultihoming is present,</t> </li> <li> <t>No split-horizon mechanism is required, or</t> </li> <li> <t>Thelocal-bias"Local Bias" method (as specified in <xreftarget="RFC8365"/>)target="RFC8365" format="default"/>) is employed.</t></list></t></li> </ul> <t>In this document, "ESI Filtering" is used as a general reference to the procedure performed by the disposition Provider Edge (PE) router to prevent forwarding of BUM traffic to local Ethernet Segments or local leaf attachment circuits, based on the presence of the ESI Filtering ARG.</t> <t>The signaling and processing descriptions outlined in the following sections also apply to End.DT2M behavior flavors designed for SRv6 SID list compression <xreftarget="I-D.ietf-spring-srv6-srh-compression"/>.target="RFC9800" format="default"/>. In deployments where a mix of compressed and uncompressed SIDs is present, the behaviors advertised in the Ethernet Auto-Discovery (A-D) per ESRoutesroutes (EVPN Route Type 1) and Inclusive Multicast Ethernet TagRoutesroutes (EVPN Route Type 3)MAY<bcp14>MAY</bcp14> consist of a combination of compressed and uncompressed End.DT2M behavior flavors. The procedures in this document remain valid for such deployments provided that theargument lengthAL consistency checks between EVPN Route Type 1 and EVPN Route Type 3, as described in the following subsections, are satisfied.</t> <section anchor="RT1"title="Advertisementnumbered="true" toc="default"> <name>Advertisement of Ethernet A-D per ESRoute">Route</name> <t>Ethernet Auto-Discovery (A-D) per ESRoutesroutes (EVPN Route Type 1), as defined in <xreftarget="RFC7432"/>,target="RFC7432" format="default"/>, are utilized to enable split-horizon filtering and fast convergence inmulti-homingmultihoming scenarios. Additionally, A-D per ESRoutesroutes facilitate egress filtering of BUM traffic originating from a Leaf, as specified in <xreftarget="RFC8317"/>.</t>target="RFC8317" format="default"/>.</t> <t>When ESI Filtering is not in use, no ESI Filtering ARG is required to be conveyed. However, for backward compatibility and consistency with <xreftarget="RFC9252"/>,target="RFC9252" format="default"/>, the advertisement of this routeSHOULD<bcp14>SHOULD</bcp14> include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an SRv6 Service SID set to ::0 in the SRv6 SID Information Sub-TLV, with the SRv6 Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior supports the use of an ARG, an SRv6 SID Structure Sub-Sub-TLVMUST<bcp14>MUST</bcp14> be included. As no ARG value is required to be signaled in this case, the ALMUST<bcp14>MUST</bcp14> be set to 0.</t><t>Following<t>The following is an example representation of the BGP Prefix-SID Attribute encoding in this case:</t> <figureanchor="RT1NOARG" title="EVPNanchor="RT1NOARG"> <name>EVPN Route Type 1withoutWithout ARG for ESIFiltering"> <artwork><![CDATA[Filtering</name> <artwork name="" type="" align="left" alt=""><![CDATA[ BGP Prefix SID Attr: SRv6 L2 Service TLV: SRv6 SID Information Sub-TLV: SID: :: Behavior: End.DT2M SRv6 SID Structure Sub-Sub-TLV: LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0 ]]></artwork> </figure> <t>When ESI Filtering is in use, the advertisement of this routeMUST<bcp14>MUST</bcp14> include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying the SRv6 Service SID that contains the ESI Filtering ARG value within the SRv6 SID Information Sub-TLV (when not using the Transposition Scheme), with the SRv6 Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior supports the use of an ARG, an SRv6 SID Structure Sub-Sub-TLVMUST<bcp14>MUST</bcp14> be included. Additionally, as a non-zero ARG value is being signaled, theArgument Length (AL) MUSTAL <bcp14>MUST</bcp14> be set to the size of the ARG, and the sizeSHOULD<bcp14>SHOULD</bcp14> be a multiple of 8 to ensure consistency across implementations for ease of operations. The SRv6 SID Structure Sub-Sub-TLVMUST<bcp14>MUST</bcp14> set theLocator Block Length (LBL), Locator Node Length (LNL),LBL, LNL, andFunction Length (FL)FL fields with values that indicate the offset at which the ARG value is encoded within the 128-bit SRv6 SID.</t> <t>The following is an example representation of the BGP Prefix-SID Attribute encoding in this scenario for a 16-bit argument value of 'aaaa':</t> <figureanchor="RT1ARG" title="EVPNanchor="RT1ARG"> <name>EVPN Route Type 1 with ARG for ESIFiltering"> <artwork><![CDATA[Filtering</name> <artwork name="" type="" align="left" alt=""><![CDATA[ BGP Prefix SID Attr: SRv6 L2 Service TLV: SRv6 SID Information Sub-TLV: SID: ::aaaa:0:0:0 Behavior: End.DT2M SRv6 SID Structure Sub-Sub-TLV: LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0 ]]></artwork> </figure> <t>In the examples above, it would have been possible to set the LBL, LNL, and FL values to 0 and to encode the SRv6 SID as either ::0 or aaaa::. However, such an encoding would not be backward compatible with <xreftarget="RFC9252"/>,target="RFC9252" format="default"/>, as further detailed in <xreftarget="BACKWARD"/>.</t>target="BACKWARD" format="default"/>.</t> <t>Therefore, it isREQUIRED<bcp14>REQUIRED</bcp14> that the LBL, LNL, and FL values be set in accordance with the SIDStructurestructure for End.DT2M SRv6 Service SIDs, ensuring compliance with <xreftarget="RFC9252"/>.</t>target="RFC9252" format="default"/>.</t> </section> <section anchor="RT3"title="Advertisementnumbered="true" toc="default"> <name>Advertisement of Inclusive Multicast Ethernet TagRoute">Route</name> <t>The Inclusive Multicast Ethernet TagRouteroute (EVPN Route Type 3), as defined in <xreftarget="RFC7432"/>,target="RFC7432" format="default"/>, is used to advertise multicast traffic reachability information viaMP-BGPMultiprotocol BGP (MP-BGP) to all other PE routers within a given EVPN instance. When utilizing SRv6 transport, the advertisement of this routeMUST<bcp14>MUST</bcp14> include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV to indicate the use of SRv6.</t> <t>Regardless of whether ESI Filtering is in use, the SRv6 Service SIDMUST<bcp14>MUST</bcp14> include only the LOC:FUNC portion within the SRv6 SID Information Sub-TLV (when not utilizing the Transposition Scheme), with the SRv6 Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior supports the use of an ARG, an SRv6 SID Structure Sub-Sub-TLVMUST<bcp14>MUST</bcp14> be included. The LBL, LNL, and FL fieldsMUST<bcp14>MUST</bcp14> be set to indicate the structure of the SRv6 Service SID being advertised.</t> <t>When ESI Filtering is not in use, no ARG is expected to be received by the router along with the advertised SRv6 Service SID. Therefore, the ALMUST<bcp14>MUST</bcp14> be set to 0.</t><t>Following<t>The following is an example representation of the BGP Prefix-SID Attribute encoding in this case:</t> <figureanchor="RT3NOARG" title="EVPNanchor="RT3NOARG"> <name>EVPN Route Type 3withoutWithout ESIFiltering"> <artwork><![CDATA[Filtering</name> <artwork name="" type="" align="left" alt=""><![CDATA[ BGP Prefix SID Attr: SRv6 L2 Service TLV: SRv6 SID Information Sub-TLV: SID: 2001:db8:1:fbd1:: Behavior: End.DT2M SRv6 SID Structure Sub-Sub-TLV: LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0 ]]></artwork> </figure> <t>When ESI Filtering is in use, the router expects to receive traffic in the data path to the SRv6 Service SID that it has signaled along with the ARG portion embedded in it. Consequently, the ALMUST<bcp14>MUST</bcp14> be set to the size of the ARG supported by the advertising router for the specific SRv6 Service SID. The AL value is unique per End.DT2M behavior signaled by the egress PE. Therefore, the egress PEMUST<bcp14>MUST</bcp14> use the same AL for all local Ethernet Segments withAttachment Circuitsattachment circuits within the sameBroadcast Domain.</t>broadcast domain.</t> <t>The following is an example representation of the BGP Prefix-SID Attribute encoding for this scenario with a 16-bit argument:</t> <figureanchor="RT3ARG" title="EVPNanchor="RT3ARG"> <name>EVPN Route Type 3 with ESIFiltering"> <artwork><![CDATA[Filtering</name> <artwork name="" type="" align="left" alt=""><![CDATA[ BGP Prefix SID Attr: SRv6 L2 Service TLV: SRv6 SID Information Sub-TLV: SID: 2001:db8:1:fbd1:: Behavior: End.DT2M SRv6 SID Structure Sub-Sub-TLV: LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0 ]]></artwork> </figure> <t>When ESI Filtering is in use, the advertising routerMUST<bcp14>MUST</bcp14> ensure that the AL signaled in the EVPN Route Type 3 is equal to the AL signaled in the corresponding EVPN Route Type 1.</t> </section> <section anchor="PROC"title="Processingnumbered="true" toc="default"> <name>Processing at IngressPE">PE</name> <t>An ingress PE receives the LOC:FUNC portion of the SRv6 Service SID to be used for BUM traffic through EVPN Route Type 3 advertisements.</t> <t>When ESI Filtering is not in use, the SRv6 Service SID to be used consists solely of the LOC:FUNC portion received via EVPN Route Type 3.</t> <t>When ESI Filtering is in use, the ESI Filtering ARG of the SRv6 Service SID is signaled through EVPN Route Type 1 (Ethernet Auto-Discovery per Ethernet SegmentRoute).route). The ARG, in combination with the LOC:FUNC portion received via EVPN Route Type 3, forms the SRv6 Service SID to be used.</t> <t>Since the LOC:FUNC and ARG portions of the SRv6 Service SID are signaled via different route advertisements, there may be cases where the ingress PE receives inconsistent AL values from the two route types. If the ingress PE expects ESI Filtering to be in use (i.e., when forwarding BUM traffic to other PEs attached to a shared Ethernet Segment) but does not receive a usable ARG value during processing, itSHOULD<bcp14>SHOULD</bcp14> log a message to facilitate troubleshooting.</t> <t>The ingress PE routerMUST<bcp14>MUST</bcp14> follow the processing steps outlined below when handling SRv6 Service SID advertisements:</t><t><list style="numbers"><ol spacing="normal" type="1"><li> <t>If AL=0 is signaled via EVPN Route Type 3, then the egress PE either does not support ESI Filtering or does not require an ESI Filtering ARG for the specific SID. In this case, the SRv6 Service SID is formed using only the LOC:FUNC portion, and all bits afterLBL+LNL+FL MUSTLBL + LNL + FL <bcp14>MUST</bcp14> be set to zero for encoding on the data path. Additionally, the routerMUST<bcp14>MUST</bcp14> ignore the SID value and its SID structure advertised in the corresponding EVPN Route Type 1.</t> </li> <li> <t>If a non-zero AL is signaled via EVPN Route Type 3, then the matching EVPN Route Type 1 for the Ethernet Segment is located and the presence of an SRv6 SID advertisement with the End.DT2M behavior isverified.<list style="letters">verified.</t> <ol spacing="normal" type="a"><li> <t>If the presence of such a SRv6 SID is not verified, or if theAL=0AL is zero in the EVPN Route Type 1, then no usable ARG value is available. The SRv6 Service SIDMUST<bcp14>MUST</bcp14> be formed as described in (1) above.</t> </li> <li> <t>If the AL values in EVPN Route Type 1 and EVPN Route Type 3 are both non-zero but not equal, then no usable ARG value is available. This inconsistency in signaling from the egress PE indicates a configuration error. To prevent potential looping, BUM trafficMUST NOT<bcp14>MUST NOT</bcp14> be forwarded for such routes from the specific Ethernet Segment. ImplementationsSHOULD<bcp14>SHOULD</bcp14> log an error message for troubleshooting this condition.</t> </li> <li> <t>If the AL values in EVPN Route Type 1 and EVPN Route Type 3 are both non-zero and equal, then the ARG value from EVPN Route Type 1 is considered valid. This ARG valueMUST<bcp14>MUST</bcp14> be encoded within the SRv6 SID (LOC:FUNC) at the ARG offset as specified in the SID structure (i.e., LBL + LNL + FL) in EVPN Route Type 3. All bits beyond LBL + LNL + FL + ALMUST<bcp14>MUST</bcp14> be set to zero.</t></list></t> </list></t></li> </ol> </li> </ol> <!-- [rfced] These sentences may be difficult to follow because of the two instances of "based on...". How may we update to improve readability? Original: Based on the above procedures, the SRv6 Service SID encoding for the data plane without an ESI Filtering ARG, based on the examples in Figure 1 and Figure 3, is as follows: ... Based on the above procedures, the SRv6 Service SID encoding for the data plane along with an ESI Filtering ARG, based on the examples in Figure 2 and Figure 4, is as follows: Perhaps: Using the procedures above with the examples in Figures 1 and 3, the SRv6 Service SID encoding for the data plane without an ESI Filtering ARG is as follows: ... Using the procedures above with the examples in Figures 2 and 4, the SRv6 Service SID encoding for the data plane along with an ESI Filtering ARG is as follows: --> <t>Based on the above procedures, the SRv6 Service SID encoding for the data plane without an ESI Filtering ARG, based on the examples in Figures <xreftarget="RT1NOARG"/>target="RT1NOARG" format="counter"/> and <xreftarget="RT3NOARG"/>,target="RT3NOARG" format="counter"/>, is as follows:</t> <figureanchor="SIDPACKET" title="SRv6anchor="SIDPACKET"> <name>SRv6 Service SID Encoding for Data Planewithout ARG"> <artwork><![CDATA[Without ARG</name> <artwork name="" type="" align="left" alt=""><![CDATA[ Route Type 3: SID: 2001:db8:1:fbd1:: Structure: LBL: 32, LNL: 16, FL: 16, AL: 0 SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1:: ]]></artwork> </figure> <t>Based on the above procedures, the SRv6 Service SID encoding for the data plane along with an ESI Filtering ARG, based on the examples in <xreftarget="RT1ARG"/>target="RT1ARG" format="counter"/> and <xreftarget="RT3ARG"/>,target="RT3ARG" format="counter"/>, is as follows:</t> <figureanchor="SIDPACKETARG" title="SRv6anchor="SIDPACKETARG"> <name>SRv6 Service SID Encoding for Data Plane withARG"> <artwork><![CDATA[RouteARG</name> <artwork name="" type="" align="left" alt=""><![CDATA[ Route Type 1: SID: ::aaaa:0:0:0 Structure: LBL: 32, LNL: 16, FL: 16, AL: 16 Route Type 3: SID: 2001:db8:1:fbd1:: Structure: LBL: 32, LNL: 16, FL: 16, AL: 16 SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1:aaaa:: ]]></artwork> </figure> <t><xreftarget="MULTIBD"/>target="MULTIBD" format="default"/> provides another example that illustrates the signaling and processing of multiple bridge domains in a deployment design.</t><t><figure anchor="MULTIBD" title="Example<figure anchor="MULTIBD"> <name>Example with Multiple BridgeDomains"> <artwork><![CDATA[Domains</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +--------------------------------+ | | PE1 | | +---------+ | BUM on BD1 | +-----+ | | +----------------> | BD1 |-------------+ | | | +-----+ | | | | BUM on BD2 | +-----+ | v PE3 | | +--------------> | BD2 |-------+ +---------+ | | +-----| +-----+ | | | +-----+ | +----+ | +---------+ v ^ | | BD1 |-----CE31 | | | | | | +-----+ | |CE12|-----+ ESI-1 | ^ | | +-----+ | | |-----+ | | | | | BD2 |-----CE32 +----+ | +---------+ ^ RT3 RT3 | +-----+ | +-----| +-----+ | | dt2m dt2m +---------+ | | BD1 | | | BD2 BD1 | | +-----+ | | FL:16 FL:32 | | +-----+ | RT1 | | | BD2 | | ESI-1 | | +-----+ | AL:16 | +---------+ | PE2 | | | | | | +-------------------------------+ Route Type 1 ESI-1: SID: ::aaaa:0:0:0 Structure: LBL: 32, LNL: 16, FL: 16, AL: 16 Route Type 3 from BD1: SID: 2001:db8:1:fbd1:fbd1: Structure: LBL: 32, LNL: 16, FL: 32, AL: 16 Route Type 3 from BD2: SID: 2001:db8:1:fbd2:: Structure: LBL: 32, LNL: 16, FL: 16, AL: 16 SRv6 Service SID for datapath from ingress PE1 to egress PE2 on BD1: 2001:db8:1:fbd1:fbd1:aaaa:: SRv6 Service SID for datapath from ingress PE1 to egress PE2 on BD2: 2001:db8:1:fbd2:aaaa:: ]]></artwork></figure></t></figure> </section> </section> <section anchor="BACKWARD"title="Backward Compatibility">numbered="true" toc="default"> <name>Backward Compatibility</name> <t>Existing implementations that rely on the bitwise logical-OR operation, as specified inSection 6.3 of<xreftarget="RFC9252"/>,target="RFC9252" section="6.3"/>, function correctly only when the SID structures of the two EVPNRoute Typesroute types are identical.</t> <t>Backward compatibility with implementations performing the bitwise logical-OR operation is maintained when EVPN Route Type 3 and its corresponding EVPN Route Type 1 advertise SIDs with the same SID structure, as outlined in Sections <xreftarget="RT1"/>target="RT1" format="counter"/> and <xreftarget="RT3"/>.</t>target="RT3" format="counter"/>.</t> <t>However, when the SID structures of the two route types are not identical, the bitwise logical-OR operation specified in <xreftarget="RFC9252"/>target="RFC9252" format="default"/> cannot be applied. Instead, the alternative method specified in <xreftarget="PROC"/> MUSTtarget="PROC" format="default"/> <bcp14>MUST</bcp14> be used to correctly derive the SRv6 Service SID in such cases.</t> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentdoes not require any action from IANA.</t>has no IANA actions.</t> </section> <section anchor="SEC"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>This documentonlyprovides a more detailed specification related to the signaling and processing of SRv6 SID advertisements for SRv6 Endpoint Behaviors with arguments. As such, it does not introduce any new security considerations over and abovewhat isthose already covered by <xreftarget="RFC9252"/>.</t>target="RFC9252" format="default"/>.</t> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9252.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8317.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8365.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/> <!-- ietf-spring-srv6-srh-compression published as RFC 9800--> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9800.xml"/> </references> </references> <section anchor="ACK"title="Acknowledgments">numbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors would like to acknowledgeJayshree Subramanian, Sonal Agarwal, Swadesh Agrawal, Dongling Duan, Luc Andre Burdet, Patrice Brissette, Senthil Sathappan, Erel Ortacdag, Neil Hart, Will Lockhart, and Vinod Prabhu<contact fullname="Jayshree Subramanian"/>, <contact fullname="Sonal Agarwal"/>, <contact fullname="Swadesh Agrawal"/>, <contact fullname="Dongling Duan"/>, <contact fullname="Luc AndrĂ© Burdet"/>, <contact fullname="Patrice Brissette"/>, <contact fullname="Senthil Sathappan"/>, <contact fullname="Erel Ortacdag"/>, <contact fullname="Neil Hart"/>, <contact fullname="Will Lockhart"/>, and <contact fullname="Vinod Prabhu"/> for theirinputsreview of the document and input on aspects related to the signaling of the End.DT2M SRv6 EndpointbehaviorBehavior that requiredclarification as also for their review of this document.clarification. The authors thankJeffrey Zhang<contact fullname="Jeffrey Zhang"/> for his shepherd reviewof the documentand suggestions forits improvements.improving the document. The authors would also like to thankGunter van<contact fullname="Gunter Van deVeldeVelde"/> for his extensive review and suggestions for improving the readability of the document.</t> </section></middle> <back> <references title="Normative References"> <?rfc include='reference.RFC.8986.xml'?> <?rfc include='reference.RFC.9252.xml'?> <?rfc include='reference.RFC.7432.xml'?> <?rfc include='reference.RFC.2119.xml'?> <?rfc include='reference.RFC.8402.xml'?> <?rfc include='reference.RFC.8174.xml'?> <?rfc include='reference.RFC.8317.xml'?> </references> <references title="Informative References"> <?rfc include='reference.RFC.8365.xml'?> <?rfc include='reference.RFC.8754.xml'?> <?rfc include='reference.I-D.ietf-spring-srv6-srh-compression'?> </references></back> <!-- [rfced] We have a few question about the text below. a) The following sentences include the descriptions of EVPN Route Types 1 and/or 3. Note that not all mentions of EVPN Route Types 1 and 3 include the descriptions. Would removing the descriptions in these sentences improve readability? If needed, perhaps the descriptions can be added to a Terminology section (which could be added as a new Section 1.2) or included in the first instance. b) Also, several forms are used for the description of EVPN Route Type 1: Ethernet Auto-Discovery per Ethernet Segment (A-D per ES) Ethernet Auto-Discovery (A-D) per ES Ethernet Auto-Discovery per Ethernet Segment Route Should the definition match what is listed in the IANA registry at <https://www.iana.org/assignments/evpn>? RFC 7432 and IANA registry define EVPN Route Type 1 as "Ethernet Auto-discovery", but RFC 7432 also discusses "Ethernet A-D per ES route" and "Ethernet A-D per EVI route". Original: As specified in [RFC9252], the LOC:FUNC portion of the SRv6 SID with End.DT2M behavior is signaled via EVPN Route Type 3 (Inclusive Multicast Ethernet Tag Route), while the Ethernet Segment Identifier (ESI) Filtering ARG (denoted as Arg.FE2 in [RFC8986]) is signaled via EVPN Route Type 1 (Ethernet Auto-Discovery per Ethernet Segment (A-D per ES) Route). In deployments where a mix of compressed and uncompressed SIDs is present, the behaviors advertised in the Ethernet Auto-Discovery (A-D) per ES Routes (EVPN Route Type 1) and Inclusive Multicast Ethernet Tag Routes (EVPN Route Type 3) MAY consist of a combination of compressed and uncompressed End.DT2M behavior flavors. Ethernet Auto-Discovery (A-D) per ES Routes (EVPN Route Type 1), as defined in [RFC7432], are utilized to enable split-horizon filtering and fast convergence in multi-homing scenarios. The Inclusive Multicast Ethernet Tag Route (EVPN Route Type 3), as defined in [RFC7432], is used to advertise multicast traffic reachability information via MP-BGP to all other PE routers within a given EVPN instance. When ESI Filtering is in use, the ESI Filtering ARG of the SRv6 Service SID is signaled through EVPN Route Type 1 (Ethernet Auto- Discovery per Ethernet Segment Route). Perhaps: As specified in [RFC9252], the LOC:FUNC portion of the SRv6 SID with End.DT2M behavior is signaled via EVPN Route Type 3, while the Ethernet Segment Identifier (ESI) Filtering ARG (denoted as Arg.FE2 in [RFC8986]) is signaled via EVPN Route Type 1. In deployments where a mix of compressed and uncompressed SIDs is present, the behaviors advertised in EVPN Route Type 1 and EVPN Route Type 3 MAY consist of a combination of compressed and uncompressed End.DT2M behavior flavors. EVPN Route Type 1, as defined in [RFC7432], is utilized to enable split-horizon filtering and fast convergence in multi-homing scenarios. EVPN Route Type 3, as defined in [RFC7432], is used to advertise multicast traffic reachability information via MP-BGP to all other PE routers within a given EVPN instance. When ESI Filtering is in use, the ESI Filtering ARG of the SRv6 Service SID is signaled through EVPN Route Type 1. --> <!-- [rfced] Terminology a) We updated two instance of "SRv6 Endpoint behavior" to "SRv6 Endpoint Behavior" to match usage elsewhere in the document and in RFC 9252. Should the two instances of "endpoint behavior" in the sentences below also be updated to "SRv6 Endpoint Behavior" (capitalized and prefaced with "SRv6")? Note that we did not make any changes to "End.DT2M behavior". Original: As specified in Section 3.2.1 of [RFC9252], the SRv6 SID Structure Sub-Sub-TLV MUST be included when signaling an SRv6 SID corresponding to an endpoint behavior that supports argument. ... While the focus is primarily on the signaling of the End.DT2M SRv6 Endpoint Behavior via EVPN Route Types 1 and 3, the procedures described herein are also applicable to other similar endpoint behaviors with arguments that may be signaled using BGP. b) We see that "BGP Prefix SID Attr" is used in the figures. Should this align with usage in general text? That is, should it be updated to "BGP Prefix-SID Attribute"? Also, should "BGP Prefix-SID Attribute" be updated to "BGP Prefix-SID attribute" (lowercase "attribute")? We see that the lowercase "attribute" is used in this context in RFC 9252 and other published RFCs. Current: BGP Prefix SID Attr (in figures) BGP Prefix-SID Attribute (in text) Perhaps: BGP Prefix-SID attribute c) We note that "Overlay Service" is capitalized in this document, but it is lowercase in RFC 9252. Would you like to use the lowercase "overlay service" for consistency with RFC 9252? d) We note inconsistencies in the terms below throughout the text. Should these be uniform? If so, please let us know which form is preferred. Route Type 1 EVPN Route Type 1 Route Type 3 EVPN Route Type 3 Leaf leaf e) We updated the following term as shown below. Let us know any concerns. Global Internet Routing > global Internet routing Note: Per usage in RFCs 9505, 9199, and others. --> <!-- [rfced] FYI - We have added expansions for the following abbreviation(s) per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Multiprotocol BGP (MP-BGP) --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> <!-- [rfced] Please review each artwork element in the xml file. Specifically, should the artwork elements in Figures 1-6 be tagged as sourcecode or another element? --> </rfc>