Internet-Draft	draft-haas-idr-bgp-diffract	August 2022
Haas	Expires 20 February 2023	[Page]

Workgroup:: IDR
Internet-Draft:: draft-haas-idr-bgp-diffract-00
Published:: 19 August 2022
Intended Status:: Informational
Expires:: 20 February 2023
Author:: J. Haas

Juniper Networks

Interoperability Procedures for BGP Routes with Color

Abstract

"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.¶

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 20 February 2023.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

▲

1. Introduction

Introductory text¶

1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2. 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.¶

3. Overview

The forwarding behaviors covered by routes for both the BGP-CAR [I-D.dskc-bess-bgp-car] and BGP-CT [I-D.kaliraj-idr-bgp-classful-transport-planes] 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 Section 7.¶

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.¶

Section 6 discusses the general mapping procedures. Section 6.4 discusses mapping BGP-CT routes into BGP-CAR routes. Section 6.6 discusses mapping BGP-CAR routes into BGP-CT routes.¶

4. Color-Aware Routes Protocol Elements

4.1. CAR Protocol Elements Diagrams


   Color-Aware Routes NLRI Type (-car-05, section 2.9.2):

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  NLRI Length  |  Key Length   |   NLRI Type   |Prefix Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               IP Prefix (variable)                           //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Color (4 octets)                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Followed by optional TLVs encoded as below:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Value (variable)          //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Local Color Map (LCM) Extended Community (-car-05, section 2.9.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x3  | Sub-Type=TBD2 |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Color                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2. 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:

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

5. Classful Transport Protocol Elements

5.1. Classful Transport Protocol Elements Diagrams


 Classful Transport NLRI (-ct-17, section 7):

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Length     |                 Label                 |Rsrv |S|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Route Distinguisher (8 bytes)             |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     IPv4/IPv6 Prefix                          ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Transport Class Extended Community (-ct-17, section 4):

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type= 0xa   | SubType= 0x02 |            Reserved           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Transport Class ID                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2. 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:

[RFC8277] Label Stack (NLRI Labels)¶
[RFC8669] Prefix SID (NLRI Labels + Prefix SID Path Attribute)¶
[RFC9252] 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.¶

6. 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 ([RFC4364], 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.¶

6.1. RD-Color Route Distinguisher Format


   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       Type = TBD (2 octets)   |        Color (4 octets)       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Color continued       |   Assigned Number (2 octets)  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             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.¶

6.2. Classful Transport Original RD Extended Community


  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type= 0x03  | SubType= TBD  |        Value (6 octets)       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Value continued                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        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.¶

6.3. Classful Transport Original Intent Extended Community


  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type= 0x0a  | SubType= TBD  |     RESERVED (2 octets)       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Transport Class ID (4 octets)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      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.¶

6.4. 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.¶

6.5. 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.¶

6.6. 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.¶

6.7. 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.¶

7. Mapping Forwarding State

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

For [RFC8277] Label Stacks, the CAR Label TLVs will be carried in the CT NLRI Labels¶
For [RFC8669] Label Index TLVs, an [RFC8669] 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 [RFC9252] SRv6 SIDs, CT does not utilize the transposition scheme documented in [RFC9252], 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.)¶

7.2. Mapping VPN CAR Routes into CT

XXX¶

7.3. 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 [RFC8669] Label Index TLVs, when an [RFC8669] 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 [RFC9252] 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.¶

7.4. Mapping CT Routes into VPN CAR

XXX¶

7.5. 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.¶

8. 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.¶

9. 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.¶

10. Security Considerations

The BGP transport route use cases for "BGP routes with color" largely overlap those for the original BGP Labeled Unicast protocol extension. ([RFC8277]) 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.¶

11. References

11.1. Normative References

[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8277]: Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/info/rfc8277>.
[RFC8669]: Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, A., and H. Gredler, "Segment Routing Prefix Segment Identifier Extensions for BGP", RFC 8669, DOI 10.17487/RFC8669, December 2019, <https://www.rfc-editor.org/info/rfc8669>.
[RFC9252]: Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, July 2022, <https://www.rfc-editor.org/info/rfc9252>.
[I-D.dskc-bess-bgp-car]: Rao, D., Agrawal, S., Filsfils, C., Steinberg, D., Jalil, L., Su, Y., Decraene, B., Guichard, J., Talaulikar, K., Patel, K., Wang, H., and J. Uttaro, "BGP Color-Aware Routing (CAR)", Work in Progress, Internet-Draft, draft-dskc-bess-bgp-car-05, 6 July 2022, <https://www.ietf.org/archive/id/draft-dskc-bess-bgp-car-05.txt>.
[I-D.kaliraj-idr-bgp-classful-transport-planes]: Vairavakkalai, K., Venkataraman, N., Rajagopalan, B., Mishra, G., Khaddam, M., Xu, X., Szarecki, R. J., Gowda, D. J., Yadlapalli, C., and I. Means, "BGP Classful Transport Planes", Work in Progress, Internet-Draft, draft-kaliraj-idr-bgp-classful-transport-planes-17, 30 June 2022, <https://www.ietf.org/archive/id/draft-kaliraj-idr-bgp-classful-transport-planes-17.txt>.

