Interoperability Procedures for BGP Routes with Color

Interoperability Procedures for BGP Routes with Color Juniper Networks

1133 Innovation Way Sunnyvale CA 94089 US jhaas@juniper.net

Routing IDR bgp "BGP Routes with Color" have become a topic of interest in the IDR Working Group. The authors of the various proposals have many things in mind to solve with them, how a color might be used, and the operational model for their solution. In general, the solutions share some core properties: Routes for an IP endpoint, that have a domain-wide semantic element to differentiate forwarding (often called a color), and appropriate state to enable that differentiated forwarding. Examples of the technologies enabling differentiated forwarding include MPLS and Segment Routing. This document examines two of the current proposals - BGP Color-Aware Routing, and BGP Classful Transport - and proposes mechanisms to permit them to interoperate.

Introduction Introductory text

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

Color:: A value, typically a 32 bit unsigned integer, associated with a forwarding behavior. In -CT, analogous to a Transport-Class.
Color Domain:: One or more networks managed by a given entity wherein the color values have a specific defined forwarding behavior. Primarily used to contrast between scenarios where the same color's value may carry a different forwarding behavior.
Effective Color:: When more than one protocol element for a BGP route can contain a property that gives the route a color, the Effective Color is what color the route is for purposes of route resolution within the procedures for that protocol extension.
Endpoint:: Terminal address for a route with color; typically a loopback.
Forwarding behavior:: Transport of IP or other traffic to an endpoint with specific properties that may include quality of service, steering over specific paths, latency properties, encapsulation, etc.
NLRI key: Properties of the BGP route with color's BGP NLRI that are used in BGP's Decision Process.
Resolution key: Properties of the BGP route with color that contribute to route resolution. This is typically resolving a given Endpoint for a specific Effective Color. This differentiates that even though the NLRI key may stay the same, the resolution key may change. See, for example, the Local-Color-Mapping mechanism for BGP-CAR.

Overview The forwarding behaviors covered by routes for both the BGP-CAR and BGP-CT proposals can largely be mapped from one mechanism to the other mechanism. BGP-CT utilizes encodings used in existing RFCs for the cited features typically for BGP Labeled-Unicast routes. BGP-CAR provides optimizations against those RFCs to attempt to enable better NLRI packing within a BGP Update message. BGP-CAR expects to carry portions of its forwarding behavior in non-key NLRI fields. The procedures for mapping forwarding state from one mechanism to another is covered in . BGP NLRI carry reachability that is expected to be exchanged across Autonomous Systems with consistent semantics for route selection. A core differentiation between BGP-CAR and BGP-CT is what contents are carried in their NLRI keys, and operationally how this is intended to be used for distributing routes with color. BGP-CAR expects to distribute NLRI keys for a given end-point for a given color. BGP-CT expects to distribute NLRI keys for a given end-point carrying a Route Distinguisher. If it is desired to pass routes from one mechanism into another mechanism, it is necessary to provide a mapping mechanism. This document introduces the idea of the "CAR-mapped-CT" route and the "CT-mapped-CAR" route wherein a BGP route of the appropriate AFI/SAFI carries the state of the other route in such a way that it can be locally utilized. It also provides procedures for "unmapping" such mapped routes to restore them to their native AFI/SAFI when re-entering the native domain. discusses the general mapping procedures. discusses mapping BGP-CT routes into BGP-CAR routes. discusses mapping BGP-CAR routes into BGP-CT routes.

Color-Aware Routes Protocol Elements

CAR Protocol Elements Diagrams

CAR Protocol Elements

NLRI Key:

(IP Prefix, Color)

Endpoint:

IP Prefix

Effective Color:

Color from NLRI, or LCM Color when LCM is present. The default scenario for CAR is that the color is carried in the NLRI and only set in the LCM in multi-color-domain scenarios.

Resolution Key:

(BGP Nexthop, Effective Color)

Forwarding:

Label Stack (optional TLV type 1)
SR-MPLS Label Index (optional TLV type 2, possibly with Prefix-SID)
SRv6 SIDs either single or multiple full-length SRv6 SIDs or transposition SIDs (optional TLV type 3 plus Prefix SID)

Classful Transport Protocol Elements

Classful Transport Protocol Elements Diagrams

Classful Transport Protocol Elements

NLRI Key:

(Route Distinguisher, IPv4/IPv6 Prefix)

Endpoint:

IPv4/IPv6 Prefix

Effective Color:

Transport Class ID

Resolution Key:

(BGP Nexthop, Effective Color)

Forwarding:

Label Stack (NLRI Labels)
Prefix SID (NLRI Labels + Prefix SID Path Attribute)
SRv6 SIDs, excluding transposition procedures. The Label field MAY contain a locally assigned label corresponding to the SRv6 forwarding, or may contain the distinguished value (XXX) indicating that no local label binding is in effect.

