Skip to main content

2. BGP CAR SAFI

2.1. Data Model​

The BGP CAR data model is:

NLRI key: Falls into two categories to accommodate the use cases described in the Introduction:

Type-1: Key is IP prefix and color (E, C). Color in the NLRI key distinguishes color-aware routes for a common IP prefix, one per intent. Color also indicates the intent associated with the route.

Type-2: Key is IP prefix (E). Unique IP prefix assigned for an intent (i.e., IP prefix == intent) distinguishes color-aware routes. Color need not be in the NLRI key as a distinguisher.

NLRI non-key encapsulation data: Data associated with the NLRI, such as MPLS label stack, SR-MPLS label index, and SRv6 SID list. Contained in TLVs as described in Section 2.9.2.

BGP next hop: Next hop address associated with a particular NLRI key [RFC4760].

AIGP metric [RFC7311]: Accumulates color/intent-specific CAR route metric value over multiple BGP hops.

Local Color Mapping Extended Community (LCM-EC): Optional non-zero 32-bit color value representing the intent associated with a CAR route:

  • When a CAR route is propagated between different color domains.
  • When a CAR route has unique IP prefix for intent.

BGP Color Extended Community (Color-EC) [RFC9012]: Optional non-zero 32-bit color value representing the intent associated with the BGP CAR next hop. Used per [RFC9256] for automated route resolution when the intent/color for the next hop is different from the intent/color of the CAR route.

The following sections describe the data model in detail. Sections describing CAR SAFI protocol processing generally apply consistently to both route types (e.g., any color-based operations). Examples use (E, C) for simplicity.

2.2. Extensible Encoding​

Extensible encoding is provided through:

NLRI Type field: This provides extensibility to add new NLRI formats to support new route types.

NLRI (route) types other than Type-1 (E, C) and Type-2 (E) are outside the scope of this document.

Key Length field: This specifies the key length. It allows opaque handling of new NLRI types, thus allowing new route types to transit through BGP speakers (such as Route Reflectors (RR)).

TLV-based encoding of non-key part of NLRI: This allows inclusion of additional non-key fields for a prefix to simultaneously support different types of transport and enable efficient BGP update packing (Section 2.9).

AIGP attribute: This provides extensibility through TLVs, enabling additional metric semantics to be defined for color as needed per intent.

2.3. BGP CAR Route Origination​

BGP CAR routes can be locally originated (e.g., loopback) or via redistribution of (E, C) color-aware paths provided by another routing solution (e.g., SR Policy, IGP Flexible Algorithm, RSVP-TE, BGP-LU [RFC8277]).

2.4. BGP CAR Route Validation​

A BGP CAR path (E, C) via next hop N and encapsulation T is valid if there exists a color-aware path (N, C) and encapsulation T is available in the data plane.

Local policy can customize the validation process:

  • The color constraint in the first check can be relaxed. The route may be considered valid if N is reachable via an alternate color or in the default routing table.

  • The data-plane availability constraint for T can be relaxed to use an alternate encapsulation.

  • Performance measurement validation can be added to ensure the intent associated with C is met (e.g., latency < threshold).

Invalid paths MUST NOT be considered for BGP best path selection.

2.5. BGP CAR Route Resolution​

A BGP color-aware route (E2, C1) with next hop N by default automatically resolves on color-aware route (N, C1). Color-aware route (N, C1) is provided by a color-aware mechanism such as IGP Flexible Algorithm [RFC9350], SR Policy (Section 2.2 of [RFC9256]), or recursively by BGP CAR. When multiple (N, C1) producers are available, the default preference is: IGP Flexible Algorithm, SR Policy, BGP CAR.