11.2. Informative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC4360]: Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4364]: Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC8402]: Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

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

BGP-CT state:¶


  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Length     |                 Label                 |Rsrv |S|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Route Distinguisher (8 bytes)             |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     IPv4/IPv6 Prefix                          ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 BGP-CT NLRI (AFI=1, SAFI=76)

 Length: 0x98 (152 bits)
 Label:  0x00 0x00 0x64 (100)
 Rsrv:   0x00 (0)
 S:      0x01 (1)
 Route Distinguisher: 0x00 0x01 0xc0 0x00 0x02 0x01 0x00 0x64
                      (Type 1, 192.0.2.1 : 100)
 IPv4/IPv6 Prefix: 0x20 0x0a 0x00 0x00 0x01 (32 / 10.0.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= 0xa   | SubType= 0x02 |            Reserved           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Transport Class ID                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Transport Class Extended Community:

 Type:     0x0a
 SubType:  0x02
 Reserved: 0x00 0x00
 Transport Class ID: 0x00 0x00 0x03 0xe7 (999)

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¶


  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  NLRI Length  |  Key Length   |   NLRI Type   |Prefix Length  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               IP Prefix (variable)                           //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Color (4 octets)                                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 CAR NLRI (AFI=1, SAFI=83):

 NLRI Length:   0x10 (16 octets)
 Key Length:    0x09 (9 octets)
 NLRI Type:     0x01 (Color-Aware Routes NLRI Type)
 Prefix Length: 0x20 (32)
 IP Prefix:     0x0a 0x00 0x00 0x01 (10.0.0.1)
 Color:         0x00 0x00 0x03 0xe7 (999)


 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |    Value (variable)          //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Label TLV:

 Type:   0x01 (Label TLV)
 Length: 0x03 (3)
 Label:  0x00 0x00 0x64 (100)

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type= 0x0a  | SubType= TBD  |     RESERVED (2 octets)       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Transport Class ID (4 octets)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Classful Transport Original Intent Extended Community:

 Type: 0x0a
 SubType: TBD
 RESERVED: 0x00 0x000
 Transport Class ID: 0x00 0x00 0x03 0xe7 (999)

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type= 0x03  | SubType= TBD  |        Value (6 octets)       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Value continued                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Classful Transport Original RD Extended Community:

 Type:    0x03
 SubType: TBD
 Value:   0x00 0x01 0xc0 0x00 0x02 0x01 0x00 0x64
          (Type 1, 192.0.2.1 : 100)

C.2. 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¶


  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  NLRI Length  |  Key Length   |   NLRI Type   |Prefix Length  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               IP Prefix (variable)                           //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Color (4 octets)                                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 CAR NLRI (AFI=1, SAFI=83):

 NLRI Length:   0x10 (16 octets)
 Key Length:    0x09 (9 octets)
 NLRI Type:     0x01 (Color-Aware Routes NLRI Type)
 Prefix Length: 0x20 (32)
 IP Prefix:     0x0a 0x00 0x00 0x01 (10.0.0.1)
 Color:         0x00 0x00 0x03 0xe7 (999)


 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |    Value (variable)          //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Label TLV:

 Type:   0x01 (Label TLV)
 Length: 0x03 (3)
 Label:  0x00 0x00 0x64 (100)

Output:¶

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

BGP-CT state:¶


  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Length     |                 Label                 |Rsrv |S|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Route Distinguisher (8 bytes)             |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     IPv4/IPv6 Prefix                          ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 BGP-CT NLRI (AFI=1, SAFI=76)

 Length: 0x98 (152 bits)
 Label:  0x00 0x00 0x64 (100)
 Rsrv:   0x00 (0)
 S:      0x01 (1)
 Route Distinguisher: 0xTBD 0xTBD 0x00 0x00 0x03 0xe7 0x00 0x00
                      (Type TBD - RD-Color, 999:0)
 IPv4/IPv6 Prefix: 0x20 0x0a 0x00 0x00 0x01 (32 / 10.0.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= 0xa   | SubType= 0x02 |            Reserved           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Transport Class ID                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Transport Class Extended Community:

 Type:     0x0a
 SubType:  0x02
 Reserved: 0x00 0x00
 Transport Class ID: 0x00 0x00 0x03 0xe7 (999)

Author's Address

Jeffrey Haas

Juniper Networks

1133 Innovation Way

Sunnyvale, CA 94089

United States of America

Email: jhaas@juniper.net

Document	Document type	Expired Internet-Draft (idr WG) Expired & archived
	Select version	00
	Author	Jeffrey Haas Email authors
	RFC stream
	Intended RFC status	(None)
	Other formats	txt html xml pdf bibtex bibxml
	Additional resources	Mailing list discussion