Problem statement for Inter-domain Intent-aware Routing using Color

The BGP Intent-Aware routing solution must support the following intents bound to a color: Minimization of a cost metric vs a latency metric Minimization of different metric types, static and dynamic Exclusion/Inclusion of SRLG and/or Link Affinity and/or minimum MTU/number of hops Bandwidth management In the inter-domain context, exclusion/inclusion of entire domains, and border routers Inclusion of one or several virtual network function chains Located in a regional domain and/or core domain, in a DC Localization of the virtual network function chains Some functions may be desired in the regional DC or vice versa Subsequent sections elaborate on these requirements.

The requirements described in this document are mostly applicable to network under a single administrative domain that are organized into multiple network domains. The requirements are also applicable to multi-AS networks with closely cooperating administration. The network diagram below illustrates the reference network topology used in this section

+-----+ +-----+ +-----+ .....|S-RR1| ............. |S-RR2| ............... |S-RR3| ... : +-----+ +-----+ +-----+ : : : : : : : +--:--------------+ +-----------------+ +--------------:--+ | : | | | | : | | : |-------| |-------| : | | : +---| D=20 |---+ +---| D=25 |---+ : | | : |121|-------|211| |231|-------|321| : | | : +---| \ / |---+ +---| \ / |---+ : | |----+ | \ / | | \ / | +----| |PE11| | V | | V | |PE31| |----+ | / \ | | / \ | +----| | +---| / \ |---+ +---| / \ |---+ | |----+ |122|-------|212| |232|-------|322| +----| |PE12| +---| D=15 |---+ +---| D=10 |---+ |PE32| |----+ | | | | +----| | Domain 1 | | Domain 2 | | Domain 3 | +-----------------+ +-----------------+ +-----------------+ The following network design assumptions apply to the reference topology above, as an example: Independent ISIS/OSPF SR instance in each domain. eBGP peering link between ASBRs (121-211, 121-212, 122-211, 122-212, 231-321, 231-322, 232-321 and 232-322). Peering links have equal cost metric. Peering links have delay configured or measured as shown by "D". D=50 for cross peering links. The cross links between ASBRs share the same risk. The top parallel link between 121-211 shares same risk with the link 122-212. The top parallel link between 231-321 shares same risk with the link 232-322. VPN service is running from PE31, PE32 to PE11, PE12 via service RRs (S-RRn in figure). Intent-aware inter-domain routing information to end point E with intent C is represented using (C,E). The notation used is a representation of the intent-aware route using color, and does not indicate a specific protocol encoding. The following sections illustrate requirements and provide detailed examples for several intent types.

Various metric types can be advertised within an IGP domain and minimum metric paths can be computed within IGP domain, with Flex-Algo [RFC9350] for instance. The BGP solution should allow the establishment of inter-domain intent-aware paths with low values of a metric type, accumulated over the end-to-end path. In the reference topology of Each domain has Algo 0 and Flex Algo 128 Algo 0 is for minimum cost metric(cost optimized). Flex Algo 128 definition is for minimum delay (low latency). Cost Optimized end-to-end path Color C1 - Minimum cost intent. Intent-aware route for C1 sets up path(s) between PEs for end-to-end minimum cost. These paths traverse over intra-domain Algo 0 in each domain and account for the peering link cost between ASBRs. Example: PE11 learns (C1, PE31) intent-aware route via several equal paths: One such path is through FA0 to node 121, links 121-211, FA0 to 231, link 231-321, FA0 to PE31 Another such path is through FA0 to node 122, link 122-212, FA0 to 232, link 232-322, FA0 to PE31. PE11 may load-balance among these paths On PE11, VPN routes from PE31 colored with C1 are steered via (C1, PE31) intent-aware route. Latency Optimized End-to-end path Color C2 - Minimum latency intent. BGP Intent-aware route for C2 advertises path(s) between PEs for end-to-end minimum delay. These paths traverse over intra-domain Flex-Algo 128 in each domain and account for the peering link delay between ASBRs. Example: PE11 learns (C2, PE31) intent-aware route and best path is through FA128 to node 122, link 122-212, FA128 to 232, link 232-322, FA128 to PE31. On PE11, VPN routes from PE31 colored with C2 are steered via (C2, PE31) intent-aware route.

