rfc9819xml2.original.xml   rfc9819.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std" docName="draft-ietf-bess-bgp-srv6-args-10"
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" ?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc subcompact="no" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-bess-bgp-srv6-args-10" number="9819" consensus="true" ipr="trust200902" updat es="9252" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" sym Refs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="SRv6 Argument Signaling for BGP Services">Segment Routing <title abbrev="SRv6 Argument Signaling for BGP Services">Argument Signaling
over IPv6 Argument Signaling for BGP Services</title> for BGP Services in Segment Routing over IPv6 (SRv6)</title>
<seriesInfo name="RFC" value="9819"/>
<author fullname="Ketan Talaulikar" initials="K" surname="Talaulikar"> <author fullname="Ketan Talaulikar" initials="K" surname="Talaulikar">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant.ietf@gmail.com</email> <email>ketant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Kamran Raza" initials="K" surname="Raza"> <author fullname="Kamran Raza" initials="K" surname="Raza">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>skraza@cisco.com</email> <email>skraza@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Jorge Rabadan" initials="J" surname="Rabadan"> <author fullname="Jorge Rabadan" initials="J" surname="Rabadan">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street/> <country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>jorge.rabadan@nokia.com</email> <email>jorge.rabadan@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Wen Lin" initials="W" surname="Lin"> <author fullname="Wen Lin" initials="W" surname="Lin">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street/> <country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>wlin@juniper.net</email> <email>wlin@juniper.net</email>
</address> </address>
</author> </author>
<date year="2025" month="July"/>
<date year=""/> <area>RTG</area>
<workgroup>bess</workgroup>
<area>Routing</area>
<workgroup>BESS Working Group</workgroup>
<keyword>BGP</keyword> <keyword>BGP</keyword>
<keyword>SRv6</keyword> <keyword>SRv6</keyword>
<abstract> <abstract>
<t>RFC9252 defines procedures and messages for BGP Overlay Services for <t>RFC 9252 defines procedures and messages for BGP overlay services for
Segment Routing over IPv6 (SRv6) including Layer 3 Virtual Private Segment Routing over IPv6 (SRv6), including Layer 3 Virtual Private
Network, Ethernet Virtual Private Network, and Global Internet Routing. Network (L3VPN), Ethernet VPN (EVPN), and global Internet routing.
This document updates RFC9252 and provides more detailed specifications This document updates RFC 9252 and provides more detailed specifications
for the signaling and processing of SRv6 Segment Identifiers for the signaling and processing of SRv6 Segment Identifier
advertisements for BGP Overlay Service routes associated with SRv6 advertisements for BGP overlay service routes associated with SRv6
Endpoint Behaviors that support arguments.</t> Endpoint Behaviors that support arguments.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="INTRO" title="Introduction"> <section anchor="INTRO" numbered="true" toc="default">
<name>Introduction</name>
<t>SRv6 refers to Segment Routing instantiated over the IPv6 data plane <t>SRv6 refers to Segment Routing instantiated over the IPv6 data plane
<xref target="RFC8402"/>. An SRv6 Segment Identifier (SID) <xref <xref target="RFC8402" format="default"/>. An SRv6 Segment Identifier (SID
target="RFC8402"/> can be associated with one of the service specific ) <xref target="RFC8402" format="default"/> can be associated with one of the se
SRv6 Endpoint behaviors on the advertising Provider Edge (PE) router for rvice-specific
Layer-3 Virtual Private Network (L3VPN), Global Internet Routing, and SRv6 Endpoint Behaviors on the advertising Provider Edge (PE) router for
Ethernet Virtual Private Network (EVPN) services as defined in <xref Layer 3 Virtual Private Network (L3VPN), global Internet routing, and
target="RFC8986"/>. Such SRv6 SIDs are referred to as SRv6 Service SIDs. Ethernet VPN (EVPN) services as defined in <xref target="RFC8986" format="
<xref target="RFC9252"/> defines the procedures and messages for the default"/>. Such SRv6 SIDs are referred to as SRv6 Service SIDs.
signaling of BGP Overlay Services including L3VPN, EVPN, and Internet <xref target="RFC9252" format="default"/> defines the procedures and messa
ges for the
signaling of BGP overlay services including L3VPN, EVPN, and Internet
services using SRv6.</t> services using SRv6.</t>
<t>For certain EVPN services, <xref target="RFC8986" section="4.12"/>
<t>For certain EVPN services, <xref target="RFC8986"/> (section 4.12)
introduced the End.DT2M SRv6 Endpoint Behavior, which utilizes arguments introduced the End.DT2M SRv6 Endpoint Behavior, which utilizes arguments
(i.e., Arg.FE2). <xref target="RFC9252"/> subsequently specified the (i.e., Arg.FE2). <xref target="RFC9252" format="default"/> subsequently sp ecified the
encoding and signaling procedures for the SRv6 SID and its associated encoding and signaling procedures for the SRv6 SID and its associated
argument via EVPN Route Type 3 and EVPN Route Type 1, respectively. argument via the Inclusive Multicast Ethernet Tag route (EVPN Route Type 3 ) and the Ethernet A-D (Auto-Discovery) per ES route (EVPN Route Type 1), respec tively.
However, during implementation and interoperability testing, it was However, during implementation and interoperability testing, it was
observed that the specifications outlined in <xref target="RFC9252"/> observed that the specifications outlined in <xref target="RFC9252" format
lacked sufficient detail, leading to ambiguities in interpretation and ="default"/>
lack sufficient detail, leading to ambiguities in interpretation and
implementation.</t> implementation.</t>
<t>This document updates <xref target="RFC9252" format="default"/> by prov
<t>This document updates <xref target="RFC9252"/> by providing iding
additional details and clarifications regarding the signaling of SRv6 additional details and clarifications regarding the signaling of SRv6
Service SIDs associated with SRv6 Endpoint Behaviors that utilize Service SIDs associated with SRv6 Endpoint Behaviors that utilize
arguments. While the focus is primarily on the signaling of the End.DT2M 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 SRv6 Endpoint Behavior via the Ethernet A-D per ES route and Inclusive Mul
described herein are also applicable to other similar endpoint behaviors ticast Ethernet Tag route, the procedures
described herein are also applicable to other similar SRv6 Endpoint Behavi
ors
with arguments that may be signaled using BGP.</t> with arguments that may be signaled using BGP.</t>
<t>Section 6.3 of <xref target="RFC9252"/> specifies that the SRv6 <t><xref target="RFC9252" section="6.3"/> specifies that the SRv6
Service SID used in the data plane is derived by applying a bitwise Service SID used in the data plane is derived by applying a bitwise
logical-OR operation between the SID with argument signaled via Route logical-OR operation between the SID with an argument signaled via the Eth
Type 1 and the SID with the 'locator + function' components signaled via ernet A-D per ES route
Route Type 3. However, this approach assumes a uniform SID structure and the SID with the 'Locator + Function' components signaled via the
across all SIDs advertised via EVPN Route Types 1 and 3. This assumption Inclusive Multicast Ethernet Tag route. However, this approach assumes a u
niform SID structure
across all SIDs advertised via the Ethernet A-D per ES route and Inclusive
Multicast Ethernet Tag route. This assumption
is not universally valid, and the procedures in this document remove is not universally valid, and the procedures in this document remove
this restriction, ensuring greater flexibility in SRv6 SID this restriction, ensuring greater flexibility in SRv6 SID
signaling.</t> signaling.</t>
<t>The descriptions and examples presented in this document do not <t>The descriptions and examples presented in this document do not
utilize the Transposition Scheme (see section 4 of <xref utilize the Transposition Scheme (see <xref target="RFC9252" section="4"/>
target="RFC9252"/>). Consequently, the Transposition Offset (TPOS-O) and ). Consequently, the Transposition Offset (TPOS-O) and
Transposition Length (TPOS-L) are set to zero, and references to MPLS Transposition Length (TPOS-L) are set to zero, and references to MPLS
label fields where the function or argument portions may be transposed label fields where the function or argument portions may be transposed
are omitted. However, the same examples could be applied with the are omitted. However, the same examples could be applied with the
Transposition Scheme. This document does not introduce any modifications Transposition Scheme. This document does not introduce any modifications
to the use of the Transposition Scheme in the signaling of EVPN Routes. to the use of the Transposition Scheme in the signaling of EVPN routes.
Implementations are expected to adhere to the procedures and Implementations are expected to adhere to the procedures and
recommendations specified in <xref target="RFC9252"/> concerning the recommendations specified in <xref target="RFC9252" format="default"/> con cerning the
Transposition Scheme.</t> Transposition Scheme.</t>
<section anchor="REQ" numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section anchor="REQ" title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
</section> </section>
<section anchor="SIDANDARGS" numbered="true" toc="default">
<section anchor="SIDANDARGS" <name>Advertisement of SRv6 SID and Arguments</name>
title="Advertisement of SRv6 SID and Arguments"> <t><xref target="RFC8986" section="3.1"/> defines the format of an SRv6
<t>Section 3.1 of <xref target="RFC8986"/> defines the format of an SRv6
SID as consisting of three components: Locator (LOC), Function (FUNC), SID as consisting of three components: Locator (LOC), Function (FUNC),
and Argument (ARG). For SRv6 SIDs associated with SRv6 Endpoint and Argument (ARG). For SRv6 SIDs associated with SRv6 Endpoint
Behaviors that do not support arguments, the ARG component is not Behaviors that do not support arguments, the ARG component is not
present. Consequently, all bits following the FUNC portion MUST be set present. Consequently, all bits following the FUNC portion <bcp14>MUST</bc
to zero, and the argument length MUST be zero.</t> p14> be set
to zero, and the Argument Length (AL) <bcp14>MUST</bcp14> be zero.</t>
<t>Certain SRv6 Endpoint Behaviors (e.g., End.DT2M) support arguments. <t>Certain SRv6 Endpoint Behaviors (e.g., End.DT2M) support arguments.
As specified in Section 3.2.1 of <xref target="RFC9252"/>, the SRv6 SID As specified in <xref target="RFC9252" section="3.2.1"/>, the SRv6 SID
Structure Sub-Sub-TLV MUST be included when signaling an SRv6 SID Structure Sub-Sub-TLV <bcp14>MUST</bcp14> be included when signaling an SR
corresponding to an endpoint behavior that supports argument. This v6 SID
corresponding to an SRv6 Endpoint Behavior that supports argument. This
ensures that the receiving router can perform consistency verification ensures that the receiving router can perform consistency verification
of the argument and correctly encode the ARG value within the SRv6 of the argument and correctly encode the ARG value within the SRv6
SID.</t> SID.</t>
<t>In certain use cases, the SRv6 SID can be signaled as a complete <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 structure, with the LOC:FUNC:ARG components fully encoded within the
SID. However, there are scenarios where the SRv6 SID, consisting only of SID. However, there are scenarios where the SRv6 SID, consisting only of
the LOC:FUNC portion, is signaled in one advertisement, while the ARG the LOC:FUNC portion, is signaled in one advertisement, while the ARG
value is either signaled through a separate advertisement or learned via value is either signaled through a separate advertisement or learned via
an alternative mechanism. It is the responsibility of the SRv6 Source an alternative mechanism. It is the responsibility of the SRv6 source
Node to append the ARG component to the LOC:FUNC portion, thereby node to append the ARG component to the LOC:FUNC portion, thereby
constructing the complete SRv6 SID (LOC:FUNC:ARG). This fully-formed SID constructing the complete SRv6 SID (LOC:FUNC:ARG). This fully formed SID
can then be utilized in the data plane, either as the IPv6 destination 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 address of a packet or as a segment within the Segment Routing Header
(SRH) <xref target="RFC8754"/>, as required.</t> (SRH) <xref target="RFC8754" format="default"/>, as required.</t>
<t>Since arguments may be optional, the SRv6 endpoint node that owns the
<t>Since arguments may be optional, the SRv6 Endpoint Node that owns the SID <bcp14>MUST</bcp14> advertise the SRv6 SID Structure Sub-Sub-TLV along
SID MUST advertise the SRv6 SID Structure Sub-Sub-TLV along with the with the
LOC:FUNC portion of the SRv6 SID to indicate whether arguments are LOC:FUNC portion of the SRv6 SID to indicate whether arguments are
supported for that specific SID. A zero Argument Length (AL) value supported for that specific SID. A zero AL value
indicates that the node does not accept an argument for the given SRv6 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 SID. Conversely, a non-zero AL value specifies the size of the supported
argument, along with the Locator Block Length (LBL), Locator Node Length argument, along with the Locator Block Length (LBL), Locator Node Length
(LNL), and Function Length (FL) parameters, which define the offset from (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 which the node expects the ARG to be encoded. All bits beyond LBL + LNL
+ FL + AL MUST be set to zero.</t> + FL + AL <bcp14>MUST</bcp14> be set to zero.</t>
<t>The advertisement of the ARG value may be performed either by the <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 node that owns the SRv6 SID and is advertising the LOC:FUNC portion of
that SID, or by another node/mechanism. The advertisement of the ARG that SID or by another node/mechanism. The advertisement of the ARG
value MUST specify the size of the argument, its value, and the value <bcp14>MUST</bcp14> specify the size of the argument, its value, and
the
associated SRv6 Endpoint Behavior of the SID. Additionally, the associated SRv6 Endpoint Behavior of the SID. Additionally, the
specification of the association of the ARG advertisement with the specification of the association of the ARG advertisement with the
corresponding SID(s) for which the argument applies is REQUIRED.</t> corresponding SID(s) for which the argument applies is <bcp14>REQUIRED</bc p14>.</t>
</section> </section>
<section anchor="EVPNESI" numbered="true" toc="default">
<section anchor="EVPNESI" <name>End.DT2M Signaling for EVPN ESI Filtering</name>
title="End.DT2M Signaling for EVPN ESI Filtering"> <t>As specified in <xref target="RFC9252" format="default"/>, the
<t>As specified in <xref target="RFC9252"/>, the LOC:FUNC portion of the LOC:FUNC portion of the SRv6 SID with End.DT2M behavior is signaled via th
SRv6 SID with End.DT2M behavior is signaled via EVPN Route Type 3 e
(Inclusive Multicast Ethernet Tag Route), while the Ethernet Segment Inclusive Multicast Ethernet Tag route, while the Ethernet Segment
Identifier (ESI) Filtering ARG (denoted as Arg.FE2 in <xref Identifier (ESI) Filtering ARG (denoted as Arg.FE2 in <xref
target="RFC8986"/>) is signaled via EVPN Route Type 1 (Ethernet target="RFC8986" format="default"/>)
Auto-Discovery per Ethernet Segment (A-D per ES) Route). The following is signaled via the Ethernet A-D per ES route. The
subsections provide a more detailed specification of the signaling and following subsections provide a more detailed specification of the
processing mechanisms compared to <xref target="RFC9252"/>.</t> signaling and processing mechanisms compared to <xref target="RFC9252"
format="default"/>.</t>
<t>ESI Filtering is a split-horizon mechanism used for Multi-Homing <t>ESI Filtering is a split-horizon mechanism used for multihoming
<xref target="RFC7432"/> or Ethernet-Tree (E-Tree) procedures <xref <xref target="RFC7432" format="default"/> or Ethernet-Tree (E-Tree) proced
target="RFC8317"/>. ESI Filtering is not applicable in scenarios ures <xref target="RFC8317" format="default"/>. ESI Filtering is not applicable
where:<list style="symbols"> in scenarios
where:</t>
<ul spacing="normal">
<li>
<t>No E-Tree leaf Broadcast, Unknown Unicast, or Multicast (BUM) <t>No E-Tree leaf Broadcast, Unknown Unicast, or Multicast (BUM)
traffic exists,</t> traffic exists,</t>
</li>
<t>No multi-homing is present,</t> <li>
<t>No multihoming is present,</t>
</li>
<li>
<t>No split-horizon mechanism is required, or</t> <t>No split-horizon mechanism is required, or</t>
</li>
<t>The local-bias method (as specified in <xref target="RFC8365"/>) <li>
<t>The "Local Bias" method (as specified in <xref target="RFC8365" for
mat="default"/>)
is employed.</t> is employed.</t>
</list></t> </li>
</ul>
<t>In this document, "ESI Filtering" is used as a general reference to <t>In this document, "ESI Filtering" is used as a general reference to
the procedure performed by the disposition Provider Edge (PE) router to the procedure performed by the disposition Provider Edge (PE) router to
prevent forwarding of BUM traffic to local Ethernet Segments or local prevent forwarding of BUM traffic to local Ethernet Segments or local
leaf attachment circuits, based on the presence of the ESI Filtering leaf attachment circuits, based on the presence of the ESI Filtering
ARG.</t> ARG.</t>
<t>The signaling and processing descriptions outlined in the following <t>The signaling and processing descriptions outlined in the following
sections also apply to End.DT2M behavior flavors designed for SRv6 SID sections also apply to End.DT2M behavior flavors designed for SRv6 SID
list compression <xref target="I-D.ietf-spring-srv6-srh-compression"/>. list compression <xref target="RFC9800" format="default"/>. In
In deployments where a mix of compressed and uncompressed SIDs is deployments where a mix of compressed and uncompressed SIDs is present,
present, the behaviors advertised in the Ethernet Auto-Discovery (A-D) the behaviors advertised in the Ethernet A-D per ES routes and Inclusive
per ES Routes (EVPN Route Type 1) and Inclusive Multicast Ethernet Tag Multicast Ethernet Tag routes <bcp14>MAY</bcp14> consist of a
Routes (EVPN Route Type 3) MAY consist of a combination of compressed combination of compressed and uncompressed End.DT2M behavior flavors.
and uncompressed End.DT2M behavior flavors. The procedures in this The procedures in this document remain valid for such deployments
document remain valid for such deployments provided that the argument provided that the AL consistency checks between the Ethernet A-D per ES ro
length consistency checks between EVPN Route Type 1 and EVPN Route Type ute and
3, as described in the following subsections, are satisfied.</t> Inclusive Multicast Ethernet Tag route, as described in the following subs
ections, are
<section anchor="RT1" title="Advertisement of Ethernet A-D per ES Route"> satisfied.</t>
<t>Ethernet Auto-Discovery (A-D) per ES Routes (EVPN Route Type 1), as <section anchor="RT1" numbered="true" toc="default">
defined in <xref target="RFC7432"/>, are utilized to enable <name>Advertisement of Ethernet A-D per ES Route</name>
split-horizon filtering and fast convergence in multi-homing <t>Ethernet A-D per ES routes, as
scenarios. Additionally, A-D per ES Routes facilitate egress filtering defined in <xref target="RFC7432" format="default"/>, are utilized to en
of BUM traffic originating from a Leaf, as specified in <xref able
target="RFC8317"/>.</t> split-horizon filtering and fast convergence in multihoming
scenarios. Additionally, Ethernet A-D per ES routes facilitate egress fi
ltering
of BUM traffic originating from a leaf, as specified in <xref target="RF
C8317" format="default"/>.</t>
<t>When ESI Filtering is not in use, no ESI Filtering ARG is required <t>When ESI Filtering is not in use, no ESI Filtering ARG is required
to be conveyed. However, for backward compatibility and consistency to be conveyed. However, for backward compatibility and consistency
with <xref target="RFC9252"/>, the advertisement of this route SHOULD with <xref target="RFC9252" format="default"/>, the advertisement of thi
include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV s route <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 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 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 End.DT2M behavior supports the use of an ARG, an SRv6 SID Structure
Sub-Sub-TLV MUST be included. As no ARG value is required to be Sub-Sub-TLV <bcp14>MUST</bcp14> be included. As no ARG value is required
signaled in this case, the AL MUST be set to 0.</t> to be
signaled in this case, the AL <bcp14>MUST</bcp14> be set to 0.</t>
<t>Following is an example representation of the BGP Prefix-SID <t>The following is an example representation of the BGP Prefix-SID
Attribute encoding in this case:</t> attribute encoding in this case:</t>
<figure anchor="RT1NOARG">
<figure anchor="RT1NOARG" <name>Ethernet A-D per ES Route Without ARG for ESI Filtering</name>
title="EVPN Route Type 1 without ARG for ESI Filtering"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ BGP Prefix-SID attribute:
BGP Prefix SID Attr:
SRv6 L2 Service TLV: SRv6 L2 Service TLV:
SRv6 SID Information Sub-TLV: SRv6 SID Information Sub-TLV:
SID: :: SID: ::
Behavior: End.DT2M Behavior: End.DT2M
SRv6 SID Structure Sub-Sub-TLV: SRv6 SID Structure Sub-Sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0 LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0
]]></artwork> ]]></artwork>
</figure> </figure>
<t>When ESI Filtering is in use, the advertisement of this route <bcp14>
<t>When ESI Filtering is in use, the advertisement of this route MUST MUST</bcp14>
include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV include the BGP Prefix-SID attribute with an SRv6 L2 Service TLV
carrying the SRv6 Service SID that contains the ESI Filtering ARG carrying the SRv6 Service SID that contains the ESI Filtering ARG
value within the SRv6 SID Information Sub-TLV (when not using the value within the SRv6 SID Information Sub-TLV (when not using the
Transposition Scheme), with the SRv6 Endpoint Behavior set to Transposition Scheme), with the SRv6 Endpoint Behavior set to
End.DT2M. Since the End.DT2M behavior supports the use of an ARG, an End.DT2M. Since the End.DT2M behavior supports the use of an ARG, an
SRv6 SID Structure Sub-Sub-TLV MUST be included. Additionally, as a SRv6 SID Structure Sub-Sub-TLV <bcp14>MUST</bcp14> be included. Addition
non-zero ARG value is being signaled, the Argument Length (AL) MUST be ally, as a
set to the size of the ARG, and the size SHOULD be a multiple of 8 to non-zero ARG value is being signaled, the AL <bcp14>MUST</bcp14> be
set to the size of the ARG, and the size <bcp14>SHOULD</bcp14> be a mult
iple of 8 to
ensure consistency across implementations for ease of operations. The ensure consistency across implementations for ease of operations. The
SRv6 SID Structure Sub-Sub-TLV MUST set the Locator Block Length SRv6 SID Structure Sub-Sub-TLV <bcp14>MUST</bcp14> set the
(LBL), Locator Node Length (LNL), and Function Length (FL) fields with LBL, LNL, and FL fields with
values that indicate the offset at which the ARG value is encoded values that indicate the offset at which the ARG value is encoded
within the 128-bit SRv6 SID.</t> within the 128-bit SRv6 SID.</t>
<t>The following is an example representation of the BGP Prefix-SID <t>The following is an example representation of the BGP Prefix-SID
Attribute encoding in this scenario for a 16-bit argument value of attribute encoding in this scenario for a 16-bit argument value of
'aaaa':</t> 'aaaa':</t>
<figure anchor="RT1ARG">
<figure anchor="RT1ARG" <name>Ethernet A-D per ES Route with ARG for ESI Filtering</name>
title="EVPN Route Type 1 with ARG for ESI Filtering"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ BGP Prefix-SID attribute:
BGP Prefix SID Attr:
SRv6 L2 Service TLV: SRv6 L2 Service TLV:
SRv6 SID Information Sub-TLV: SRv6 SID Information Sub-TLV:
SID: ::aaaa:0:0:0 SID: ::aaaa:0:0:0
Behavior: End.DT2M Behavior: End.DT2M
SRv6 SID Structure Sub-Sub-TLV: SRv6 SID Structure Sub-Sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0 LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0
]]></artwork> ]]></artwork>
</figure> </figure>
<t>In the examples above, it would have been possible to set the LBL, <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 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 aaaa::. However, such an encoding would not be backward compatible
with <xref target="RFC9252"/>, as further detailed in <xref with <xref target="RFC9252" format="default"/>, as further detailed in <
target="BACKWARD"/>.</t> xref target="BACKWARD" format="default"/>.</t>
<t>Therefore, it is <bcp14>REQUIRED</bcp14> that the LBL, LNL, and FL va
<t>Therefore, it is REQUIRED that the LBL, LNL, and FL values be set lues be set
in accordance with the SID Structure for End.DT2M SRv6 Service SIDs, in accordance with the SID structure for End.DT2M SRv6 Service SIDs,
ensuring compliance with <xref target="RFC9252"/>.</t> ensuring compliance with <xref target="RFC9252" format="default"/>.</t>
</section> </section>
<section anchor="RT3" numbered="true" toc="default">
<section anchor="RT3" <name>Advertisement of Inclusive Multicast Ethernet Tag Route</name>
title="Advertisement of Inclusive Multicast Ethernet Tag Route"> <t>The Inclusive Multicast Ethernet Tag route, as
<t>The Inclusive Multicast Ethernet Tag Route (EVPN Route Type 3), as defined in <xref target="RFC7432" format="default"/>, is used to adverti
defined in <xref target="RFC7432"/>, is used to advertise multicast se multicast
traffic reachability information via MP-BGP to all other PE routers traffic reachability information via Multiprotocol BGP (MP-BGP) to all o
ther PE routers
within a given EVPN instance. When utilizing SRv6 transport, the within a given EVPN instance. When utilizing SRv6 transport, the
advertisement of this route MUST include the BGP Prefix-SID Attribute advertisement of this route <bcp14>MUST</bcp14> include the BGP Prefix-S ID attribute
with an SRv6 L2 Service TLV to indicate the use of SRv6.</t> 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 SID <t>Regardless of whether ESI Filtering is in use, the SRv6 Service SID
MUST include only the LOC:FUNC portion within the SRv6 SID Information <bcp14>MUST</bcp14> include only the LOC:FUNC portion within the SRv6 SI D Information
Sub-TLV (when not utilizing the Transposition Scheme), with the SRv6 Sub-TLV (when not utilizing the Transposition Scheme), with the SRv6
Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior
supports the use of an ARG, an SRv6 SID Structure Sub-Sub-TLV MUST be supports the use of an ARG, an SRv6 SID Structure Sub-Sub-TLV <bcp14>MUS
included. The LBL, LNL, and FL fields MUST be set to indicate the T</bcp14> be
included. The LBL, LNL, and FL fields <bcp14>MUST</bcp14> be set to indi
cate the
structure of the SRv6 Service SID being advertised.</t> structure of the SRv6 Service SID being advertised.</t>
<t>When ESI Filtering is not in use, no ARG is expected to be received <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, by the router along with the advertised SRv6 Service SID. Therefore,
the AL MUST be set to 0.</t> the AL <bcp14>MUST</bcp14> be set to 0.</t>
<t>The following is an example representation of the BGP Prefix-SID
<t>Following is an example representation of the BGP Prefix-SID attribute encoding in this case:</t>
Attribute encoding in this case:</t> <figure anchor="RT3NOARG">
<name>Inclusive Multicast Ethernet Tag Route Without ESI Filtering</na
<figure anchor="RT3NOARG" me>
title="EVPN Route Type 3 without ESI Filtering"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ BGP Prefix-SID attribute:
BGP Prefix SID Attr:
SRv6 L2 Service TLV: SRv6 L2 Service TLV:
SRv6 SID Information Sub-TLV: SRv6 SID Information Sub-TLV:
SID: 2001:db8:1:fbd1:: SID: 2001:db8:1:fbd1::
Behavior: End.DT2M Behavior: End.DT2M
SRv6 SID Structure Sub-Sub-TLV: SRv6 SID Structure Sub-Sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0 LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0
]]></artwork> ]]></artwork>
</figure> </figure>
<t>When ESI Filtering is in use, the router expects to receive traffic <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 in the data path to the SRv6 Service SID that it has signaled along
with the ARG portion embedded in it. Consequently, the AL MUST be set with the ARG portion embedded in it. Consequently, the AL <bcp14>MUST</b cp14> be set
to the size of the ARG supported by the advertising router for the 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 specific SRv6 Service SID. The AL value is unique per End.DT2M
behavior signaled by the egress PE. Therefore, the egress PE MUST use behavior signaled by the egress PE. Therefore, the egress PE <bcp14>MUST
the same AL for all local Ethernet Segments with Attachment Circuits </bcp14> use
within the same Broadcast Domain.</t> the same AL for all local Ethernet Segments with attachment circuits
within the same broadcast domain.</t>
<t>The following is an example representation of the BGP Prefix-SID <t>The following is an example representation of the BGP Prefix-SID
Attribute encoding for this scenario with a 16-bit argument:</t> attribute encoding for this scenario with a 16-bit argument:</t>
<figure anchor="RT3ARG">
<figure anchor="RT3ARG" title="EVPN Route Type 3 with ESI Filtering"> <name>Inclusive Multicast Ethernet Tag Route with ESI Filtering</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
BGP Prefix SID Attr: BGP Prefix-SID attribute:
SRv6 L2 Service TLV: SRv6 L2 Service TLV:
SRv6 SID Information Sub-TLV: SRv6 SID Information Sub-TLV:
SID: 2001:db8:1:fbd1:: SID: 2001:db8:1:fbd1::
Behavior: End.DT2M Behavior: End.DT2M
SRv6 SID Structure Sub-Sub-TLV: SRv6 SID Structure Sub-Sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0 LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0
]]></artwork> ]]></artwork>
</figure> </figure>
<t>When ESI Filtering is in use, the advertising router <bcp14>MUST</bcp
<t>When ESI Filtering is in use, the advertising router MUST ensure 14> ensure
that the AL signaled in the EVPN Route Type 3 is equal to the AL that the AL signaled in the Inclusive Multicast Ethernet Tag route is eq
signaled in the corresponding EVPN Route Type 1.</t> ual to the AL
signaled in the corresponding Ethernet A-D per ES route.</t>
</section> </section>
<section anchor="PROC" numbered="true" toc="default">
<section anchor="PROC" title="Processing at Ingress PE"> <name>Processing at Ingress PE</name>
<t>An ingress PE receives the LOC:FUNC portion of the SRv6 Service SID <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 to be used for BUM traffic through Inclusive Multicast Ethernet Tag rout e
advertisements.</t> advertisements.</t>
<t>When ESI Filtering is not in use, the SRv6 Service SID to be used <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 consists solely of the LOC:FUNC portion received via the Inclusive Multi
3.</t> cast Ethernet Tag route.
</t>
<t>When ESI Filtering is in use, the ESI Filtering ARG of the SRv6 <t>When ESI Filtering is in use, the ESI Filtering ARG of the SRv6
Service SID is signaled through EVPN Route Type 1 (Ethernet Service SID is signaled through the Ethernet A-D per ES route.
Auto-Discovery per Ethernet Segment Route). The ARG, in combination The ARG, in combination
with the LOC:FUNC portion received via EVPN Route Type 3, forms the with the LOC:FUNC portion received via the Inclusive Multicast Ethernet
Tag route, forms the
SRv6 Service SID to be used.</t> SRv6 Service SID to be used.</t>
<t>Since the LOC:FUNC and ARG portions of the SRv6 Service SID are <t>Since the LOC:FUNC and ARG portions of the SRv6 Service SID are
signaled via different route advertisements, there may be cases where signaled via different route advertisements, there may be cases where
the ingress PE receives inconsistent AL values from the two route 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., 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 when forwarding BUM traffic to other PEs attached to a shared Ethernet
Segment) but does not receive a usable ARG value during processing, it Segment) but does not receive a usable ARG value during processing, it
SHOULD log a message to facilitate troubleshooting.</t> <bcp14>SHOULD</bcp14> log a message to facilitate troubleshooting.</t>
<t>The ingress PE router <bcp14>MUST</bcp14> follow the processing steps
<t>The ingress PE router MUST follow the processing steps outlined outlined
below when handling SRv6 Service SID advertisements:</t> below when handling SRv6 Service SID advertisements:</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers"> <t>If AL=0 is signaled via the Inclusive Multicast Ethernet Tag rout
<t>If AL=0 is signaled via EVPN Route Type 3, then the egress PE e, then the egress PE
either does not support ESI Filtering or does not require ESI either does not support ESI Filtering or does not require an ESI
Filtering ARG for the specific SID. In this case, the SRv6 Service Filtering ARG for the specific SID. In this case, the SRv6 Service
SID is formed using only the LOC:FUNC portion, and all bits after SID is formed using only the LOC:FUNC portion, and all bits after
LBL+LNL+FL MUST be set to zero for encoding on the data path. LBL + LNL + FL <bcp14>MUST</bcp14> be set to zero for encoding on th
Additionally, the router MUST ignore the SID value and its SID e data path.
structure advertised in the corresponding EVPN Route Type 1.</t> Additionally, the router <bcp14>MUST</bcp14> ignore the SID value an
d its SID
<t>If a non-zero AL is signaled via EVPN Route Type 3, then the structure advertised in the corresponding Ethernet A-D per ES route.
matching EVPN Route Type 1 for the Ethernet Segment is located and </t>
</li>
<li>
<t>If a non-zero AL is signaled via the Inclusive Multicast Ethernet
Tag route, then the
matching Ethernet A-D per ES route for the Ethernet Segment is locat
ed and
the presence of an SRv6 SID advertisement with the End.DT2M the presence of an SRv6 SID advertisement with the End.DT2M
behavior is verified.<list style="letters"> behavior is verified.</t>
<ol spacing="normal" type="a"><li>
<t>If the presence of such a SRv6 SID is not verified, or if <t>If the presence of such a SRv6 SID is not verified, or if
the AL=0 in the EVPN Route Type 1, then no usable ARG value is the AL is zero in the Ethernet A-D per ES route, then no usable
available. The SRv6 Service SID MUST be formed as described in ARG value is
available. The SRv6 Service SID <bcp14>MUST</bcp14> be formed as
described in
(1) above.</t> (1) above.</t>
</li>
<t>If the AL values in EVPN Route Type 1 and EVPN Route Type 3 <li>
<t>If the AL values in the Ethernet A-D per ES route and Inclusi
ve Multicast Ethernet Tag route
are both non-zero but not equal, then no usable ARG value is are both non-zero but not equal, then no usable ARG value is
available. This inconsistency in signaling from the egress PE available. This inconsistency in signaling from the egress PE
indicates a configuration error. To prevent potential looping, indicates a configuration error. To prevent potential looping,
BUM traffic MUST NOT be forwarded for such routes from the BUM traffic <bcp14>MUST NOT</bcp14> be forwarded for such routes
specific Ethernet Segment. Implementations SHOULD log an error from the
specific Ethernet Segment. Implementations <bcp14>SHOULD</bcp14>
log an error
message for troubleshooting this condition.</t> message for troubleshooting this condition.</t>
</li>
<t>If the AL values in EVPN Route Type 1 and EVPN Route Type 3 <li>
are both non-zero and equal, then the ARG value from EVPN <t>If the AL values in the Ethernet A-D per ES route and Inclusi
Route Type 1 is considered valid. This ARG value MUST be ve Multicast Ethernet Tag route
are both non-zero and equal, then the ARG value from the
Ethernet A-D per ES route is considered valid. This ARG value <b
cp14>MUST</bcp14> be
encoded within the SRv6 SID (LOC:FUNC) at the ARG offset as encoded within the SRv6 SID (LOC:FUNC) at the ARG offset as
specified in the SID structure (i.e., LBL + LNL + FL) in EVPN specified in the SID structure (i.e., LBL + LNL + FL) in the
Route Type 3. All bits beyond LBL + LNL + FL + AL MUST be set Inclusive Multicast Ethernet Tag route. All bits beyond LBL + LN
L + FL + AL <bcp14>MUST</bcp14> be set
to zero.</t> to zero.</t>
</list></t> </li>
</list></t> </ol>
</li>
<t>Based on the above procedures, the SRv6 Service SID encoding for </ol>
the data plane without an ESI Filtering ARG, based on the examples in
<xref target="RT1NOARG"/> and <xref target="RT3NOARG"/>, is as
follows:</t>
<figure anchor="SIDPACKET" <t>Using the procedures above with the examples in Figures
title="SRv6 Service SID Encoding for Data Plane without ARG"> <xref target="RT1NOARG" format="counter"/> and <xref target="RT3NOARG" f
<artwork><![CDATA[ ormat="counter"/>, the
Route Type 3: SRv6 Service SID encoding for the
data plane without an ESI Filtering ARG
is as follows:
</t>
<figure anchor="SIDPACKET">
<name>SRv6 Service SID Encoding for Data Plane Without ARG</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Inclusive Multicast Ethernet Tag route:
SID: 2001:db8:1:fbd1:: SID: 2001:db8:1:fbd1::
Structure: LBL: 32, LNL: 16, FL: 16, AL: 0 Structure: LBL: 32, LNL: 16, FL: 16, AL: 0
SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1:: SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1::
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Using the procedures above with the examples in
<t>Based on the above procedures, the SRv6 Service SID encoding for Figures <xref target="RT1ARG" format="counter"/> and <xref target="RT3AR
the data plane along with an ESI Filtering ARG, based on the examples G" format="counter"/>, the
in <xref target="RT1ARG"/> and <xref target="RT3ARG"/>, is as SRv6 Service SID encoding for the
follows:</t> data plane along with an ESI Filtering ARG
is as follows:
<figure anchor="SIDPACKETARG" </t>
title="SRv6 Service SID Encoding for Data Plane with ARG"> <figure anchor="SIDPACKETARG">
<artwork><![CDATA[Route Type 1: <name>SRv6 Service SID Encoding for Data Plane with ARG</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Ethernet A-D per ES route:
SID: ::aaaa:0:0:0 SID: ::aaaa:0:0:0
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16 Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
Route Type 3: Inclusive Multicast Ethernet Tag route:
SID: 2001:db8:1:fbd1:: SID: 2001:db8:1:fbd1::
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16 Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1:aaaa:: SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1:aaaa::
]]></artwork> ]]></artwork>
</figure> </figure>
<t><xref target="MULTIBD" format="default"/> provides another example th
<t><xref target="MULTIBD"/> provides another example that illustrates at illustrates
the signaling and processing of multiple bridge domains in a the signaling and processing of multiple bridge domains in a
deployment design.</t> deployment design.</t>
<figure anchor="MULTIBD">
<t><figure anchor="MULTIBD" <name>Example with Multiple Bridge Domains</name>
title="Example with Multiple Bridge Domains"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+--------------------------------+ +--------------------------------+
| | | |
PE1 | | PE1 | |
+---------+ | +---------+ |
BUM on BD1 | +-----+ | | BUM on BD1 | +-----+ | |
+----------------> | BD1 |-------------+ | +----------------> | BD1 |-------------+ |
| | +-----+ | | | | | +-----+ | | |
| BUM on BD2 | +-----+ | v PE3 | | BUM on BD2 | +-----+ | v PE3 |
| +--------------> | BD2 |-------+ +---------+ | +--------------> | BD2 |-------+ +---------+
| | +-----| +-----+ | | | +-----+ | | | +-----| +-----+ | | | +-----+ |
skipping to change at line 537 skipping to change at line 475
| +-----+ | | FL:16 FL:32 | | +-----+ | | FL:16 FL:32 |
| +-----+ | RT1 | | +-----+ | RT1 |
| | BD2 | | ESI-1 | | | BD2 | | ESI-1 |
| +-----+ | AL:16 | | +-----+ | AL:16 |
+---------+ | +---------+ |
PE2 | | PE2 | |
| | | |
| | | |
+-------------------------------+ +-------------------------------+
Route Type 1 ESI-1: Ethernet A-D per ES route for ESI-1:
SID: ::aaaa:0:0:0 SID: ::aaaa:0:0:0
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16 Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
Route Type 3 from BD1: Inclusive Multicast Ethernet Tag route from BD1:
SID: 2001:db8:1:fbd1:fbd1: SID: 2001:db8:1:fbd1:fbd1:
Structure: LBL: 32, LNL: 16, FL: 32, AL: 16 Structure: LBL: 32, LNL: 16, FL: 32, AL: 16
Route Type 3 from BD2: Inclusive Multicast Ethernet Tag route from BD2:
SID: 2001:db8:1:fbd2:: SID: 2001:db8:1:fbd2::
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16 Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
SRv6 Service SID for datapath from ingress PE1 to egress PE2 on BD1: SRv6 Service SID for datapath from ingress PE1 to egress PE2 on BD1:
2001:db8:1:fbd1:fbd1:aaaa:: 2001:db8:1:fbd1:fbd1:aaaa::
SRv6 Service SID for datapath from ingress PE1 to egress PE2 on BD2: SRv6 Service SID for datapath from ingress PE1 to egress PE2 on BD2:
2001:db8:1:fbd2:aaaa:: 2001:db8:1:fbd2:aaaa::
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
</section> </section>
<section anchor="BACKWARD" numbered="true" toc="default">
<section anchor="BACKWARD" title="Backward Compatibility"> <name>Backward Compatibility</name>
<t>Existing implementations that rely on the bitwise logical-OR <t>Existing implementations that rely on the bitwise logical-OR
operation, as specified in Section 6.3 of <xref target="RFC9252"/>, operation, as specified in <xref target="RFC9252" section="6.3"/>,
function correctly only when the SID structures of the two EVPN Route function correctly only when the SID structures of the two EVPN route
Types are identical.</t> types are identical.</t>
<t>Backward compatibility with implementations performing the bitwise <t>Backward compatibility with implementations performing the bitwise
logical-OR operation is maintained when EVPN Route Type 3 and its logical-OR operation is maintained when the Inclusive Multicast Ethernet T
corresponding EVPN Route Type 1 advertise SIDs with the same SID ag route and its
structure, as outlined in <xref target="RT1"/> and <xref corresponding Ethernet A-D per ES route advertise SIDs with the same SID
target="RT3"/>.</t> structure, as outlined in Sections <xref target="RT1" format="counter"/> a
nd <xref target="RT3" format="counter"/>.</t>
<t>However, when the SID structures of the two route types are not <t>However, when the SID structures of the two route types are not
identical, the bitwise logical-OR operation specified in <xref identical, the bitwise logical-OR operation specified in <xref target="RFC
target="RFC9252"/> cannot be applied. Instead, the alternative method 9252" format="default"/> cannot be applied. Instead, the alternative method
specified in <xref target="PROC"/> MUST be used to correctly derive the specified in <xref target="PROC" format="default"/> <bcp14>MUST</bcp14> be
used to correctly derive the
SRv6 Service SID in such cases.</t> SRv6 Service SID in such cases.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document does not require any action from IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="SEC" numbered="true" toc="default">
<section anchor="SEC" title="Security Considerations"> <name>Security Considerations</name>
<t>This document only provides a more detailed specification related to <t>This document provides a more detailed specification related to
the signaling and processing of SRv6 SID advertisements for SRv6 the signaling and processing of SRv6 SID advertisements for SRv6
Endpoint Behaviors with arguments. As such, it does not introduce any Endpoint Behaviors with arguments. As such, it does not introduce any
new security considerations over and above what is already covered by new security considerations over and above those already covered by
<xref target="RFC9252"/>.</t> <xref target="RFC9252" format="default"/>.</t>
</section>
<section anchor="ACK" title="Acknowledgments">
<t>The authors would like to acknowledge Jayshree Subramanian, Sonal
Agarwal, Swadesh Agrawal, Dongling Duan, Luc Andre Burdet, Patrice
Brissette, Senthil Sathappan, Erel Ortacdag, Neil Hart, Will Lockhart,
and Vinod Prabhu for their inputs on aspects related to the signaling of
the End.DT2M SRv6 Endpoint behavior that required clarification as also
for their review of this document. The authors thank Jeffrey Zhang for
his shepherd review of the document and suggestions for its
improvements. The authors would also like to thank Gunter van de Velde
for his extensive review and suggestions for improving the readability
of the document.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include='reference.RFC.8986.xml'?> <name>References</name>
<references>
<?rfc include='reference.RFC.9252.xml'?> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.7432.xml'?> 986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<?rfc include='reference.RFC.2119.xml'?> 252.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include='reference.RFC.8402.xml'?> 432.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include='reference.RFC.8174.xml'?> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.8317.xml'?> 402.xml"/>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<references title="Informative References"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.8365.xml'?> 317.xml"/>
</references>
<?rfc include='reference.RFC.8754.xml'?> <references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
365.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
754.xml"/>
<?rfc include='reference.I-D.ietf-spring-srv6-srh-compression'?> <!-- ietf-spring-srv6-srh-compression published as RFC 9800-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
800.xml"/>
</references>
</references> </references>
<section anchor="ACK" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to acknowledge <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 the
ir review of the document and
input on aspects related to the signaling of the End.DT2M SRv6
Endpoint Behavior that required clarification. The authors thank <contact
fullname="Jeffrey Zhang"/>
for his shepherd review and suggestions for
improving the document. The authors would also like to thank <contact
fullname="Gunter Van de Velde"/> for his extensive review and
suggestions for improving the readability of the document.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 122 change blocks. 
357 lines changed or deleted 371 lines changed or added

This html diff was produced by rfcdiff 1.48.