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 " "> | ||||
<!ENTITY zwsp "​"> | ||||
<!ENTITY nbhy "‑"> | ||||
<!ENTITY wj "⁠"> | ||||
]> | ||||
<?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 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. |