The Intent-aware BGP routing solution should allow the establishment of inter-domain paths that satisfy link affinity inclusion/exclusion constraints. The link affinity constraints should also be satisfied for inter-domain links, such as those between ASBRs. Using the reference topology of Figure 7 for the example below: Color C3 - Intent to Minimize cost metric and avoid purple links Each domain has Flex Algo 129 and some links have purple affinity. Flex Algo 129 definition is set to minimum cost metric and avoid purple links (within domain). Peering cross links are colored purple by policy. BGP intent-aware route for C3 sets up paths between PEs for minimum end-to-end cost and avoiding purple link affinity. These paths traverse over intra domain Flex Algo 129 in each domain and accounts for peering link cost between ASBR and avoiding purple links. Example: PE11 learns (C3, PE31) intent-aware route via 2 paths. First path is through FA 129 to node 121, link 121-211, FA129 to 231, link 231-321, FA129 to PE31. Second path is through FA129 to node 122, link 122-212, FA129 to 232, link 232-322, FA129 to PE31. On PE11, VPN routes from PE31 colored with C3 are steered via (C3, PE31) intent-aware route.

Support creating an inter-domain path that includes or excludes a certain set of nodes in each domain. Mechanisms used to achieve the node inclusion/exclusion constraints within different domains should be independent. For example, an RSVP-based domain may use link affinities to achieve node exclusion constraints, while an SR-based domain may use Flex-Algo, which natively supports excluding nodes. The example below describes the details for Color C4 - Intent to Minimize cost metric and avoid nodes Each domain has Flex Algo 129 and Flex-Algo 129 is not enabled on nodes 121,211,231,321 Flex Algo 129 definition is set to minimum cost metric Intent-aware route for C4 sets up paths between PEs for minimum end-to-end cost and avoiding specific nodes. These paths traverse over intra domain Flex Algo 129 in each domain and accounts for peering link cost between ASBR and avoiding specific nodes. Example: PE11 learns (C4, PE31) intent-aware route via 1 path. The path is through FA129 to node 122, link 122-212, FA129 to 232,link 232-322, FA129 to PE31. On PE11, VPN routes colored with C4 are steered via (C4, PE31) intent-aware route.

Support the creation of node- and link-diverse inter-domain paths. The intra-domain portion of the end-to-end paths should make use of existing mechanisms for computing and instantiating diverse paths within a domain. Inter-domain links (such as those connecting ASBRs) should also be taken into account for diverse inter-domain paths. Support creation of inter-domain diverse paths that avoid shared risk links. The example below describes the details for Color C5 and C6 - Intent to create diverse paths avoiding common node, link and shared risk Each domain has SRLG aware diverse path built as below Domain 1: Color C5 -> PE11,121 Color C6 -> PE12,122 Domain 2: Color C5 -> 211,231 Color C6 -> 212,232 Domain 3: Color C5 -> 321,PE31 Color C6 -> 322,PE32 Shared risk among inter-domain links is as described in the topology description Intent-aware diverse paths represented by C5 and C6 setup in each domain Local policies on inter-domain links to avoid common shared risk for intent C5 and C6 Example: PE11 learns (C5, PE31) intent-aware route via 1 path. The path is through PE11,121-211 (bottom link), 231-321 (bottom link), PE31 Example: PE12 learns (C6, PE32) intent-aware route via1 path. The path is through PE12,122,212, 232,322, PE32 On PE11, VPN routes colored with C5 are steered via (C5, PE31) Intent-aware route. On PE12, VPN routes colored with C6 are steered via (C6, PE32) intent-aware route.

Support creation of paths with certain intents applicable to only a subset of domains. No constraint specific state on internal nodes where intent is not applicable. The example below describes the details for Color C7 to exclude purple links Purple links exist only in domain 2 Intra-domain Intent-aware paths in domain 2 via 211,231 Intra-domain paths for C7 not created in Domain 1 and Domain 3 On PE11, VPN routes colored with C7 are steered via (C7, PE31) intent-aware route. Intent-aware route (C7,PE31) uses best effort paths in Domain1 and Domain3 Intent-aware route (C7,PE31) uses intra-domain intent-aware path C7 in Domain2

+-----+ +-----+ +-----+ ....|S-RR1|.............. |S-RR2| .............. |S-RR3| .... : +-----+ +-----+ +-----+ : : : : +----------------+ : : | | : +--:--------------+ |---+ +---| +--------------:--+ | : | |---|211| |241|---| | : | | : | | |---+ +---| | | : | | : +---| | | Domain 2 | | |---+ : | | : |121|---| +----------------+ |---|421| : | | : +---| |---+ : | |----+ | | +----| |PE11| | | |PE41| |----+ | | +----| | +---| |---+ | | |131|---| +----------------+ |---|431| | | +---| | | | | |---+ | | | | |---+ +---| | | | | Domain 1 | |---|311| |341|---| | Domain 4 | +-----------------+ |---+ +---| +-----------------+ | Domain 3 | +----------------+ Color C4 - Avoid sending selected traffic via Domain 3 VPN routes advertised from PEs with Color C4 Intent-aware route for Color C4 should only set up paths between PE11 and PE41 that exclude Domain 3

____ ____ / \ / \ | NFV1 | | NFV2 | \ / \ / +---------------------+ +--------------------+ +-------------------+ | |E11| | | |E21| | | | | +---+ | | +---+ | | | | | | | | | | | | | | | |----+ +------+ +------+ +----| |PE11| | 121 | | 231 | |PE31| |----+ +------+ +------+ +----| | | | | | | | | | | | | | | | | | | | | | | | | | Domain 1 | | Domain 2 | | Domain 3 | +---------------------+ +--------------------+ +-------------------+ Color intent C5 - Routing via min-cost paths C6 - Routing via a local NFV service chain situated at E11 C7 - Routing via a centrally located NFV service chain situated at E21 Forwarding of packets from PE11 towards PE31: (C5, PE31) mapped packets are sent via nodes 121, 231 to PE31 (C6, PE31) mapped packets are sent to E11 and then post- service chain, via 121, 231 to PE31 (C7, PE31) mapped packets are sent via 121 to E21 and then post-service chain, via 231 to PE31 E11 and E21 MAY be involved in inter-domain signaling in order to send service traffic towards PEs in remote domains. Different functions may be collocated at the same network node. (For example, PE functionality and NFV attachment functionality may be collocated.)

This section describes requirements and reference use-cases for extending intent-aware routing to the VPN (Service) layer. The solution should: Extend the signaling of intent awareness end-to-end to the customer domain: CE site to CE site across provider networks. Specific goals are to: Provide ability for a CE to select paths through specific PEs for a given intent Example-1: Certain intent in transport not available via specific PEs Example-2: Certain CE-PE connection does not support specific intent Example-3: Customer Site access via certain CE node does not support specific intent. For instance, link connecting a specific CE to a DC hosting loss-sensitive service may have better quality than a link from another CE Provide ability for a CE node to send traffic indicating a specific intent (via suitable encapsulation) to the PE for optimal steering. Provide ability for a PE node to apply filtering and other security mechanisms and authentication for the incoming encapsulated packets Provide ability for a PE node to apply traffic policing and shaping mechanisms to the received encapsulated packets. The PE-CE link and the transport domains can be in different color domains. Intent-aware routing may extend further into customer networks towards the network edge, closer to applications that originate traffic Applications or hosts that do not participate in routing can indicate the intent desired for an emitted traffic flow by setting appropriate DSCP values in the packet header. This enables the ingress intent-aware routing device to perform the necessary classification and traffic steering (Section 6.2) Support intent aware routing for multiple service (VPN) interworking models IBGP and Inter-AS Option C models are inherently supported since they natively extend from PE to PE. Additional models to be supported are: Inter-AS Option A Inter-AS Option B GW based interworking (L3VPN, EVPN) Co-existence with legacy PEs and CEs in a L3VPN network Intent-aware routing capable PEs co-exist with other PEs that are not capable Intent-aware routing capable PEs simultaneously interact with both capable CEs and legacy CEs

The network diagram below illustrates the reference network topology used in this section for VPN Intent-aware routing using Color +-------------------+ +-------------------+ | ....|S-RR|.... | | ....|S-RR|..... | | : +----+ : | | : +----+ : | | : : : : | | : : : : | |----+ : : +---| D=20 |---+ : : +----| /|PE11| : : |121|-----------|211| : : |PE21|\ D=25/ |----+ : : +---| X X |---+ : : +----| \ D=25 / | : : | X X | : : | \ V/24 CE1 | : : | X D=50| : : | CE2 X | : : | X X | : : | X D=15 X |----+ : : +---| X X |---+ : : +----| X D=10 X|PE12|...: :...|2122|-----------|2132|...: :...|PE22|X |----+ +---| D=10 |---+ +----| | | | | | AS 1 | | AS 2 | +-------------------+ +-------------------+ The following network design assumptions apply to the reference topology above, as an example: eBGP peering link between VPN ASBRs 121-211, 121-212, 122-211, 122-212 VPN service runs between PEs in each AS via service RRs to local VPN ASBRs. Between ASBRs, its VPN IAS-Option-B i.e. next hop self. CE1 is dual homed to PE11,PE12. CE2 is dual homed to PE21, PE22. Peering links have equal cost metric Peering links have delay configured or measured as shown by "D" The following sections illustrate a few examples of intent use-cases applicable to VPN routes.

This use-case extends the transport use-case from Minimization of end-to-end metric section to further to establish e2e paths with low values of a metric type between CEs attached to different PEs, additionally taking the metrics on the PE-CE links and inter-ASBR links into account. In the reference topology of VPN service intent topology, each AS has Flex Algo 0 and 128. Flex Algo 0 is for minimumcost metric (cost optimized) while Flex Algo 128 definition is for minimum delay (low latency) Cost Optimized end-to-end (CE-CE) path Color C1 - Minimum cost intent. On CE1, flows requiring cost optimized paths to V/24 are steered over (C1, V/24) intent-aware route using color. This needs BGP intent-aware route between PE-CE for V/24 prefix and color C1 awareness. It also needs BGP VPN Intent-aware route between PEs and ASBRs for V/24 prefix with VPN RD and color C1 awareness (C1, RD:V/24) CE1 may learn (C1, V/24) route through several equal cost paths. For example: One path is through link CE1-PE11, FA0 to 121, link 121-211, FA0 to PE21 and link PE21-CE2. Another such path is through CE1-PE12, FA0 to node 122, link 122-212, FA0 to PE22, link PE22-CE2. CE1 may load-balance among these paths Latency optimized end-to-end (CE-CE) path Color C2 - Minimum latency intent On CE1, flows requiring low latency paths to prefix V/24 are steered over (C2, V/24) intent-aware route using color. This needs BGP intent-aware route between PE-CE for V/24 prefix and color C2 awareness. It also needs BGP VPN intent-aware route between PEs and ASBR for V/24 prefix with VPN RD and color C2 awareness Paths traverse over intra-domain Flex Algo 128 in each AS and accounts for inter ASBR link delays and PE-CE link delays. CE1 learns (C2, V/24) BGP intent-aware best route using color through link CE1-PE12, FA128 to 122, link 122-212, FA128 to PE22 and link PE22-CE2 between PE-CE for V/24 prefix and color C2 awareness.

Color C3 - Intent to minimize cost metric and avoid purple links In the reference topology of Figure 6 Each AS has Flex Algo 129 and some links have purple affinity. Flex Algo 129 definition is set to minimum cost metric and avoid purple links (within AS). ASBR cross links are colored purple by policy. Bottom PE-CE links are colored purple as well by policy On CE1, flows requiring minimum cost path avoiding purple links to V/24 are steered over (C3, V/24) BGP intent-aware route using color CE1 learns (C3, V/24) route through link CE1-PE11, FA129 to 121, link 121-211, FA129 to PE21 and link PE21-CE2.

The below diagram represents a typical service function chaining deployment with NFV services deployed in the service layer. The transport layer is not aware of the services in this model.

+-----+ ........................|S-RR | ................. : +-----+ ........... : : : : : : : : ___ ___ ___ : : : / \ / \ / \ : : :| S1 | | S2 | | S3 | : : : \ / \ / \ / : : +-:---------------+ +--------------+ +------:----:--+ | : |E11| |E12| | | |E21| | | : : | | : +---+ +---+ | | +---+ | | : +----| (V1/24,C1) | : | | | | : |PE31|--CE2 | V | | | | : +----| |----+ +------+ +------+ : | CE1--|PE11| | 121 | | 231 | : | |----+ +------+ +------+ : +----| (V2/24/C2) | | | | | :..|PE32|--CE3 | | | | | +----| | | | | | | | | | | | | | Domain 1 | | Domain 2 | | Domain 3 | +-----------------+ +--------------+ +--------------+ Color intent C1 - Routing via NFV service chain comprising of [S1, S2] attached to E11 and E12 C2 - Routing via NFV service [S3] attached to E21 CE1, CE2, CE3 are sites of VPN1. S1, S2 and S3 are service VNFs in VPN1 Prefix V1/24 colored with C1 from CE2, and advertised as RD:V1/24 with C1 by PE31 to PE11 via S-RR Prefix V2/24 colored with C2 from CE3, and advertised as RD:V2/24 with C2 by PE32 to PE11 via SS-RR From PE11: [V1/24, C1] mapped packets are sent via S1, S2 and then routed to PE31, CE2 [V2/24, C2] mapped packets are sent via S3 and then routed to PE32, CE3

