rfc9723xml2.original.xml   rfc9723.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
<?rfc compact="yes"?> etf-idr-cpr-08" number="9723" ipr="trust200902" consensus="true" obsoletes="" up
<?rfc subcompact="no"?> dates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symR
<rfc category="info" docName="draft-ietf-idr-cpr-08" ipr="trust200902"> efs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="BGP CPR for SRv6 Services">BGP Colored Prefix Routing (CPR) <title abbrev="BGP CPR for SRv6 Services">BGP Colored Prefix Routing (CPR)
for SRv6 based Services</title> for SRv6-Based Services</title>
<seriesInfo name="RFC" value="9723"/>
<author fullname="Haibo Wang" initials="H." surname="Wang"> <author fullname="Haibo Wang" initials="H." surname="Wang">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>rainsword.wang@huawei.com</email> <email>rainsword.wang@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Jie Dong" initials="J." surname="Dong"> <author fullname="Jie Dong" initials="J." surname="Dong">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>jie.dong@huawei.com</email> <email>jie.dong@huawei.com</email>
</address> </address>
</author> </author>
<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/>
<city/>
<region/>
<code/>
<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="Tao Han" initials="T." surname="Han"> <author fullname="Tao Han" initials="T." surname="Han">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<code/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>hantao@huawei.com</email> <email>hantao@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Ran Chen" initials="R." surname="Chen"> <author fullname="Ran Chen" initials="R." surname="Chen">
<organization>ZTE Corporation</organization> <organization>ZTE Corporation</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>chen.ran@zte.com.cn</email> <email>chen.ran@zte.com.cn</email>
</address> </address>
</author> </author>
<date month="May" year="2025"/>
<date day="24" month="February" year="2025"/> <area>RTG</area>
<workgroup>idr</workgroup>
<area>Routing Area</area> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<workgroup>Interdomain Routing Working Group</workgroup> <keyword>example</keyword>
<abstract> <abstract>
<t>This document describes a mechanism to advertise IPv6 prefixes in BGP <t>This document describes a mechanism to advertise IPv6 prefixes in BGP
which are associated with Color Extended Communities to establish that are associated with Color Extended Communities to establish
end-to-end intent-aware paths for Segment Routing over IPv6 (SRv6) end-to-end intent-aware paths for Segment Routing over IPv6 (SRv6)
services. Such IPv6 prefixes are called "Colored Prefixes", and this services. Such IPv6 prefixes are called "Colored Prefixes", and this
mechanism is called Colored Prefix Routing (CPR). In SRv6 networks, the mechanism is called "Colored Prefix Routing" (CPR). In SRv6 networks, the
Colored prefixes are the SRv6 locators associated with different intent. Colored Prefixes are the SRv6 locators associated with different intents.
SRv6 services (e.g. SRv6 VPN services) with specific intent could be SRv6 services (e.g., SRv6 VPN services) with a specific intent could be
assigned with SRv6 Segment Identifiers (SIDs) under the corresponding assigned with SRv6 Segment Identifiers (SIDs) under the corresponding
SRv6 locators, which are advertised as Colored prefixes.</t> SRv6 locators, which are advertised as Colored Prefixes.</t>
<t>This operational methodology allows the SRv6 service traffic to be <t>This operational methodology allows the SRv6 service traffic to be
steered into end-to-end intent-aware paths simply based on the longest steered into end-to-end intent-aware paths based on the longest
prefix matching of SRv6 Service SIDs to the Colored prefixes. The prefix matching of SRv6 Service SIDs to the Colored Prefixes. The
existing IPv6 Address Family and Color Extended Community are reused for existing IPv6 Address Family and Color Extended Community are reused to
the advertisement of IPv6 Colored prefixes without new BGP extensions, advertise IPv6 Colored Prefixes without new BGP extensions;
thus this mechanism is easy to interoperate and can be deployed thus, this mechanism is easy to interoperate and can be deployed
incrementally in multi-Autonomous System (AS) networks which belong to incrementally in multi-Autonomous System (AS) networks that belong to
the same trusted domain.</t> the same trusted domain.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>With the trend of using one common network to carry multiple types of <t>With the trend of using one common network to carry multiple types of
services, each service type can have different requirements for the services, each service type can have different requirements for the
network. Such requirements are usually considered as the "intent" of the network. Such requirements are usually considered the "intent" of the
service or customer, and is represented as an abstract notion called service or customer, which is represented as an abstract notion called
"color".</t> "color".</t>
<t>In network scenarios where the services are delivered across multiple <t>In network scenarios where the services are delivered across multiple
Autonomous Systems (ASes) , there is a need to provide the services with Autonomous Systems (ASes), there is a need to provide the services with
different end-to-end paths to meet the intent. <xref different end-to-end paths to meet the intent. <xref target="I-D.hr-spring
target="I-D.hr-spring-intentaware-routing-using-color"/> describes the -intentaware-routing-using-color" format="default"/> describes the
problem statements and requirements for inter-domain intent-aware problem statements and requirements for inter-domain intent-aware
routing.</t> routing.</t>
<!-- [rfced] RFC 8277 doesn't appear to use the term "BGP Labeled Unicast" or "B GP-LU." For clarity, may we add text to draw a more clear connection, for examp le, "the mechanism described in RFC 8277 is referred to BGP-LU although that ter m does not actually appear in the document."
Original:
The inter-domain path can be established using either Multi-Protocol
Label Switching (MPLS) or IP data plane. In MPLS-based networks, the
usual inter-domain approach is to establish an end-to-end Label-
Switched Path (LSP) based on the BGP Labeled Unicast (BGP-LU)
mechanism as defined in [RFC8277].
-->
<t>The inter-domain path can be established using either Multi-Protocol <t>The inter-domain path can be established using either Multi-Protocol
Label Switching (MPLS) or IP data plane. In MPLS-based networks, the Label Switching (MPLS) or the IP data plane. In MPLS-based networks, the
usual inter-domain approach is to establish an end-to-end Label-Switched usual inter-domain approach is to establish an end-to-end Label Switched
Path (LSP) based on the BGP Labeled Unicast (BGP-LU) mechanism as Path (LSP) based on the BGP Labeled Unicast (BGP-LU) mechanism as
defined in <xref target="RFC8277"/>. Each domain's ingress border node defined in <xref target="RFC8277" format="default"/>. Each domain's ingres s border node
needs to perform label swapping for the end-to-end LSP, and impose the needs to perform label swapping for the end-to-end LSP, and impose the
label stack which is used for the LSP within its own domain.</t> label stack that is used for the LSP within its own domain.</t>
<t>In IP-based networks, the IP reachability information can be <t>In IP-based networks, the IP reachability information can be
advertised to network nodes in different domains using BGP, so that all advertised to network nodes in different domains using BGP, so that all
the domain border nodes can obtain the routes to the IP prefixes of the the domain border nodes can obtain the routes to the IP prefixes of the
destination nodes in other domains. With the introduction of SRv6 <xref destination nodes in other domains. With the introduction of SRv6 <xref ta
target="RFC8402"/> <xref target="RFC8754"/> <xref target="RFC8986"/>, rget="RFC8402" format="default"/> <xref target="RFC8754" format="default"/> <xre
BGP services are assigned with SRv6 Service SIDs <xref f target="RFC8986" format="default"/>,
target="RFC9252"/>, which are routable in the network according to its BGP services are assigned with SRv6 Service SIDs <xref target="RFC9252" fo
rmat="default"/>, which are routable in the network according to its
SRv6 locator prefix. Thus, the inter-domain path can be established SRv6 locator prefix. Thus, the inter-domain path can be established
simply based on the inter-domain routes to the prefix, and inter-domain simply based on the inter-domain routes to the prefix. Inter-domain
LSPs based on BGP-LU mechanism is not necessary for IPv6 and SRv6-based LSPs based on the BGP-LU mechanism are not necessary for IPv6- and SRv6-ba
sed
networks.</t> networks.</t>
<t>This document describes a mechanism to advertise IPv6 prefixes that
<t>This document describes a mechanism to advertise IPv6 prefixes which are associated with the Color Extended Community to establish end-to-end
are associated with Color Extended Community to establish end-to-end
intent-aware paths for SRv6 services. The color value in the Color intent-aware paths for SRv6 services. The color value in the Color
Extended Community indicates the intent <xref target="RFC9256"/>. Such Extended Community indicates the intent <xref target="RFC9256" format="def ault"/>. Such
IPv6 prefixes are called "Colored Prefixes", and this mechanism is IPv6 prefixes are called "Colored Prefixes", and this mechanism is
called Colored Prefix Routing (CPR). In SRv6 networks, the Colored called Colored Prefix Routing (CPR). In SRv6 networks, the Colored
Prefixes are the SRv6 locators associated with different intent. BGP Prefixes are the SRv6 locators associated with different intents. BGP
services over SRv6 (e.g. SRv6 VPN services) <xref target="RFC9252"/> services over SRv6 (e.g., SRv6 VPN services) <xref target="RFC9252" format
="default"/>
with specific intent could be assigned with SRv6 SIDs under the with specific intent could be assigned with SRv6 SIDs under the
corresponding SRv6 locators, which are advertised as Colored Prefixes. corresponding SRv6 locators, which are advertised as Colored Prefixes.
This allows the SRv6 service traffic to be steered (as specified in This allows the SRv6 service traffic to be steered (as specified in
<xref target="RFC9252"/>) into end-to-end intent-aware paths simply <xref target="RFC9252" format="default"/>) into end-to-end intent-aware pa ths
based on the longest prefix matching of SRv6 Service SIDs to the Colored based on the longest prefix matching of SRv6 Service SIDs to the Colored
Prefixes. In the data plane, the dedicated transport label or SID for Prefixes. In the data plane, the dedicated transport label or SID for
the inter-domain path is not needed, resulting in smaller encapsulation the inter-domain path is not needed, resulting in smaller encapsulation
overhead than with other options.</t> overhead than with other options.</t>
<t>The existing IPv6 Address Family and Color Extended Community could <t>The existing IPv6 Address Family and Color Extended Community could
be reused for the advertisement of IPv6 Colored Prefixes without new BGP be reused to advertise IPv6 Colored Prefixes without new BGP
extensions, thus this mechanism is easy to interoperate and can be extensions; thus, this mechanism is easy to interoperate and can be
deployed incrementally in multi-AS networks which belong to the same deployed incrementally in multi-AS networks that belong to the same
trusted domain (in the sense used by Section 8 of <xref trusted domain (in the sense used by <xref target="RFC8402" sectionFormat=
target="RFC8402"/>).</t> "of" section="8"/>).</t>
</section> </section>
<section numbered="true" toc="default">
<name>BGP CPR</name>
<section numbered="true" toc="default">
<name>Colored Prefix Allocation</name>
<!-- [rfced] Would it be correct to change "and" to "whereby"?
<section title="BGP CPR"> Original:
<t/> One way to achieve this is by splitting the base SRv6 locator of the
node into N sub-locators, and these sub-locators are Colored Prefixes
associated with different intents.
-->
<section title="Colored Prefix Allocation">
<t>In SRv6 networks, an SRv6 locator needs to be allocated for each <t>In SRv6 networks, an SRv6 locator needs to be allocated for each
node. In order to distinguish N different intents, a Provider Edge node. In order to distinguish N different intents, a Provider Edge
(PE) node needs to be allocated with N SRv6 locators, each of which is (PE) node needs to be allocated with N SRv6 locators, each of which is
associated a different intent that is identified by a color value. One associated a different intent that is identified by a color value. One
way to achieve this is by splitting the base SRv6 locator of the node way to achieve this is by splitting the base SRv6 locator of the node
into N sub-locators, and these sub-locators are Colored Prefixes into N sub-locators, and these sub-locators are Colored Prefixes
associated with different intents.</t> associated with different intents.</t>
<t>For example, a PE node is allocated with the base SRv6 Locator <t>For example, a PE node is allocated with the base SRv6 Locator
2001:db8:aaaa:1::/64. In order to provide 16 different intents, this 2001:db8:aaaa:1::/64. In order to provide 16 different intents, this
base SRv6 Locator is split into 16 sub-locators from base SRv6 Locator is split into 16 sub-locators from
2001:db8:aaaa:1:0000::/68 to 2001:db8:aaaa:1:F000::/68, each of these 2001:db8:aaaa:1:0000::/68 to 2001:db8:aaaa:1:F000::/68; each of these
sub-locators is associated with a different intent, such as low-delay, sub-locators is associated with a different intent, such as low-delay,
high-bandwidth, etc.</t> high-bandwidth, etc.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Colored Prefix Advertisement"> <name>Colored Prefix Advertisement</name>
<t>After the allocation of Colored Prefixes on a PE node, routes to <t>After the allocation of Colored Prefixes on a PE node, routes to
these Colored Prefixes need to be advertised both in the local domain these Colored Prefixes need to be advertised both in the local domain
and also to other domains using BGP, so that the BGP SRv6 services and also to other domains using BGP, so that the BGP SRv6 services
routes could be resolved using the corresponding CPR route.</t> routes could be resolved using the corresponding CPR route.</t>
<!-- [rfced] RFC 2545 does not contain the term "IPv6 unicast Address
Family/Subsequent Address Family (AFI/SAFI = 2/1)", "AFI", or "SAFI". We see on
e instance of "Address Family" and a couple instances of "unicast address". Ple
ase consider how the text and citation can be clarified.
<t>In a multi-AS IPv6 network, the IPv6 unicast Address In a multi-AS IPv6 network, the IPv6 unicast Address Family/
Family/Subsequent Address Family (AFI/SAFI = 2/1) <xref Subsequent Address Family (AFI/SAFI = 2/1) [RFC2545] is used for the
target="RFC2545"/> is used for the advertisement of the Colored Prefix advertisement of the Colored Prefix routes.
routes. The color extended community <xref target="RFC9012"/> is -->
<t>In a multi-AS IPv6 network, the IPv6 Unicast Address
Family / Subsequent Address Family (AFI/SAFI = 2/1) <xref target="RFC254
5" format="default"/> is used for the advertisement of the Colored Prefix
routes. The color extended community <xref target="RFC9012" format="defa
ult"/> is
carried with the Colored Prefix route with the color value indicating carried with the Colored Prefix route with the color value indicating
the intent <xref target="RFC9256"/>. The procedure of Colored Prefix the intent <xref target="RFC9256" format="default"/>. The procedure of C olored Prefix
advertisement is described using an example with the following advertisement is described using an example with the following
topology:</t> topology:</t>
<t><figure> <figure anchor="fig-1">
<artwork><![CDATA[ <name>Example Topology for CPR Route Illustration</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Consistent Color Domain: Consistent Color Domain:
C1, C2, ... C1, C2, ...
+--------------+ +--------------+ +-------------+ +--------------+ +--------------+ +-------------+
| | | | | | | | | | | |
| [ASBR11]---[ASBR21] [ASBR23]---[ASBR31] | | [ASBR11]---[ASBR21] [ASBR23]---[ASBR31] |
--[PE1] [P1] | X | [P2] | X | [P3] [PE3]-- --[PE1] [P1] | X | [P2] | X | [P3] [PE3]--
| [ASBR12]---[ASBR22] [ASBR24]---[ASBR32] | | [ASBR12]---[ASBR22] [ASBR24]---[ASBR32] |
| | | | | | | | | | | |
+--------------+ +--------------+ +-------------+ +--------------+ +--------------+ +-------------+
AS1 AS2 AS3 AS1 AS2 AS3
Colored Prefixes of PE3: Colored Prefixes of PE3:
Low delay: PE3:CL1:: Low delay: PE3:CL1::
High bandwidth: PE3:CL2:: High bandwidth: PE3:CL2::
... ...
Figure 1. Example Topology for CPR Route Illustration
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Assume PE3 is provisioned with two different Colored Prefixes CLP-1 <t>Assume PE3 is provisioned with two different Colored Prefixes CLP-1
and CLP-2 for two different intents such as "low-delay" and and CLP-2 for two different intents such as "low-delay" and
"high-bandwidth" respectively. In this example, It is assumed that the "high-bandwidth" respectively. In this example, It is assumed that the
color representing a specific intent is consistent throughout all the color representing a specific intent is consistent throughout all the
domains.</t> domains.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>PE3 originates BGP IPv6 unicast (AFI/SAFI=2/1) route for the <t>PE3 originates BGP IPv6 unicast (AFI/SAFI=2/1) route for the
Colored Prefixes PE3:CL1:: and PE3:CL2::. Each route should carry Colored Prefixes PE3:CL1:: and PE3:CL2::. Each route should carry
the corresponding color extended community C1 or C2. PE3 also the corresponding color extended community C1 or C2. PE3 also
advertises a route for the base SRv6 Locator prefix PE3:BL, and advertises a route for the base SRv6 Locator prefix PE3:BL, and
there is no color extended community carried with this route.</t> there is no color extended community carried with this route.</t>
</li>
<li>
<t>ASBR31 and ASBR32 receive the CPR routes of PE3, and advertise <t>ASBR31 and ASBR32 receive the CPR routes of PE3, and advertise
the CPR routes further to ASBR23 and ASBR24 with next-hop set to the CPR routes further to ASBR23 and ASBR24 with next-hop set to
itself.</t> itself.</t>
</li>
<li>
<t>ASBR23 and ASBR24 receive the CPR routes of PE3. Since the <t>ASBR23 and ASBR24 receive the CPR routes of PE3. Since the
color-to-intent mapping in AS2 is consistent with that in AS3, the color-to-intent mapping in AS2 is consistent with that in AS3, the
Color Extended Community in the received CPR routes are kept Color Extended Community in the received CPR routes are kept
unchanged. ASBR23 and ASBR 24 advertise the CPR routes further in unchanged. ASBR23 and ASBR24 advertise the CPR routes further in
AS2 with the next-hop set to itself.</t> AS2 with the next hop set to itself.</t>
</li>
<li>
<t>The behavior of ASBR21 and ASBR22 are similar to the behavior <t>The behavior of ASBR21 and ASBR22 are similar to the behavior
of ASBR31 and ASBR32.</t> of ASBR31 and ASBR32.</t>
</li>
<li>
<t>The behavior of ASBR11 and ASBR12 are similar to the behavior <t>The behavior of ASBR11 and ASBR12 are similar to the behavior
of ASBR23 and ASBR24.</t> of ASBR23 and ASBR24.</t>
</list></t> </li>
</ul>
<t>In normal cases, the color value in the color extended community <t>In normal cases, the color value in the color extended community
associated with the CPR route is consistent through all the domains, associated with the CPR route is consistent through all the domains,
so that the Color Extended Community in the CPR routes is kept so that the Color Extended Community in the CPR routes is kept
unchanged. While in some special cases, one intent may be represented unchanged. In some special cases, one intent may be represented
as different color value in different domains. If this is the case, as a different color value in different domains. If this is the case,
then the Color Extended Community in the CPR routes needs to be then the Color Extended Community in the CPR routes needs to be
updated at the border nodes of the domains based on the color-mapping updated at the border nodes of the domains based on the color-mapping
policy. For example, in AS1, the intent "low latency" is represented policy. For example, in AS1, the intent "low latency" is represented
by color "red", while in AS2 the same intent is represented by color by the color "red", while the same intent is represented by color
"blue". When a CPR route is sent from AS1 to AS2, the Color Extended "blue" in AS2. When a CPR route is sent from AS1 to AS2, the Color Exten
ded
Community in the CPR routes needs to be updated from "red" to "blue" Community in the CPR routes needs to be updated from "red" to "blue"
at the border nodes based on the color-mapping policy.</t> at the border nodes based on the color-mapping policy.</t>
<t>In network scenarios where some of the intermediate autonomous <t>In network scenarios where some of the intermediate autonomous
systems are MPLS-based, the CPR routes may still be advertised using systems are MPLS based, the CPR routes may still be advertised using
the IPv6 unicast address family (AFI/SAFI=2/1) in the MPLS-based the IPv6 unicast address family (AFI/SAFI=2/1) in the MPLS-based
intermediate domains, and at the MPLS domain border nodes, some route intermediate domains; at the MPLS domain border nodes, some route
resolution policy could be used to make the CPR routes resolved to resolution policy could be used to make the CPR routes resolve to
intra-domain intent-aware MPLS LSPs. Another possible mechanism is to intra-domain intent-aware MPLS LSPs. Another possible mechanism is to
use the IPv6 LU address family (AFI/SAFI=2/4) to advertise the CPR use the IPv6 LU address family (AFI/SAFI=2/4) to advertise the CPR
routes in the MPLS domains, the detailed procedure is described in routes in the MPLS domains, the detailed procedure is described in
Section 7.1.2.1 of <xref <xref target="I-D.ietf-spring-srv6-mpls-interworking" sectionFormat="of"
target="I-D.ietf-spring-srv6-mpls-interworking"/>.</t> section="7.1.2.1"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="CPR to Intra-domain Path Resolution"> <name>CPR to Intra-Domain Path Resolution</name>
<t>A domain border node which receives a CPR route can resolve the CPR <t>A domain border node that receives a CPR route can resolve the CPR
route to an intra-domain color-aware path based on the tuple (N, C), route to an intra-domain color-aware path based on the tuple (N, C),
where N is the next-hop of the CPR route, and C is the color extended where N is the next hop of the CPR route, and C is the color extended
community of the CPR route. The intra-domain color-aware path could be community of the CPR route. The intra-domain color-aware path could be
built with any of the following mechanisms:</t> built with any of the following mechanisms:</t>
<!-- [rfced] In the bulleted list, is it correct for SRv6 to be listed twice? Al so, adding conjunctions may improve clarity regarding how the mechanisms are rel ated. Is the path built with a combination of the bulleted items or only one of the individual items?
<t><list style="symbols"> Original:
<t>SRv6 or SR-MPLS Policy</t> The intra-domain color-aware path could
be built with any of the following mechanisms:
<t>SRv6 or SR-MPLS Flex-Algo</t> * SRv6 or SR-MPLS Policy
<t>RSVP-TE</t> * SRv6 or SR-MPLS Flex-Algo
</list></t>
<t>For example, PE1 receives a CPR route to PE3:CL1:: with color C1 * RSVP-TE
and next-hop ASBR11, it can resolve the CPR routes to an intra-domain
SRv6 Policy based on the tuple (ASBR11, C1).</t> Perhaps (a combination):
The intra-domain color-aware path could
be built with any of the following mechanisms:
* SRv6 or SR-MPLS Policy, and
* SRv6 or SR-MPLS Flex-Algo, and
* RSVP-TE.
Perhaps (a single item):
The intra-domain color-aware path could
be built with any of the following mechanisms:
* SRv6,
* SR-MPLS Policy,
* SR-MPLS Flex-Algo, or
* RSVP-TE.
-->
<ul spacing="normal">
<li>
<t>SRv6 or SR-MPLS Policy</t>
</li>
<li>
<t>SRv6 or SR-MPLS Flex-Algo</t>
</li>
<li>
<t>RSVP-TE</t>
</li>
</ul>
<t>For example, if PE1 receives a CPR route to PE3:CL1:: with the color
C1
and next hop ASBR11, it can resolve the CPR routes to an intra-domain
SRv6 Policy based on the tuple (ASBR11, C1).</t>
<t>The intra-domain path resolution scheme could be based on any <t>The intra-domain path resolution scheme could be based on any
existing tunnel resolution policy, and new tunnel resolution existing tunnel resolution policy, and new tunnel resolution
mechanisms could be introduced if needed.</t> mechanisms could be introduced if needed.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="SRv6 Service Route Advertisement"> <name>SRv6 Service Route Advertisement</name>
<t>For an SRv6 service which is associated with a specific intent, the <t>For an SRv6 service that is associated with a specific intent, the
SRv6 Service SID could be allocated under the corresponding Colored SRv6 Service SID could be allocated under the corresponding Colored
locator prefix. For example, on PE3 in the example topology, an SRv6 locator prefix. For example, on PE3 in the example topology, an SRv6
VPN service with the low-delay intent can be allocated with the SRv6 VPN service with the low-delay intent can be allocated with the SRv6
End.DT4 SID PE3:CL1:DT::, where PE3:CL1:: is the SRv6 Colored Prefix End.DT4 SID PE3:CL1:DT::, where PE3:CL1:: is the SRv6 Colored Prefix
for low-delay service.</t> for low-delay service.</t>
<t>The SRv6 service routes are advertised using the mechanism defined <t>The SRv6 service routes are advertised using the mechanism defined
in <xref target="RFC9252"/>. The inter-domain VPN Option C is used, in <xref target="RFC9252" format="default"/>. The inter-domain VPN Optio
which means the next-hop of the SRv6 service route is set to the n C is used,
originating PE and not changed. Since the intent of the service is which means the next hop of the SRv6 service route is set to the
originating PE and is not changed. Since the intent of the service is
embedded in the SRv6 service SID, the SRv6 service route does not need embedded in the SRv6 service SID, the SRv6 service route does not need
to carry the color extended community.</t> to carry the color extended community.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="SRv6 Service Steering"> <name>SRv6 Service Steering</name>
<t>With the CPR routing mechanism, the ingress PE node which receives <t>With the CPR routing mechanism, the ingress PE node that receives
the SRv6 service routes follows the behavior of SRv6 shortest path the SRv6 service routes follows the behavior of SRv6 shortest path
forwarding (refer to Section 5 and 6 of <xref target="RFC9252"/>). The forwarding (refer to Sections <xref target="RFC9252"
SRv6 service SID carried in the service route is used as the sectionFormat="bare" section="5"/> and <xref target="RFC9252"
destination address in the outer IPv6 header that encapsulates the sectionFormat="bare" section="6"/> of <xref target="RFC9252"
service packet. If the corresponding CPR route has been received and format="default"/>). The SRv6 service SID carried in the service route
installed, longest prefix matching of SRv6 service SIDs to the Colored is used as the destination address in the outer IPv6 header that
Prefixes is performed. As a result of this prefix matching, the next encapsulates the service packet. If the corresponding CPR route has
hop found is an intra-domain color-aware path, which will be used for been received and installed, longest prefix matching of SRv6 service
forwarding the SRv6 service traffic. This process repeats at the SIDs to the Colored Prefixes is performed. As a result of this prefix
border node of each domain the packet traverses, until it reaches its matching, the next hop found is an intra-domain color-aware path,
destination.</t> which will be used for forwarding the SRv6 service traffic. This
process repeats at the border node of each domain the packet
traverses, until it reaches its destination.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<name>Encapsulation and Forwarding Process</name>
<section title="Encapsulation and Forwarding Processes">
<t>This section describes the encapsulation and forwarding process of <t>This section describes the encapsulation and forwarding process of
data packets which are matched with the corresponding CPR route.</t> data packets which are matched with the corresponding CPR route.</t>
<t>The topology of <xref target="fig-1"/> is used in each example.</t>
<t>The topology of Figure 1 is used in each example.</t> <section numbered="true" toc="default">
<name>CPR over SRv6 Intra-Domain Paths</name>
<section title="CPR over SRv6 Intra-Domain Paths">
<t>Following is an illustration of the packet encapsulation and <t>Following is an illustration of the packet encapsulation and
forwarding process of CPR over SRv6 Policy. The abstract forwarding process of CPR over SRv6 Policy. The abstract
representation of IPv6 and SRH in section 6 of <xref representation of IPv6 and the Segment Routing Header (SRH) described in
target="RFC8754"/> is used.</t> <xref target="RFC8754" sectionFormat="of" section="6"/> is used.</t>
<t>PE3 is provisioned with a Colored Prefix PE3:CL1:: for <t>PE3 is provisioned with a Colored Prefix PE3:CL1:: for
"low-delay".</t> "low-delay".</t>
<t>In AS1, the SRv6 Policy on PE1 for (ASBR11, C1) is represented with <t>In AS1, the SRv6 Policy on PE1 for (ASBR11, C1) is represented with
SID list &lt;P1, ASBR11&gt;.</t> SID list &lt;P1, ASBR11&gt;.</t>
<t>In AS2, the SRv6 Policy on ASBR21 for (ASBR23, C1) is represented <t>In AS2, the SRv6 Policy on ASBR21 for (ASBR23, C1) is represented
with the SID list &lt;P2, ASBR23&gt;.</t> with the SID list &lt;P2, ASBR23&gt;.</t>
<t>In AS3, the SRv6 Policy on ASBR31 for (PE3, C1) is represented with <t>In AS3, the SRv6 Policy on ASBR31 for (PE3, C1) is represented with
the SID list &lt;P3, PE3&gt;.</t> the SID list &lt;P3, PE3&gt;.</t>
<t>C-pkt is the customer packet PE1 received from its attaching <t>C-pkt is the customer packet PE1 received from its attaching
CE.</t> CE.</t>
<t>For packets that belong to an SRv6 VPN service associated with the
<t>For packets which belong to an SRv6 VPN service associated with the
SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding
process using H.Encaps.Red behavior <xref target="RFC8986"/> is shown process using H.Encaps.Red behavior <xref target="RFC8986" format="defau lt"/> is shown
as below:</t> as below:</t>
<figure>
<t><figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[PE1 ->P1: (PE1, P1)(PE3:CL1.DT6, ASBR11; PE1 ->P1: (PE1, P1)(PE3:CL1.DT6, ASBR11; SL=2)(C-pkt)
SL=2)(C-pkt)
P1 ->ASBR11: (PE1, ASBR11)(PE3:CL1.DT6, ASBR11; SL=1)(C-pkt) P1 ->ASBR11: (PE1, ASBR11)(PE3:CL1.DT6, ASBR11; SL=1)(C-pkt)
ASBR11->ASBR21: (PE1, PE3:CL1.DT6)(C-pkt) ASBR11->ASBR21: (PE1, PE3:CL1.DT6)(C-pkt)
ASBR21->P2: (ASBR21, P2)(ASBR23; SL=1)(PE1, PE3:CL1.DT6)(C-pkt) ASBR21->P2: (ASBR21, P2)(ASBR23; SL=1)(PE1, PE3:CL1.DT6)(C-pkt)
P2->ASBR23: (ASBR21, ASBR23)(PE1, PE3:CL1.DT6)(C-pkt) P2->ASBR23: (ASBR21, ASBR23)(PE1, PE3:CL1.DT6)(C-pkt)
ASBR23->ASBR31: (PE1, PE3:CL1.DT6)(C-pkt) ASBR23->ASBR31: (PE1, PE3:CL1.DT6)(C-pkt)
ASBR31->P3: (ASBR31, P3)(PE3; SL=1)(PE1, PE3:CL1.DT6)(C-pkt) ASBR31->P3: (ASBR31, P3)(PE3; SL=1)(PE1, PE3:CL1.DT6)(C-pkt)
P3->PE3: (ASBR31, PE3)(PE1, PE3:CL1.DT6)(C-pkt) P3->PE3: (ASBR31, PE3)(PE1, PE3:CL1.DT6)(C-pkt)
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>In some autonomous systems, SRv6 Flex-Algo may be used to provide <t>In some autonomous systems, SRv6 Flex-Algo may be used to provide
intent-aware intra-domain paths. The encapsulation is similar to the intent-aware intra-domain paths. The encapsulation is similar to the
case with SRv6 Policy.</t> case with SRv6 Policy.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="CPR over MPLS Intra-Domain Paths"> <name>CPR over MPLS Intra-Domain Paths</name>
<t>In network scenarios where some of the autonomous systems use MPLS <t>In network scenarios where some of the autonomous systems use the MPL
based data plane, the CPR route can be resolved over a color-aware S-based data plane, the CPR route can be resolved over a color-aware
intra-domain MPLS LSP. Such intra-domain MPLS LSP may be established intra-domain MPLS LSP. Such an intra-domain MPLS LSP may be established
using SR-MPLS Policy, SR-MPLS Flex-Algo or RSVP-TE.</t> using SR-MPLS Policy, SR-MPLS Flex-Algo, or RSVP-TE.</t>
<t>The encapsulation and forwarding of SRv6 service packets (which are <t>The encapsulation and forwarding of SRv6 service packets (which are
actually IPv6 packets) over an intra-domain MPLS LSP is based on the actually IPv6 packets) over an intra-domain MPLS LSP is based on the
MPLS mechanisms as defined in <xref target="RFC3031"/> <xref MPLS mechanisms as defined in <xref target="RFC3031" format="default"/>,
target="RFC3032"/> and <xref target="RFC8660"/>. The behavior is <xref target="RFC3032" format="default"/> and <xref target="RFC8660" format="de
similar to that of 6PE <xref target="RFC4798"/>.</t> fault"/>. The behavior is
similar to that of IPv6 Provider Edge Routers (6PEs) <xref target="RFC47
98" format="default"/>.</t>
<t>In AS1, the SR-MPLS Policy on PE1 for (ASBR11, C1) is represented <t>In AS1, the SR-MPLS Policy on PE1 for (ASBR11, C1) is represented
with SID list &lt;P1, ASBR11&gt;.</t> with the SID list &lt;P1, ASBR11&gt;.</t>
<t>In AS2, the SR-MPLS Flex-Algo on ASBR21 for (ASBR23, C1) is <t>In AS2, the SR-MPLS Flex-Algo on ASBR21 for (ASBR23, C1) is
represented with SID list &lt;ASBR23&gt;.</t> represented with SID list &lt;ASBR23&gt;.</t>
<t>In AS3, the SR-MPLS Policy on ASBR31 for (PE3, C1) is represented <t>In AS3, the SR-MPLS Policy on ASBR31 for (PE3, C1) is represented
with SID list &lt;P3, PE3&gt;.</t> with SID list &lt;P3, PE3&gt;.</t>
<t>C-pkt is the customer packet PE-1 received from its attaching <t>C-pkt is the customer packet PE-1 received from its attaching
CE.</t> CE.</t>
<t>For packets that belong to an SRv6 VPN service associated with the
<t>For packets which belong to an SRv6 VPN service associated with the
SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding
process is shown as below:</t> process is shown as below:</t>
<figure>
<t><figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[PE1-> P1: Label-stack(P1, ASBR11)(PE1, PE3:CL1.DT6 PE1-> P1: Label-stack(P1, ASBR11)(PE1, PE3:CL1.DT6)(C-pkt)
)(C-pkt)
P1->ASBR11: Label-stack(ASBR11)(PE1, PE3:CL1.DT6)(C-pkt) P1->ASBR11: Label-stack(ASBR11)(PE1, PE3:CL1.DT6)(C-pkt)
ASBR11->ASBR21: (PE1, PE3:CL1.DT6)(C-pkt) ASBR11->ASBR21: (PE1, PE3:CL1.DT6)(C-pkt)
ASBR21->P2: Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt) ASBR21->P2: Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt)
P2->ASBR23: Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt) P2->ASBR23: Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt)
ASBR23->ASBR31: (PE1, PE3:CL1.DT6)(C-pkt) ASBR23->ASBR31: (PE1, PE3:CL1.DT6)(C-pkt)
ASBR31->P3: Label-stack(P3, PE3)(PE1, PE3:CL1.DT6)(C-pkt) ASBR31->P3: Label-stack(P3, PE3)(PE1, PE3:CL1.DT6)(C-pkt)
P3->PE3: Label-stack(PE3)(PE1, PE3:CL1.DT6)(C-pkt) P3->PE3: Label-stack(PE3)(PE1, PE3:CL1.DT6)(C-pkt)
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t/>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<name>Operational Considerations</name>
<!-- [rfced] "which makes them belonging" is unclear. We have updated the text
as shown below.
Original:
The CPR mechanism can be used in network scenarios where multiple
inter-connected ASes belong to the same operator, or there is an
operational trust model between the ASes of different operators which
makes them belonging to the same trusted domain (in the sense used by
Section 8 of [RFC8402]).
Current:
The CPR mechanism can be used in network scenarios where multiple
inter-connected ASes belong to the same operator, or where there is
an operational trust model between the ASes of different operators
which means they belong to the same trusted domain (in the sense used
by Section 8 of [RFC8402]).
-->
<section title="Operational Considerations">
<t>The CPR mechanism can be used in network scenarios where multiple <t>The CPR mechanism can be used in network scenarios where multiple
inter-connected ASes belong to the same operator, or there is an inter-connected ASes belong to the same operator, or where there is an
operational trust model between the ASes of different operators which operational trust model between the ASes of different operators which
makes them belonging to the same trusted domain (in the sense used by means they belong to the same trusted domain (in the sense used by
Section 8 of <xref target="RFC8402"/>).</t> <xref target="RFC8402" sectionFormat="of" section="8"/>).</t>
<!-- [rfced] What spans across multiple ASes? Is it the SR Policy or the tunnel
?
<t>As described in section 5 of <xref Original:
target="I-D.hr-spring-intentaware-routing-using-color"/>, the As described in section 5 of
inter-domain intent-aware routing may be achieved with a logical tunnel [I-D.hr-spring-intentaware-routing-using-color], the inter-domain
created by an SR Policy across multiple ASes, and service traffic with intent-aware routing may be achieved with a logical tunnel created by
specific intent can be steered to the inter-domain SR Policy based on an SR Policy across multiple ASes, and service traffic with specific
the intent signaled by Color Extended Community. An operator may prefer intent can be steered to the inter-domain SR Policy based on the
a BGP routing based solution for the reasons described in <xref intent signaled by Color Extended Community.
target="I-D.hr-spring-intentaware-routing-using-color"/>. Another
possible consideration of the operator is the availability of
inter-domain controller for end-to-end intent-aware path computation.
This document proposes an alternate solution to signal the intent with
IPv6 Colored Prefixes using BGP.</t>
<t>When the Colored Prefixes are assigned as the sub-locators of the Perhaps:
As described in Section 5 of
[INTENTAWARE], the inter-domain
intent-aware routing may be achieved with a logical tunnel created by
an SR Policy that applies to multiple ASes. In addition, service traffic wit
h a specific
intent can be steered to the inter-domain SR Policy based on the
intent signaled by Color Extended Community.
-->
<t>As described in <xref
target="I-D.hr-spring-intentaware-routing-using-color"
sectionFormat="of" section="5"/>, inter-domain intent-aware routing
may be achieved with a logical tunnel created by an SR Policy across
multiple ASes, and service traffic with specific intent can be steered
to the inter-domain SR Policy based on the intent signaled by Color
Extended Community. An operator may prefer a BGP routing-based solution
for the reasons described in <xref
target="I-D.hr-spring-intentaware-routing-using-color"
format="default"/>. The operator may also consider
the availability of an inter-domain controller for end-to-end intent-aware
path computation. This document proposes an alternate solution to
signal the intent with IPv6 Colored Prefixes using BGP.</t>
<t>When Colored Prefixes are assigned as sub-locators of the
node's base SRv6 locator, the IPv6 unicast route of the base locator node's base SRv6 locator, the IPv6 unicast route of the base locator
prefix is the covering prefix of all the Colored locator prefixes. To prefix is the prefix that covers all of the Colored locator prefixes. To
make sure the Colored locator prefixes can be distributed to the ingress make sure the Colored locator prefixes can be distributed to the ingress
PE nodes along the border nodes, it is required that the route PE nodes along the border nodes, it is required that route
aggregation be disabled for IPv6 unicast routes which carry the color aggregation be disabled for IPv6 unicast routes that carry the color
extended community.</t> extended community.</t>
<t>With the CPR mechanism, at the prefix originator, each Colored Prefix i
<t>With CPR mechanism, at the prefix originator, each colored prefix is s
associated with one specific intent (i.e. color). And in each domain, associated with one specific intent (i.e., color). In each domain,
according to the color mapping policy, the same CPR route is always according to the color mapping policy, the same CPR route is always
updated with the same color. The case where there are multiple copies of updated with the same color. The case where there are multiple copies of
CPR routes with the same colored prefix but different color extened CPR routes with the same Colored Prefix but different color extended
commuity is considered a misconfiguration.</t> community is considered a misconfiguration.</t>
<!-- [rfced] Is seems as though there may be words missing in the following. Wh
at can "fall back"?
Original:
This allows the CPR routes to be resolved to
intent-aware intra-domain paths in any autonomous systems that
support the CPR mechanism, while can fall back to resolve over best-
effort intra-domain path in the legacy autonomous systems.
-->
<t>All the border nodes and the ingress PE nodes need to install the <t>All the border nodes and the ingress PE nodes need to install the
Colored locator prefixes into the RIB and FIB. For transit domains which Colored locator prefixes in the RIB and FIB. For transit domains that
support the CPR mechanism, the border nodes can use the tuple (N, C) support the CPR mechanism, the border nodes can use the tuple (N, C),
where N is next hop and C is color, to resolve the CPR routes to where N is the next hop and C is the color, to resolve the CPR routes to
intent-aware intra-domain paths. For transit domains which do not intent-aware intra-domain paths. For transit domains that do not
support the CPR mechanism, the border nodes would ignore the color support the CPR mechanism, the border nodes would ignore the color
extended community and resolve the CPR routes over a best-effort extended community and resolve the CPR routes over a best-effort
intra-domain path to the next-hop N, while the CPR route will be intra-domain path to the next-hop N, while the CPR route will be
advertised further to the downstream domains with only the next-hop advertised further to the downstream domains with only the next hop
changed to itself. This allows the CPR routes to be resolved to changed to itself. This allows the CPR routes to resolve to
intent-aware intra-domain paths in any autonomous systems that support intent-aware intra-domain paths in any autonomous systems that support
the CPR mechanism, while can fall back to resolve over best-effort the CPR mechanism, while can fall back to resolve over best-effort
intra-domain path in the legacy autonomous systems.</t> intra-domain path in the legacy autonomous systems.</t>
<t>There may be multiple inter-domain links between the adjacent <t>There may be multiple inter-domain links between the adjacent
autonomous systems, and a border node BGP speaker may receive CPR routes autonomous systems, and a border node BGP speaker may receive CPR routes
from multiple peering BGP speakers in another domain via EBGP. The local from multiple peering BGP speakers in another domain via External BGP (EBG P). The local
policy of a BGP speaker may take the attributes of the inter-domain policy of a BGP speaker may take the attributes of the inter-domain
links and the attributes of the received CPR routes into consideration links and the attributes of the received CPR routes into consideration
when selecting the best path for specific Colored Prefixes to better when selecting the best path for specific Colored Prefixes to better
meet the intent. The detailed local policy is outside the scope of this meet the intent. The detailed local policy is outside the scope of this
document. In a multi-AS environment, the policy of BGP speakers in document. In a multi-AS environment, the policy of BGP speakers in
different domains needs to be consistent.</t> different domains needs to be consistent.</t>
<t>In this document, the IPv6 Unicast Address Family is used for the
<t>In this document, IPv6 Unicast Address Family is used for the
advertisement of IPv6 Colored Prefixes. The primary advantage of this advertisement of IPv6 Colored Prefixes. The primary advantage of this
approach is the improved interoperability with legacy networks that lack approach is the improved interoperability with legacy networks that lack
support for intent-aware paths, and the facilitation of incremental support for intent-aware paths, and the facilitation of incremental
deployment of intent-aware routing mechanisms. One potential concern deployment of intent-aware routing mechanisms. One potential concern
arises regarding the necessity of separating Colored Prefixes from arises regarding the need to separate Colored Prefixes from
public IPv6 unicast routes. Since the IP prefixes and SRv6 locators of public IPv6 unicast routes. Because the IP prefixes and SRv6 locators of
network infrastructure are usually advertised as part of the IP unicast network infrastructure are usually advertised as part of the IP unicast
routes, and appropriate filters are configured at the boundaries of routes, and appropriate filters are configured at the boundaries of
network administration, this is not considered to be a significant network administration, this concern is not considered to be a significant
issue. <xref target="RFC9602"/> allocates the prefix 5f00::/16 for SRv6 issue. <xref target="RFC9602" format="default"/> allocates the prefix 5f00
SIDs, by common agreement among participants in the trusted domain, the ::/16 for SRv6
SIDs. By common agreement among participants in the trusted domain, the
filters can be configured to by default drop all traffic from 5f00::/16 filters can be configured to by default drop all traffic from 5f00::/16
but permit the colored prefixes in use in these domains. The proposal in but permit the Colored Prefixes in use in these domains. The proposal in
<xref target="I-D.ietf-idr-bgp-car"/> provides a complementary solution <xref target="BGP-CAR" format="default"/> provides a complementary solutio
n
that is also based on the notion of color indicating the intent and that is also based on the notion of color indicating the intent and
where the SRv6 Locator prefix itself signifies the intent, the where the SRv6 Locator prefix itself signifies the intent; the
difference is that a separate SAFI is used.</t> difference is that a separate SAFI is used.</t>
<t><xref target="I-D.ietf-idr-bgp-ct" format="default"/> describes another
<t><xref target="I-D.ietf-idr-bgp-ct"/> describes another mechanism for mechanism for
intent-aware routing, in which the SRv6 service SIDs are not directly intent-aware routing, in which the SRv6 service SIDs are not directly
associated with the intent, while additional SRv6 transport SIDs are associated with the intent (additional SRv6 transport SIDs are
required for steering traffic to the inter-domain intent-aware paths, required to steer traffic to the inter-domain intent-aware paths),
and an SRv6 operation similar to MPLS label swapping is needed on the and an SRv6 operation similar to MPLS label swapping is needed on the
border nodes of autonomous systems.</t> border nodes of autonomous systems.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document makes no request of IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The mechanism described in this document provides an approach for <t>The mechanism described in this document provides an approach for
inter-domain intent-aware routing based on existing BGP protocol inter-domain intent-aware routing based on existing BGP protocol
mechanisms. The existing BGP IPv6 Unicast Address Family and existing mechanisms. The existing BGP IPv6 Unicast Address Family and existing
Color extended community are reused without further BGP extensions. With Color extended community are reused without further BGP extensions. With
this approach, the number of IPv6 Colored Prefixes advertised by PE this approach, the number of IPv6 Colored Prefixes advertised by PE
nodes is in proportion to the number of intents it supports. This may nodes is proportionate to the number of intents it supports. This may
introduce additional routes to BGP IPv6 routing table. While since these introduce additional routes to the BGP IPv6 routing table. Because these
are infrastructure routes, the amount of Colored Prefixes is only a are infrastructure routes, the number of Colored Prefixes is only a
small portion of the total amount of IPv6 prefixes. Thus it is small portion of the total amount of IPv6 prefixes. Thus,
considered that the impact to the required routing table size is the impact to the required routing table size is considered
acceptable.</t> acceptable.</t>
<t>As the CPR routes are distributed across multiple ASes that belong
<t>As the CPR routes are distributed across multiple ASes which belong
to a trusted domain, the mapping relationship between the intent and the to a trusted domain, the mapping relationship between the intent and the
IPv6 Colored Prefixes are observable to BGP nodes in those ASes. It is IPv6 Colored Prefixes are observable to BGP nodes in those ASes. It is
possible for an on-path attacker in the trusted domain to identify possible for an on-path attacker in the trusted domain to identify
packets associated with a particular intent.</t> packets associated with a particular intent.</t>
<t>The security considerations as described in <xref target="RFC4271" form
<t>The security considerations as described in <xref target="RFC4271"/> at="default"/>,
<xref target="RFC4272"/> and <xref target="RFC8754"/> apply to this <xref target="RFC4272" format="default"/> and <xref target="RFC8754" for
mat="default"/> apply to this
document.</t> document.</t>
</section> </section>
<section title="Contributing Authors"> </middle>
<t>The following people contributed significantly to the content of this <back>
document and should be considered co-authors:</t> <displayreference target="I-D.ietf-idr-bgp-ct" to="BGP-CT"/>
<t><figure> <displayreference target="I-D.hr-spring-intentaware-routing-using-color" to="INT
<artwork><![CDATA[Xinjun Chen ENTAWARE"/>
ifocus.chen@huawei.com <displayreference target="I-D.ietf-spring-srv6-mpls-interworking" to="SRv6-INTER
WORK"/>
Jingrong Xie <references>
xiejingrong@huawei.com <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
545.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
272.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
754.xml"/>
<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
012.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.9
256.xml"/>
</references>
<references>
<name>Informative References</name>
Zhenqiang Li <!-- [I-D.hr-spring-intentaware-routing-using-color]
li_zhenqiang@hotmail.com IESG State: I-D Exists
]]></artwork> -->
</figure></t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</section> hr-spring-intentaware-routing-using-color.xml"/>
<section anchor="Acknowledgements" title="Acknowledgements"> <!-- [I-D.ietf-spring-srv6-mpls-interworking]
<t>The authors would like to thank Shunwan Zhuang, Zhibo Hu, Zhenbin Li, IESG State: Expired
Dhananjaya Rao and Dhruv Dhody for the review and valuable -->
discussion.</t>
</section>
</middle>
<back> <reference anchor="I-D.ietf-spring-srv6-mpls-interworking" target="https://datat
<references title="Normative References"> racker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-00">
<?rfc include='reference.RFC.4271'?> <front>
<title>SRv6 and MPLS interworking</title>
<author initials="S." surname="Agrawal" fullname="Swadesh Agrawal" role="e
ditor">
<organization>Cisco Systems</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
</author>
<author initials="D." surname="Voyer" fullname="Daniel Voyer">
<organization>Bell Canada</organization>
</author>
<author initials="G." surname="Dawra" fullname="Gaurav Dawra">
<organization>LinkedIn</organization>
</author>
<author initials="Z." surname="Li" fullname="Zhenbin Li">
<organization>Huawei Technologies</organization>
</author>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde">
<organization>Juniper Networks</organization>
</author>
<date month="October" day="17" year="2024" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-mpls-interwor
king-00" />
</reference>
<?rfc include='reference.RFC.2545'?> <!-- [I-D.ietf-idr-bgp-car]
IESG State: RFC ED Queue
-->
<?rfc include='reference.RFC.4272'?> <reference anchor="BGP-CAR" target="https://datatracker.ietf.org/doc/html/draft-
ietf-idr-bgp-car-16">
<front>
<title>BGP Color-Aware Routing (CAR)</title>
<author initials="D." surname="Rao" fullname="Dhananjaya Rao" role="editor
">
<organization>Cisco Systems</organization>
</author>
<author initials="S." surname="Agrawal" fullname="Swadesh Agrawal" role="e
ditor">
<organization>Cisco Systems</organization>
</author>
<date month="February" day="20" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-car-16" />
<?rfc include='reference.RFC.8402'?> </reference>
<?rfc include='reference.RFC.8754'?> <!-- [I-D.ietf-idr-bgp-ct]
IESG State: RFC Ed Queue
-->
<?rfc include='reference.RFC.8986'?> <reference anchor="I-D.ietf-idr-bgp-ct" target="https://datatracker.ietf.org/doc
/html/draft-ietf-idr-bgp-ct-39">
<front>
<title>BGP Classful Transport Planes</title>
<author initials="K." surname="Vairavakkalai" fullname="Kaliraj Vairavakka
lai" role="editor">
<organization>Juniper Networks, Inc.</organization>
</author>
<author initials="N." surname="Venkataraman" fullname="Natrajan Venkataram
an" role="editor">
<organization>Juniper Networks, Inc.</organization>
</author>
<date month="February" day="28" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ct-39" />
<?rfc include='reference.RFC.9012'?> </reference>
<?rfc include='reference.RFC.9252'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
031.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
032.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
798.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
277.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
660.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
602.xml"/>
<?rfc include='reference.RFC.9256'?> </references>
</references> </references>
<references title="Informative References"> <section anchor="Acknowledgements" numbered="false" toc="default">
<?rfc include='reference.I-D.hr-spring-intentaware-routing-using-color'?> <name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Shunwan Zhuang"/>,
<contact fullname="Zhibo Hu"/>, <contact fullname="Zhenbin Li"/>,
<contact fullname="Dhananjaya Rao"/>, and <contact fullname="Dhruv
Dhody"/> for their reviews and valuable discussion.</t>
</section>
<?rfc include='reference.I-D.ietf-spring-srv6-mpls-interworking'?> <section anchor="contribs" numbered="false" toc="default">
<name>Contributors</name>
<t>The following people contributed significantly to the content of this
document and should be considered co-authors:</t>
<?rfc include='reference.I-D.ietf-idr-bgp-car'?> <contact fullname="Xinjun Chen">
<address>
<email>ifocus.chen@huawei.com</email>
</address>
</contact>
<?rfc include='reference.I-D.ietf-idr-bgp-ct'?> <contact fullname="Jingrong Xie">
<address>
<email>xiejingrong@huawei.com</email>
</address>
</contact>
<?rfc include='reference.RFC.3031'?> <contact fullname="Zhenqiang Li">
<address>
<email>li_zhenqiang@hotmail.com</email>
</address>
</contact>
<?rfc include='reference.RFC.3032'?> </section>
<?rfc include='reference.RFC.4798'?> <!-- [rfced] Throughout the text, the following terminology appears to be used
inconsistently. Please review.
<?rfc include='reference.RFC.8277'?> a) Colored Prefix vs Colored prefixes vs colored prefix
<?rfc include='reference.RFC.8660'?> We updated to use the form on the left. Please let us know if any updates are n
eeded.
In addition, please consider whether the capitalization of "Colored locator pref
ixes" is correct.
b) Please review the use of the following and let us know how/if they may be upd
ated for consistency.
color extended community vs Color Extended Community
-->
<!-- [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.
-->
<?rfc include='reference.RFC.9602'?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 155 change blocks. 
331 lines changed or deleted 503 lines changed or added

This html diff was produced by rfcdiff 1.48.