rfc9871v1.txt   rfc9871.txt 
Internet Engineering Task Force (IETF) D. Rao, Ed. Internet Engineering Task Force (IETF) D. Rao, Ed.
Request for Comments: 9871 S. Agrawal, Ed. Request for Comments: 9871 S. Agrawal, Ed.
Category: Experimental Cisco Systems Category: Experimental Cisco Systems
ISSN: 2070-1721 September 2025 ISSN: 2070-1721 October 2025
BGP Color-Aware Routing (CAR) BGP Color-Aware Routing (CAR)
Abstract Abstract
This document describes a BGP-based routing solution to establish This document describes a BGP-based routing solution to establish
end-to-end intent-aware paths across a multi-domain transport end-to-end intent-aware paths across a multi-domain transport
network. The transport network can span multiple service provider network. The transport network can span multiple service provider
and customer network domains. The BGP intent-aware paths can be used and customer network domains. The BGP intent-aware paths can be used
to steer traffic flows for service routes that need a specific to steer traffic flows for service routes that need a specific
skipping to change at line 27 skipping to change at line 27
This document describes the routing framework and BGP extensions to This document describes the routing framework and BGP extensions to
enable intent-aware routing using the BGP CAR solution. The solution enable intent-aware routing using the BGP CAR solution. The solution
defines two new BGP SAFIs (BGP CAR SAFI and BGP VPN CAR SAFI) for defines two new BGP SAFIs (BGP CAR SAFI and BGP VPN CAR SAFI) for
IPv4 and IPv6. It also defines an extensible Network Layer IPv4 and IPv6. It also defines an extensible Network Layer
Reachability Information (NLRI) model for both SAFIs that allows Reachability Information (NLRI) model for both SAFIs that allows
multiple NLRI types to be defined for different use cases. Each type multiple NLRI types to be defined for different use cases. Each type
of NLRI contains key and TLV-based non-key fields for efficient of NLRI contains key and TLV-based non-key fields for efficient
encoding of different per-prefix information. This specification encoding of different per-prefix information. This specification
defines two NLRI types: Color-Aware Route NLRI and IP Prefix NLRI. defines two NLRI types: Color-Aware Route NLRI and IP Prefix NLRI.
It defines non-key TLV types for the MPLS label stack -- Label Index It defines non-key TLV types for the MPLS label stack, SR-MPLS Label
and and Segment Routing over IPv6 (SRv6) Segment Identifiers (SIDs). Index and Segment Routing over IPv6 (SRv6) Segment Identifiers
This solution also defines a new Local Color Mapping (LCM) Extended (SIDs). This solution also defines a new Local Color Mapping (LCM)
Community. Extended Community.
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and published for examination, experimental implementation, and
evaluation. evaluation.
This document defines an Experimental Protocol for the Internet This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF Task Force (IETF). It represents the consensus of the IETF
skipping to change at line 78 skipping to change at line 78
1.1. Terminology 1.1. Terminology
1.2. Illustration 1.2. Illustration
1.3. Requirements Language 1.3. Requirements Language
2. BGP CAR SAFI 2. BGP CAR SAFI
2.1. Data Model 2.1. Data Model
2.2. Extensible Encoding 2.2. Extensible Encoding
2.3. BGP CAR Route Origination 2.3. BGP CAR Route Origination
2.4. BGP CAR Route Validation 2.4. BGP CAR Route Validation
2.5. BGP CAR Route Resolution 2.5. BGP CAR Route Resolution
2.6. AIGP Metric Computation 2.6. AIGP Metric Computation
2.7. Native Multipath Capability 2.7. Inherent Multipath Capability
2.8. BGP CAR Signaling Through Different Color Domains 2.8. BGP CAR Signaling Through Different Color Domains
2.9. Format and Encoding 2.9. Format and Encoding
2.9.1. BGP CAR SAFI NLRI Format 2.9.1. BGP CAR SAFI NLRI Format
2.9.2. Type-Specific Non-Key TLV Format 2.9.2. Type-Specific Non-Key TLV Format
2.9.3. Color-Aware Route (E, C) NLRI Type 2.9.3. Color-Aware Route (E, C) NLRI Type
2.9.4. IP Prefix (E) NLRI Type 2.9.4. IP Prefix (E) NLRI Type
2.9.5. Local-Color-Mapping (LCM) Extended-Community 2.9.5. Local Color Mapping (LCM) Extended Community
2.10. LCM-EC and BGP Color-EC Usage 2.10. LCM-EC and BGP Color-EC Usage
2.11. Error Handling 2.11. Error Handling
3. Service Route Automated Steering on Color-Aware Paths 3. Service Route Automated Steering on Color-Aware Paths
4. Filtering 4. Filtering
5. Scaling 5. Scaling
5.1. Ultra-Scale Reference Topology 5.1. Ultra-Scale Reference Topology
5.2. Deployment Model 5.2. Deployment Model
5.2.1. Flat 5.2.1. Flat
5.2.2. Hierarchical Design with Next-Hop-Self at Ingress 5.2.2. Hierarchical Design with Next-Hop-Self at Ingress
Domain BR Domain BR
skipping to change at line 135 skipping to change at line 135
10.4.2. Additional Evaluation Criteria for the "BGP CAR NLRI 10.4.2. Additional Evaluation Criteria for the "BGP CAR NLRI
TLV" Registry TLV" Registry
10.5. "Border Gateway Protocol (BGP) Extended Communities" 10.5. "Border Gateway Protocol (BGP) Extended Communities"
Registry Registry
11. Manageability and Operational Considerations 11. Manageability and Operational Considerations
12. Security Considerations 12. Security Considerations
13. References 13. References
13.1. Normative References 13.1. Normative References
13.2. Informative References 13.2. Informative References
Appendix A. Illustrations of Service Steering Appendix A. Illustrations of Service Steering
A.1. E2E BGP Transport CAR Intent Realized Using IGP Flex-Algo A.1. E2E BGP Transport CAR Intent Realized Using IGP Flexible
Algorithm
A.2. E2E BGP Transport CAR Intent Realized Using SR Policy A.2. E2E BGP Transport CAR Intent Realized Using SR Policy
A.3. BGP Transport CAR Intent Realized in a Section of the A.3. BGP Transport CAR Intent Realized in a Section of the
Network Network
A.3.1. Provide Intent for Service Flows Only in Core Domain A.3.1. Provide Intent for Service Flows Only in Core Domain
Running IS-IS Flex-Algo Running IS-IS Flexible Algorithm
A.3.2. Provide Intent for Service Flows Only in Core Domain A.3.2. Provide Intent for Service Flows Only in Core Domain
over TE Tunnel Mesh over TE Tunnel Mesh
A.4. Transit Network Domains That Do Not Support CAR A.4. Transit Network Domains That Do Not Support CAR
A.5. Resource Avoidance Using BGP CAR and IGP Flex-Algo A.5. Resource Avoidance Using BGP CAR and IGP Flexible Algorithm
A.6. Per-Flow Steering over CAR Routes A.6. Per-Flow Steering over CAR Routes
A.7. Advertising BGP CAR Routes for Shared IP Addresses A.7. Advertising BGP CAR Routes for Shared IP Addresses
Appendix B. Color Mapping Illustrations Appendix B. Color Mapping Illustrations
B.1. Single Color Domain Containing Network Domains with N:N B.1. Single Color Domain Containing Network Domains with N:N
Color Distribution Color Distribution
B.2. Single Color Domain Containing Network Domains with N:M B.2. Single Color Domain Containing Network Domains with N:M
Color Distribution Color Distribution
B.3. Multiple Color Domains B.3. Multiple Color Domains
Appendix C. CAR SRv6 Illustrations Appendix C. CAR SRv6 Illustrations
C.1. BGP CAR SRv6 Locator Reachability Hop-by-Hop Distribution C.1. BGP CAR SRv6 Locator Reachability Hop-by-Hop Distribution
skipping to change at line 225 skipping to change at line 226
the operator specifies a unique network IP address block for a given the operator specifies a unique network IP address block for a given
intent, and the transport node gets assigned a unique IP prefix or intent, and the transport node gets assigned a unique IP prefix or
address for each intent. An example use case is Segment Routing over address for each intent. An example use case is Segment Routing over
IPv6 (SRv6) per-intent locators. IPv6 (SRv6) per-intent locators.
These BGP CAR intent-aware paths are then used by an ingress node These BGP CAR intent-aware paths are then used by an ingress node
(such as a PE) to steer traffic flows for service routes that need (such as a PE) to steer traffic flows for service routes that need
the specific intents. Steering may be towards a destination for all the specific intents. Steering may be towards a destination for all
or specific traffic flows. or specific traffic flows.
BGP CAR adheres to the flat routing model of BGP-IP/LU(Labeled BGP CAR adheres to the flat routing model of BGP for IP routing (RFC
Unicast) but extends it to support intent awareness, thereby 4271) or BGP Labeled Unicast (SAFI 4 in RFC 8277), and extends it to
providing a consistent operational experience with those widely support intent awareness, thereby providing a consistent operational
deployed transport routing technologies. experience with those widely deployed transport routing technologies.
1.1. Terminology 1.1. Terminology
Intent (in routing): Intent (in routing):
Any behaviors to influence routing or path selection, including Any behaviors to influence routing or path selection, including
any combination of the following behaviors: any combination of the following behaviors:
a. Topology path selection (e.g., minimize metric or avoid a. Topology path selection (e.g., minimize metric or avoid
resource) resource)
b. Network Function Virtualization (NFV) service insertion (e.g., b. Network Function Virtualization (NFV) service insertion (e.g.,
skipping to change at line 256 skipping to change at line 257
Color: Color:
A non-zero 32-bit integer value associated with an intent (e.g., A non-zero 32-bit integer value associated with an intent (e.g.,
low cost, low delay, or avoid some resources) as defined in low cost, low delay, or avoid some resources) as defined in
Section 2.1 of [RFC9256]. Color assignment is managed by the Section 2.1 of [RFC9256]. Color assignment is managed by the
operator. operator.
Colored service route: Colored service route:
An egress PE (e.g., E2) colors its BGP service (e.g., VPN) route An egress PE (e.g., E2) colors its BGP service (e.g., VPN) route
(e.g., V/v) to indicate the intent that it requests for the (e.g., V/v) to indicate the intent that it requests for the
traffic bound to V/v. The color is encoded as a BGP Color traffic bound to V/v. The color is encoded as a BGP Color
Extended-Community [RFC9012], used as per [RFC9256], or Extended Community [RFC9012], used as per [RFC9256], or
represented by the locator part of SRv6 Service SID [RFC9252]. represented by the locator part of SRv6 Service SID [RFC9252].
Color-aware path to (E2, C): Color-aware path to (E2, C):
A path to forward packets towards E2 that satisfies the intent A path to forward packets towards E2 that satisfies the intent
associated with color C. Several technologies may provide a associated with color C. Several technologies may provide a
color-aware path to (E2, C), such as SR Policy [RFC9256], IGP color-aware path to (E2, C), such as SR Policy [RFC9256], IGP
Flex-Algo [RFC9350], and BGP CAR (as specified in this document). Flexible Algorithm [RFC9350], and BGP CAR (as specified in this
document).
Color-aware route (E2, C): Color-aware route (E2, C):
A distributed or signaled route that builds a color-aware path to A distributed or signaled route that builds a color-aware path to
E2 for color C. E2 for color C.
Service route automated steering on color-aware path: Service route automated steering on color-aware path:
An ingress PE (or ASBR) E1 automatically steers traffic for a An ingress PE (or ASBR) E1 automatically steers traffic for a
C-colored service route V/v from E2 onto an (E2, C) color-aware C-colored service route V/v from E2 onto an (E2, C) color-aware
path. If several such paths exist, a preference scheme is used to path. If several such paths exist, a preference scheme is used to
select the best path (for example, IGP Flex-Algo is preferred over select the best path (for example, IGP Flexible Algorithm is
SR Policy, and SR Policy is preferred over BGP CAR). preferred over SR Policy, and SR Policy is preferred over BGP
CAR).
Color domain: Color domain:
A set of nodes that share the same color-to-intent mapping, A set of nodes that share the same color-to-intent mapping,
typically under single administration. This set can be organized typically under single administration. This set can be organized
into one or multiple network domains (IGP areas/instances within a into one or multiple network domains (IGP areas/instances within a
single BGP AS, or multiple BGP ASes). Color-to-intent mapping on single BGP AS, or multiple BGP ASes). Color-to-intent mapping on
nodes is set by configuration. Color re-mapping and filtering may nodes is set by configuration. Color re-mapping and filtering may
happen at color domain boundaries. Refer to [INTENT-AWARE]. happen at color domain boundaries. Refer to [INTENT-AWARE].
Resolution of a BGP CAR route (E, C): Resolution of a BGP CAR route (E, C):
skipping to change at line 300 skipping to change at line 303
Consistent with the terminology used in the SR Policy document Consistent with the terminology used in the SR Policy document
(Section 8 of [RFC9256]), in this document (service route) (Section 8 of [RFC9256]), in this document (service route)
steering is used to describe the mapping of the traffic for a steering is used to describe the mapping of the traffic for a
service route onto a BGP CAR path. In contrast, the term service route onto a BGP CAR path. In contrast, the term
resolution is preserved for the mapping of an inter-domain BGP CAR resolution is preserved for the mapping of an inter-domain BGP CAR
route on an intra-domain color-aware path. route on an intra-domain color-aware path.
Service steering: Service steering:
Service route maps traffic to a BGP CAR path (or other color- Service route maps traffic to a BGP CAR path (or other color-
aware path, e.g., SR Policy). If a color-aware path is not aware path, e.g., SR Policy). If a color-aware path is not
available, local policy may map to a traditional routing/TE available, local policy may map to a color-unaware routing/TE
path (e.g., BGP LU, RSVP-TE, IGP/LDP). The service steering path (e.g., BGP LU, RSVP-TE, IGP/LDP). The service steering
concept is agnostic to the transport technology used. concept is agnostic to the transport technology used.
Section 3 describes the specific service steering mechanisms Section 3 describes the specific service steering mechanisms
leveraged for MPLS, SR-MPLS, and SRv6. leveraged for MPLS, SR-MPLS, and SRv6.
Intra-domain resolution: Intra-domain resolution:
BGP CAR route maps to an intra-domain color-aware path (e.g., BGP CAR route maps to an intra-domain color-aware path (e.g.,
SR Policy, IGP Flex-Algo, BGP CAR) or a traditional routing/TE SR Policy, IGP Flexible Algorithm, BGP CAR) or a color-unaware
path (e.g., RSVP-TE, IGP/LDP, BGP-LU). routing/TE path (e.g., RSVP-TE, IGP/LDP, BGP-LU).
Transport network: Transport network:
A network that comprises of multiple cooperating domains managed A network that comprises of multiple cooperating domains managed
by one or more operators, and uses routing technologies such as by one or more operators, and uses routing technologies such as
IP, MPLS, and SR to forward packets for connectivity and other IP, MPLS, and SR to forward packets for connectivity and other
services. In an SR deployment, the transport network is within a services. In an SR deployment, the transport network is within a
trusted domain as per [RFC8402]. trusted domain as per [RFC8402].
Transport layer: Transport layer:
Refers to an underlay network layer (e.g., MPLS LSPs between PEs) Refers to an underlay network layer (e.g., MPLS LSPs between PEs)
skipping to change at line 340 skipping to change at line 343
Abbreviations: Abbreviations:
ABR: Area Border Router ABR: Area Border Router
AFI: Address Family Identifier AFI: Address Family Identifier
AIGP: Accumulated IGP Metric Attribute [RFC7311] AIGP: Accumulated IGP Metric Attribute [RFC7311]
ASBR: Autonomous System Border Router ASBR: Autonomous System Border Router
BGP-LU: BGP Labeled Unicast SAFI [RFC8277] BGP-LU: BGP Labeled-Unicast SAFI (SAFI value 4 as per [RFC8277])
BGP-IP: BGP IPv4/IPv6 Unicast AFI/SAFIs [RFC4271] [RFC4760] BGP-IP: BGP IPv4/IPv6 Unicast SAFI (SAFI value 1 as per [RFC4760]
and [RFC4271])
BR: Border Router (either for an IGP area (an ABR) or a BGP BR: Border Router (either for an IGP area (an ABR) or a BGP
autonomous system (an ASBR)) autonomous system (an ASBR))
Color-EC: BGP Color Extended-Community [RFC9012] Color-EC: BGP Color Extended Community [RFC9012]
E: Generic representation of a transport endpoint such as a PE, ABR, E: Generic representation of a transport endpoint such as a PE, ABR,
or ASBR or ASBR
LCM-EC: BGP Local Color Mapping Extended-Community LCM-EC: BGP Local Color Mapping Extended Community
NLRI: Network Layer Reachability Information [RFC4271] NLRI: Network Layer Reachability Information [RFC4271]
P node: An intra-domain transport router P node: An intra-domain transport router
RD: Route Distinguisher RD: Route Distinguisher
RR: Route Reflector RR: Route Reflector
SAFI: Subsequent Address Family Identifier SAFI: Subsequent Address Family Identifier
skipping to change at line 389 skipping to change at line 393
|----+ | | | | +----| W/w with C2 |----+ | | | | +----| W/w with C2
| |------| |------| | | |------| |------| |
| Domain 1 | | Domain 2 | | Domain 3 | | Domain 1 | | Domain 2 | | Domain 3 |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
Figure 1: BGP CAR Solution Illustration Figure 1: BGP CAR Solution Illustration
All the nodes are part of an inter-domain network under a single All the nodes are part of an inter-domain network under a single
authority and with a consistent color-to-intent mapping: authority and with a consistent color-to-intent mapping:
* C1 is mapped to "low-delay" * C1 is mapped to "low delay"
- Flex-Algo FA1 is mapped to "low delay", and hence to C1 - Flex-Algo 1 is mapped to "low delay", and hence to C1
* C2 is mapped to "low-delay and avoid resource R" * C2 is mapped to "low delay and avoid resource R"
- Flex-Algo FA2 is mapped to "low delay and avoid resource R", - Flex-Algo 2 is mapped to "low delay and avoid resource R", and
and hence to C2 hence to C2
E1 receives two service routes from E2: E1 receives two service routes from E2:
* V/v with BGP Color-EC C1 * V/v with BGP Color-EC C1
* W/w with BGP Color-EC C2 * W/w with BGP Color-EC C2
E1 has the following color-aware paths: E1 has the following color-aware paths:
* (E2, C1) provided by BGP CAR with the following per-domain * (E2, C1) provided by BGP CAR with the following per-domain
skipping to change at line 429 skipping to change at line 433
* V/v via (E2, C1) provided by BGP CAR * V/v via (E2, C1) provided by BGP CAR
* W/w via (E2, C2) provided by SR Policy * W/w via (E2, C2) provided by SR Policy
Illustrated properties: Illustrated properties:
* Leverage of the BGP Color-EC * Leverage of the BGP Color-EC
- The service routes are colored with widely used BGP Color - The service routes are colored with widely used BGP Color
Extended-Community [RFC9012] to request intent Extended Community [RFC9012] to request intent
* (E, C) automated steering * (E, C) automated steering
- V/v and W/w are automatically steered on the appropriate color- - V/v and W/w are automatically steered on the appropriate color-
aware path aware path
* Seamless coexistence of BGP CAR and SR Policy * Seamless coexistence of BGP CAR and SR Policy
- V/v is steered on BGP CAR color-aware path - V/v is steered on a color-aware path provided by BGP CAR
- W/w is steered on SR Policy color-aware path - W/w is steered on a color-aware path provided by SR Policy
* Seamless interworking of BGP CAR and SR Policy * Seamless interworking of BGP CAR and SR Policy
- V/v is steered on a BGP CAR color-aware path that is itself - V/v is steered on a BGP CAR path that is itself resolved within
resolved within domain 2 onto an SR Policy bound to the color domain 2 onto an SR Policy bound to the color of V/v
of V/v
Other properties: Other properties:
* MPLS data-plane: with 300k PEs and 5 colors, the BGP CAR solution * MPLS data-plane: with 300k PEs and 5 colors, the BGP CAR solution
ensures that no single node needs to support a data-plane scaling ensures that no single node needs to support a data-plane scaling
in the order of Remote PE * C (Section 5). This would otherwise in the order of Remote PE * C (Section 5). This would otherwise
exceed the MPLS data-plane. exceed the MPLS data-plane.
* Control-plane: a node should not install a (E, C) path if it's not * Control-plane: a node should not install a (E, C) path if it's not
participating in that color-aware path. participating in that color-aware path.
skipping to change at line 479 skipping to change at line 482
* The definition of the data model of a BGP CAR path: (E, C) * The definition of the data model of a BGP CAR path: (E, C)
- Natural extension of BGP IP/LU data model (E) - Natural extension of BGP IP/LU data model (E)
- Consistent with SR Policy data model - Consistent with SR Policy data model
* The definition of the recursive resolution of a BGP CAR route: a * The definition of the recursive resolution of a BGP CAR route: a
BGP CAR (E2, C) route via N is resolved onto the color-aware path BGP CAR (E2, C) route via N is resolved onto the color-aware path
(N, C), which may itself be provided by BGP CAR or via another (N, C), which may itself be provided by BGP CAR or via another
color-aware routing solution (e.g., SR Policy, IGP Flex-Algo) color-aware routing solution (e.g., SR Policy, IGP Flexible
Algorithm)
* Native support for multiple transport encapsulations (e.g., MPLS, * Explicit definitions for multiple transport encapsulations (e.g.,
SR, SRv6, IP) MPLS, SR, SRv6, IP)
1.3. Requirements Language 1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. BGP CAR SAFI 2. BGP CAR SAFI
skipping to change at line 507 skipping to change at line 511
NLRI key: Falls into two categories to accommodate the use cases NLRI key: Falls into two categories to accommodate the use cases
described in the introduction: described in the introduction:
Type-1: Key is IP Prefix and Color (E, C). Color in NLRI key Type-1: Key is IP Prefix and Color (E, C). Color in NLRI key
distinguishes a color-aware route for a common IP prefix, one distinguishes a color-aware route for a common IP prefix, one
per intent. Color also indicates the intent associated with per intent. Color also indicates the intent associated with
the route. the route.
Type-2: Key is IP Prefix (E). The unique IP prefix assigned for Type-2: Key is IP Prefix (E). The unique IP prefix assigned for
an intent (i.e, IP Prefix == intent or Color) distinguishes the an intent (i.e, IP Prefix == intent) distinguishes the color-
color-aware route. Color is not needed in NLRI key as a aware route. Color is not needed in NLRI key as a
distinguisher. distinguisher.
NLRI non-key encapsulation data: Data such as MPLS label stack, NLRI non-key encapsulation data: Data such as MPLS label stack, SR-
Label Index, and SRv6 SID list associated with NLRI. Contained in MPLS label index, and SRv6 SID list associated with NLRI.
TLVs as described in Section 2.9.2. Contained in TLVs as described in Section 2.9.2.
BGP next hop. BGP next hop: Next hop address associated with a particular NLRI key
[RFC4760].
AIGP metric [RFC7311]: Accumulates a metric value specific to color/ AIGP metric [RFC7311]: Accumulates a metric value specific to color/
intent for a CAR route across multiple BGP hops. intent for a CAR route across multiple BGP hops.
Local-Color-Mapping Extended-Community (LCM-EC): Optional non-zero Local Color Mapping Extended Community (LCM-EC): Optional non-zero
32-bit Color value used to represent the intent associated with a 32-bit Color value used to represent the intent associated with a
CAR route: CAR route:
* when the CAR route propagates between different color domains. * when the CAR route propagates between different color domains.
* when the CAR route has a unique IP prefix for an intent. * when the CAR route has a unique IP prefix for an intent.
BGP Color Extended-Community (Color-EC) [RFC9012]: Optional non-zero BGP Color Extended Community (Color-EC) [RFC9012]: Optional non-zero
32-bit Color value used to represent the intent associated with 32-bit color value used to represent the intent associated with
the BGP CAR next hop. It is used as per [RFC9256] for automated the BGP CAR next hop. It is used as per [RFC9256] for automated
route resolution, when intent/color used for the next hop is route resolution, when intent/color used for the next hop is
different than the CAR route's intent/color. different than the CAR route's intent/color.
The sections below describe the data model in detail. The sections The sections below describe the data model in detail. The sections
that describe the protocol processing for CAR SAFI generally apply that describe the protocol processing for CAR SAFI generally apply
consistently to both route types (for instance, any operation based consistently to both route types (for instance, any operation based
on color). The examples use (E, C) for simplicity. on color). The examples use (E, C) for simplicity.
2.2. Extensible Encoding 2.2. Extensible Encoding
skipping to change at line 566 skipping to change at line 571
update packing (Section 2.9). update packing (Section 2.9).
AIGP attribute: This provides extensibility via TLVs, enabling AIGP attribute: This provides extensibility via TLVs, enabling
definition of additional metric semantics for a color as needed definition of additional metric semantics for a color as needed
for an intent. for an intent.
2.3. BGP CAR Route Origination 2.3. BGP CAR Route Origination
A BGP CAR route may be originated locally (e.g., loopback) or through A BGP CAR route may be originated locally (e.g., loopback) or through
redistribution of an (E, C) color-aware path provided by another redistribution of an (E, C) color-aware path provided by another
routing solution (e.g., SR Policy, IGP Flex-Algo, RSVP-TE, BGP-LU routing solution (e.g., SR Policy, IGP Flexible Algorithm, RSVP-TE,
[RFC8277]). BGP-LU [RFC8277]).
2.4. BGP CAR Route Validation 2.4. BGP CAR Route Validation
A BGP CAR path (E, C) via next hop N with encapsulation T is valid if A BGP CAR path (E, C) via next hop N with encapsulation T is valid if
color-aware path (N, C) exists with encapsulation T available in color-aware path (N, C) exists with encapsulation T available in
data-plane. data-plane.
A local policy may customize the validation process: A local policy may customize the validation process:
* The color constraint in the first check may be relaxed. If N is * The color constraint in the first check may be relaxed. If N is
skipping to change at line 595 skipping to change at line 600
the intent associated with C is met (e.g., delay < bound). the intent associated with C is met (e.g., delay < bound).
A path that is not valid MUST NOT be considered for BGP best path A path that is not valid MUST NOT be considered for BGP best path
selection. selection.
2.5. BGP CAR Route Resolution 2.5. BGP CAR Route Resolution
A BGP color-aware route (E2, C1) with next hop N is automatically A BGP color-aware route (E2, C1) with next hop N is automatically
resolved over a color-aware route (N, C1) by default. The color- resolved over a color-aware route (N, C1) by default. The color-
aware route (N, C1) is provided by color-aware mechanisms such as IGP aware route (N, C1) is provided by color-aware mechanisms such as IGP
Flex-Algo [RFC9350], SR policy (Section 2.2 of [RFC9256]), or Flexible Algorithm [RFC9350], SR Policy (Section 2.2 of [RFC9256]),
recursively by BGP CAR. When multiple producers of (N, C1) are or recursively by BGP CAR. When multiple producers of (N, C1) are
available, the default preference is: IGP Flex-Algo, SR Policy, BGP available, the default preference is: IGP Flexible Algorithm, SR
CAR. Policy, BGP CAR.
Local policy SHOULD provide additional control: Local policy SHOULD provide additional control:
* A BGP color-aware route (E2, C1) with next hop N may be resolved * A BGP color-aware route (E2, C1) with next hop N may be resolved
over a color-aware route (N, C2) (i.e., the local policy maps the over a color-aware route (N, C2) (i.e., the local policy maps the
resolution of C1 over a different color C2). resolution of C1 over a different color C2). Examples where such
a resolution can occur are:
- For example, in a domain where resource R is known to not be - In a domain where resource R is known to not be present, the
present, the inter-domain intent C1="low delay and avoid R" may inter-domain intent C1="low delay and avoid R" may be resolved
be resolved over an intra-domain path of intent C2="low delay". over an intra-domain path of intent C2="low delay".
- Another example is: if no (N, C1) path is available and the - In a domain where if no (N, C1) path is available, resolution
user has allowed resolution to fallback to a C2 path. may fallback to a C2 path if the user has permitted it.
* Route resolution may be driven by an egress node. In an SRv6 * Route resolution may be driven by an egress node. In an SRv6
domain, an egress node selects and advertises an SRv6 SID from its domain, an egress node selects and advertises an SRv6 SID from its
locator for intent C1, with a BGP CAR route. In such a case, the locator for intent C1, with a BGP CAR route. In such a case, the
ingress node resolves the received SRv6 SID over an IPv6 route for ingress node resolves the received SRv6 SID over an IPv6 route for
the intent-aware locator of the egress node for C1 or a summary the intent-aware locator of the egress node for C1 or a summary
route that covers the locator. This summary route may be provided route that covers the locator. This summary route may be provided
by SRv6 Flex Algo or BGP CAR IP Prefix route itself (e.g., by SRv6 Flexible Algorithm or BGP CAR IP Prefix route itself
Appendix C.2). (e.g., Appendix C.2).
* Local policy may map the CAR route to traditional mechanisms that * Local policy may map the CAR route to mechanisms that are unaware
are unaware of color or that provide best-effort, such as RSVP-TE, of color or that provide best-effort, such as RSVP-TE, IGP/LDP,
IGP/LDP, BGP LU/IP (e.g., Appendix A.3.2) for brownfield BGP LU/IP (e.g., Appendix A.3.2) for brownfield scenarios.
scenarios.
Route resolution via a different color C2 can be automated by Route resolution via a different color C2 can be automated by
attaching BGP Color-EC C2 to CAR route (E2, C1), leveraging automated attaching BGP Color-EC C2 to CAR route (E2, C1), leveraging automated
steering as described in Section 8.4 of "Segment Routing Policy steering as described in Section 8.4 of "Segment Routing Policy
Architecture" [RFC9256] for BGP CAR routes. This mechanism is Architecture" [RFC9256] for BGP CAR routes. This mechanism is
illustrated in Appendix B.2. This mechanism SHOULD be supported. illustrated in Appendix B.2. This mechanism SHOULD be supported.
For CAR route resolution, Color-EC color if present takes precedence For CAR route resolution, if Color-EC color is present with the
over the route's intent color (LCM-EC if present (Section 2.9.5), or route, it takes precedence over the route's intent color. The
else NLRI color). route’s intent color is the LCM-EC color if present (see
Section 2.9.5), or else it is the NLRI color.
Local policy takes precedence over the color-based automated Local policy takes precedence over the color-based automated
resolution specified above. resolution specified above.
The color-aware route (N, C1) may be provided by BGP CAR itself in a The color-aware route (N, C1) may be provided by BGP CAR itself in a
hierarchical transport routing design. In such cases, based on the hierarchical transport routing design. In such cases, based on the
procedures described above, recursive resolution may occur over the procedures described above, recursive resolution may occur over the
same or different CAR route type. Section 7.1.2 describes a scenario same or different CAR route type. Section 7.1.2 describes a scenario
where CAR (E, C) route resolves over CAR IP Prefix route. where CAR (E, C) route resolves over CAR IP Prefix route.
skipping to change at line 669 skipping to change at line 675
[RFC9012]. [RFC9012].
BGP CAR resolution in one network domain is independent of resolution BGP CAR resolution in one network domain is independent of resolution
in another domain. in another domain.
2.6. AIGP Metric Computation 2.6. AIGP Metric Computation
The Accumulated IGP (AIGP) Metric Attribute [RFC7311] is updated as The Accumulated IGP (AIGP) Metric Attribute [RFC7311] is updated as
the BGP CAR route propagates across the network. the BGP CAR route propagates across the network.
The value set (or appropriately incremented) in the AIGP TLV The value that is set (or appropriately incremented) in the AIGP TLV
corresponds to the metric associated with the underlying intent of corresponds to the metric associated with the underlying intent of
the color. For example, when the color is associated with a low- the color. For example, when the color is associated with a low
latency path, the metric value is set based on the delay metric. latency path, the metric value is set based on the delay metric.
Information regarding the metric type used by the underlying intra- Information regarding the metric type used by the underlying intra-
domain mechanism can also be used to set the metric value. domain mechanism can also be used to set the metric value.
If BGP CAR routes traverse across a discontinuity in the transport If BGP CAR routes traverse across a discontinuity in the transport
path for a given intent, a penalty is added in the AIGP metric (value path for a given intent, a penalty is added in the AIGP metric (value
set by user policy). This could occur, for instance, when color C1 set by user policy). This could occur, for instance, when color C1
path is not available, and route resolves via color C2 path (see path is not available, and route resolves via color C2 path (see
Appendix A.3 for an example). Appendix A.3 for an example).
skipping to change at line 694 skipping to change at line 700
To avoid continuous IGP metric changes causing end-to-end BGP CAR To avoid continuous IGP metric changes causing end-to-end BGP CAR
route churn, an implementation should provide thresholds to trigger route churn, an implementation should provide thresholds to trigger
AIGP updates. AIGP updates.
Additional AIGP extensions may be defined to signal state for Additional AIGP extensions may be defined to signal state for
specific use cases such as Maximum SID Depth (MSD) along the BGP CAR specific use cases such as Maximum SID Depth (MSD) along the BGP CAR
route advertisement and minimum MTU along the BGP CAR route route advertisement and minimum MTU along the BGP CAR route
advertisement. This is out of scope for this document. advertisement. This is out of scope for this document.
2.7. Native Multipath Capability 2.7. Inherent Multipath Capability
The (E, C) route definition inherently provides availability of The (E, C) route definition inherently provides availability of
redundant paths at every BGP hop identical to BGP-LU or BGP IP. For redundant paths at every BGP hop identical to BGP-LU or BGP IP. For
instance, BGP CAR routes originated by two or more egress ABRs in a instance, BGP CAR routes originated by two or more egress ABRs in a
domain are advertised as multiple paths to ingress ABRs in the domain are advertised as multiple paths to ingress ABRs in the
domain, where they become equal-cost or primary-backup paths. A domain, where they become equal-cost or primary-backup paths. A
failure of an egress ABR is detected and handled by ingress ABRs failure of an egress ABR is detected and handled by ingress ABRs
locally within the domain for faster convergence, without any locally within the domain for faster convergence, without any
necessity to propagate the event to upstream nodes for traffic necessity to propagate the event to upstream nodes for traffic
restoration. restoration.
BGP ADD-PATH [RFC7911] SHOULD be enabled for BGP CAR to signal BGP ADD-PATH [RFC7911] SHOULD be enabled for BGP CAR to signal
multiple next hops through a transport RR. multiple next hops through a transport RR.
2.8. BGP CAR Signaling Through Different Color Domains 2.8. BGP CAR Signaling Through Different Color Domains
[Color Domain 1 A]-----[B Color Domain 2 E2] [Color Domain 1 A]-----[B Color Domain 2 E2]
[C1=low-delay ] [C2=low-delay ] [C1=low delay ] [C2=low delay ]
Let us assume a BGP CAR route (E2, C2) is signaled from B to A, two Let us assume a BGP CAR route (E2, C2) is signaled from B to A, two
border routers of Domain 2 and Domain 1, respectively. Let us assume border routers of Domain 2 and Domain 1, respectively. Let us assume
that these two domains do not share the same color-to-intent mapping that these two domains do not share the same color-to-intent mapping
(i.e., they belong to different color domains). Low-delay in Domain (i.e., they belong to different color domains). Low-delay in Domain
2 is color C2, while it is C1 in Domain 1 (C1 <> C2). 2 is color C2, while it is C1 in Domain 1 (C1 <> C2).
It is not expected to be a typical scenario to have an underlay It is not expected to be a typical scenario to have an underlay
transport path (e.g., an MPLS LSP) extend across different color transport path (e.g., an MPLS LSP) extend across different color
domains. However, the BGP CAR solution seamlessly supports this rare domains. However, the BGP CAR solution seamlessly supports this rare
scenario while maintaining the separation and independence of the scenario while maintaining the separation and independence of the
administrative authority in different color domains. administrative authority in different color domains.
The solution works as described below: The solution works as described below:
* Within Domain 2, the BGP CAR route is (E2, C2) via E2. * Within Domain 2, the BGP CAR route is (E2, C2) via E2.
* B signals to A the BGP CAR route as (E2, C2) via B with Local- * B signals to A the BGP CAR route as (E2, C2) via B with Local
Color-Mapping-Extended-Community (LCM-EC) of color C2. Color Mapping Extended Community (LCM-EC) of color C2.
* A is aware of the intent-to-color mapping within Domain 2 ("low- * A is aware of the intent-to-color mapping within Domain 2 ("low
delay" in Domain 2 is C2), as per typical coordination that exists delay" in Domain 2 is C2), as per typical coordination that exists
between operators of peering domains. between operators of peering domains.
* A maps C2 in LCM-EC to C1 and signals within Domain 1 the received * A maps C2 in LCM-EC to C1 and signals within Domain 1 the received
BGP CAR route as (E2, C2) via A with LCM-EC (C1). BGP CAR route as (E2, C2) via A with LCM-EC (C1).
* The nodes within the receiving Domain 1 use the local color * The nodes within the receiving Domain 1 use the local color
encoded in the LCM-EC for next-hop resolution and service encoded in the LCM-EC for next-hop resolution and service
steering. steering.
skipping to change at line 820 skipping to change at line 826
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-Specific Non-Key TLV Fields (if applicable) // | Type-Specific Non-Key TLV Fields (if applicable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
NLRI Length: 1-octet field that indicates the length in octets of NLRI Length: 1-octet field that indicates the length in octets of
the NLRI excluding the NLRI Length field itself. the NLRI excluding the NLRI Length field itself.
Key Length: 1-octet field that indicates the length in octets of the Key Length: 1-octet field that indicates the length in octets of the
NLRI type-specific key fields. Key length MUST be at least 2 less NLRI Type-Specific Key Fields. Key Length MUST be at least 2 less
than the NLRI length. than the NLRI Length.
NLRI Type: 1-octet field that indicates the type of the BGP CAR NLRI Type: 1-octet field that indicates the type of the BGP CAR
NLRI. NLRI.
Type-Specific Key Fields: The exact definition of these fields Type-Specific Key Fields: The exact definition of these fields
depends on the NLRI type. They have length indicated by the Key depends on the NLRI Type. They have length indicated by the Key
Length. Length.
Type-Specific Non-Key TLV Fields: The fields are optional and can Type-Specific Non-Key TLV Fields: The fields are optional and can
carry one or more non-key TLVs (of different types) depending on carry one or more non-key TLVs (of different types) depending on
the NLRI type. The NLRI definition allows for encoding of the NLRI Type. The NLRI definition allows for encoding of
specific non-key information associated with the route as part of specific non-key information associated with the route as part of
the NLRI for efficient packing of BGP updates. the NLRI for efficient packing of BGP updates.
The non-key TLVs portion of the NLRI MUST be omitted while carrying The non-key TLVs portion of the NLRI MUST be omitted while carrying
it within the MP_UNREACH_NLRI when withdrawing the route it within the MP_UNREACH_NLRI when withdrawing the route
advertisement. advertisement.
Error handling for CAR SAFI NLRI and non-key TLVs is described in Error handling for CAR SAFI NLRI and non-key TLVs is described in
Section 2.11. Section 2.11.
skipping to change at line 907 skipping to change at line 913
unrecognized transitive TLV MUST be propagated by a speaker unrecognized transitive TLV MUST be propagated by a speaker
that changes the next hop. that changes the next hop.
* The T bit is unset to indicate TLV is non-transitive. An * The T bit is unset to indicate TLV is non-transitive. An
unrecognized non-transitive TLV MUST NOT be propagated by a unrecognized non-transitive TLV MUST NOT be propagated by a
speaker that changes the next hop. speaker that changes the next hop.
A speaker that does not change the next hop SHOULD propagate A speaker that does not change the next hop SHOULD propagate
all received TLVs. all received TLVs.
Type code: Remaining 6 bits contain the type of the TLV. Type code: Remaining 6 bits contain the type of the TLV.
Length: 1-octet field that contains the length of the value portion Length: 1-octet field that contains the length of the value portion
of the non-key TLV in terms of octets. of the Non-Key TLV in terms of octets.
Value: Variable-length field as indicated by the Length field and to Value: Variable-length field as indicated by the Length field and to
be interpreted as per the Type field. be interpreted as per the Type field.
The following sub-sections specify non-key TLVs. Each NLRI type MUST The following sub-sections specify non-key TLVs. Each NLRI Type MUST
list the TLVs that can be associated with it. list the TLVs that can be associated with it.
2.9.2.1. Label TLV 2.9.2.1. Label TLV
The Label TLV is used for the advertisement of CAR routes along with The Label TLV is used for the advertisement of CAR routes along with
their MPLS labels. It has the following format as per Section 2.9.2: their MPLS labels. It has the following format as per Section 2.9.2:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|T| Type | Length | |R|T| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is followed by one (or more) Labels encoded as below: It is followed by one (or more) labels encoded as below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |Rsrv |S| | Label |Rsrv |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Type: Type code is 1. The T bit MUST be unset. Type: Type code is 1. The T bit MUST be unset.
Length: Length is in octets, variable, and MUST be a multiple of 3. Length: Length is in octets, variable, and MUST be a multiple of 3.
skipping to change at line 955 skipping to change at line 961
Length field. The 3-bit Rsrv field and the 1-bit S field SHOULD Length field. The 3-bit Rsrv field and the 1-bit S field SHOULD
be set to zero on transmission and MUST be ignored on reception. be set to zero on transmission and MUST be ignored on reception.
If a BGP transport CAR speaker sets itself as the next hop while If a BGP transport CAR speaker sets itself as the next hop while
propagating a CAR route, it allocates a local label for the type- propagating a CAR route, it allocates a local label for the type-
specific key, and updates the value in this TLV. It also MUST specific key, and updates the value in this TLV. It also MUST
program a label cross-connect that would result in the label swap program a label cross-connect that would result in the label swap
operation for the incoming label that it advertises with the label operation for the incoming label that it advertises with the label
received from its best-path router(s). received from its best-path router(s).
2.9.2.2. Label Index TLV 2.9.2.2. Label-Index TLV
The Label Index TLV is used for the advertisement of Segment Routing The Label-Index TLV is used for the advertisement of Segment Routing
over MPLS (SR-MPLS) Segment Identifier (SID) [RFC8402] information over MPLS (SR-MPLS) Segment Identifier (SID) [RFC8402] information
associated with the labeled CAR routes. It has the following format associated with the labeled CAR routes. It has the following format
as per Section 2.9.2: as per Section 2.9.2:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|T| Type | Length | Reserved | Flags ~ |R|T| Type | Length | Reserved | Flags ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Label Index ~ ~ | Label Index ~
skipping to change at line 982 skipping to change at line 988
where: where:
Type: Type code is 2. The T bit MUST be set. Type: Type code is 2. The T bit MUST be set.
Length: Length is in octets and is 7. Length: Length is in octets and is 7.
Reserved: 1-octet field that MUST be set to 0 and ignored on Reserved: 1-octet field that MUST be set to 0 and ignored on
receipt. receipt.
Flags: 2-octet field that's defined as per the Flags field of the Flags: 2-octet field that's defined as per the Flags field of the
Label Index TLV of the BGP Prefix-SID attribute (Section 3.1 of Label-Index TLV of the BGP Prefix-SID attribute (Section 3.1 of
[RFC8669]). [RFC8669]).
Label Index: 4-octet field that's defined as per the Label Index Label Index: 4-octet field that's defined as per the Label Index
field of the Label Index TLV of the BGP Prefix-SID attribute field of the Label-Index TLV of the BGP Prefix-SID attribute
(Section 3.1 of [RFC8669]). (Section 3.1 of [RFC8669]).
This TLV provides the equivalent functionality as the Label Index TLV This TLV provides the equivalent functionality as the Label-Index TLV
of [RFC8669] for Transport CAR route in SR-MPLS deployments. When a of [RFC8669] for Transport CAR route in SR-MPLS deployments. When a
speaker allocates a local label for a received CAR route as per speaker allocates a local label for a received CAR route as per
Section 2.9.2.1, it SHOULD use the received Label Index as a hint Section 2.9.2.1, it SHOULD use the received Label Index as a hint
using procedures as specified in [RFC8669], Section 4. using procedures as specified in [RFC8669], Section 4.
The Label Index TLV provides much better packing efficiency by The Label-Index TLV provides much better packing efficiency by
carrying the Label Index in NLRI instead of in the BGP Prefix-SID carrying the Label Index in NLRI instead of in the BGP Prefix-SID
attribute (Appendix D). attribute (Appendix D).
The Label Index TLV MUST NOT be carried in the Prefix-SID attribute The Label-Index TLV MUST NOT be carried in the Prefix-SID attribute
for BGP CAR routes. If a speaker receives a CAR route with the Label for BGP CAR routes. If a speaker receives a CAR route with the
Index TLV in the Prefix-SID attribute, it SHOULD ignore it. The BGP Label-Index TLV in the Prefix-SID attribute, it SHOULD ignore it.
Prefix-SID attribute SHOULD NOT be sent with the labeled CAR routes The BGP Prefix-SID attribute SHOULD NOT be sent with the labeled CAR
if the attribute is being used only to convey the Label Index TLV. routes if the attribute is being used only to convey the Label-Index
TLV.
2.9.2.3. SRv6 SID TLV 2.9.2.3. SRv6 SID TLV
BGP Transport CAR can be also used to set up end-to-end color-aware BGP Transport CAR can be also used to set up end-to-end color-aware
connectivity using Segment Routing over IPv6 (SRv6) [RFC8402]. connectivity using Segment Routing over IPv6 (SRv6) [RFC8402].
[RFC8986] specifies the SRv6 Endpoint behaviors (e.g., End [RFC8986] specifies the SRv6 Endpoint behaviors (e.g., End
Penultimate Segment Pop (PSP)), which can be leveraged for BGP CAR Penultimate Segment Pop (PSP)), which can be leveraged for BGP CAR
with SRv6. The SRv6 SID TLV is used for the advertisement of CAR with SRv6. The SRv6 SID TLV is used for the advertisement of CAR
routes along with their SRv6 SIDs. It has the following format as routes along with their SRv6 SIDs. It has the following format as
per Section 2.9.2: per Section 2.9.2:
skipping to change at line 1040 skipping to change at line 1047
of the following: of the following:
* A single 128-bit SRv6 SID or an ordered list of 128-bit SRv6 * A single 128-bit SRv6 SID or an ordered list of 128-bit SRv6
SIDs. SIDs.
* A transposed portion (refer to [RFC9252]) of the SRv6 SID that * A transposed portion (refer to [RFC9252]) of the SRv6 SID that
MUST be of size in multiples of one octet and less than 16. MUST be of size in multiples of one octet and less than 16.
BGP CAR SRv6 SID TLV definitions provide the following benefits: BGP CAR SRv6 SID TLV definitions provide the following benefits:
* The native encoding of SIDs avoids robustness issues caused by the * The explicit encoding of SIDs avoids robustness issues caused by
overloading of MPLS label fields. the overloading of MPLS label fields.
* The simple encoding to signal Unique SIDs (non-transposition) * The encoding to include the entire 128 bits for unique SIDs (non-
maintains BGP update prefix packing. transposition) maintains BGP update prefix packing.
* The highly efficient transposition scheme (12-14 bytes saved per * The highly efficient transposition scheme (12-14 bytes saved per
NLRI) also maintains BGP update prefix packing. NLRI) also maintains BGP update prefix packing.
The BGP CAR route update for SRv6 encapsulation MUST include the BGP The BGP CAR route update for SRv6 encapsulation MUST include the BGP
Prefix-SID attribute along with the SRv6 L3 Service TLV carrying the Prefix-SID attribute along with the SRv6 L3 Service TLV carrying the
SRv6 SID information as specified in [RFC9252]. When using the SRv6 SID information as specified in [RFC9252]. When using the
transposition scheme of encoding for packing efficiency of BGP transposition scheme of encoding for packing efficiency of BGP
updates [RFC9252], the transposed part of the SID is carried in the updates [RFC9252], the transposed part of the SID is carried in the
SRv6 SID TLV and is not limited by MPLS label field size. SRv6 SID TLV and is not limited by MPLS label field size.
If a BGP transport CAR speaker sets itself as the next hop while If a BGP transport CAR speaker sets itself as the next hop while
propagating a CAR route and allocates an SRv6 SID that maps to the propagating a CAR route and allocates an SRv6 SID that maps to the
received SRv6 SID, it updates the value in this TLV. received SRv6 SID, it updates the value in this TLV.
Received MPLS information can map to SRv6 and vice versa. Received MPLS information can map to SRv6 and vice versa.
[SRv6-INTERWORK] describes MPLS and SRv6 interworking procedures and
an extension to BGP CAR routes. | [SRv6-INTERWORK] describes MPLS and SRv6 interworking
| procedures and their applicability to BGP CAR routes.
2.9.3. Color-Aware Route (E, C) NLRI Type 2.9.3. Color-Aware Route (E, C) NLRI Type
The Color-Aware Route NLRI Type is used for the advertisement of BGP The Color-Aware Route NLRI Type is used for the advertisement of BGP
CAR color-aware routes (E, C). It has the following format: CAR color-aware routes (E, C). It has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Length | Key Length | NLRI Type |Prefix Length | | NLRI Length | Key Length | NLRI Type |Prefix Length |
skipping to change at line 1125 skipping to change at line 1133
The last octet has enough trailing bits to make the end of the The last octet has enough trailing bits to make the end of the
field fall on an octet boundary. Note that the value of the field fall on an octet boundary. Note that the value of the
trailing bits MUST be set to zero. The size of the field MUST trailing bits MUST be set to zero. The size of the field MUST
be less than or equal to 4 for IPv4 (AFI=1) and less than or be less than or equal to 4 for IPv4 (AFI=1) and less than or
equal to 16 for IPv6 (AFI=2). equal to 16 for IPv6 (AFI=2).
Color: 4 octets that contain non-zero color value associated with Color: 4 octets that contain non-zero color value associated with
the prefix. the prefix.
Type-Specific Non-Key TLVs: The Label TLV, Label Index TLV, and SRv6 Type-Specific Non-Key TLVs: The Label TLV, Label-Index TLV, and SRv6
SID TLV (Section 2.9.2) may be associated with the Color-aware SID TLV (Section 2.9.2) may be associated with the Color-aware
route NLRI type. route NLRI type.
The prefix is unique across the administrative domains where BGP The prefix is unique across the administrative domains where BGP
transport CAR is deployed. It is possible that the same prefix is transport CAR is deployed. It is possible that the same prefix is
originated by multiple BGP CAR speakers in the case of anycast originated by multiple BGP CAR speakers in the case of anycast
addressing or multihoming. addressing or multihoming.
The Color is introduced to enable multiple route advertisements for The Color is introduced to enable multiple route advertisements for
the same prefix. The color is associated with an intent (e.g., low- the same prefix. The color is associated with an intent (e.g., low
latency) in originator color domain. latency) in originator color domain.
2.9.4. IP Prefix (E) NLRI Type 2.9.4. IP Prefix (E) NLRI Type
The IP Prefix Route NLRI Type is used for the advertisement of BGP The IP Prefix Route NLRI Type is used for the advertisement of BGP
CAR IP Prefix routes (E). It has the following format: CAR IP Prefix routes (E). It has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 1194 skipping to change at line 1202
The format for this field for an IPv6 address follows the same The format for this field for an IPv6 address follows the same
pattern for prefix lengths of 1-128 (octets 1-16). pattern for prefix lengths of 1-128 (octets 1-16).
The last octet has enough trailing bits to make the end of the The last octet has enough trailing bits to make the end of the
field fall on an octet boundary. Note that the value of the field fall on an octet boundary. Note that the value of the
trailing bits MUST be set to zero. The size of the field MUST trailing bits MUST be set to zero. The size of the field MUST
be less than or equal to 4 for IPv4 (AFI=1) and less than or be less than or equal to 4 for IPv4 (AFI=1) and less than or
equal to 16 for IPv6 (AFI=2). equal to 16 for IPv6 (AFI=2).
Type-Specific Non-Key TLVs: The Label TLV, Label Index TLV, and SRv6 Type-Specific Non-Key TLVs: The Label TLV, Label-Index TLV, and SRv6
SID TLV (Section 2.9.2) may be associated with the IP Prefix NLRI SID TLV (Section 2.9.2) may be associated with the IP Prefix NLRI
type. Type.
2.9.5. Local-Color-Mapping (LCM) Extended-Community 2.9.5. Local Color Mapping (LCM) Extended Community
This document defines a new BGP Extended-Community called "LCM". The This document defines a new BGP Extended Community called "LCM". The
LCM is a Transitive Opaque Extended-Community with the following LCM is a Transitive Opaque Extended Community with the following
encoding: encoding:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x3 | Sub-Type=0x1b | Reserved | | Type=0x3 | Sub-Type=0x1b | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color | | Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 1322 skipping to change at line 1330
The CAR NLRI definition encodes NLRI length and key length The CAR NLRI definition encodes NLRI length and key length
explicitly. The NLRI length MUST be relied upon to enable the explicitly. The NLRI length MUST be relied upon to enable the
beginning of the next NLRI field to be located. Key length MUST be beginning of the next NLRI field to be located. Key length MUST be
relied upon to extract the key and perform 'treat-as-withdraw' for relied upon to extract the key and perform 'treat-as-withdraw' for
malformed information. malformed information.
A sender MUST ensure that the NLRI and key lengths are the number of A sender MUST ensure that the NLRI and key lengths are the number of
actual bytes encoded in the NLRI and key fields, respectively, actual bytes encoded in the NLRI and key fields, respectively,
regardless of content being encoded. regardless of content being encoded.
Given NLRI length and Key length MUST be valid, failures in the Given the NLRI length and Key length MUST be valid, failures in the
following checks result in 'AFI/SAFI disable' or 'session reset': following checks result in 'AFI/SAFI disable' or 'session reset':
* Minimum NLRI length (must be at least 2, as key length and NLRI * The minimum NLRI length MUST be at least 2, as key length and NLRI
type are required fields). type are required fields.
* Key Length MUST be at least two less than NLRI Length. * The Key Length MUST be at least 2 less than NLRI Length.
NLRI type-specific error handling: NLRI type-specific error handling:
* By default, a speaker SHOULD discard an unrecognized or * By default, a speaker SHOULD discard an unrecognized or
unsupported NLRI type and move to the next NLRI. unsupported NLRI type and move to the next NLRI.
* Key length and key errors of a known NLRI type SHOULD result in * Key length and key errors of a known NLRI type SHOULD result in
the discard of NLRI similar to an unrecognized NLRI type. (This the discard of NLRI similar to an unrecognized NLRI type. (This
MUST be logged for trouble shooting.) MUST be logged for trouble shooting.)
skipping to change at line 1387 skipping to change at line 1395
considered invalid and not eligible for best path selection. considered invalid and not eligible for best path selection.
'Treat-as-withdraw' may be used, though it is recommended to keep 'Treat-as-withdraw' may be used, though it is recommended to keep
the NLRI for debugging purposes. the NLRI for debugging purposes.
3. Service Route Automated Steering on Color-Aware Paths 3. Service Route Automated Steering on Color-Aware Paths
An ingress PE (or ASBR) E1 automatically steers a C-colored service An ingress PE (or ASBR) E1 automatically steers a C-colored service
route V/v from E2 onto an (E2, C) color-aware path, as illustrated in route V/v from E2 onto an (E2, C) color-aware path, as illustrated in
Section 1.2. If several such paths exist, a preference scheme is Section 1.2. If several such paths exist, a preference scheme is
used to select the best path. The default preference scheme is IGP used to select the best path. The default preference scheme is IGP
Flex-Algo first, then SR Policy, followed by BGP CAR. A Flexible Algorithm first, then SR Policy, followed by BGP CAR. A
configuration option may be used to adjust the default preference configuration option may be used to adjust the default preference
scheme. scheme.
An egress PE may express its intent that traffic should be steered a An egress PE may express its intent that traffic should be steered a
certain way through the transport layer by including the BGP Color-EC certain way through the transport layer by including the BGP Color-EC
[RFC9012] with the relevant service routes. An ingress PE steers [RFC9012] with the relevant service routes. An ingress PE steers
service traffic over a CAR (E, C) route using the service route's service traffic over a CAR (E, C) route using the service route's
next hop and BGP Color-EC. next hop and BGP Color-EC.
This is consistent with the automated service route steering on SR This is consistent with the automated service route steering on SR
Policy (a routing solution providing color-aware paths) defined in Policy (a routing solution providing color-aware paths) defined in
[RFC9256]. All the steering variations described in [RFC9256] are [RFC9256]. All the steering variations described in [RFC9256] are
applicable to BGP CAR color-aware paths: on-demand steering, per- applicable to BGP CAR paths: on-demand steering, per-destination
destination steering, per-flow steering, and color-only steering. steering, per-flow steering, and color-only steering. For brevity,
For brevity, please refer to Section 8 of [RFC9256]. please refer to Section 8 of [RFC9256].
Appendix A provides illustrations of service route automated steering Appendix A provides illustrations of service route automated steering
over BGP CAR (E, C) routes. over BGP CAR (E, C) routes.
An egress PE may express its intent that traffic should be steered a An egress PE may express its intent that traffic should be steered a
certain way through the transport layer by allocating the SRv6 certain way through the transport layer by allocating the SRv6
Service SID from a routed intent-aware locator prefix (Section 3.3 of Service SID from a routed intent-aware locator prefix (Section 3.3 of
[RFC8986]). Steering at an ingress PE is via resolution of the [RFC8986]). Steering at an ingress PE is via resolution of the
Service SID over a CAR Type-2 IP Prefix route. Service steering over Service SID over a CAR Type-2 IP Prefix route. Service steering over
BGP CAR SRv6 transport is described in Section 7. BGP CAR SRv6 transport is described in Section 7.
skipping to change at line 1424 skipping to change at line 1432
Service steering via BGP CAR routes is applicable to any BGP SAFI, Service steering via BGP CAR routes is applicable to any BGP SAFI,
including SAFIs for IPv4/IPv6 (SAFI 1), L3VPN (SAFI 128), pseudowire including SAFIs for IPv4/IPv6 (SAFI 1), L3VPN (SAFI 128), pseudowire
(PW), EVPN (SAFI 70), FlowSpec, and BGP-LU (SAFI 4). (PW), EVPN (SAFI 70), FlowSpec, and BGP-LU (SAFI 4).
4. Filtering 4. Filtering
PEs and BRs may support filtering of CAR routes. For instance, the PEs and BRs may support filtering of CAR routes. For instance, the
filtering may only accept routes of locally configured colors. filtering may only accept routes of locally configured colors.
Techniques such as RT Constrain [RFC4684] may also be applied to the Techniques such as RT Constrain [RFC4684] may also be applied to the
CAR SAFI, where Route Target (RT) Extended-Communities [RFC4360] can CAR SAFI, where Route Target (RT) Extended Communities [RFC4360] can
be used to constrain distribution and automate filtering of CAR be used to constrain distribution and automate filtering of CAR
routes. RT assignment may be via user policy; for example, an RT routes. RT assignment may be via user policy; for example, an RT
value can be assigned to all routes of a specific color. value can be assigned to all routes of a specific color.
A PE may support on-demand installation of a CAR route based on the A PE may support on-demand installation of a CAR route based on the
presence of a service route whose next hop resolves via the CAR presence of a service route whose next hop resolves via the CAR
route. route.
Similarly, a PE may dynamically subscribe to receive individual CAR Similarly, a PE may dynamically subscribe to receive individual CAR
routes from upstream routers or Route Reflectors (RRs) to limit the routes from upstream routers or Route Reflectors (RRs) to limit the
skipping to change at line 1504 skipping to change at line 1512
| domain 1 | domain 2 | domain 3 | domain 4 | domain 5 | | domain 1 | domain 2 | domain 3 | domain 4 | domain 5 |
+-------------+--------------+--------------+--------------+----------+ +-------------+--------------+--------------+--------------+----------+
iPE iBRM iBRC eBRC eBRM ePE iPE iBRM iBRC eBRC eBRM ePE
Figure 2: Ultra-Scale Reference Topology Figure 2: Ultra-Scale Reference Topology
The following description applies to the reference topology above: The following description applies to the reference topology above:
* Independent IS-IS/OSPF SR instance in each domain. * Independent IS-IS/OSPF SR instance in each domain.
* Each domain has Flex Algo 128. Prefix-SID for a node is Segment * Each domain has Flex-Algo 128. Prefix-SID for a node is Segment
Routing Global Block (SRGB) 168000 plus node number. Routing Global Block (SRGB) 168000 plus node number.
* A BGP CAR route (E2, C1) is advertised by egress BRM node 451. * A BGP CAR route (E2, C1) is advertised by egress BRM node 451.
The route is sourced locally from redistribution from IGP-FA 128. The route is sourced locally from redistribution from IGP Flex-
Algo 128.
* Not shown for simplicity, node 452 will also advertise (E2, C1). * Not shown for simplicity, node 452 will also advertise (E2, C1).
* When a transport RR is used within the domain or across domains, * When a transport RR is used within the domain or across domains,
ADD-PATH is enabled to advertise paths from both egress BRs to its ADD-PATH is enabled to advertise paths from both egress BRs to its
clients. clients.
* Egress PE E2 advertises a VPN route RD:V/v with BGP Color-EC C1 * Egress PE E2 advertises a VPN route RD:V/v with BGP Color-EC C1
that propagates via service RRs to ingress PE E1. that propagates via service RRs to ingress PE E1.
skipping to change at line 1569 skipping to change at line 1578
* Each BGP hop allocates local label and programs swap entry in * Each BGP hop allocates local label and programs swap entry in
forwarding for (E2, C1). forwarding for (E2, C1).
* E1 receives BGP CAR route (E2, C1) via 121 with label 168002. * E1 receives BGP CAR route (E2, C1) via 121 with label 168002.
- Let's assume E1 selects that path. - Let's assume E1 selects that path.
* E1 resolves BGP CAR route (E2, C1) via 121 on color-aware path * E1 resolves BGP CAR route (E2, C1) via 121 on color-aware path
(121, C1). (121, C1).
- Color-aware path (121, C1) is FA128 path to 121 (label 168121). - Color-aware path (121, C1) is Flex-Algo 128 path to 121 (label
168121).
* E1's imposition color-aware label stack for V/v is thus: * E1's imposition color-aware label stack for V/v is thus:
- 30030 <=> V/v - 30030 <=> V/v
- 168002 <=> (E2, C1) - 168002 <=> (E2, C1)
- 168121 <=> (121, C1) - 168121 <=> (121, C1)
* Each BGP hop performs swap operation on 168002 bound to color- * Each BGP hop performs swap operation on 168002 bound to color-
skipping to change at line 1622 skipping to change at line 1632
* Node 451 advertises BGP CAR route (451, C1) to 341, from which it * Node 451 advertises BGP CAR route (451, C1) to 341, from which it
goes to 231, and finally to 121. goes to 231, and finally to 121.
* Each BGP hop allocates local label and programs swap entry in * Each BGP hop allocates local label and programs swap entry in
forwarding for (451, C1). forwarding for (451, C1).
* 121 resolves received BGP CAR route (451, C1) via 231 (label * 121 resolves received BGP CAR route (451, C1) via 231 (label
168451) on color-aware path (231, C1). 168451) on color-aware path (231, C1).
- Color-aware path (231, C1) is FA128 path to 231 (label 168231). - Color-aware path (231, C1) is Flex-Algo 128 path to 231 (label
168231).
* 451 advertises BGP CAR route (E2, C1) via 451 to transport RR * 451 advertises BGP CAR route (E2, C1) via 451 to transport RR
T-RR2, which reflects it to transport RR T-RR1, which reflects it T-RR2, which reflects it to transport RR T-RR1, which reflects it
to 121. to 121.
* 121 receives BGP CAR route (E2, C1) via 451 with label 168002. * 121 receives BGP CAR route (E2, C1) via 451 with label 168002.
- Let's assume 121 selects that path. - Let's assume 121 selects that path.
* 121 resolves BGP CAR route (E2, C1) via 451 on color-aware path * 121 resolves BGP CAR route (E2, C1) via 451 on color-aware path
skipping to change at line 1720 skipping to change at line 1731
* Node 121 advertises (E2, C1) to E1 with next hop as 451 (i.e., * Node 121 advertises (E2, C1) to E1 with next hop as 451 (i.e.,
next-hop-unchanged). next-hop-unchanged).
* 121 also advertises (451, C1) to E1 with next-hop-self (121) and * 121 also advertises (451, C1) to E1 with next-hop-self (121) and
label 168451. label 168451.
* E1 resolves BGP CAR route (451, C1) via 121 on color-aware path * E1 resolves BGP CAR route (451, C1) via 121 on color-aware path
(121, C1). (121, C1).
- Color-aware path (121, C1) is FA128 path to 121 (label 168121). - Color-aware path (121, C1) is Flex-Algo 128 path to 121 (label
168121).
* E1 receives BGP CAR route (E2, C1) via 451 with label 168002. * E1 receives BGP CAR route (E2, C1) via 451 with label 168002.
- Let's assume E1 selects that path. - Let's assume E1 selects that path.
* E1 resolves BGP CAR route (E2, C1) via 451 on color-aware path * E1 resolves BGP CAR route (E2, C1) via 451 on color-aware path
(451, C1). (451, C1).
- Color-aware path (451, C1) is BGP CAR path to 451 (label - Color-aware path (451, C1) is BGP CAR path to 451 (label
168451). 168451).
skipping to change at line 1892 skipping to change at line 1904
7.1.1. Routed Service SID 7.1.1. Routed Service SID
The SRv6 Service SID that is advertised with a service route is The SRv6 Service SID that is advertised with a service route is
allocated by an egress PE from a routed intent-aware locator prefix allocated by an egress PE from a routed intent-aware locator prefix
(Section 3.3 of [RFC8986]). Service steering at an ingress PE is via (Section 3.3 of [RFC8986]). Service steering at an ingress PE is via
resolution of the Service SID signaled with the service route as resolution of the Service SID signaled with the service route as
described in [RFC9252]. described in [RFC9252].
The intent-aware transport path to the SRv6 locator of the egress PE The intent-aware transport path to the SRv6 locator of the egress PE
is provided by underlay IP routing. Underlay IP routing can include is provided by underlay IP routing. Underlay IP routing can include
IGP Flex-Algo [RFC9350] within a domain, and BGP CAR (as defined in IGP Flexible Algorithm [RFC9350] within a domain, and BGP CAR (as
this document) across multiple IGP domains or BGP ASes. defined in this document) across multiple IGP domains or BGP ASes.
An SRv6 locator prefix is assigned for a given intent or color. The An SRv6 locator prefix is assigned for a given intent or color. The
SRv6 locator may be shared with an IGP Flex-Algo, or it may be SRv6 locator may be shared with an IGP Flexible Algorithm, or it may
assigned specific to BGP CAR for a given intent. be assigned specific to BGP CAR for a given intent.
Distribution of SRv6 locators in BGP CAR SAFI: Distribution of SRv6 locators in BGP CAR SAFI:
* In a multi-domain network, the SRv6 locator prefix is distributed * In a multi-domain network, the SRv6 locator prefix is distributed
using BGP CAR SAFI to ingress PEs and ASBRs in a remote domain. using BGP CAR SAFI to ingress PEs and ASBRs in a remote domain.
The SRv6 locator prefix may be advertised in the BGP CAR SAFI from The SRv6 locator prefix may be advertised in the BGP CAR SAFI from
an egress PE, or redistributed into BGP CAR from an IGP-FlexAlgo an egress PE, or redistributed into BGP CAR from an IGP-FlexAlgo
at a BR. The locator prefix may also be summarized on a border at a BR. The locator prefix may also be summarized on a border
node along the path and a summary route distributed to ingress node along the path and a summary route distributed to ingress
PEs. PEs.
skipping to change at line 1995 skipping to change at line 2007
(E, C) route. (E, C) route.
* The ingress PE via the recursive resolution above builds the * The ingress PE via the recursive resolution above builds the
packet encapsulation that contains the SRv6 Service SID and the packet encapsulation that contains the SRv6 Service SID and the
received (E, C) route's SRv6 transport SID in the SID list. received (E, C) route's SRv6 transport SID in the SID list.
Appendix C.3 contains an example that illustrates the control plane Appendix C.3 contains an example that illustrates the control plane
distribution, recursive resolution and forwarding behaviors described distribution, recursive resolution and forwarding behaviors described
above. above.
Note: An SR-policy may also be defined for multi-domain end to end Note: An SR Policy may also be defined for multi-domain end to end
[RFC9256], independent of BGP CAR. In that case, both BGP CAR and [RFC9256], independent of BGP CAR. In that case, both BGP CAR and
SR-TE inter-domain paths may be available at an ingress PE for an (E, SR-TE inter-domain paths may be available at an ingress PE for an (E,
C) route (Section 1.2). C) route (Section 1.2).
7.2. Deployment Options for CAR SRv6 Locator Reachability Distribution 7.2. Deployment Options for CAR SRv6 Locator Reachability Distribution
and Forwarding and Forwarding
Since an SRv6 locator (or summary) is an IPv6 prefix, it will be Since an SRv6 locator (or summary) is an IPv6 prefix, it will be
installed into the IPv6 forwarding table on a BGP router (e.g., ABR installed into the IPv6 forwarding table on a BGP router (e.g., ABR
or ASBR) for packet forwarding. With the use of IPv6 locator or ASBR) for packet forwarding. With the use of IPv6 locator
skipping to change at line 2078 skipping to change at line 2090
* An egress BR sets itself as BGP next hop, and selects and * An egress BR sets itself as BGP next hop, and selects and
advertises an appropriate encapsulation towards itself. advertises an appropriate encapsulation towards itself.
- If SRv6 encapsulation, then the SRv6 SID advertised from egress - If SRv6 encapsulation, then the SRv6 SID advertised from egress
BR is from an SRv6 locator for the specific intent within the BR is from an SRv6 locator for the specific intent within the
domain. Multiple BGP SRv6 prefixes may share a common SID, domain. Multiple BGP SRv6 prefixes may share a common SID,
avoiding per-PE SID allocation and installation on any BGP hop. avoiding per-PE SID allocation and installation on any BGP hop.
- If MPLS/SR-MPLS transport, the route will carry the label/ - If MPLS/SR-MPLS transport, the route will carry the label/
Prefix-SID allocated by the next hop, may be shared. Prefix-SID allocated by the next hop. The label/SID may be
shared among multiple routes.
* An ingress BR encapsulates SRv6 egress PE destined packets with * An ingress BR encapsulates SRv6 egress PE destined packets with
encapsulation to BGP next hop (i.e., the egress BR). encapsulation to BGP next hop (i.e., the egress BR).
The benefits of this scheme are: The benefits of this scheme are:
* P nodes do not need to learn or install BGP SRv6 prefixes in this * P nodes do not need to learn or install BGP SRv6 prefixes in this
(BGP-free core) design. (BGP-free core) design.
* No per-PE SID allocation and installation on any BGP hop. * No per-PE SID allocation and installation on any BGP hop.
skipping to change at line 2119 skipping to change at line 2132
o preventing inadvertent leaking of routes, and o preventing inadvertent leaking of routes, and
o avoiding the need to configure specific route filters for o avoiding the need to configure specific route filters for
locator routes. locator routes.
- Priority handling of infrastructure routes over service - Priority handling of infrastructure routes over service
(Internet) routes. (Internet) routes.
* CAR SAFI also supports inter-domain distribution of (E, C) routes * CAR SAFI also supports inter-domain distribution of (E, C) routes
sourced from SR-Policy, in addition to SRv6 locator IPv6 prefixes. sourced from SR Policy, in addition to SRv6 locator IPv6 prefixes.
* CAR SAFI may also be used for best-effort routes in addition to * CAR SAFI may also be used for best-effort routes in addition to
intent-aware routes as described in the next section. intent-aware routes as described in the next section.
Note: If infrastructure routes such as SRv6 locator routes are Note: If infrastructure routes such as SRv6 locator routes are
carried in both BGP-IP [RFC4271] / BGP-LU [RFC8277] [RFC4798], and carried in both BGP-IP [RFC4271] / BGP-LU [RFC8277] [RFC4798], and
BGP CAR, Section 8 describes the path selection preference between BGP CAR, Section 8 describes the path selection preference between
them. them.
8. CAR IP Prefix Route 8. CAR IP Prefix Route
skipping to change at line 2170 skipping to change at line 2183
color associated with the CAR IP Prefix route is signaled using LCM- color associated with the CAR IP Prefix route is signaled using LCM-
EC. EC.
Reminder: LCM-EC conveys end-to-end intent/color associated with Reminder: LCM-EC conveys end-to-end intent/color associated with
route/NLRI. When traversing network domain(s) where a different route/NLRI. When traversing network domain(s) where a different
intent/color is used for next-hop resolution, BGP Color-EC may intent/color is used for next-hop resolution, BGP Color-EC may
additionally be used as in Section 2.10. additionally be used as in Section 2.10.
A special case of intent is best-effort, which may be represented by A special case of intent is best-effort, which may be represented by
a color and follow the above procedures. However, to be compatible a color and follow the above procedures. However, to be compatible
with traditional operational usage, the CAR IP Prefix route is with existing operational usage, the CAR IP Prefix route is allowed
allowed to be without color for best-effort. In this case, the to be without color for best-effort. In this case, the routes will
routes will not carry an LCM-EC. Resolution is described in not carry an LCM-EC. Resolution is described in Section 2.5.
Section 2.5.
As described in Section 7.3, infrastructure prefixes are intended to As described in Section 7.3, infrastructure prefixes are intended to
be carried in CAR SAFI instead of SAFIs that also carry service be carried in CAR SAFI instead of SAFIs that also carry service
routes such as BGP-IP (SAFI 1, [RFC4271]) and BGP-LU (SAFI 4, routes such as BGP-IP (SAFI 1, [RFC4271]) and BGP-LU (SAFI 4,
[RFC4798]). However, if such infrastructure routes are also [RFC4798]). However, if such infrastructure routes are also
distributed in these SAFIs, a router may receive both BGP CAR SAFI distributed in these SAFIs, a router may receive both BGP CAR SAFI
paths and IP/LU SAFI paths. By default, the CAR SAFI transport path paths and IP/LU SAFI paths. By default, the CAR SAFI transport path
is preferred over the BGP IP or BGP-LU SAFI path. is preferred over the BGP IP or BGP-LU SAFI path.
A BGP transport CAR speaker that supports packet forwarding lookup A BGP transport CAR speaker that supports packet forwarding lookup
skipping to change at line 2204 skipping to change at line 2216
intent-aware routing requirement stated in Section 6.1.2 of intent-aware routing requirement stated in Section 6.1.2 of
[INTENT-AWARE]. The examples use MPLS, but other transport types can [INTENT-AWARE]. The examples use MPLS, but other transport types can
also be used (e.g., SRv6). also be used (e.g., SRv6).
CE1 -------------- PE1 -------------------- PE2 -------------- CE2 - V CE1 -------------- PE1 -------------------- PE2 -------------- CE2 - V
* BGP CAR SAFI is enabled on CE1-PE1 and PE2-CE2 sessions. * BGP CAR SAFI is enabled on CE1-PE1 and PE2-CE2 sessions.
* BGP VPN CAR SAFI is enabled between PE1 and PE2. * BGP VPN CAR SAFI is enabled between PE1 and PE2.
* Provider publishes to customer that intent 'low-delay' is mapped * Provider publishes to customer that intent "low delay" is mapped
to color CP on its inbound peering links. to color CP ("Provider Color") on its inbound peering links.
* Within its infrastructure, provider maps intent 'low-delay' to * Within its infrastructure, provider maps intent "low delay" to
color CPT. color CPT ("Provider Transport Color").
* On CE1 and CE2, intent 'low-delay' is mapped to CC. * On CE1 and CE2, intent "low delay" is mapped to CC ("Customer
Color").
(V, CC) is a color-aware route originated by CE2. (V, CC) is a color-aware route originated by CE2.
1. CE2 sends to PE2: [(V, CC), Label L1] via CE2 with LCM-EC (CP) as 1. CE2 sends to PE2:
per peering agreement.
2. PE2 installs in VRF A: [(V, CC), L1] via CE2, which resolves on [(V, CC), label L1] via CE2 with LCM-EC (CP) as per peering
(CE2, CP) or connected Outgoing Interface (OIF). agreement.
3. PE2 allocates VPN Label L2 and programs swap entry for (V, CC). 2. PE2 installs in VRF A:
4. PE2 sends to PE1: [(RD, V, CC), L2] via PE2, LCM-EC (CP) with [(V, CC), L1] via CE2, which resolves on (CE2, CP) or
regular Color-EC (CPT). connected Outgoing Interface (OIF).
5. PE1 installs in VRF A: [(V, CC), L2] via (PE2, CPT) steered on 3. PE2 allocates VPN label L2 and programs swap entry for (V, CC).
(PE2, CPT).
6. PE1 allocates Label L3 and programs swap entry for (V, CC). 4. PE2 sends to PE1:
7. PE1 sends to CE1: [(V, CC), L3] via PE1 after removing LCM-EC [(RD, V, CC), L2] via PE2, LCM-EC (CP) with regular Color-EC
through route policy. (CPT).
8. CE1 installs: [(V, CC), L3] via PE1, which resolves on (PE1, CC) 5. PE1 installs in VRF A:
or connected OIF.
[(V, CC), L2] via (PE2, CPT) steered on (PE2, CPT).
6. PE1 allocates label L3 and programs swap entry for (V, CC).
7. PE1 sends to CE1:
[(V, CC), L3] via PE1 after removing LCM-EC through route
policy.
8. CE1 installs:
[(V, CC), L3] via PE1, which resolves on (PE1, CC) or
connected OIF.
9. Label L3 is installed as the imposition label for (V, CC). 9. Label L3 is installed as the imposition label for (V, CC).
VPN CAR distribution for (RD, V, CC) requires a new SAFI that follows VPN CAR distribution for (RD, V, CC) requires a new SAFI that follows
the same VPN semantics as defined in [RFC4364] and also supports the the same VPN semantics as defined in [RFC4364] and also supports the
distribution of routes with the CAR NLRI and associated non-key TLVs distribution of routes with the CAR NLRI and associated non-key TLVs
defined in Section 2.9 of this document. defined in Section 2.9 of this document.
Procedures defined in [RFC4364] and [RFC4659] apply to VPN CAR SAFI. Procedures defined in [RFC4364] and [RFC4659] apply to VPN CAR SAFI.
Further, all CAR SAFI procedures described in Section 2 above apply Further, all CAR SAFI procedures described in Section 2 above apply
skipping to change at line 2312 skipping to change at line 2336
all fields are encoded as per Section 2.9.3 with the following all fields are encoded as per Section 2.9.3 with the following
changes: changes:
Key Length: This length indicates the total length comprised of the Key Length: This length indicates the total length comprised of the
RD, Prefix Length field, IP Prefix field, and the Color field. RD, Prefix Length field, IP Prefix field, and the Color field.
Route Distinguisher: An 8-octet field encoded according to Route Distinguisher: An 8-octet field encoded according to
[RFC4364]. [RFC4364].
Type-Specific Non-Key TLVs: The Label TLV, Label Index TLV, and SRv6 Type-Specific Non-Key TLVs: The Label TLV, Label-Index TLV, and SRv6
SID TLV (Section 2.9.2) may be associated with the VPN CAR (E, C) SID TLV (Section 2.9.2) may be associated with the VPN CAR (E, C)
NLRI type. NLRI Type.
9.1.2. VPN CAR IP Prefix NLRI Type 9.1.2. VPN CAR IP Prefix NLRI Type
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Length | Key Length | NLRI Type |Prefix Length | | NLRI Length | Key Length | NLRI Type |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 2343 skipping to change at line 2367
all fields are encoded as per Section 2.9.4 with the following all fields are encoded as per Section 2.9.4 with the following
changes: changes:
Key Length: This length indicates the total length comprised of the Key Length: This length indicates the total length comprised of the
RD, Prefix Length field, and IP Prefix field. RD, Prefix Length field, and IP Prefix field.
Route Distinguisher: An 8-octet field encoded according to Route Distinguisher: An 8-octet field encoded according to
[RFC4364]. [RFC4364].
Type-Specific Non-Key TLVs: The Label TLV, Label Index TLV, and SRv6 Type-Specific Non-Key TLVs: The Label TLV, Label-Index TLV, and SRv6
SID TLV (Section 2.9.2) may be associated with the VPN CAR IP SID TLV (Section 2.9.2) may be associated with the VPN CAR IP
Prefix NLRI type. Prefix NLRI Type.
The error handling specified in Section 2.11 also applies to VPN CAR The error handling specified in Section 2.11 also applies to VPN CAR
SAFI. SAFI.
10. IANA Considerations 10. IANA Considerations
10.1. BGP CAR SAFIs 10.1. BGP CAR SAFIs
IANA has assigned SAFI value 83 (BGP CAR) and SAFI value 84 (BGP VPN IANA has assigned SAFI value 83 (BGP CAR) and SAFI value 84 (BGP VPN
CAR) from the "SAFI Values" registry in the "Subsequent Address CAR) from the "SAFI Values" registry in the "Subsequent Address
skipping to change at line 2400 skipping to change at line 2424
points for BGP CAR NLRI non-key TLV types and is populated with the points for BGP CAR NLRI non-key TLV types and is populated with the
values shown below: values shown below:
+======+=================+===========+ +======+=================+===========+
| Type | NLRI TLV Type | Reference | | Type | NLRI TLV Type | Reference |
+======+=================+===========+ +======+=================+===========+
| 0 | Reserved | RFC 9871 | | 0 | Reserved | RFC 9871 |
+------+-----------------+-----------+ +------+-----------------+-----------+
| 1 | Label TLV | RFC 9871 | | 1 | Label TLV | RFC 9871 |
+------+-----------------+-----------+ +------+-----------------+-----------+
| 2 | Label Index TLV | RFC 9871 | | 2 | Label-Index TLV | RFC 9871 |
+------+-----------------+-----------+ +------+-----------------+-----------+
| 3 | SRv6 SID TLV | RFC 9871 | | 3 | SRv6 SID TLV | RFC 9871 |
+------+-----------------+-----------+ +------+-----------------+-----------+
| 4-64 | Unassigned | | 4-64 | Unassigned |
+------+-----------------------------+ +------+-----------------------------+
Table 4 Table 4
Allocations within the registry are to be made with the Allocations within the registry are to be made with the
"Specification Required" policy as specified in [RFC8126] and in "Specification Required" policy as specified in [RFC8126] and in
Section 10.4. Section 10.4.
For a new TLV to be used with existing NLRI Types, documentation of For a new TLV to be used with existing NLRI types, documentation of
the NLRI Types must be updated. the NLRI types must be updated.
10.4. Guidance for Designated Experts 10.4. Guidance for Designated Experts
In all cases of review by the Designated Expert (DE) described here, In all cases of review by the Designated Expert (DE) described here,
the DE is expected to ascertain the existence of suitable the DE is expected to ascertain the existence of suitable
documentation (a specification) as described in [RFC8126] for the documentation (a specification) as described in [RFC8126] for the
"BGP CAR NLRI Types" registry and the "BGP CAR NLRI TLV" registry. "BGP CAR NLRI Types" registry and the "BGP CAR NLRI TLV" registry.
The DE is also expected to check the clarity of purpose and use of The DE is also expected to check the clarity of purpose and use of
the requested code points. Additionally, the DE must verify that any the requested code points. Additionally, the DE must verify that any
skipping to change at line 2450 skipping to change at line 2474
the applicant. the applicant.
10.4.1. Additional Evaluation Criteria for the "BGP CAR NLRI Types" 10.4.1. Additional Evaluation Criteria for the "BGP CAR NLRI Types"
Registry Registry
* Check the interoperability between the new NLRI type and current * Check the interoperability between the new NLRI type and current
NLRI types specified in this document for BGP CAR SAFIs (BGP CAR NLRI types specified in this document for BGP CAR SAFIs (BGP CAR
SAFI and VPN CAR SAFI), and any updates to this document. SAFI and VPN CAR SAFI), and any updates to this document.
* Check if the specification indicates which non-key TLVs are * Check if the specification indicates which non-key TLVs are
applicable for the new NLRI Type. applicable for the new NLRI type.
10.4.2. Additional Evaluation Criteria for the "BGP CAR NLRI TLV" 10.4.2. Additional Evaluation Criteria for the "BGP CAR NLRI TLV"
Registry Registry
* Check the applicability of the new TLV for the BGP CAR NLRI Types * Check the applicability of the new TLV for the BGP CAR NLRI types
defined. defined.
* Check the T bit setting for the new TLV. * Check the T bit setting for the new TLV.
10.5. "Border Gateway Protocol (BGP) Extended Communities" Registry 10.5. "Border Gateway Protocol (BGP) Extended Communities" Registry
IANA has assigned the sub-type 0x1b for "Local Color Mapping (LCM)" IANA has assigned the sub-type 0x1b for "Local Color Mapping (LCM)"
in the "Transitive Opaque Extended Community Sub-Types" registry in in the "Transitive Opaque Extended Community Sub-Types" registry in
the "Border Gateway Protocol (BGP) Extended Communities" registry the "Border Gateway Protocol (BGP) Extended Communities" registry
group. group.
skipping to change at line 2741 skipping to change at line 2765
Appendix A. Illustrations of Service Steering Appendix A. Illustrations of Service Steering
The following sub-sections illustrate example scenarios of colored The following sub-sections illustrate example scenarios of colored
service route steering over end-to-end (E2E) BGP CAR paths, resolving service route steering over end-to-end (E2E) BGP CAR paths, resolving
over different intra-domain mechanisms. over different intra-domain mechanisms.
The examples in this section use MPLS/SR for the transport data The examples in this section use MPLS/SR for the transport data
plane. Scenarios related to SRv6 encapsulation are in a section plane. Scenarios related to SRv6 encapsulation are in a section
below. below.
A.1. E2E BGP Transport CAR Intent Realized Using IGP Flex-Algo A.1. E2E BGP Transport CAR Intent Realized Using IGP Flexible Algorithm
RD:V/v via E2 RD:V/v via E2
+-----+ vpn label: 30030 +-----+ +-----+ vpn label: 30030 +-----+
...... |S-RR1| <..................................|S-RR2| <....... ...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ Color C1 +-----+ : : +-----+ Color C1 +-----+ :
: : : :
: : : :
: : : :
+-:-----------------------+----------------------+------------------:--+ +-:-----------------------+----------------------+------------------:--+
| : | | : | | : | | : |
skipping to change at line 2765 skipping to change at line 2789
| : |-------------------|121|<-----------------|231|<-------------| : | | : |-------------------|121|<-----------------|231|<-------------| : |
| : V LI=8002 +---+ LI=8002 +---+ | : | | : V LI=8002 +---+ LI=8002 +---+ | : |
|----+ | | +-----| |----+ | | +-----|
| E1 | | | | E2 | | E1 | | | | E2 |
|----+(E2,C1) via 122 | (E2,C1) via 232 | (E2,C1)via E2+-----| |----+(E2,C1) via 122 | (E2,C1) via 232 | (E2,C1)via E2+-----|
| ^ L=168002,AIGP=210 +---+ L=168002,AIGP=20 +---+ L=0x3 | | | ^ L=168002,AIGP=210 +---+ L=168002,AIGP=20 +---+ L=0x3 | |
| |---------------- |122|<-----------------|232|<-------------| | | |---------------- |122|<-----------------|232|<-------------| |
| LI=8002 +---+ LI=8002 +---+ LI=8002 | | LI=8002 +---+ LI=8002 +---+ LI=8002 |
| | | | | | | |
| IS-IS SR | IS-IS SR | IS-IS SR | | IS-IS SR | IS-IS SR | IS-IS SR |
| FA 128 | FA 128 | FA 128 | | FA128 | FA128 | FA128 |
+-------------------------+----------------------+---------------------+ +-------------------------+----------------------+---------------------+
iPE iABR eABR ePE iPE iABR eABR ePE
---------direction of traffic--------> ---------direction of traffic-------->
+------+ +------+ +------+ +------+
|168121| |168231| |168121| |168231|
+------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|168002| |168002| |168002| |168002| |168002| |168002|
+------+ +------+ +------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|30030 | |30030 | |30030 | |30030 | |30030 | |30030 |
+------+ +------+ +------+ +------+ +------+ +------+
Figure 6: BGP FA Aware Transport CAR Path Figure 6: BGP Flexible Algorithm Aware Transport CAR Path
Use case: Provide end-to-end intent for service flows. Use case: Provide end-to-end intent for service flows.
* The following description applies to the reference topology above: * The following description applies to the reference topology above:
- IGP FA 128 is running in each domain, and mapped to color C1. - IGP Flex-Algo 128 is running in each domain, and mapped to
color C1.
- Egress PE E2 advertises a VPN route RD:V/v colored with Color- - Egress PE E2 advertises a VPN route RD:V/v colored with Color-
EC C1 to steer traffic to BGP transport CAR (E2, C1). VPN EC C1 to steer traffic to BGP transport CAR (E2, C1). VPN
route propagates via service RRs to ingress PE E1. route propagates via service RRs to ingress PE E1.
- BGP CAR route (E2, C1) with next hop, label index, and label as - BGP CAR route (E2, C1) with next hop, label index, and label as
shown above are advertised through border routers in each shown above are advertised through border routers in each
domain. When an RR is used in the domain, ADD-PATH is enabled domain. When an RR is used in the domain, ADD-PATH is enabled
to advertise multiple available paths. to advertise multiple available paths.
- On each BGP hop, the (E2, C1) route's next hop is resolved over - On each BGP hop, the (E2, C1) route's next hop is resolved over
IGP FA 128 of the domain. The AIGP attribute influences the IGP Flex-Algo 128 of the domain. The AIGP attribute influences
BGP CAR route best path decision as per [RFC7311]. The BGP CAR the BGP CAR route best path decision as per [RFC7311]. The BGP
label swap entry is installed that goes over FA 128 LSP to next CAR label swap entry is installed that goes over Flex-Algo 128
hop providing intent in each IGP domain. The AIGP metric LSP to next hop providing intent in each IGP domain. The AIGP
should be updated to reflect FA 128 metric to next hop. metric should be updated to reflect Flex-Algo 128 metric to
next hop.
- Ingress PE E1 learns CAR route (E2, C1). It steers colored VPN - Ingress PE E1 learns CAR route (E2, C1). It steers colored VPN
route RD:V/v into (E2, C1). route RD:V/v into (E2, C1).
* Important: * Important:
- IGP FA 128 top label provides intent within each domain. - IGP Flex-Algo 128 top label provides intent within each domain.
- BGP CAR label (e.g., 168002) carries end-to-end intent. Thus, - BGP CAR label (e.g., 168002) carries end-to-end intent. Thus,
it stitches intent over intra-domain FA 128. it stitches intent over intra-domain Flex-Algo 128.
A.2. E2E BGP Transport CAR Intent Realized Using SR Policy A.2. E2E BGP Transport CAR Intent Realized Using SR Policy
RD:1/8 via E2 RD:1/8 via E2
+-----+ vpn label: 30030 +-----+ +-----+ vpn label: 30030 +-----+
...... |S-RR1| <..................................|S-RR2| <...... ...... |S-RR1| <..................................|S-RR2| <......
: +-----+ Color C1 +-----+ : : +-----+ Color C1 +-----+ :
: : : :
: : : :
: : : :
+-:-----------------------+----------------------+------------------:-+ +-:-----------------------+----------------------+------------------:-+
| : | | : | | : | | : |
| : | | : | | : | | : |
| : <-(E2,C1) via 121 | <-(E2,C1) via 231 | <-(E2,C1)via E2 : | | : <-(E2,C1) via 121 | <-(E2,C1) via 231 | <-(E2,C1)via E2 : |
| : +---+ +---+ : | | : +---+ +---+ : |
| : ------------------>|121|----------------->|231|--------------| : | | : ------------------>|121|----------------->|231|--------------| : |
| : | SR policy(C1,121) +---+ SR policy(C1,231)+---+ SR policy v : | | : | SR Policy(C1,121) +---+ SR Policy(C1,231)+---+ SR Policy v : |
|----+ | | (C1,E2) +---| |----+ | | (C1,E2) +---|
| E1 | | | |E2 | | E1 | | | |E2 |
|----+ <-(E2,C1) via 122 | (E2,C1) via 232 | <-(E2,C1)via E2+---| |----+ <-(E2,C1) via 122 | (E2,C1) via 232 | <-(E2,C1)via E2+---|
| | +---+ +---+ ^ | | | +---+ +---+ ^ |
| ------------------>|122|----------------->|232|---------------| | | ------------------>|122|----------------->|232|---------------| |
| SR policy(C1,122) +---+ SR policy(C1,232)+---+ SR policy(C1,E2) | | SR Policy(C1,122) +---+ SR Policy(C1,232)+---+ SR Policy(C1,E2) |
| | | | | | | |
| | | | | | | |
| IS-IS SR | IS-IS SR | IS-IS SR | | IS-IS SR | IS-IS SR | IS-IS SR |
+-------------------------+----------------------+--------------------+ +-------------------------+----------------------+--------------------+
iPE iABR eABR ePE iPE iABR eABR ePE
---------direction of traffic--------> ---------direction of traffic-------->
+------+ +------+ +------+ +------+
| S1 | | S2 | | S1 | | S2 |
+------+ +------+ +------+ +------+
skipping to change at line 2867 skipping to change at line 2893
Use case: Provide end-to-end intent for service flows. Use case: Provide end-to-end intent for service flows.
* The following description applies to the reference topology above: * The following description applies to the reference topology above:
- An SR Policy provides intra-domain intent. The following are - An SR Policy provides intra-domain intent. The following are
the example SID lists that are realized from SR policies in the example SID lists that are realized from SR policies in
each domain and correspond to the label stack shown in each domain and correspond to the label stack shown in
Figure 7: Figure 7:
o SR policy (C1, 121) segments <S1, 121>, o SR Policy (C1, 121) segments <S1, 121>,
o SR policy (C1, 231) segments <S2, 231>, and o SR Policy (C1, 231) segments <S2, 231>, and
o SR policy (C1, E2) segments <S3, E2>. o SR Policy (C1, E2) segments <S3, E2>.
- Egress PE E2 advertises a VPN route RD:V/v colored with Color- - Egress PE E2 advertises a VPN route RD:V/v colored with Color-
EC C1 to steer traffic to BGP transport CAR (E2, C1). VPN EC C1 to steer traffic to BGP transport CAR (E2, C1). VPN
route propagates via service RRs to ingress PE E1. route propagates via service RRs to ingress PE E1.
- BGP CAR route (E2, C1) with next hop, label index, and label as - BGP CAR route (E2, C1) with next hop, label index, and label as
shown above are advertised through border routers in each shown above are advertised through border routers in each
domain. When an RR is used in the domain, ADD-PATH is enabled domain. When an RR is used in the domain, ADD-PATH is enabled
to advertise multiple available paths. to advertise multiple available paths.
- On each BGP hop, the CAR route (E2, C1) next hop is resolved - On each BGP hop, the CAR route (E2, C1) next hop is resolved
over an SR policy (C1, next hop). The BGP CAR label swap entry over an SR Policy (C1, next hop). The BGP CAR label swap entry
is installed that goes over SR policy segment list. is installed that goes over SR Policy segment list.
- Ingress PE E1 learns CAR route (E2, C1). It steers colored VPN - Ingress PE E1 learns CAR route (E2, C1). It steers colored VPN
route RD:V/v into (E2, C1). route RD:V/v into (E2, C1).
* Important: * Important:
- SR policy provides intent within each domain. - SR Policy provides intent within each domain.
- BGP CAR label (e.g., 168002) carries end-to-end intent. Thus, - BGP CAR label (e.g., 168002) carries end-to-end intent. Thus,
it stitches intent over intra-domain SR policies. it stitches intent over intra-domain SR policies.
A.3. BGP Transport CAR Intent Realized in a Section of the Network A.3. BGP Transport CAR Intent Realized in a Section of the Network
A.3.1. Provide Intent for Service Flows Only in Core Domain Running IS- A.3.1. Provide Intent for Service Flows Only in Core Domain Running IS-
IS Flex-Algo IS Flexible Algorithm
RD:1/8 via E2 RD:1/8 via E2
+-----+ vpn label: 30030 +-----+ +-----+ vpn label: 30030 +-----+
...... |S-RR1| <..................................|S-RR2| <....... ...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ Color C1 +-----+ : : +-----+ Color C1 +-----+ :
: : : :
: : : :
: : : :
+-:-----------------------+----------------------+------------------:--+ +-:-----------------------+----------------------+------------------:--+
| : | | : | | : | | : |
skipping to change at line 2939 skipping to change at line 2965
+------+ +------+ +------+ +------+
|160121| |168231| |160121| |168231|
+------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|168002| |168002| |160002| |168002| |168002| |160002|
+------+ +------+ +------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|30030 | |30030 | |30030 | |30030 | |30030 | |30030 |
+------+ +------+ +------+ +------+ +------+ +------+
Figure 8: BGP Hybrid Flex-Algo Aware Transport CAR Path Figure 8: BGP Hybrid Flexible Algorithm Aware Transport CAR Path
* The following description applies to the reference topology above: * The following description applies to the reference topology above:
- IGP FA 128 is only enabled in core (e.g., WAN network), mapped - IGP Flex-Algo 128 is only enabled in core (e.g., WAN network),
to C1. Access network domain only has Base Algo 0. mapped to C1. Access network domain only has Base Algo 0.
- Egress PE E2 advertises a VPN route RD:V/v colored with Color- - Egress PE E2 advertises a VPN route RD:V/v colored with Color-
EC C1 to steer traffic via BGP transport CAR (E2, C1). VPN EC C1 to steer traffic via BGP transport CAR (E2, C1). VPN
route propagates via service RRs to ingress PE E1. route propagates via service RRs to ingress PE E1.
- BGP CAR route (E2, C1) with next hop, label index, and label as - BGP CAR route (E2, C1) with next hop, label index, and label as
shown above are advertised through border routers in each shown above are advertised through border routers in each
domain. When an RR is used in the domain, ADD-PATH is enabled domain. When an RR is used in the domain, ADD-PATH is enabled
to advertise multiple available paths. to advertise multiple available paths.
- Local policy on 231 and 232 maps intent C1 to resolve CAR route - Local policy on 231 and 232 maps intent C1 to resolve CAR route
next hop over IGP Base Algo 0 in right access domain. The BGP next hop over IGP Base Algo 0 in right access domain. The BGP
CAR label swap entry is installed that goes over Base Algo 0 CAR label swap entry is installed that goes over Base Algo 0
LSP to next hop. AIGP metric is updated to reflect Base Algo 0 LSP to next hop. AIGP metric is updated to reflect Base Algo 0
metric to next hop with an additional penalty (+1000). metric to next hop with an additional penalty (+1000).
- On 121 and 122, CAR route (E2, C1) next hop learnt from Core - On 121 and 122, CAR route (E2, C1) next hop learnt from Core
domain is resolved over IGP FA 128. The BGP CAR label swap domain is resolved over IGP Flex-Algo 128. The BGP CAR label
entry is installed that goes over FA 128 LSP to next hop swap entry is installed that goes over Flex-Algo 128 LSP to
providing intent in Core IGP domain. next hop providing intent in Core IGP domain.
- Ingress PE E1 learns CAR route (E2, C1). It maps intent C1 to - Ingress PE E1 learns CAR route (E2, C1). It maps intent C1 to
resolve CAR route next hop over IGP Base Algo 0. It steers resolve CAR route next hop over IGP Base Algo 0. It steers
colored VPN route RD:V/v via (E2, C1). colored VPN route RD:V/v via (E2, C1).
* Important: * Important:
- IGP Flex-Algo 128 top label provides intent in Core domain. - IGP Flex-Algo 128 top label provides intent in Core domain.
- BGP CAR label (e.g., 168002) carries intent from PEs, which is - BGP CAR label (e.g., 168002) carries intent from PEs, which is
skipping to change at line 3104 skipping to change at line 3130
* BR4 does the same in the reverse direction. * BR4 does the same in the reverse direction.
* Thus, the color awareness of the routes, and hence the paths in * Thus, the color awareness of the routes, and hence the paths in
the data plane, are maintained between E1 and E2, even if the the data plane, are maintained between E1 and E2, even if the
intent is not available within the BGP-LU island. intent is not available within the BGP-LU island.
* A similar design can be used for going over network islands of * A similar design can be used for going over network islands of
other types. other types.
A.5. Resource Avoidance Using BGP CAR and IGP Flex-Algo A.5. Resource Avoidance Using BGP CAR and IGP Flexible Algorithm
This example illustrates a case of resource avoidance within a domain This example illustrates a case of resource avoidance within a domain
for a multi-domain color-aware path. for a multi-domain color-aware path.
+-------------+ +-------------+ +-------------+ +-------------+
| | | | V/v with C1 | | | | V/v with C1
|----+ |------| +----|/ |----+ |------| +----|/
| E1 | | | | E2 |\ | E1 | | | | E2 |\
|----+ | | +----| W/w with C2 |----+ | | +----| W/w with C2
| |------| IGP FA128 | | |------| IGP FA128 |
| IGP FA128 | | IGP FA129 | | IGP FA128 | | IGP FA129 |
| Domain 1 | | Domain 2 | | Domain 1 | | Domain 2 |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 11: BGP CAR Resolution over IGP Flex-Algo for Resource Figure 11: BGP CAR Resolution over IGP Flexible Algorithm for
Avoidance in a Domain Resource Avoidance in a Domain
* C1 and C2 represent the following two unique intents in the multi- * C1 and C2 represent the following two unique intents in the multi-
domain network: domain network:
- C1 is mapped to "minimize IGP metric", and - C1 is mapped to "minimize IGP metric", and
- C2 is mapped to "minimize IGP metric and avoid resource R". - C2 is mapped to "minimize IGP metric and avoid resource R".
* Resource R represents link(s) or node(s) to be avoided. * Resource R represents link(s) or node(s) to be avoided.
* Flex-Algo FA128 in Domain 2 is mapped to "minimize IGP metric", * Flex-Algo 128 in Domain 2 is mapped to "minimize IGP metric", and
and hence to C1. hence to C1.
* Flex-Algo FA129 in Domain 2 is mapped to "minimize IGP metric and * Flex-Algo 129 in Domain 2 is mapped to "minimize IGP metric and
avoid resource R", and hence to C2. avoid resource R", and hence to C2.
* Flex-Algo FA128 in Domain 1 is mapped to "minimize IGP metric" * Flex-Algo 128 in Domain 1 is mapped to "minimize IGP metric"
(i.e., there is no resource R to be avoided in Domain 1, hence (i.e., there is no resource R to be avoided in Domain 1, hence
both C1 and C2 are mapped to FA128). both C1 and C2 are mapped to Flex-Algo 128).
* E1 receives the following two service routes from E2: * E1 receives the following two service routes from E2:
- V/v with BGP Color-EC C1, and - V/v with BGP Color-EC C1, and
- W/w with BGP Color-EC C2. - W/w with BGP Color-EC C2.
* E1 has the following color-aware paths: * E1 has the following color-aware paths:
- (E2, C1) provided by BGP CAR with the following per-domain - (E2, C1) provided by BGP CAR with the following per-domain
resolution: resolution:
o Domain 1: over IGP FA128, and o Domain 1: over IGP Flex-Algo 128, and
o Domain 2: over IGP FA128. o Domain 2: over IGP Flex-Algo 128.
- (E2, C2) provided by BGP CAR with the following per-domain - (E2, C2) provided by BGP CAR with the following per-domain
resolution: resolution:
o Domain 1: over IGP FA128, and o Domain 1: over IGP Flex-Algo 128, and
o Domain 2: over IGP FA129 (avoiding resource R). o Domain 2: over IGP Flex-Algo 129 (avoiding resource R).
* E1 automatically steers the received service routes as follows: * E1 automatically steers the received service routes as follows:
- V/v via (E2, C1) provided by BGP CAR. - V/v via (E2, C1) provided by BGP CAR.
- W/w via (E2, C2) provided by BGP CAR. - W/w via (E2, C2) provided by BGP CAR.
Observations: Observations:
* C1 and C2 are realized over a common intra-domain intent (FA128) * C1 and C2 are realized over a common intra-domain intent (Flex-
in one domain and distinct intents in another domain as required. Algo 128) in one domain and distinct intents in another domain as
required.
* 32-bit Color space provides flexibility in defining a large number * 32-bit Color space provides flexibility in defining a large number
of intents in a multi-domain network. They may be efficiently of intents in a multi-domain network. They may be efficiently
realized by mapping to a smaller number of intra-domain intents in realized by mapping to a smaller number of intra-domain intents in
different domains. different domains.
A.6. Per-Flow Steering over CAR Routes A.6. Per-Flow Steering over CAR Routes
This section provides an example of ingress PE per-flow steering as This section provides an example of ingress PE per-flow steering as
defined in Section 8.6 of [RFC9256] onto BGP CAR routes. defined in Section 8.6 of [RFC9256] onto BGP CAR routes.
skipping to change at line 3208 skipping to change at line 3235
array is called a Forwarding Class (FC). The index can have array is called a Forwarding Class (FC). The index can have
values 0 to 7, especially when derived from the MPLS TC bits values 0 to 7, especially when derived from the MPLS TC bits
[RFC5462]. [RFC5462].
* E1 is configured to match flows in its ingress interfaces (upon * E1 is configured to match flows in its ingress interfaces (upon
any field such as Ethernet destination/source/VLAN/TOS or IP any field such as Ethernet destination/source/VLAN/TOS or IP
destination/source/DSCP or transport ports, etc.) and color them destination/source/DSCP or transport ports, etc.) and color them
with an internal per-packet FC variable (0, 1, or 2 in this with an internal per-packet FC variable (0, 1, or 2 in this
example). example).
* This array is presented as a composite candidate path of SR policy * This array is presented as a composite candidate path of SR Policy
(E2, C100) and acts as a container for grouping constituent paths (E2, C100) and acts as a container for grouping constituent paths
of different colors/best-effort. This representation provides of different colors/best-effort. This representation provides
automated steering for services colored with Color-EC C100 via automated steering for services colored with Color-EC C100 via
paths of different colors. Note that Color-EC C100 is used as paths of different colors. Note that Color-EC C100 is used as
indirection to the composite policy configured on ingress PE. indirection to the composite policy configured on ingress PE.
* Egress PE E2 advertises a VPN route RD:V/v with Color-EC C100 to * Egress PE E2 advertises a VPN route RD:V/v with Color-EC C100 to
steer traffic via composite SR policy (E2, C100) (i.e., FC array steer traffic via composite SR Policy (E2, C100) (i.e., FC array
of paths). of paths).
E1 receives three packets K, K1, and K2 on its incoming interface. E1 receives three packets K, K1, and K2 on its incoming interface.
These three packets match on the VPN route that recurses on E2. E1 These three packets match on the VPN route that recurses on E2. E1
colors these 3 packets with forwarding class 0, 1, and 2, colors these 3 packets with forwarding class 0, 1, and 2,
respectively. respectively.
As a result: As a result:
* E1 forwards K along the best-effort path to E2 (i.e., for the MPLS * E1 forwards K along the best-effort path to E2 (i.e., for the MPLS
skipping to change at line 3265 skipping to change at line 3292
packet encapsulation (e.g., LSP) may terminate on any one among a set packet encapsulation (e.g., LSP) may terminate on any one among a set
of nodes. All the nodes are capable of forwarding the inner payload, of nodes. All the nodes are capable of forwarding the inner payload,
typically via an IP lookup in the global table for Internet routes. typically via an IP lookup in the global table for Internet routes.
A couple of variations of the use case are described in the example A couple of variations of the use case are described in the example
below. below.
One node is shown in each domain, but there will be multiple nodes in One node is shown in each domain, but there will be multiple nodes in
practice for redundancy. practice for redundancy.
Example 1: Anycast with forwarding to nearest: Example 1: Anycast with forwarding to nearest egress:
* Both E2 (in egress domain 2) and E3 (in egress domain 3) advertise * Both E2 (in egress domain 2) and E3 (in egress domain 3) advertise
Anycast (shared) IP (IP1, C1) with same Label L1. Anycast (shared) IP (IP1, C1) with same label L1.
* An ingress PE E1 receives by default the best path(s) for (IP1, * An ingress PE E1 receives by default the best path(s) for (IP1,
C1) propagated through BGP hops across the network. C1) propagated through BGP hops across the network.
* The paths to (IP1, C1) from E2 and E3 may merge at a common node * The paths to (IP1, C1) from E2 and E3 may merge at a common node
along the path to E1, forming equal cost multipaths or active- along the path to E1, forming equal cost multipaths or active-
backup paths at that node. backup paths at that node.
* Service route V/v is advertised from egress domains D2 and D3 with * Service route V/v is advertised from egress domains D2 and D3 with
color C1 and next hop IP1. color C1 and next hop IP1.
skipping to change at line 3467 skipping to change at line 3494
o CAR color C400 that resolves on C2 in access and C40 in Core o CAR color C400 that resolves on C2 in access and C40 in Core
domain. domain.
- E2 may originate BGP CAR routes with multiple BGP Color-ECs as - E2 may originate BGP CAR routes with multiple BGP Color-ECs as
shown above. At each hop, CAR route's next hop is resolved shown above. At each hop, CAR route's next hop is resolved
over the available intra-domain color. For example (E2, C100) over the available intra-domain color. For example (E2, C100)
with BGP Color-ECs C1, C10 resolves over C1 at ABR 231, C10 at with BGP Color-ECs C1, C10 resolves over C1 at ABR 231, C10 at
ABR 121, and C1 at E1. ABR 121, and C1 at E1.
- Egress PE E2 advertises a VPN route RD:V/v colored with BGP - Egress PE E2 advertises a VPN route RD:V/v colored with BGP
Color-EC C100 to steer traffic through FA 132 in access and FA Color-EC C100 to steer traffic through Flex-Algo 132 in access
128 in core. It also advertises another VPN route RD:W/w and Flex-Algo 128 in core. It also advertises another VPN
colored with BGP Color-EC C200 to steer traffic through FA 132 route RD:W/w colored with BGP Color-EC C200 to steer traffic
in access and FA 129 in core. through Flex-Algo 132 in access and Flex-Algo 129 in core.
* Important: * Important:
- End-to-end (BGP CAR) colors can be decoupled from intra-domain - End-to-end (BGP CAR) colors can be decoupled from intra-domain
transport colors. transport colors.
- Each end-to-end BGP CAR color is a combination of various - Each end-to-end BGP CAR color is a combination of various
intra-domain colors or intents. intra-domain colors or intents.
- Combination can be expressed by local policy at ABRs or by - Combination can be expressed by local policy at ABRs or by
skipping to change at line 3578 skipping to change at line 3605
| E1 | +---+ : +---+ : | | | En | | E1 | +---+ : +---+ : | | | En |
|----+ |P12|<.:..>|P14| : | | +-----| |----+ |P12|<.:..>|P14| : | | +-----|
| +---+ +---+ : +----+ eBGP +---+ | | +---+ +---+ : +----+ eBGP +---+ |
| IPv6 FIB: ...| 122|-----IP2|232| | | IPv6 FIB: ...| 122|-----IP2|232| |
| B:C11::/32 via IP1 +----+ +---+ | | B:C11::/32 via IP1 +----+ +---+ |
| via IP2 | B:C11::/32 | | | via IP2 | B:C11::/32 | |
| | via 232 | | | | via 232 | |
| | LCM=C1 | | | | LCM=C1 | |
| | AIGP=10 | | | | AIGP=10 | |
| IS-ISv6 | | IS-ISv6 | | IS-ISv6 | | IS-ISv6 |
| FA 128 (B:C12::/32) | |FA128(B:C11::/32)| | FA128 (B:C12::/32) | |FA128(B:C11::/32)|
| FA 0 (B:02::/32) | |FA0 (B:01::/32) | | FA0 (B:02::/32) | |FA0 (B:01::/32) |
+--------------------------------------+ +-----------------+ +--------------------------------------+ +-----------------+
iPE ASBR ASBR ePE iPE ASBR ASBR ePE
Figure 15 Figure 15
The topology above is an example to illustrate the BGP CAR SRv6 The topology above is an example to illustrate the BGP CAR SRv6
locator prefix route-based design (Section 7.1.1) with hop-by-hop locator prefix route-based design (Section 7.1.1) with hop-by-hop
IPv6 routing within and between domains. IPv6 routing within and between domains.
* Multi-AS network with eBGP CAR session between ASBRs. * Multi-AS network with eBGP CAR session between ASBRs.
skipping to change at line 3628 skipping to change at line 3655
* AIGP attribute influences BGP CAR route best path decision. * AIGP attribute influences BGP CAR route best path decision.
* Egress PE E2 advertises a VPN route RD:V/v with SRv6 Service SID * Egress PE E2 advertises a VPN route RD:V/v with SRv6 Service SID
B:C11:2:DT4::. Service SID is allocated by E2 from its locator of B:C11:2:DT4::. Service SID is allocated by E2 from its locator of
color C1 intent. color C1 intent.
* Ingress PE E1 learns (via service RRs S-RR1 and S-RR2) VPN route * Ingress PE E1 learns (via service RRs S-RR1 and S-RR2) VPN route
RD:V/v with SRv6 SID B:C11:2:DT4::. RD:V/v with SRv6 SID B:C11:2:DT4::.
* Service traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: * Service traffic encapsulated with SRv6 Service SID B:C11:2:DT4::
is natively steered hop by hop along IPv6 routed path to is inherently steered hop by hop along IPv6 routed path to
B:C11::/32 provided by BGP CAR in AS2. B:C11::/32 provided by BGP CAR in AS2.
* Encapsulated service traffic is natively steered along IPv6 routed * Encapsulated service traffic is inherently steered along IPv6
path to B:C11::/32 provided by IS-ISv6 Flex-Algo 128 in AS1. routed path to B:C11::/32 provided by IS-ISv6 Flex-Algo 128 in
AS1.
* Design applies to multiple ASNs. BGP next hop is rewritten across * Design applies to multiple ASNs. BGP next hop is rewritten across
an eBGP hop. an eBGP hop.
Important: Important:
* No tunneling/encapsulation on ingress PE and BRs for BGP CAR * No tunneling/encapsulation on ingress PE and BRs for BGP CAR
provided transport. provided transport.
* Uses longest prefix match of SRv6 Service SID to BGP CAR IP * Uses longest prefix match of SRv6 Service SID to BGP CAR IP
prefix. No mapping to labels/SIDs, instead use of simple IP-based prefix. No mapping to labels/SIDs, instead use of simple IP-based
forwarding. forwarding.
Packet forwarding: Packet forwarding:
@E1: IPv4 VRF V/v => H.Encaps.red <B:C11:2:DT4::> => Forward based @E1: IPv4 VRF V/v => H.Encaps.red <B:C11:2:DT4::> => Forward based
on B:C11::/32 on B:C11::/32
@P*: IPv6 table: B:C11::/32 => Forward to interface, NH @P*: IPv6 table: B:C11::/32 => Forward to interface, NH
@121: IPv6 Table: B:C11::/32 => Forward to interface, NH @121: IPv6 Table: B:C11::/32 => Forward to interface, NH
@231: IPv6 table: B:C11:2::/48 :: => Forward via IS-ISv6 FA path to E2 @231: IPv6 table: B:C11:2::/48 :: => Forward via IS-ISv6 Flex-Algo path to E2
@231: IPv6 Table B:C11:2::/48 => Forward via IS-ISv6 FA path to E2 @231: IPv6 Table B:C11:2::/48 => Forward via IS-ISv6 Flex-Algo path to E2
@E2: My SID table B:C11:2:DT4:: => Pop the outer header and look up @E2: My SID table B:C11:2:DT4:: => Pop the outer header and look up
the inner DA in the VRF the inner DA in the VRF
C.2. BGP CAR SRv6 Locator Reachability Distribution with Encapsulation C.2. BGP CAR SRv6 Locator Reachability Distribution with Encapsulation
RD:V/v via E2 RD:V/v via E2
+-----+ SRv6SID=B:C11:2:DT4:: +-----+ +-----+ SRv6SID=B:C11:2:DT4:: +-----+
...... |S-RR1| <..................................|S-RR2| <....... ...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ +-----+ : : +-----+ +-----+ :
: : : :
: : : :
: : : :
skipping to change at line 3690 skipping to change at line 3718
| | | | | En | | | | | | En |
| | | | +-----| | | | | +-----|
| | +---+ +---+ | | | | +---+ +---+ | |
| |---------------- |122|<-----------------|232|<-------------| | | |---------------- |122|<-----------------|232|<-------------| |
| +---+ +---+ | | +---+ +---+ |
| B:C11::/32 via 122 | B:C11::/32 via 232 | | | B:C11::/32 via 122 | B:C11::/32 via 232 | |
| SID=B:C13:122:END:: | SID=B:C12:232:END:: | | | SID=B:C13:122:END:: | SID=B:C12:232:END:: | |
| LCM=C1 AIGP=120 | LCM=C1 AIGP=20 | | | LCM=C1 AIGP=120 | LCM=C1 AIGP=20 | |
| | | | | | | |
| IS-ISv6 | IS-ISv6 | IS-ISv6 | | IS-ISv6 | IS-ISv6 | IS-ISv6 |
| FA 128 (B:C13::/32) | FA 128 (B:C12::/32) | FA128 (B:C11::/32) | | FA128 (B:C13::/32) | FA128 (B:C12::/32) | FA128 (B:C11::/32) |
| FA 0 (B:03::/32) | FA 0 (B:02::/32) | FA1 0 (B:01::/32) | | FA0 (B:03::/32) | FA0 (B:02::/32) | FA0 (B:01::/32) |
+-------------------------+----------------------+---------------------+ +-------------------------+----------------------+---------------------+
iPE iABR eABR ePE iPE iABR eABR ePE
Figure 16 Figure 16
The topology above is an example to illustrate the BGP CAR SRv6 The topology above is an example to illustrate the BGP CAR SRv6
locator prefix route-based design (Section 7.1.1) with intra-domain locator prefix route-based design (Section 7.1.1) with intra-domain
encapsulation. The example shown is iBGP, but also applies to eBGP encapsulation. The example shown is iBGP, but also applies to eBGP
(multi-AS). (multi-AS).
* IGP Flex-Algo 128 is running in each domain, where: * IGP Flex-Algo 128 is running in each domain, where:
- Prefix B:C11::/32 summarizes Flex-Algo 128 block in egress - Prefix B:C11::/32 summarizes Flex-Algo 128 block in egress
domain for the given intent. Node locators in the egress domain for the given intent. Node locators in the egress
domain are sub-allocated from the block. domain are sub-allocated from the block.
- Prefix B:C12::/32 summarizes FA128 block in transit domain. - Prefix B:C12::/32 summarizes Flex-Algo 128 block in transit
domain.
- Prefix B:C13::/32 summarizes FA128 block in ingress domain. - Prefix B:C13::/32 summarizes Flex-Algo 128 block in ingress
domain.
* BGP CAR route B:C11::/32 is originated by ABRs 231 and 232 with * BGP CAR route B:C11::/32 is originated by ABRs 231 and 232 with
LCM C1. Along the propagation path, border routers set next-hop- LCM C1. Along the propagation path, border routers set next-hop-
self and appropriately update the intra-domain encapsulation self and appropriately update the intra-domain encapsulation
information for the C1 intent. For example, 231 and 121 signal information for the C1 intent. For example, 231 and 121 signal
SRv6 SID of End behavior [RFC8986] allocated from their respective SRv6 SID of End behavior [RFC8986] allocated from their respective
locators for the C1 intent. (Note: IGP Flex-Algo is shown for locators for the C1 intent. (Note: IGP Fleixible Algorithm is
intra-domain path, but SR-Policy may also provide the path as shown for intra-domain path, but SR Policy may also provide the
shown in Appendix C.3.) path as shown in Appendix C.3.)
* AIGP attribute influences BGP CAR route best path decision. * AIGP attribute influences BGP CAR route best path decision.
* Egress PE E2 advertises a VPN route RD:V/v with SRv6 Service SID * Egress PE E2 advertises a VPN route RD:V/v with SRv6 Service SID
B:C11:2:DT4::. Service SID is allocated by E2 from its locator of B:C11:2:DT4::. Service SID is allocated by E2 from its locator of
color C1 intent. color C1 intent.
* Ingress PE E1 learns CAR route B:C11::/32 and VPN route RD:V/v * Ingress PE E1 learns CAR route B:C11::/32 and VPN route RD:V/v
with SRv6 SID B:C11:2:DT4::. with SRv6 SID B:C11:2:DT4::.
* Traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: is * Traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: is
steered along IPv6 routed path provided by BGP CAR IP prefix route steered along IPv6 routed path provided by BGP CAR IP Prefix route
to locator B:C11::/32. to locator B:C11::/32.
Important: Important:
* Uses longest prefix match of SRv6 Service SID to BGP CAR prefix. * Uses longest prefix match of SRv6 Service SID to BGP CAR prefix.
There is no mapping labels/SIDs; there is simple IP-based There is no mapping labels/SIDs; there is simple IP-based
forwarding instead. forwarding instead.
* Originating domain PE locators of the given intent can be * Originating domain PE locators of the given intent can be
summarized on transit BGP hops eliminating per PE state on border summarized on transit BGP hops eliminating per PE state on border
routers. routers.
Packet forwarding: Packet forwarding:
@E1: IPv4 VRF V/v => H.Encaps.red <B:C13:121:END::, B:C11:2:DT4::> @E1: IPv4 VRF V/v => H.Encaps.red <B:C13:121:END::, B:C11:2:DT4::>
@121: My SID table: B:C13:121:END:: => Update DA with B:C11:2:DT4:: @121: My SID table: B:C13:121:END:: => Update DA with B:C11:2:DT4::
@121: IPv6 Table: B:C11::/32 => H.Encaps.red <B:C12:231:END::> @121: IPv6 Table: B:C11::/32 => H.Encaps.red <B:C12:231:END::>
@231: My SID table: B:C12:231:END:: => Remove IPv6 header; @231: My SID table: B:C12:231:END:: => Remove IPv6 header;
Inner DA B:C11:2:DT4:: Inner DA B:C11:2:DT4::
@231: IPv6 Table B:C11:2::/48 => Forward via IS-ISv6 FA path to E2 @231: IPv6 Table B:C11:2::/48 => Forward via IS-ISv6 Flex-Algo path to E2
@E2: My SID table B:C11:2:DT4:: => Pop the outer header and look up @E2: My SID table B:C11:2:DT4:: => Pop the outer header and look up
the inner DA in the VRF the inner DA in the VRF
C.3. BGP CAR (E, C) Route Distribution for Steering Non-Routed Service C.3. BGP CAR (E, C) Route Distribution for Steering Non-Routed Service
SID SID
RD:V/v via E2 RD:V/v via E2
+-----+ SRv6SID: B:01:2:DT4:: +-----+ +-----+ SRv6SID: B:01:2:DT4:: +-----+
...... |S-RR1| <..................................|S-RR2| <....... ...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ Color C2 +-----+ : : +-----+ Color C2 +-----+ :
: : : :
: +-----+ (E2,C2) via 231 : : +-----+ (E2,C2) via 231 :
: -----------------| TRR |-------------------| : : -----------------| TRR |-------------------| :
:| +-----+ SID=B:C21:2:B6:: | : :| +-----+ SID=B:C21:2:B6:: | :
+-:|---------------------+---------------------|+------------------:--+ +-:|---------------------+---------------------|+------------------:--+
| :| | || : | | :| | || : |
| :| | || : | | :| | || : |
| :| B:C21::/32 via 121 | B:C21::/32 via 231 ||SR policy(E2,C2) : | | :| B:C21::/32 via 121 | B:C21::/32 via 231 ||SR Policy(E2,C2) : |
| :| LCM=C2,AIGP=110 | LCM=C2 AIGP=10 ||BSID=B:C21:2:B6:: : | | :| LCM=C2,AIGP=110 | LCM=C2 AIGP=10 ||BSID=B:C21:2:B6:: : |
| :| +---+ +---+ : | | :| +---+ +---+ : |
| :|-------------------|121|<-----------------|231|<-------------| : | | :|-------------------|121|<-----------------|231|<-------------| : |
| :V SR policy(121,C2) +---+SR policy(231,C2) +---+ | : | | :V SR Policy(121,C2) +---+SR Policy(231,C2) +---+ | : |
|----+ | | +-----| |----+ | | +-----|
| E1 | | | | E2 | | E1 | | | | E2 |
|----+ | | +-----| |----+ | | +-----|
| ^ SR policy(122,C2) +---+SR policy(232,C2) +---+ | | | ^ SR Policy(122,C2) +---+SR Policy(232,C2) +---+ | |
| |---------------- |122|<-----------------|232|<-------------| | | |---------------- |122|<-----------------|232|<-------------| |
| B:C21::/32 via 121+---+B:C21::/32 via 232+---+ SR policy(E2,C2) | | B:C21::/32 via 121+---+B:C21::/32 via 232+---+ SR Policy(E2,C2) |
| LCM=C2,AIGP=120 | LCM=C2 AIGP=20 | BSID=B:C21:2:B6:: | | LCM=C2,AIGP=120 | LCM=C2 AIGP=20 | BSID=B:C21:2:B6:: |
| | | | | | | |
| IS-ISv6 | IS-ISv6 | IS-ISv6 | | IS-ISv6 | IS-ISv6 | IS-ISv6 |
| FA 0 (B:03::/32) | FA 0 (B:02::/32) | FA 0(B:01::/32) | | FA0 (B:03::/32) | FA0 (B:02::/32) | FA0(B:01::/32) |
+------------------------+----------------------+---------------------+ +------------------------+----------------------+---------------------+
iPE iABR eABR ePE iPE iABR eABR ePE
Figure 17 Figure 17
The topology above is an example to illustrate the BGP CAR (E, C) The topology above is an example to illustrate the BGP CAR (E, C)
route-based design (Section 7.1.2). The example is iBGP, but the route-based design (Section 7.1.2). The example is iBGP, but the
design also applies to eBGP (multi-AS). design also applies to eBGP (multi-AS).
* SR policy (E2, C2) provides given intent in egress domain. * SR Policy (E2, C2) provides given intent in egress domain.
- SR policy (E2, C2) with segments <B:01:z:END::, B:01:2:END::>, - SR Policy (E2, C2) with segments <B:01:z:END::, B:01:2:END::>,
where z is the node id in egress domain. where z is the node id in egress domain.
* Egress ABRs 231 and 232 redistribute SR policy into BGP CAR Type-1 * Egress ABRs 231 and 232 redistribute SR Policy into BGP CAR Type-1
NLRI (E2, C2) to other domains, with SRv6 SID of End.B6 behavior. NLRI (E2, C2) to other domains, with SRv6 SID of End.B6 behavior.
This route is propagated to ingress PEs through Transport RR (TRR) This route is propagated to ingress PEs through Transport RR (TRR)
or inline with next-hop-unchanged. or inline with next-hop-unchanged.
* The ABRs also advertise BGP CAR prefix route (B:C21::/32) * The ABRs also advertise BGP CAR prefix route (B:C21::/32)
summarizing locator part of SRv6 SIDs for SR policies of given summarizing locator part of SRv6 SIDs for SR policies of given
intent to different PEs in egress domain. BGP CAR prefix route intent to different PEs in egress domain. BGP CAR prefix route
propagates through border routers. At each BGP hop, BGP CAR propagates through border routers. At each BGP hop, BGP CAR
prefix next-hop resolution triggers intra-domain transit SR policy prefix next-hop resolution triggers intra-domain transit SR Policy
(C2, CAR next hop). For example: (C2, CAR next hop). For example:
- SR policy (231, C2) with segments <B:02:y:END::, - SR Policy (231, C2) with segments <B:02:y:END::,
B:02:231:END::>, and B:02:231:END::>, and
- SR policy (121, C2) with segments <B:03:x:END::, - SR Policy (121, C2) with segments <B:03:x:END::,
B:03:121:END::>, B:03:121:END::>,
- where x and y are node ids within the respective domains. - where x and y are node ids within the respective domains.
* Egress PE E2 advertises a VPN route RD:V/v with Color-EC C2. * Egress PE E2 advertises a VPN route RD:V/v with Color-EC C2.
* Ingress PE E1 steers VPN route from E2 onto BGP CAR route (E2, C2) * Ingress PE E1 steers VPN route from E2 onto BGP CAR route (E2, C2)
that results in H.Encaps.red of SRv6 transport SID B:C21:2:B6:: that results in H.Encaps.red of SRv6 transport SID B:C21:2:B6::
and SRv6 Service SID as last segment in IPv6 header. and SRv6 Service SID as last segment in IPv6 header.
skipping to change at line 3840 skipping to change at line 3870
segments to E2). segments to E2).
Important: Important:
* Ingress PE steers services via (E, C) CAR route as per [RFC9256]. * Ingress PE steers services via (E, C) CAR route as per [RFC9256].
* In data plane (E, C), resolution results in IPv6 header * In data plane (E, C), resolution results in IPv6 header
destination being SRv6 SID of END.B6 behavior whose locator is of destination being SRv6 SID of END.B6 behavior whose locator is of
given intent on originating ABRs. given intent on originating ABRs.
* CAR IP prefix route along the transit path provides simple Longest * CAR IP Prefix route along the transit path provides simple Longest
Prefix Match (LPM) IPv6 forwarding along the transit BGP hops. Prefix Match (LPM) IPv6 forwarding along the transit BGP hops.
* CAR NLRI Type-2 prefix summarizes binding SIDs of all SR policies * CAR NLRI Type-2 prefix summarizes binding SIDs of all SR policies
on originating ABR of a given intent to different PEs in egress on originating ABR of a given intent to different PEs in egress
domain. This eliminates per PE state on transit routers. domain. This eliminates per PE state on transit routers.
Packet forwarding: Packet forwarding:
@E1: IPv4 VRF V/v => H.Encaps.red <B:C21:2:B6::, B:0:E2:DT4::> @E1: IPv4 VRF V/v => H.Encaps.red <B:C21:2:B6::, B:0:E2:DT4::>
H.Encaps.red <SR policy (C2,121) sid list> H.Encaps.red <SR Policy (C2,121) sid list>
@121: My SID table: B:03:121:END:: => Remove outer IPv6 header; @121: My SID table: B:03:121:END:: => Remove outer IPv6 header;
Inner DA B:C21:2:B6:: Inner DA B:C21:2:B6::
@121: IPv6 Table: B:C21::/32 => H.Encaps.red <SR Policy (C2,231) sid @121: IPv6 Table: B:C21::/32 => H.Encaps.red <SR Policy (C2,231) sid
list> list>
@231: My SID table: B:02:231:END:: => Remove outer IPv6 header; @231: My SID table: B:02:231:END:: => Remove outer IPv6 header;
Inner DA B:C21:2:B6:: Inner DA B:C21:2:B6::
@231: MySIDtable B:C21:2:B6:: => H.Encaps.red <SR Policy (C2,E2) sid @231: MySIDtable B:C21:2:B6:: => H.Encaps.red <SR Policy (C2,E2) sid
list> list>
@E2: IPv6 Table B:0:2:DT4:: => Pop the outer header and look up the @E2: IPv6 Table B:0:2:DT4:: => Pop the outer header and look up the
skipping to change at line 3872 skipping to change at line 3902
Appendix D. CAR SAFI NLRI Update Packing Efficiency Calculation Appendix D. CAR SAFI NLRI Update Packing Efficiency Calculation
CAR SAFI NLRI encoding is optimized for update packing. It allows CAR SAFI NLRI encoding is optimized for update packing. It allows
per-route information (for example, label, label index, and SRv6 SID per-route information (for example, label, label index, and SRv6 SID
encapsulation data) to be carried in the non-key TLV part of NLRI. encapsulation data) to be carried in the non-key TLV part of NLRI.
This allows multiple NLRIs to be packed in a single update message This allows multiple NLRIs to be packed in a single update message
when other attributes (including LCM-EC, when present) are shared. when other attributes (including LCM-EC, when present) are shared.
The table below shows a theoretical analysis calculated from observed The table below shows a theoretical analysis calculated from observed
BGP update message size in operational networks. It compares total BGP update message size in operational networks. It compares total
BGP data on the wire for CAR SAFI and [RFC8277] style encoding in BGP data on the wire for CAR SAFI against encoding as specified in
MPLS label (CASE A), SR extension with MPLS (per-prefix label index [RFC8277] in the following cases: an MPLS label (CASE A), an SR
in Prefix-SID attribute) [RFC8669] (CASE B) and SRv6 SID (CASE C) extension with MPLS (per-prefix label index in Prefix-SID attribute;
cases. The packing scenarios considered are as follows: see [RFC8669]) (CASE B), and an SRv6 SID (CASE C). The packing
scenarios considered are as follows:
* the ideal case (where the maximum number of routes are packed to * the ideal case (where the maximum number of routes are packed to
the update message limit of 4k bytes), the update message limit of 4k bytes),
* the practical case of average packing (where 5 routes share a set * the practical case of average packing (where 5 routes share a set
of BGP path attributes, and hence are packed in a single update of BGP path attributes, and hence are packed in a single update
message), and message), and
* the worst case of no packing (where each route is in a separate * the worst case of no packing (where each route is in a separate
update message). update message).
+=============+=========+===========+============================+ +=============+=========+===========+==============================+
| Encoding | BGP CAR | [RFC8277] | Result | | Encoding | BGP CAR | NLRI as | Result |
| | NLRI | style | | | | NLRI | per | |
| | | NLRI | | | | | [RFC8277] | |
+=============+=========+===========+============================+ +=============+=========+===========+==============================+
| CASE A: Label | | CASE A: Label |
+=============+=========+===========+============================+ +=============+=========+===========+==============================+
| (Ideal) | 27.5 MB | 26 MB | No degradation from | | (Ideal) | 27.5 MB | 26 MB | No degradation compared to |
| | | | [RFC8277] like encoding. | | | | | encoding as specified in |
+-------------+---------+-----------+ | | | | | [RFC8277]. |
| (Practical) | 86 MB | 84 MB | | +-------------+---------+-----------+ |
+-------------+---------+-----------+ | | (Practical) | 86 MB | 84 MB | |
| (Worst; no | 325 MB | 324 MB | | +-------------+---------+-----------+ |
| packing) | | | | | (Worst; no | 325 MB | 324 MB | |
+=============+=========+===========+============================+ | packing) | | | |
| CASE B: Label & Label-index | +=============+=========+===========+==============================+
+=============+=========+===========+============================+ | CASE B: Label & Label-Index |
| (Ideal) | 42 MB | 339 MB | CAR SAFI encoding is more | +=============+=========+===========+==============================+
| | | Packing | efficient by 88% in the | | (Ideal) | 42 MB | 339 MB | CAR SAFI encoding is more |
| | | not | best case and 71% in the | | | | Packing | efficient by 88% in the best |
| | | possible | average case over | | | | not | case and 71% in the average |
| | | | [RFC8277] style encoding | | | | possible | case over the encoding as |
| | | | (which precludes packing). | | | | | specified in [RFC8277] |
+-------------+---------+-----------+ | | | | | (which precludes packing). |
| (Practical) | 99 MB | 339 MB | | +-------------+---------+-----------+ |
| | | Packing | | | (Practical) | 99 MB | 339 MB | |
| | | not | | | | | Packing | |
| | | possible | | | | | not | |
+-------------+---------+-----------+ | | | | possible | |
| (Worst; no | 339 MB | 339 MB | | +-------------+---------+-----------+ |
| packing) | | | | | (Worst; no | 339 MB | 339 MB | |
+=============+=========+===========+============================+ | packing) | | | |
| CASE C: SRv6 SID | +=============+=========+===========+==============================+
+=============+=========+===========+============================+ | CASE C: SRv6 SID |
| (Ideal) | 49 MB | 378 MB | Results are similar to the | +=============+=========+===========+==============================+
| | | | SR-MPLS case. | | (Ideal) | 49 MB | 378 MB | Results are similar to the |
| | | | Transposition provides a | | | | Packing | SR-MPLS case. Transposition |
| | | | further 20% reduction in | | | | not | provides a further 20% |
| | | | BGP data. | | | | possible | reduction in BGP data. |
+-------------+---------+-----------+ | +-------------+---------+-----------+ |
| (Practical) | 115 MB | 378 MB | | | (Practical) | 115 MB | 378 MB | |
+-------------+---------+-----------+ | | | | Packing | |
| (Worst; no | 378 MB | 378 MB | | | | | not | |
| packing) | | | | | | | possible | |
+-------------+---------+-----------+----------------------------+ +-------------+---------+-----------+ |
| (Worst; no | 378 MB | 378 MB | |
| packing) | | | |
+-------------+---------+-----------+------------------------------+
Table 5: Summary of the Ideal, Practical, and Worst Cases of Table 5: Summary of the Ideal, Practical, and Worst Cases of
Packing BGP Data Packing BGP Data
This analysis considers 1.5 million routes (5 colors across 300k This analysis considers 1.5 million routes (5 colors across 300k
endpoints). endpoints).
CASE A: BGP data exchanged for the non-SR-MPLS case: CASE A: BGP data exchanged for MPLS (non-SR):
Consider 200 bytes of shared attributes Consider 200 bytes of shared attributes
CAR SAFI signal Label in non-key TLV part of NLRI CAR SAFI signals label in non-key TLV part of NLRI
Each NLRI size for AFI 1 = 12(key) + 5(label) = 17 bytes Each NLRI size for AFI 1 = 12(key) + 5(label) = 17 bytes
Ideal packing: Ideal packing:
number of NLRIs in 4k update size = 223 (4k-200/17) Number of NLRIs in 4k update size = 223 (4k-200/17)
number of update messages of 4k size = 1.5 million/223 = 6726 Number of update messages of 4k size = 1.5 million/223 = 6726
Total BGP data on wire = 6726 * 4k = ~27.5MB Total BGP data on wire = 6726 * 4k = ~27.5MB
Practical packing (5 routes in update message): Practical packing (5 routes in update message):
size of update message = (17 * 5) + 200 = 285 Size of update message = (17 * 5) + 200 = 285
Total BGP data on wire = 285 * 300k = ~86MB Total BGP data on wire = 285 * 300k = ~86MB
No-packing case (1 route per update message): No-packing case (1 route per update message):
size of update message = 17 + 200 = 217 Size of update message = 17 + 200 = 217
Total BGP data on wire = 217 * 1.5 million = ~325MB Total BGP data on wire = 217 * 1.5 million = ~325MB
SAFI 128 8277 style encoding with label in NLRI SAFI 128 using encoding specified in RFC 8277 with label in NLRI
Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes
Ideal packing: Ideal packing:
number of NLRIs in 4k update size = 237 (4k-200/16) Number of NLRIs in 4k update size = 237 (4k-200/16)
number of update messages of 4k size = 1.5 million/237 = ~6330 Number of update messages of 4k size = 1.5 million/237 = ~6330
Total BGP data on wire = 6330 * 4k = ~25.9MB Total BGP data on wire = 6330 * 4k = ~25.9MB
Practical packing (5 routes in update message): Practical packing (5 routes in update message):
size of update message = (16 * 5) + 200 = 280 Size of update message = (16 * 5) + 200 = 280
Total BGP data on wire = 280 * 300k = ~84MB Total BGP data on wire = 280 * 300k = ~84MB
No-packing case (1 route per update message): No-packing case (1 route per update message):
size of update message = 16 + 200 = 216 Size of update message = 16 + 200 = 216
Total BGP data on wire = 216 * 1.5 million = ~324MB Total BGP data on wire = 216 * 1.5 million = ~324MB
CASE B: BGP data exchanged for SR label index: CASE B: BGP data exchanged for SR-MPLS label index:
Consider 200 bytes of shared attributes Consider 200 bytes of shared attributes
CAR SAFI signal Label in non-key TLV part of NLRI CAR SAFI signals label index in non-key TLV part of NLRI
Each NLRI size for AFI 1 Each NLRI size for AFI 1
= 12(key) + 5(label) + 9(Index) = 26 bytes = 12(key) + 5(label) + 9(Index) = 26 bytes
Ideal packing: Ideal packing:
number of NLRIs in 4k update size = 146 (4k-200/26) Number of NLRIs in 4k update size = 146 (4k-200/26)
number of update messages of 4k size = 1.5 million/146 = 6726 Number of update messages of 4k size = 1.5 million/146 = 6726
Total BGP data on wire = 10274 * 4k = ~42MB Total BGP data on wire = 10274 * 4k = ~42MB
Practical packing (5 routes in update message) Practical packing (5 routes in update message)
size of update message = (26 * 5) + 200 = 330 Size of update message = (26 * 5) + 200 = 330
Total BGP data on wire = 330 * 300k = ~99MB Total BGP data on wire = 330 * 300k = ~99MB
No-packing case (1 route per update message) No-packing case (1 route per update message)
size of update message = 26 + 200 = 226 Size of update message = 26 + 200 = 226
Total BGP data on wire = 226 * 1.5 million = ~339MB Total BGP data on wire = 226 * 1.5 million = ~339MB
SAFI 128 8277 style encoding with label in NLRI SAFI 128 using encoding specified in RFC 8277 with label in NLRI
Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes
Ideal packing: Ideal packing:
Not supported as label index is encoded in Prefix-SID Not supported as label index is encoded in Prefix-SID
attribute attribute
Practical packing (5 routes in update message): Practical packing (5 routes in update message):
Not supported as label index is encoded in Prefix-SID Not supported as label index is encoded in Prefix-SID
attribute attribute
No-packing case (1 route per update message): No-packing case (1 route per update message):
size of update message = 16 + 210 = 226 Size of update message = 16 + 210 = 226
Total BGP data on wire = 216 * 1.5 million = ~339MB Total BGP data on wire = 216 * 1.5 million = ~339MB
CASE C: BGP data exchanged with 128 bit single SRv6 SID: CASE C: BGP data exchanged with 128 bit single SRv6 SID:
Consider 200 bytes of shared attributes Consider 200 bytes of shared attributes
CAR SAFI signal Label in non-key TLV part of NLRI CAR SAFI signals SRv6 SID in non-key TLV part of NLRI
Each NLRI size for AFI 1 = 12(key) + 18(Srv6 SID) = 30 bytes Each NLRI size for AFI 1 = 12(key) + 18(SRv6 SID) = 30 bytes
Ideal packing: Ideal packing:
number of NLRIs in 4k update size = 126 (4k-200/30) Number of NLRIs in 4k update size = 126 (4k-200/30)
number of update messages of 4k size = 1.5 million/126 = ~12k Number of update messages of 4k size = 1.5 million/126 = ~12k
Total BGP data on wire = 12k * 4k = ~49MB Total BGP data on wire = 12k * 4k = ~49MB
Practical packing (5 routes in update message): Practical packing (5 routes in update message):
size of update message Size of update message
= (30 * 5) + 236 (including Prefix-SID) = 386 = (30 * 5) + 236 (including Prefix-SID) = 386
Total BGP data on wire = 386 * 300k = ~115MB Total BGP data on wire = 386 * 300k = ~115MB
No-packing case (1 route per update message): No-packing case (1 route per update message):
size of update message = 12 + 236 (SID in Prefix-SID) = 252 Size of update message = 12 + 236 (SID in Prefix-SID) = 252
Total BGP data on wire = 252 * 1.5 million = ~378MB Total BGP data on wire = 252 * 1.5 million = ~378MB
SAFI 128 8277 style encoding with label in NLRI (No transposition) SAFI 128 using encoding specified in RFC 8277 with label in NLRI (No transposition)
Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes
Ideal packing: Ideal packing:
Not supported as label index is encoded in Prefix-SID Not supported as SRv6 SID is encoded in Prefix-SID
attribute attribute
Practical packing (5 routes in update message): Practical packing (5 routes in update message):
Not supported as label index is encoded in Prefix-SID Not supported as SRv6 SID is encoded in Prefix-SID
attribute attribute
No-packing case (1 route per update message): No-packing case (1 route per update message):
size of update message = 16 + 236 = 252 Size of update message = 16 + 236 = 252
Total BGP data on wire = 252 * 1.5 million = ~378MB Total BGP data on wire = 252 * 1.5 million = ~378MB
BGP data exchanged with SRv6 SID 4 bytes transposition into SRv6 SID BGP data exchanged with transposition of 4 bytes from SRv6 SID into
TLV: SRv6 SID TLV:
Consider 200 bytes of shared attributes Consider 200 bytes of shared attributes
CAR SAFI signal Label in non-key TLV part of NLRI CAR SAFI signals SRv6 SID in non-key TLV part of NLRI
Each NLRI size for AFI 1 = 12(key) + 6(Srv6 SID) = 18 bytes Each NLRI size for AFI 1 = 12(key) + 6(SRv6 SID) = 18 bytes
Ideal packing: Ideal packing:
number of NLRIs in 4k update size = 211 (4k-200/18) Number of NLRIs in 4k update size = 211 (4k-200/18)
number of update messages of 4k size = 1.5 million/211 = ~7110 Number of update messages of 4k size = 1.5 million/211 = ~7110
Total BGP data on wire = 7110 * 4k = ~29MB Total BGP data on wire = 7110 * 4k = ~29MB
Practical packing (5 routes in update message): Practical packing (5 routes in update message):
size of update message Size of update message
= (18 * 5) + 236 (including Prefix-SID) = 326 = (18 * 5) + 236 (including Prefix-SID) = 326
Total BGP data on wire = 326 * 300k = ~98MB Total BGP data on wire = 326 * 300k = ~98MB
No-packing case (1 route per update message): No-packing case (1 route per update message):
size of update message Size of update message
= 12 + 236 (SID in Prefix-SID attribute) = 252 = 12 + 236 (SID in Prefix-SID attribute) = 252
Total BGP data on wire = 252 * 1.5 million = ~378MB Total BGP data on wire = 252 * 1.5 million = ~378MB
Acknowledgements Acknowledgements
The authors would like to acknowledge the invaluable contributions of The authors would like to acknowledge the invaluable contributions of
many collaborators towards the BGP CAR solution and this document in many collaborators towards the BGP CAR solution and this document in
providing input about use cases, participating in brainstorming and providing input about use cases, participating in brainstorming and
mailing list discussions and in reviews of the solution and draft mailing list discussions and in reviews of the solution and draft
revisions. In addition to the contributors listed in the revisions. In addition to the contributors listed in the
 End of changes. 186 change blocks. 
352 lines changed or deleted 386 lines changed or added

This html diff was produced by rfcdiff 1.48.