This section describes the intent requirements for the multicast traffic. In principle all the intent requirements described in section can apply to multicast traffic as well. The intent requirements as currently seen from actual usecases have been listed here. Ability to create multicast distribution trees that minimize latency metric Ability to create multicast distribution trees that avoid nodes located in certain geographical region Ability to create multicast distribution trees that that provide bandwidth guarantees within as well as across domains Ability to create multicast distribution trees that use subset of the topology

Traffic arriving at an ingress PE for a colored service route gets steered into an intent-aware path to the egress PE. illustrates the automated steering mechanism, driven through Color Extended Community in the service route. Flexible traffic steering is required, with support for different types: Per-Destination Steering: Incoming packets are steered based on the destination address of the packets Per-Flow Steering: Incoming packets are steered based on the destination address of the packets and additional fields in the packet header DSCP for IPv4/IPv6 packets and EXP for MPLS packets 5-tuple IP flow (Source address, destination address, source port, destination port and protocol fields). The Per-Flow Steering enables different flows for the same destination to be steered into different paths – for example, one flow into an intent-aware path and another into a best-effort path; or two different flows steered into paths of two different intents. Section 8.6 of RFC 9256 describes the operation of per-flow steering in detail. When no path that fulfills the desired intent is available: An option of ordered fallback should be supported via one or more alternative intents; or via a best-effort path. An option of not using a fallback path for the service route should also be supported. Fallback scheme per service route should be supported Fallback schemes should be decoupled from primary. For example, different service routes using same primary but different fallback schemes An indication that the route followed a less preferred path due to fallback may be given to a CE by modifying/adding suitable BGP attribute through policy. Above steering mechanisms should be supported for any service, including L2/L3 VPNs and Internet/global routing.

The solution must support the representative deployment designs and associated deployment requirements described in the following sub sections.

This section describes four different ways that multi-domain networks could be organized. This is a representation of most common deployments and not an exhaustive coverage.

+-----+ .............................. |S-RR | ......................... : +-----+ : : : : : +--:----iBGP---------+ +----------iBGP------+ +---------iBGP----:--+ | : | | | | : | | : | | | | : | | : +------+ +------+ : | | : | 121 | | 231 | : | | . +------+ +------+ : | |----+ | | | | +----| |PE11| | | | | |PE31| |----+ | | | | +----| | +------+ +------+ | | | 122 | | 232 | | | +------+ +------+ | | | | | | | | AS1 (Domain 1) | | AS1(Domain 2) | | AS1(Domain 3) | +--------------------+ +--------------------+ +--------------------+ The above diagram shows three different IGP domains, Domain1, Domain2 and Domain3 inter-connected at the ABRs 121,122,231,232. This single-AS network uses I-BGP sessions, with ABRs acting as inline route reflectors to PEs. Note that the IGP design included here and in other models below is illustrative. In practice, there may be multiple areas/levels or multiple IGP instances.

+-----+ +-----+ +-----+ ....|S-RR1| .............. |S-RR2| ................ |S-RR3| .... : +-----+ +-----+ +-----+ : : : : : +--:--iBGP---------+ iBGP +--------iBGP------+ iBGP +--------iBGP--:--+ | : | | | | : | | : | | | | : | | : +---| |---+ +---| |---+ : | | : |121|------|211| |231|------|321| : | | : +---| |---+ +---| |---+ : | |----+ | \ / | | \ / | +----| |PE11| | X | | X | |PE31| |----+ | / \ | | / \ | +----| | +---| |---+ +---| |---+ | | |122|------|212| |232|------|322| | | +---| |---+ +---| |---+ | | | | | | | | AS1(Domain 1) | | AS1(Domain 2) | | AS1(Domain 3) | +------------------+ +------------------+ +-----------------+ The above diagram shows a single AS1 with three different IGP domains, Domain1, Domain2, and Domain3. 121,122,211,212,231,232,321,322 are border nodes for the IGP domains and they participate in only one IGP domain. In this design, domain inter-connect is via iBGP peering links between Area border nodes. ABRs act as inline route reflectors to PEs.

+-----+ +-----+ +-----+ ....|S-RR1| .............. |S-RR2| ................ |S-RR3| .... : +-----+ +-----+ +-----+ : : : : : +--:--iBGP---------+ eBGP +--------iBGP------+ eBGP +--------iBGP--:--+ | : | | | | : | | : | | | | : | | : +---| |---+ +---| |---+ : | | : |121|------|211| |231|------|321| : | | : +---| |---+ +---| |---+ : | |----+ | \ / | | \ / | +----| |PE11| | X | | X | |PE31| |----+ | / \ | | / \ | +----| | +---| |---+ +---| |---+ | | |122|------|212| |232|------|322| | | +---| |---+ +---| |---+ | | | | | | | | AS1(Domain 1) | | AS2(Domain 2) | | AS3(Domain 3) | +------------------+ +------------------+ +-----------------+ The above diagram shows three different ASes (AS1, AS2 and AS3.) 121,122, 211, 212, 231,232, 321,322 are border nodes between the ASes. In this design, domain inter-connect is via eBGP peering links between AS border nodes. The ASBR also runs I-BGP sessions with other ASBRs or RRs in the same AS.

+-----+ .............................. |S-RR | ......................... : +-----+ : : : : : +--:----eBGP---------+ +-----iBGP-----------+ +---eBGP----------:--+ | : | | | | : | | : | | | | : | | : +------+ +------+ : | | : | 121 | | 231 | : | | . +------+ +------+ : | |----+ | | | | +----| |PE11| | | | | |PE31| |----+ | | | | +----| | +------+ +------+ | | | 122 | | 232 | | | +------+ +------+ | | | | | | | | AS1(Domain 1) | | AS2(Domain 2) | | AS1(Domain 3) | +--------------------+ +--------------------+ +--------------------+ 121,122,231,232 belong to AS2 only. AS1 and AS2 domains may run multi-instance IGP or different levels/areas. This topology uses I-BGP sessions to some clients and E-BGP sessions to other nodes. When an RR is used between PEs in AS1 and ABRs in AS2, it will have iBGP sessions to clients in same AS and e-BGP sessions to nodes in other AS.

BGP confederations [RFC 5065] allows the division of a public AS into multiple sub-ASes, usually with private identifiers. The solution should support BGP based intent-aware paths within the sub-AS or across the sub-ASes of the confederation, in any of the network designs described in sections 5.4.1.1 to section 5.4.1.4.

The solution must support the following: End-to-end paths crossing transport domains that use different technologies and encapsulations, such as: LDP-MPLS RSVP-TE-MPLS SR-MPLS SRv6 SR-TE (MPLS and SRv6) IGP Flex-Algo (MPLS and SRv6) Native IPv4/IPv6 forwarding (networks without MPLS enabled Note: All MPLS/SR-MPLS deployments may be IPv4/IPv6 or dual-stack SR-TE includes color-only and other policies as defined in [RFC9256] Interworking between domains with different encapsulations (e.g. SR-MPLS and SRv6) Different transport encapsulations simultaneously within a domain, for co-existence and migration

A routing solution for end-to-end intent-aware paths should support multicast as well as unicast. An End-to-end multicast path crossing multiple transport domains may use different encapsulation mechanisms, such as: mLDP RSVP-TE P2MP SR-MPLS Tree SIDs SRv6 Tree SIDs Native IPv4/IPv6 forwarding (networks without MPLS enabled

The BGP intent-aware routing solution MUST be compliant with the intent-aware routing framework described in . Specifically, It MUST support service routes using Color Extended-Community to request intent as defined in It MUST support automated steering of colored service routes on a BGP intent-aware path using color Intent-aware routes MAY resolve recursively via other intent-aware routes provided by any solution

BGP-LU [RFC8277] is widely deployed to provide inter-domain best-effort connectivity across different domains. The BGP intent-aware routing solution should support: Establishment of best-effort paths by using a color to represent best-effort intent, to avoid the need to deploy both technologies Co-existence of inter-domain BGP-LU and BGP intent aware routing in a network Support interworking of BGP-LU and BGP intent-aware network domains.

All domains in a network may not support the same number and granular definition of colors. However, the maximum granularity of colors should be provided for end to end paths that are set up for steering of a colored service route, with mapping from a more granular color to a less granular color where needed.

As illustrated in , network domains under different administrative control may assign different colors to represent the same intent. A color domain represents a collection of one or more network (IGP/BGP) domains with a single, consistent set of color-to-intent mappings. Color for a given intent may need to be re-mapped across a color domain boundary. The solution should support efficient color re-mapping for intent-aware routes that are propagated to a different color domain.

It may be useful to have a few well-defined common intents with well-known color values assigned that can be used across multiple operator networks. Such a scheme can provide a consistent service definition to customers that use paths for such intents from multiple operators. This scheme does not preclude operators from defining intents with similar characteristics and assigning other color values. It may additionally be useful to have a reserved range of color values for requirements that may arise in future. However, it should also be noted that color assignments have been used in customer deployments for a while now. Coordination and care will be necessary for defining a range that does not conflict with current deployments.

Section 5 describes co-existence and interworking of the BGP intent aware routing solution with other existing intent-aware solutions. Controller based approaches or other distributed TE solutions can also address the use-cases in this document. The intent-aware routing solution should coexist with such alternative solutions. It should allow traffic to use paths created by an alternative solution. It should allow part of the inter-domain path to be created by an alternative solution. The routing solution may be used to provide backup paths for a primary path created by an alternative solution, or vice versa.

Support a massive scaled transport network Number of Remote PE's: >= 300k Number of Colors C: >= 5 Support a scalable MPLS dataplane solution Constraints that need to be addressed: Typical inter-domain MPLS network designs (e.g. Seamless-MPLS) build hop-by-hop stitched MPLS LSPs towards every PE in the network. For the scale above, the number of forwarding entries required to represent each remote PE for each color will exceed the 1M MPLS label space limit. PE and transit nodes may be devices with low FIB capacity. Additionally, they may also have constraints on packet processing (e.g, label ops, number of labels pushed) To address these constraints: The solution must support hierarchy in the forwarding plane E.g. via a label stack or a list of segments, such that no single node needs to support a data-plane scaling in the order of (Remote PE * C) The solution should minimize state on border nodes in order to reduce label and FIB resource consumption, while taking into account packet processing constraints. Support ability to abstract the topology and network events from remote domains - for scale, stability and faster convergence. E.g. contain the control plane propagation of a failure event for an ABR within its attached upstream domain. Support an Emulated-PULL model for the BGP signaling PE nodes may be devices with limited CPU and memory. The state on a PE should be restricted to transport endpoints that it needs for service steering. BGP Signaling is natively a PUSH model. For comparison, the SR-PCE solution natively supports a PULL model: when PE1 installs a VPN route V/v via (C, PE2), PE1 requests its serving SR-PCE to compute the SR Policy to (C, PE2). I.e. PE1 does not learn unneeded SR policies. Emulated-PULL refers to the ability for a BGP node PE1 to "subscribe" to (C, PE2) route such that only paths for (C, PE2) are signaled to PE1. The requirements for an Emulated-PULL solution are as follows: The subscription and related filtering solution must apply to any BGP node. For transport routes, this means Ability for a node (e.g. PE/ABR/ASBR) to signal interest for routes of specific colors. Ability for a node (e.g ABR/ASBR) to propagate the subscription message. PEs may choose to only learn routes that they need – e.g. remote VPN endpoints (PEs/VPN ASBRs) or transit nodes (ABRs/transport ASBRs). ABR/ASBRs also only learn and propagate routes for which nodes within the local domain have expressed interest. The requirements for VPN routes will be updated in the future version of the document. Automation of the subscription/filter route Similar to the SR-PCE solution, when an ingress PE1 installs VPN V/v via (C, PE2), PE1 originates its subscription/filter route for (C, PE2). Efficient propagation and processing of subscription/filter routes. Ability to summarize the endpoints and thus request a number of endpoints for a particular intent in a single subscription route. The solution may be optional for networks that do not have the large scaling requirements.

This section will be updated in the future revision of the document.

A BGP intent-aware routing solution should provide high network availability for typical deployment topologies, with minimum loss of connectivity in different network failure scenarios. The network failure scenarios, applicable technologies and design options described in should be used as a reference. In the Seamless-MPLS reference topology in section 5.4.1.1 : Failure of intra-domain links should limit loss of connectivity (LoC) to under 50ms. E.g., PE11 to a P node (not shown), 121 to a P node in Domain1 or Domain2) Failure of an intra-domain node (P node in any domain) should limit LoC to under 50ms Failure of an ABR node (e.g. 121, 231) should limit LoC to under 1sec, or under 50ms depending on the network deployment scenario. Failure of a remote PE node (e.g. PE31) should limit LoC to under 1sec, or under 50ms depending on the network deployment scenario and specific service failover requirements In the Inter-AS Option C VPN reference topology in Section 5.4.1.3: Failure of intra-domain links should limit LoC to under 50ms. E.g., PE11 to a P node (not shown), 121 to a P node in Domain1 or Domain2) Failure of an intra-domain node (P node in any domain) should limit LoC to under 50ms Failure of an ASBR node (e.g. 121, 211) should limit LoC to under 1sec, or under 50ms depending on the network deployment scenario. Failure of a remote PE node (e.g. PE31) should limit LoC to under 1sec, or under 50ms depending on the network deployment scenario and specific service failover requirements Failure of an external link (e.g. 121-211) should limit LoC to under 1sec, or under 50ms depending on the network deployment scenario. The solution should explore and describe additional techniques and design options that are applicable to further improve handling of the failure cases listed above.