Local policy SHOULD provide additional control:

  • A BGP color-aware route (E2, C1) with next hop N can resolve on color-aware route (N, C2) (i.e., local policy maps resolution of C1 to a different color C2). Examples where such resolution may occur include:

    • In a domain where resource R is known not to exist, inter-domain intent C1="low-latency and avoid R" can resolve on intra-domain path for intent C2="low-latency".

    • In a domain, if no (N, C1) path is available, resolution can fall back to a C2 path if user permits.

  • Route resolution can be driven by the egress node. In an SRv6 domain, the egress node selects and advertises an SRv6 SID with the BGP CAR route from its locator for intent C1. In this case, the ingress node resolves the received SRv6 SID on an IPv6 route for the egress node's intent-aware locator for C1 or on an aggregate route covering the locator. This aggregate route can be provided by SRv6 Flexible Algorithm or by BGP CAR IP Prefix route itself (e.g., Appendix C.2).

  • Local policy can map a CAR route to color-unaware or best-effort mechanisms such as RSVP-TE, IGP/LDP, BGP-LU/BGP-IP (e.g., Appendix A.3.2) for brownfield scenarios.

Route resolution via a different color C2 can be automated by attaching BGP Color-EC C2 to the CAR route (E2, C1), leveraging the automated steering described in Section 8.4 of "Segment Routing Policy Architecture" [RFC9256] for BGP CAR routes. This mechanism is illustrated in Appendix B.2. This mechanism SHOULD be supported.

For CAR route resolution, if a Color-EC color is present in the route, it takes precedence over the route's intent color. The route's intent color is the LCM-EC color if present (see Section 2.9.5), else the NLRI color.

Local policy takes precedence over color-based automatic resolution specified above.

Color-aware route (N, C1) can be provided by BGP CAR itself in a hierarchical transport routing design. In this case, recursive resolution may occur on the same or different CAR route types, based on the process described above. Section 7.1.2 describes a scenario where a CAR (E, C) route resolves on a CAR IP Prefix route.

CAR IP Prefix routes allow no color for best-effort. In this case, resolution is based on BGP next hop N, or when present, based on best-effort SRv6 SID advertised by node N.

BGP CAR routes can recursively resolve on BGP routes carrying TEA and follow [RFC9012] Section 6 for validation. In this case, the procedures of Section 8 of [RFC9012] apply to BGP CAR routes, using the color precedence specified above for resolution.

The procedures of Section 6 of [RFC9012] also apply to BGP CAR routes (AFI/SAFI = 1/83 or 2/83). For example, a BGP CAR BR can advertise BGP CAR routes to ingress BRs or PEs with a specific BGP next hop per color, with TEA or Tunnel Encapsulation EC as described in Section 6 of [RFC9012].

BGP CAR resolution in one network domain is independent of resolution in another domain.

2.6. AIGP Metric Computation​

The Accumulated IGP (AIGP) metric attribute [RFC7311] is updated as BGP CAR routes propagate through the network.

The value set (or appropriately incremented) in the AIGP TLV corresponds to the metric related to the underlying intent for the color. For example, when the color is associated with a low-latency path, the metric value is set based on latency metrics.

Information about the type of metric used by the underlying intra-domain mechanisms can also be used to set the metric value.

If a BGP CAR route crosses a discontinuity in the transport path for a given intent, a penalty (value set by user policy) is added to the AIGP metric. For example, this can happen when a color C1 path is not available and the route resolves via a color C2 path (see Appendix A.3 for an example).

AIGP metric computation is recursive.

To avoid continuous IGP metric changes causing end-to-end BGP CAR route churn, implementations should provide thresholds to trigger AIGP updates.

Additional AIGP extensions can be defined to signal for specific use cases, such as Maximum SID Depth (MSD) advertised along the BGP CAR route and minimum MTU advertised along the BGP CAR route. This is outside the scope of this document.

2.7. Inherent Multipath Capability​

The (E, C) route definition inherently provides availability of redundant paths at each BGP hop, identical to BGP-LU or BGP-IP. For example, BGP CAR routes originated by two or more egress ABRs in a domain are advertised as multiple paths to ingress ABRs in the domain, where they become equal-cost or primary-backup paths. Failure of an egress ABR is locally detected and handled by ingress ABRs within the domain for faster convergence without needing to propagate the event to upstream nodes for traffic recovery.

BGP ADD-PATH [RFC7911] SHOULD be enabled for BGP CAR to signal multiple next hops through Transport RRs (T-RRs).

2.8. BGP CAR Signaling Through Different Color Domains​

[Color Domain 1   A]-----[B     Color Domain 2     E2]
[C1=low delay      ]     [C2=low delay               ]

Assume a BGP CAR route (E2, C2) is signaled from B to A, two BRs in domain 2 and domain 1 respectively. Assume these two domains do not share the same color-to-intent mapping (i.e., they belong to different color domains). Low-latency in domain 2 is color C2, whereas in domain 1 it is C1 (C1 <> C2).

Extending an underlying transport path (e.g., MPLS LSP) between different color domains is not expected to be a typical scenario. However, the BGP CAR solution seamlessly supports this rare scenario while maintaining separation and independence of administrative authority in different color domains.

The solution is as described below:

  • Within domain 2, the BGP CAR route is (E2, C2) via E2.

  • B signals the BGP CAR route to A as (E2, C2) via B, with a Local Color Mapping Extended Community (LCM-EC) of color C2.

  • A knows the intent-to-color mapping within domain 2 ("low-latency" in domain 2 is C2), as typical coordination exists between operators of peering domains.

  • A maps C2 in the LCM-EC to C1 and signals the received BGP CAR route within domain 1 as (E2, C2) via A, with LCM-EC(C1).

  • Receiving nodes within domain 1 use the local color encoded in the LCM-EC for next hop resolution and service steering.

The following procedures apply at color domain boundaries for BGP CAR routes, executed by routing policy on the sending and receiving peers:

  • Use local policy to control which routes are advertised to or accepted from peers in different color domains.

  • If LCM-EC does not exist in the route, attach LCM-EC. If LCM-EC exists, update the value as needed to remap the color.

    • This capability can be performed by either the advertising BGP speaker or the receiving BGP speaker, as determined by operator peering protocol and indicated by local policy on BGP peers.

These procedures apply to both CAR route types, along with all procedures specified in the preceding sections. LCM-EC is described in Section 2.9.5.

2.9. Format and Encoding​

BGP CAR leverages BGP Multiprotocol Extensions [RFC4760] and uses MP_REACH_NLRI and MP_UNREACH_NLRI attributes for route updates within SAFI value 83, with AFI 1 for IPv4 prefixes and AFI 2 for IPv6 prefixes.

2.9.1. BGP CAR SAFI NLRI Format​

The generic format of BGP CAR SAFI NLRI includes: NLRI Length, Key Length, NLRI Type, Type-Specific Key Fields, and optional Type-Specific Non-Key TLV Fields.

2.9.2. Type-Specific Non-Key TLV Format​

Non-key TLVs include: Label TLV (for MPLS labels), Label-Index TLV (for SR-MPLS), and SRv6 SID TLV (for SRv6 encapsulation).

2.9.3-2.9.4. NLRI Types​

Two NLRI types are defined: Color-Aware Route (E, C) NLRI and IP Prefix (E) NLRI.

2.9.5. Local Color Mapping (LCM) Extended Community​

LCM-EC is used to convey local color mapping when CAR routes cross color domain boundaries.

2.10. LCM-EC and BGP Color-EC Usage​

LCM-EC and BGP Color-EC work together to support route signaling across different color domains and flexible color mapping scenarios.

2.11. Error Handling​

BGP CAR NLRI error handling follows the treat-as-withdraw approach. The presence of the Key Length field makes error handling more resilient.

Note: This document is based on RFC 9871. For the complete official specification with detailed protocol encoding formats, please refer to https://www.rfc-editor.org/rfc/rfc9871.html.

Last updated on