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" ?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc iprnotified="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">
<?rfc strict="yes" ?> <!-- [rfced] May we update the document title as follows to improve readability?
<?rfc compact="yes" ?> Original:
Segment Routing over IPv6 Argument Signaling for BGP Services
<?rfc subcompact="no" ?> Perhaps:
Argument Signaling for BGP Services in Segment Routing over IPv6 (SRv6)
-->
<front> <front>
<title abbrev="SRv6 Argument Signaling for BGP Services">Segment Routing <title abbrev="SRv6 Argument Signaling for BGP Services">Segment Routing
over IPv6 Argument Signaling for BGP Services</title> over IPv6 Argument Signaling for BGP Services</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.
<xref target="RFC9252" format="default"/> defines the procedures and messa
ges for the
signaling of BGP Overlay Services including L3VPN, EVPN, and Internet 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 EVPN Route Type 3 and EVPN Route Type 1, respectively.
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 EVPN Route Types 1 and 3, the procedures
described herein are also applicable to other similar endpoint behaviors described herein are also applicable to other similar endpoint behaviors
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 <!-- [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 [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 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 Route
Type 1 and the SID with the 'locator + function' components signaled via Type 1 and the SID with the 'Locator + Function' components signaled via
Route Type 3. However, this approach assumes a uniform SID structure Route Type 3. However, this approach assumes a uniform SID structure
across all SIDs advertised via EVPN Route Types 1 and 3. This assumption across all SIDs advertised via EVPN Route Types 1 and 3. 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
v6 SID
corresponding to an endpoint behavior that supports argument. This corresponding to an 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 LOC:FUNC
<t>As specified in <xref target="RFC9252"/>, the LOC:FUNC portion of the portion of the
SRv6 SID with End.DT2M behavior is signaled via EVPN Route Type 3 SRv6 SID with End.DT2M behavior is signaled via EVPN Route Type 3
(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="RFC898
target="RFC8986"/>) is signaled via EVPN Route Type 1 (Ethernet 6" format="default"/>) is signaled via EVPN Route Type 1 (Ethernet
Auto-Discovery per Ethernet Segment (A-D per ES) Route). The following Auto-Discovery per Ethernet Segment (A-D per ES) route). The following
subsections provide a more detailed specification of the signaling and subsections provide a more detailed specification of the signaling and
processing mechanisms compared to <xref target="RFC9252"/>.</t> 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 deployments where a mix of compressed and uncompressed SIDs is In deployments where a mix of compressed and uncompressed SIDs is
present, the behaviors advertised in the Ethernet Auto-Discovery (A-D) present, the behaviors advertised in the Ethernet Auto-Discovery (A-D)
per ES Routes (EVPN Route Type 1) and Inclusive Multicast Ethernet Tag per ES routes (EVPN Route Type 1) and Inclusive Multicast Ethernet Tag
Routes (EVPN Route Type 3) MAY consist of a combination of compressed routes (EVPN Route Type 3) <bcp14>MAY</bcp14> consist of a combination of
compressed
and uncompressed End.DT2M behavior flavors. The procedures in this and uncompressed End.DT2M behavior flavors. The procedures in this
document remain valid for such deployments provided that the argument document remain valid for such deployments provided that the AL
length consistency checks between EVPN Route Type 1 and EVPN Route Type consistency checks between EVPN Route Type 1 and EVPN Route Type
3, as described in the following subsections, are satisfied.</t> 3, as described in the following subsections, are satisfied.</t>
<section anchor="RT1" numbered="true" toc="default">
<section anchor="RT1" title="Advertisement of Ethernet A-D per ES Route"> <name>Advertisement of Ethernet A-D per ES Route</name>
<t>Ethernet Auto-Discovery (A-D) per ES Routes (EVPN Route Type 1), as <t>Ethernet Auto-Discovery (A-D) per ES routes (EVPN Route Type 1), as
defined in <xref target="RFC7432"/>, are utilized to enable defined in <xref target="RFC7432" format="default"/>, are utilized to en
split-horizon filtering and fast convergence in multi-homing able
scenarios. Additionally, A-D per ES Routes facilitate egress filtering split-horizon filtering and fast convergence in multihoming
of BUM traffic originating from a Leaf, as specified in <xref scenarios. Additionally, A-D per ES routes facilitate egress filtering
target="RFC8317"/>.</t> 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 s route <bcp14>SHOULD</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 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>EVPN Route Type 1 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 Attr: 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>EVPN Route Type 1 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 Attr: 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 (EVPN Route Type 3), 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">
<figure anchor="RT3NOARG" <name>EVPN Route Type 3 Without ESI Filtering</name>
title="EVPN Route Type 3 without ESI Filtering"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
BGP Prefix SID Attr: 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>EVPN Route Type 3 with ESI Filtering</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
BGP Prefix SID Attr: 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: 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 EVPN Route Type 3 is equal to the AL
signaled in the corresponding EVPN Route Type 1.</t> signaled in the corresponding EVPN Route Type 1.</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 EVPN Route Type 3
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 EVPN Route Type
3.</t> 3.</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 EVPN Route Type 1 (Ethernet
Auto-Discovery per Ethernet Segment Route). The ARG, in combination Auto-Discovery per Ethernet Segment route). The ARG, in combination
with the LOC:FUNC portion received via EVPN Route Type 3, forms the with the LOC:FUNC portion received via EVPN Route Type 3, 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 EVPN Route Type 3, then the egress PE <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 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.
Additionally, the router <bcp14>MUST</bcp14> ignore the SID value an
d its SID
structure advertised in the corresponding EVPN Route Type 1.</t> 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 <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 matching EVPN Route Type 1 for the Ethernet Segment is located 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 EVPN Route Type 1, then no usable ARG valu
available. The SRv6 Service SID MUST be formed as described in e is
available. The SRv6 Service SID <bcp14>MUST</bcp14> be formed as
described in
(1) above.</t> (1) above.</t>
</li>
<li>
<t>If the AL values in EVPN Route Type 1 and EVPN Route Type 3 <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 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>
<li>
<t>If the AL values in EVPN Route Type 1 and EVPN Route Type 3 <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 are both non-zero and equal, then the ARG value from EVPN
Route Type 1 is considered valid. This ARG value MUST be Route Type 1 is considered valid. This ARG value <bcp14>MUST</bc p14> 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 EVPN
Route Type 3. All bits beyond LBL + LNL + FL + AL MUST be set Route Type 3. All bits beyond LBL + LNL + FL + AL <bcp14>MUST</b cp14> be set
to zero.</t> to zero.</t>
</list></t> </li>
</list></t> </ol>
</li>
</ol>
<t>Based on the above procedures, the SRv6 Service SID encoding for <!-- [rfced] These sentences may be difficult to follow because of the two
the data plane without an ESI Filtering ARG, based on the examples in instances of "based on...". How may we update to improve readability?
<xref target="RT1NOARG"/> and <xref target="RT3NOARG"/>, is as
follows:</t>
<figure anchor="SIDPACKET" Original:
title="SRv6 Service SID Encoding for Data Plane without ARG"> Based on the above procedures, the SRv6 Service SID encoding for the
<artwork><![CDATA[ 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 Fi
gures
<xref target="RT1NOARG" format="counter"/> and <xref target="RT3NOARG" f
ormat="counter"/>, 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[
Route Type 3: Route Type 3:
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>Based on the above procedures, the SRv6 Service SID encoding for <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 the data plane along with an ESI Filtering ARG, based on the examples
in <xref target="RT1ARG"/> and <xref target="RT3ARG"/>, is as in <xref target="RT1ARG" format="counter"/> and <xref target="RT3ARG" fo rmat="counter"/>, is as
follows:</t> follows:</t>
<figure anchor="SIDPACKETARG">
<figure anchor="SIDPACKETARG" <name>SRv6 Service SID Encoding for Data Plane with ARG</name>
title="SRv6 Service SID Encoding for Data Plane with ARG"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[Route Type 1: Route Type 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: Route Type 3:
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 553 skipping to change at line 535
Structure: LBL: 32, LNL: 16, FL: 32, AL: 16 Structure: LBL: 32, LNL: 16, FL: 32, AL: 16
Route Type 3 from BD2: Route Type 3 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 EVPN Route Type 3 and its
corresponding EVPN Route Type 1 advertise SIDs with the same SID corresponding EVPN Route Type 1 advertise SIDs with the same SID
structure, as outlined in <xref target="RT1"/> and <xref structure, as outlined in Sections <xref target="RT1" format="counter"/> a
target="RT3"/>.</t> 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>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
252.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
432.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
317.xml"/>
</references>
<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"/>
<section anchor="ACK" title="Acknowledgments"> <!-- ietf-spring-srv6-srh-compression published as RFC 9800-->
<t>The authors would like to acknowledge Jayshree Subramanian, Sonal <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
Agarwal, Swadesh Agrawal, Dongling Duan, Luc Andre Burdet, Patrice 800.xml"/>
Brissette, Senthil Sathappan, Erel Ortacdag, Neil Hart, Will Lockhart, </references>
and Vinod Prabhu for their inputs on aspects related to the signaling of </references>
the End.DT2M SRv6 Endpoint behavior that required clarification as also <section anchor="ACK" numbered="false" toc="default">
for their review of this document. The authors thank Jeffrey Zhang for <name>Acknowledgments</name>
his shepherd review of the document and suggestions for its <t>The authors would like to acknowledge <contact fullname="Jayshree
improvements. The authors would also like to thank Gunter van de Velde Subramanian"/>, <contact fullname="Sonal Agarwal"/>, <contact
for his extensive review and suggestions for improving the readability fullname="Swadesh Agrawal"/>, <contact fullname="Dongling Duan"/>,
of the document.</t> <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> </section>
</middle> </back>
<back> <!-- [rfced] We have a few question about the text below.
<references title="Normative References">
<?rfc include='reference.RFC.8986.xml'?>
<?rfc include='reference.RFC.9252.xml'?> 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.
<?rfc include='reference.RFC.7432.xml'?> b) Also, several forms are used for the description of EVPN Route Type 1:
<?rfc include='reference.RFC.2119.xml'?> Ethernet Auto-Discovery per Ethernet Segment (A-D per ES)
Ethernet Auto-Discovery (A-D) per ES
Ethernet Auto-Discovery per Ethernet Segment Route
<?rfc include='reference.RFC.8402.xml'?> 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".
<?rfc include='reference.RFC.8174.xml'?> 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).
<?rfc include='reference.RFC.8317.xml'?> In deployments where a mix of compressed and uncompressed SIDs is
</references> 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.
<references title="Informative References"> Ethernet Auto-Discovery (A-D) per ES Routes (EVPN Route Type 1), as
<?rfc include='reference.RFC.8365.xml'?> defined in [RFC7432], are utilized to enable split-horizon filtering
and fast convergence in multi-homing scenarios.
<?rfc include='reference.RFC.8754.xml'?> 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 include='reference.I-D.ietf-spring-srv6-srh-compression'?>
</references>
</back>
</rfc> </rfc>
 End of changes. 137 change blocks. 
296 lines changed or deleted 483 lines changed or added

This html diff was produced by rfcdiff 1.48.