This section summarizes the key protocol requirements that should be addressed by the intent-aware BGP routing solution. While the context for several requirements has been discussed earlier in the document, this section emphasizes aspects pertinent to the protocol design. The solution should support the following: Signaling and distribution of different Intent-aware routes to reach a participating node, e.g. a PE. Intent must be indicated by the notion of a Color as defined in Signal different instances of a prefix, one route per color Signal intent (color) associated with each route At any BGP hop, allow propagating the best path selected for each route, or additional paths Generate routes sourced from IGP-FA, SR-TE Policies, RSVP-TE and BGP-LU from a domain Path selection for Intent-aware routes Accumulation of intent specific metric at each BGP hop and compare the accumulated metric across all received paths at intermediate hops and at an ingress PE. Ability to load balance among multiple received paths at intermediate BGP hops and at an ingress PE Backup path installation for fast convergence at intermediate BGP hops and at an ingress PE Validation of received paths Resolvability of next-hop in control plane Availability of encapsulation in data plane Next-hop resolution for BGP Intent-aware route Flexibility to use different intra-domain and inter-domain mechanisms, both intent-aware and traditional IGP-FA, SR-TE, RSVP-TE, IGP, BGP-LU etc. Recursive resolution over other BGP Intent-Aware routes Recursive resolution via alternative color or best-effort paths when a particular intent is not available in a domain Flexible, efficient, extensible protocol definition As an example for context, currently deployed mechanisms such as BGP-LU (RFC 8277) were designed for MPLS, hence only signal per prefix label(s) in NLRI. However, RFC9012 and RFC8669 have described extensions to BGP to signal multiple encapsulations, though in BGP attributes. The target deployments for intent-aware routing need to support additional transport as described in section 6.3.1.6.1. In addition, they also need to support a significantly higher targeted scale as described in scaling requirements. Hence, the protocol definition should Support efficient signaling of different transport encapsulations Support efficient signaling multiple encapsulations for co-existence and migration between encapsulations Accommodate efficiency of processing and future extensibility Separation of transport and VPN service semantics Allow for different route distribution planes or processing for service vs transport routes Signaling across domains with different color mappings for a given intent

OAM in each domain should be function independently. This allows for more flexible evolution of the network. Basic MPLS OAM mechanisms described in [RFC8029] should be supported for MPLS based solutions deployments. Extensions defined in [RFC8287] should be supported. Mechanisms described in [RFC 9259] should be supported for SRv6 based deployments. End-to-end ping and traceroute procedures should be supported. The ability to validate the path inside each domain should be supported. Statistics for inter-domain intent-based transport paths should be supported on a per intent-aware path basis on the ingress PE nodes and as needed on egress and border nodes.