Mapping NLRI keys: CAR Color, CT Route Distinguisher To carry routes from one protocol across BGP Speakers using the other protocol, NLRI key mapping operations must be carried out consistently. Mapped NLRI keys MUST be able to be "unmapped" to the original native NLRI key. This, along with preserving BGP route loop prevention mechanisms, permits consistent route selection across deployments. The NLRI key elements for both CAR and CT include the IP Prefix for the endpoint. However, each protocol differs on the additional key carried in the NLRI to identify the route and its forwarding behavior. For CAR, the additional key is the Color of the route, and the original intent for that route. In the absence of the Local Color Map (LCM) Extended Community, this Color is also the route's Effective Color. For CT, the additional key is a Route Distinguisher with similar semantics to those used in BGP VPNs (, and others). It serves two purposes: Providing administrative information about the source of the route with a set of cooperating networks; providing the ability to allow the same endpoint to be originated from the same BGP Speaker with differing forwarding behaviors that are to be preserved end-to-end within the cooperating networks. CT doesn't encode any information about the route's Color or intent in the NLRI. The procedures below describe CAR-mapped-CT routes and CT-mapped-CAR routes. New BGP protocol elements are defined to provide these mapping capabilities.

RD-Color Route Distinguisher Format To carry the CAR Color NLRI key element in a CT-mapped-CAR route, this document create the RD-Color Route Distinguisher. Its Type is TBD and should be assigned from IANA's Route Distinguisher Type Field registry from the IETF Review range. The format of the RD-Color Route Distinguisher is a four-octet Administrator subfield containing the Color, followed by a two-octet Assigned Number subfield.

Classful Transport Original RD Extended Community To permit CAR-mapped-CT routes to restore the original Route Distinguisher during unmapping, it is necessary to carry the original Route Distinguisher in the route CAR-mapped-CT route. To do so, a new BGP Extended Community is defined: the Classful Transport Original RD (CTORD) Extended Community. The Classful Transport Original RD Extended Community should be allocated from the Transitive Opaque Extended Community Sub-Types registry (Type 0x03) with a sub-type TBD. Its value field will contain the CT Route Distinguisher that is to be carried in the CAR-mapped-CT route.

Classful Transport Original Intent Extended Community To permit retention of the "original intent" for the CT route's Transport Color when carried in a CAR-mapped-CT route and CAR procedural purposes, a new Extended Community is defined: The Classful Transport Original Intent (CTOI) Extended Community. This Extended Community should be allocated from the Transport Class Extended Communities Sub-Types registry (Type 0x0a) with a sub-type TBD. Its contents will be identical to the Transport Class Extended Community defined in -ct, Section 4: Two octets of RESERVED field, four octets for Transport Class ID.

CAR-mapped-CT mapping procedures The need to be able to consistently map a CAR Color to a CT Route Distinguisher provides a challenge to the CT operational model. Since the originating router for the CAR route is not carried as part the CAR protocol procedures, there isn't clear information that could be utilized to consistently populate the Route Distinguisher. If no Classful Transport Original Intent Extended Community exists, the CT route's Transport Class ID is added to a newly created CTOI Extended Community, and this value is used for the CAR-mapped-CT route's Color NLRI key. If a CTOI Extended Community is already present in the CAR route, indicating that this route has been previously been mapped and then unmapped, the value from that CTOI Extended Community is used for the CAR-mapped-CT route's Color NLRI key. The CT route's Route Distinguisher is carried in the Classful Transport Original RD Extended Community in the newly created CAR-mapped-CT route.

CAR-mapped-CT unmapping procedures The CT route's Route Distinguisher is set from the Classful Transport Original RD Extended Community. This Extended Community is then deleted. The CT route's Transport Class Transport Class ID Extended Community value is set to the value from the CAR-mapped-CT route's RD-Color Administrator subfield. The CT route's Classful Transport Original Intent Community is retained from the CAR-mapped-CT route. This permits consistent CAR-mapped-CT NLRI Color mapping in the event of further redistribution between CT and CAR domains.

CT-mapped-CAR mapping procedures The CT-mapped-CAR's Route Distinguisher uses the RD-Color format and contains the CAR route's NLRI Color in the Administrator field. It is RECOMMENDED that the RD-Color Assigned number subfield is set to zero. If a CAR Local-Color-Mapping (LCM) Extended Community is present on the CAR route, that community's Color value is the Effective Color of the CAR route. Otherwise, the Effective Color is the value of the NLRI's Color field. The LCM Extended Community deleted, if present. A Transport Class Extended Community is set on the CT-mapped-CAR's route with the Transport Class ID being assigned the Effective Color, determined above.

CT-mapped-CAR unmapping procedures The CAR route's NLRI Color field is set from the RD-Color Administrator subfield. If the Transport Class ID for the CT-mapped-CAR route is different from the value used for the NLRI Color, above, a Local-Color-Mapping Extended Community is added to the CAR route using the Transport Class ID value. The Transport Class Extended Community is deleted.

Mapping Forwarding State

Mapping CAR Route Forwarding State into CT-mapped-CAR routes

