rfc9723v1.txt   rfc9723.txt 
skipping to change at line 107 skipping to change at line 107
In network scenarios where the services are delivered across multiple In network scenarios where the services are delivered across multiple
Autonomous Systems (ASes), there is a need to provide the services Autonomous Systems (ASes), there is a need to provide the services
with different end-to-end paths to meet the intent. [INTENTAWARE] with different end-to-end paths to meet the intent. [INTENTAWARE]
describes the problem statements and requirements for inter-domain describes the problem statements and requirements for inter-domain
intent-aware routing. intent-aware routing.
The inter-domain path can be established using either Multi-Protocol The inter-domain path can be established using either Multi-Protocol
Label Switching (MPLS) or the IP data plane. In MPLS-based networks, 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 the usual inter-domain approach is to establish an end-to-end Label
Switched Path (LSP) based on the BGP Labeled Unicast (BGP-LU) Switched Path (LSP) based on the mechanism defined in [RFC8277]
mechanism as defined in [RFC8277]. Each domain's ingress border node (which is usually referred to as BGP-LU (BGP Labeled Unicast)). Each
needs to perform label swapping for the end-to-end LSP, and impose domain's ingress border node needs to perform label swapping for the
the label stack that is used for the LSP within its own domain. end-to-end LSP, and impose the label stack that is used for the LSP
within its own domain.
In IP-based networks, the IP reachability information can be In IP-based networks, the IP reachability information can be
advertised to network nodes in different domains using BGP, so that advertised to network nodes in different domains using BGP, so that
all the domain border nodes can obtain the routes to the IP prefixes all the domain border nodes can obtain the routes to the IP prefixes
of the destination nodes in other domains. With the introduction of of the destination nodes in other domains. With the introduction of
SRv6 [RFC8402] [RFC8754] [RFC8986], BGP services are assigned with SRv6 [RFC8402] [RFC8754] [RFC8986], BGP services are assigned with
SRv6 Service SIDs [RFC9252], which are routable in the network SRv6 Service SIDs [RFC9252], which are routable in the network
according to its SRv6 locator prefix. Thus, the inter-domain path according to its SRv6 locator prefix. Thus, the inter-domain path
can be established simply based on the inter-domain routes to the can be established simply based on the inter-domain routes to the
prefix. Inter-domain LSPs based on the BGP-LU mechanism are not prefix. Inter-domain LSPs based on the BGP-LU mechanism are not
skipping to change at line 155 skipping to change at line 156
2. BGP CPR 2. BGP CPR
2.1. Colored Prefix Allocation 2.1. Colored Prefix Allocation
In SRv6 networks, an SRv6 locator needs to be allocated for each 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 (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. is 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 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 node into N sub-locators, whereby these sub-locators are Colored
associated with different intents. Prefixes associated with different intents.
For example, a PE node is allocated with the base SRv6 Locator 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- sub-locators is associated with a different intent, such as low-
delay, high-bandwidth, etc. delay, high-bandwidth, etc.
2.2. Colored Prefix Advertisement 2.2. Colored Prefix Advertisement
After the allocation of Colored Prefixes on a PE node, routes to 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. routes could be resolved using the corresponding CPR route.
In a multi-AS IPv6 network, the IPv6 Unicast Address Family / In a multi-AS IPv6 network, the mechanism for IPv6 unicast routing as
Subsequent Address Family (AFI/SAFI = 2/1) [RFC2545] is used for the defined in [RFC2545] is used for the advertisement of the Colored
advertisement of the Colored Prefix routes. The color extended Prefix routes, in which the Address Family / Subsequent Address
community [RFC9012] is carried with the Colored Prefix route with the Family (AFI/SAFI = 2/1) is used. The Color Extended Community
color value indicating the intent [RFC9256]. The procedure of [RFC9012] is carried with the Colored Prefix route with the color
Colored Prefix advertisement is described using an example with the value indicating the intent [RFC9256]. The procedure of Colored
following topology: Prefix advertisement is described using an example with the following
topology:
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] |
| | | | | | | | | | | |
+--------------+ +--------------+ +-------------+ +--------------+ +--------------+ +-------------+
skipping to change at line 206 skipping to change at line 208
Figure 1: Example Topology for CPR Route Illustration Figure 1: Example Topology for CPR Route Illustration
Assume PE3 is provisioned with two different Colored Prefixes CLP-1 Assume PE3 is provisioned with two different Colored Prefixes CLP-1
and CLP-2 for two different intents such as "low-delay" and "high- and CLP-2 for two different intents such as "low-delay" and "high-
bandwidth" respectively. In this example, It is assumed that the 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. domains.
* PE3 originates BGP IPv6 unicast (AFI/SAFI=2/1) route for the * 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. there is no Color Extended Community carried with this route.
* ASBR31 and ASBR32 receive the CPR routes of PE3, and advertise the * ASBR31 and ASBR32 receive the CPR routes of PE3, and advertise the
CPR routes further to ASBR23 and ASBR24 with next-hop set to CPR routes further to ASBR23 and ASBR24 with next-hop set to
itself. itself.
* ASBR23 and ASBR24 receive the CPR routes of PE3. Since the color- * 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 unchanged. Extended Community in the received CPR routes are kept unchanged.
ASBR23 and ASBR24 advertise the CPR routes further in AS2 with the ASBR23 and ASBR24 advertise the CPR routes further in AS2 with the
next hop set to itself. next hop set to itself.
* The behavior of ASBR21 and ASBR22 are similar to the behavior of * The behavior of ASBR21 and ASBR22 are similar to the behavior of
ASBR31 and ASBR32. ASBR31 and ASBR32.
* The behavior of ASBR11 and ASBR12 are similar to the behavior of * The behavior of ASBR11 and ASBR12 are similar to the behavior of
ASBR23 and ASBR24. ASBR23 and ASBR24.
In normal cases, the color value in the color extended community 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. In some special cases, one intent may be represented as a unchanged. In some special cases, one intent may be represented as a
different color value in different domains. If this is the case, 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 the color "red", while the same intent is represented by color by the color "red", while the same intent is represented by color
"blue" in AS2. When a CPR route is sent from AS1 to AS2, the Color "blue" in AS2. When a CPR route is sent from AS1 to AS2, the Color
Extended Community in the CPR routes needs to be updated from "red" Extended Community in the CPR routes needs to be updated from "red"
skipping to change at line 253 skipping to change at line 255
resolution policy could be used to make the CPR routes resolve to resolution policy could be used to make the CPR routes resolve to
intra-domain intent-aware MPLS LSPs. Another possible mechanism is 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 to 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 [SRv6-INTERWORK]. Section 7.1.2.1 of [SRv6-INTERWORK].
2.3. CPR to Intra-Domain Path Resolution 2.3. CPR to Intra-Domain Path Resolution
A domain border node that receives a CPR route can resolve the CPR 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 Community of the CPR route. The intra-domain color-aware path could
be built with any of the following mechanisms: be built with any of the following mechanisms:
* SRv6 or SR-MPLS Policy * SRv6 Policy
* SRv6 or SR-MPLS Flex-Algo * SR-MPLS Policy
* SRv6 Flex-Algo
* SR-MPLS Flex-Algo
* RSVP-TE * RSVP-TE
For example, if PE1 receives a CPR route to PE3:CL1:: with the color 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- C1 and next hop ASBR11, it can resolve the CPR routes to an intra-
domain SRv6 Policy based on the tuple (ASBR11, C1). domain SRv6 Policy based on the tuple (ASBR11, C1).
The intra-domain path resolution scheme could be based on any 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. mechanisms could be introduced if needed.
skipping to change at line 285 skipping to change at line 291
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. for low-delay service.
The SRv6 service routes are advertised using the mechanism defined in The SRv6 service routes are advertised using the mechanism defined in
[RFC9252]. The inter-domain VPN Option C is used, which means the [RFC9252]. The inter-domain VPN Option C is used, which means the
next hop of the SRv6 service route is set to the originating PE and 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 is not changed. Since the intent of the service is embedded in the
SRv6 service SID, the SRv6 service route does not need to carry the SRv6 service SID, the SRv6 service route does not need to carry the
color extended community. Color Extended Community.
2.5. SRv6 Service Steering 2.5. SRv6 Service Steering
With the CPR routing mechanism, the ingress PE node that receives the With the CPR routing mechanism, the ingress PE node that receives the
SRv6 service routes follows the behavior of SRv6 shortest path SRv6 service routes follows the behavior of SRv6 shortest path
forwarding (refer to Sections 5 and 6 of [RFC9252]). The SRv6 forwarding (refer to Sections 5 and 6 of [RFC9252]). The SRv6
service SID carried in the service route is used as the destination service SID carried in the service route is used as the destination
address in the outer IPv6 header that encapsulates the service address in the outer IPv6 header that encapsulates the service
packet. If the corresponding CPR route has been received and packet. If the corresponding CPR route has been received and
installed, longest prefix matching of SRv6 service SIDs to the installed, longest prefix matching of SRv6 service SIDs to the
skipping to change at line 397 skipping to change at line 403
4. Operational Considerations 4. Operational Considerations
The CPR mechanism can be used in network scenarios where multiple The CPR mechanism can be used in network scenarios where multiple
inter-connected ASes belong to the same operator, or where there is inter-connected ASes belong to the same operator, or where there is
an operational trust model between the ASes of different operators an operational trust model between the ASes of different operators
which means they belong to the same trusted domain (in the sense used which means they belong to the same trusted domain (in the sense used
by Section 8 of [RFC8402]). by Section 8 of [RFC8402]).
As described in Section 5 of [INTENTAWARE], inter-domain intent-aware As described in Section 5 of [INTENTAWARE], inter-domain intent-aware
routing may be achieved with a logical tunnel created by an SR Policy routing may be achieved with a logical tunnel created by an SR Policy
across multiple ASes, and service traffic with specific intent can be that applies to multiple ASes. In addition, service traffic with
steered to the inter-domain SR Policy based on the intent signaled by specific intent can be steered to the inter-domain SR Policy based on
Color Extended Community. An operator may prefer a BGP routing-based the intent signaled by Color Extended Community. An operator may
solution for the reasons described in [INTENTAWARE]. The operator prefer a BGP routing-based solution for the reasons described in
may also consider the availability of an inter-domain controller for [INTENTAWARE]. The operator may also consider the availability of an
end-to-end intent-aware path computation. This document proposes an inter-domain controller for end-to-end intent-aware path computation.
alternate solution to signal the intent with IPv6 Colored Prefixes This document proposes an alternate solution to signal the intent
using BGP. with IPv6 Colored Prefixes using BGP.
When Colored Prefixes are assigned as sub-locators of the node's base When Colored Prefixes are assigned as sub-locators of the node's base
SRv6 locator, the IPv6 unicast route of the base locator prefix is SRv6 locator, the IPv6 unicast route of the base locator prefix is
the prefix that covers all of the Colored locator prefixes. To make the prefix that covers all of the Colored locator prefixes. To make
sure the Colored locator prefixes can be distributed to the ingress sure the Colored locator prefixes can be distributed to the ingress
PE nodes along the border nodes, it is required that route PE nodes along the border nodes, it is required that route
aggregation be disabled for IPv6 unicast routes that carry the color aggregation be disabled for IPv6 unicast routes that carry the Color
extended community. Extended Community.
With the CPR mechanism, at the prefix originator, each Colored Prefix With the CPR mechanism, at the prefix originator, each Colored Prefix
is associated with one specific intent (i.e., color). In each is associated with one specific intent (i.e., color). In each
domain, according to the color mapping policy, the same CPR route is domain, according to the color mapping policy, the same CPR route is
always updated with the same color. The case where there are always updated with the same color. The case where there are
multiple copies of CPR routes with the same Colored Prefix but multiple copies of CPR routes with the same Colored Prefix but
different color extended community is considered a misconfiguration. different Color Extended Community is considered a misconfiguration.
All the border nodes and the ingress PE nodes need to install the All the border nodes and the ingress PE nodes need to install the
Colored locator prefixes in the RIB and FIB. For transit domains Colored locator prefixes in the RIB and FIB. For transit domains
that support the CPR mechanism, the border nodes can use the tuple that support the CPR mechanism, the border nodes can use the tuple
(N, C), where N is the next hop and C is the color, to resolve the (N, C), 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 CPR routes to intent-aware intra-domain paths. For transit domains
that do not support the CPR mechanism, the border nodes would ignore that do not support the CPR mechanism, the border nodes would ignore
the color extended community and resolve the CPR routes over a best- the Color Extended Community and resolve the CPR routes over a best-
effort intra-domain path to the next-hop N, while the CPR route will effort intra-domain path to the next-hop N, while the CPR route will
be advertised further to the downstream domains with only the next be advertised further to the downstream domains with only the next
hop changed to itself. This allows the CPR routes to resolve to hop changed to itself. This allows the CPR routes to resolve to
intent-aware intra-domain paths in any autonomous systems that intent-aware intra-domain paths in any autonomous systems that
support the CPR mechanism, while can fall back to resolve over best- support the CPR mechanism, while the CPR routes can fall back to
effort intra-domain path in the legacy autonomous systems. resolve over best-effort intra-domain paths in the legacy autonomous
systems.
There may be multiple inter-domain links between the adjacent There may be multiple inter-domain links between the adjacent
autonomous systems, and a border node BGP speaker may receive CPR autonomous systems, and a border node BGP speaker may receive CPR
routes from multiple peering BGP speakers in another domain via routes from multiple peering BGP speakers in another domain via
External BGP (EBGP). The local policy of a BGP speaker may take the External BGP (EBGP). The local policy of a BGP speaker may take the
attributes of the inter-domain links and the attributes of the attributes of the inter-domain links and the attributes of the
received CPR routes into consideration when selecting the best path received CPR routes into consideration when selecting the best path
for specific Colored Prefixes to better meet the intent. The for specific Colored Prefixes to better meet the intent. The
detailed local policy is outside the scope of this document. In a detailed local policy is outside the scope of this document. In a
multi-AS environment, the policy of BGP speakers in different domains multi-AS environment, the policy of BGP speakers in different domains
skipping to change at line 481 skipping to change at line 488
5. IANA Considerations 5. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
6. Security Considerations 6. Security Considerations
The mechanism described in this document provides an approach for 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 mechanisms. The existing BGP IPv6 Unicast Address Family and
existing Color extended community are reused without further BGP existing Color Extended Community are reused without further BGP
extensions. With this approach, the number of IPv6 Colored Prefixes extensions. With this approach, the number of IPv6 Colored Prefixes
advertised by PE nodes is proportionate to the number of intents it advertised by PE nodes is proportionate to the number of intents it
supports. This may introduce additional routes to the BGP IPv6 supports. This may introduce additional routes to the BGP IPv6
routing table. Because these are infrastructure routes, the number routing table. Because these are infrastructure routes, the number
of Colored Prefixes is only a small portion of the total amount of of Colored Prefixes is only a small portion of the total amount of
IPv6 prefixes. Thus, the impact to the required routing table size IPv6 prefixes. Thus, the impact to the required routing table size
is considered acceptable. is considered acceptable.
As the CPR routes are distributed across multiple ASes that belong to As the CPR routes are distributed across multiple ASes that belong to
a trusted domain, the mapping relationship between the intent and the a trusted domain, the mapping relationship between the intent and the
 End of changes. 16 change blocks. 
36 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.48.