For Label Stacks, the CAR Label TLVs will be carried in the CT NLRI Labels
For Label Index TLVs, an Prefix-SID is created with the Label Index set to the value from the CAR optional NLRI's Label Index and the Flags are similarly copied. If the CAR route contains a Prefix-SID SRGB, it is similarly copied. The CT Label MAY be initialized with the value of the label derived from the Prefix SID, but this is a local matter.
For SRv6 SIDs, CT does not utilize the transposition scheme documented in , Section 4. Instead, the whole SRv6 SID should be encoded in the SRv6 Service Data Sub-Sub-TLV. (Transposition length 0.) The CT Label MAY carry a locally assigned label covering this forwarding state, however it may also carry the distinguished label (XXX) indicating that no label mapping has been assigned. (XXX needs ref in updated CT doc.)

Mapping VPN CAR Routes into CT XXX

Mapping CT Route Forwarding State into CAR-mapped-CT routes

For the simple label stack scenario for CT (no Prefix-SID Path Attribute), the CT Label Stack is carried in the Type 1 Label TLV. (-car, Section 2.9.2.1).
For Label Index TLVs, when an Prefix-SID Path Attribute excluding the SRv6 Service TLVs is present, the Prefix-SID Path Attribute, if present, MAY be copied if the SRGB is identical to local configuration. The CAR Type 2 Label Index TLV (-car, Section 2.9.2.2) is initialized with the contents of the CT Prefix-SID's Label-Index TLV.
For SRv6 SIDs, the CAR Type 3 SRv6 SID TLV (-car, Section 2.9.2.3) is initialized from the CT's SRv6 SIDs carried in the Prefix-SID Path Attribute. The transposition scheme encoding SHOULD be used, when possible.

Mapping CT Routes into VPN CAR XXX

Miscellany The CAR type specific non-key transitivity field is not directly mapped into CT routes. The CAR type specific non-key fields currently specify a set of forwarding behaviors. The handling of all combinations of forwarding behaviors for currently specified types is not fully described in the latest CAR document.

BGP Decision Process and Route Resolution Considerations The sections above describe how BGP routes with color can be mapped from one form to the other form. BGP implementations that implement both mechanisms can receive routes from both. The purpose of the mapping mechanisms above is to attempt to preserve route comparability across mapped NLRI. The core desired behavior for these mechanisms is to permit BGP service routes that have a color mapping mechanism to resolve their BGP Nexthops over endpoints for that color. In particular, both mechanisms perform a longest-match lookup for the Endpoint over the resolution state for a particular color. These resolution mechanisms may implement specific fall-back procedures. However, a given deployment of one or both of these mechanisms will desire consistent route selection and nexthop resolution regardless of the source of the resolving state. On BGP Speakers participating in both mechanisms, operators SHOULD chose one of the two mechanisms to generate the BGP route resolution state for those protocols. The mapping mechanisms permit BGP routes received across the different mechanisms to be able to tie-break in a single RIB according to the properties of the routes within that RIB. The choice of the mapping mechanism would likely be based on the desired overall deployment model for routes with color and the underlying comparability of the routes as they are distributed across the cooperating networks. The chosen RIB on that BGP Speaker would then be used to create the route resolution state for BGP routes with color for that device.

IANA Considerations IANA is requested to allocate a Route Distinguisher from the Route Distinguisher Type Field registry from the IETF Review range. The Description should be "RD-Color, Administrator field is a four-byte Color, Assigned value field is a two-byte integer". The reference should be this document. IANA is requested to allocate a BGP Extended Community from the Transitive Opaque Extended Community Sub-Types registry. Its name will be "Classful Transport Original RD". The reference should be this document. IANA is requested to allocate a BGP Extended Community from the Transport Class Extended Communities Sub-Types registry. Its Name will be "Classful Transport Original RD". The reference should be this document.

Security Considerations The BGP transport route use cases for "BGP routes with color" largely overlap those for the original BGP Labeled Unicast protocol extension. () Such routes are traditionally only accepted from trusted BGP Speakers that exist within a BGP transport domain. This document defines procedures for BGP Speakers implementing both the BGP-CAR and BGP-CT address families to mutually exchange routing information. Some of these procedures utilize BGP Extended Communities. Care should be taken to not accept routes with Extended Communities with mapping semantics from parties not eligible to participate in these procedures. Such care may include filtering, or discarding reachability with such Extened Communities from unauthorized parties.

References Normative References Informative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

Acknowledgements TBD

Contributors TBD

Example NLRI Mapping

Mapping a BGP-CT route into BGP-CAR Input:

Route Distinguisher 192.0.2.1:100
Endpoint: 10.0.0.1/32
Label: 100
Color: 999

BGP-CT state: Output:

NLRI Type: 1
Prefix Length: 32
IP Prefix: 10.0.0.1
Color: 999
Label TLV:
- Type: 1
- Length: 3
- Value: 100
CTOI Extended Community: 999
CTORD Extended Community: 192.0.2.1:100

Mapping a BGP-CAR route into BGP-CT Input:

NLRI Type: 1
Prefix Length: 32
IP Prefix: 10.0.0.1
Color: 999
Label TLV:
- Type: 1
- Length: 3
- Value: 100

Output:

Route Distinguisher 192.0.2.1:100
Endpoint: 10.0.0.1/32
Label: 100
Color: 999

BGP-CT state: