BGP Classful Transport Planes

2.1. Definitions

Intent: A set of operational goals (that a network should meet) and outcomes (that a network is supposed to deliver) defined in a declarative manner without specifying how to achieve or implement them, as defined in Section 2 of [RFC9315].¶

Service Family: A BGP address family used for advertising routes for "data traffic" as opposed to tunnels (e.g. AFI/SAFIs 1/1 or 1/128).¶

Transport Family: A BGP address family used for advertising tunnels, which are in turn used by service routes for resolution (e.g. AFI/SAFIs 1/4 or 1/76).¶

Transport Tunnel : A tunnel over which a service may place traffic. Such a tunnel can be provisioned or signaled using a variety of means (e.g., Generic Routing Encapsulation (GRE), UDP, LDP, RSVP-TE, IGP FLEX-ALGO or SRTE).¶

Tunnel Ingress Route: A Route to Tunnel Destination/Endpoint that is installed at the headend (ingress) of the tunnel using a tunneling mechanism.¶

Tunnel Domain: A domain of the network containing Service Nodes (SNs) and Border Nodes (BNs) under a single administrative control that has tunnels between them. An end-to-end tunnel spanning several adjacent tunnel domains can be created by "stitching" them together using MPLS labels (or an equivalent identifier based on the forwarding architecture).¶

Transport Class: A construct to group transport tunnels offering the same SLA.¶

Transport Class RT: A Route Target Extended Community used to identify a specific Transport Class.¶

Transport Route Database (TRDB): At the SN and BN, a Transport Class has an associated Transport Route Database that collects its tunnel ingress routes.¶

Resolution Scheme: A construct comprising of an ordered set of TRDBs to resolve next hop reachability, for realizing a desired intent.¶

Mapping Community: Any BGP Community/Extended Community on a BGP route that maps to a Resolution Scheme. e.g., color:0:100, transport-target:0:100.¶

Transport Plane: An end-to-end plane consisting of transport tunnels belonging to the same Transport Class. Tunnels of the same Transport Class are stitched together by BGP CT route readvertisements with next hop self to enable Label-Swap forwarding across domain boundaries.¶

7.1. Preparing the network to deploy Classful Transport planes

• It is responsibility of the operators to decide the Transport Classes to enable and use in their network. They are also expected to allocate a Transport Class Route Target to identify each Transport Class.¶
• Operators configure the Transport Classes on the SNs and BNs in the network with Transport Class Route Targets and unique Route-Distinguishers.¶
• Implementations MAY provide automatic generation and assignment of RD, RT values; they MAY also provide a way to manually override the automatic mechanism in order to deal with any conflicts that may arise with existing RD, RT values in different network domains participating in the deployment.¶

7.2. Originating Classful Transport Routes

• BGP CT routes are sent only to BGP peers that have negotiated the Multiprotocol Extensions capability described in Section 8 of [RFC4760] to be able to send and receive BGP CT routes.¶
• At the ingress node of the tunnel's home domain, the tunneling protocols install tunnel ingress routes in the TRDB associated with the Transport Class to which the tunnel belongs.¶
• The egress node of the tunnel i.e. the tunnel endpoint originates the BGP Classful Transport route with NLRI containing RD:TunnelEndpoint, Transport Class RT and PNH TunnelEndpoint, which will be resolved over the tunnel route in TRDB at the ingress node. When the tunnel is up, the Classful Transport BGP route will become usable and get re-advertised by the ingress node to BGP peers in neighboring domains.¶
• Alternatively, the ingress node may advertise this tunnel destination into BGP as a Classful Transport family route with NLRI RD:TunnelEndpoint, attaching a Transport Class Route Target that identifies the Transport Class. This BGP CT route is advertised to EBGP peers and IBGP peers in neighboring domains.¶
• This route SHOULD NOT be advertised to the IBGP core that contains the tunnel, using policy configuration. Impact of not prohibiting such advertisements is outside the scope of this document.¶
• Unique RD SHOULD be used by the originator of a Classful Transport route to disambiguate the multiple BGP advertisements for a transport endpoint. An administrator may use duplicate RDs based on local choice, understanding the impact on path diversity and troubleshooting, as described in Section 10.2.¶

7.3. Processing Classful Transport Routes by Ingress Nodes

• Upon receipt of a BGP Classful Transport route with a PNH that is not directly connected (e.g. an IBGP-route), a Mapping Community on the route (the Transport Class RT) is used to decide to which resolution scheme this route is to be mapped. The resolution scheme for a Transport Class RT with Transport Class ID "C1" contains TRDB for Transport Class with same ID. In cases where Transport Class "C1" tunnels are not available in a domain, the administrator MAY customize the resolution scheme to map to a different set of transport classes available in that domain.¶
• The routes in the associated TRDBs are used to resolve the received PNH. The order of TRDBs in a resolution scheme is followed when resolving the received PNH, such that a route in backup TRDB is used only when a matching route was not found in the primary TRDBs preceding it. This achieves the fallback desired by the resolution scheme.¶
• If the resolution process does not find a matching route in any of the associated TRDBs, the received BGP CT route MUST be considered unusable for forwarding purpose and be withdrawn.¶
• The received BGP CT route MUST be added to the TRDB corresponding to the Transport Class "C1". So that service routes can resolve over this BGP CT ingress route. RD is stripped by the ingress node from the BGP CT NLRI prefix when a BGP CT route is added to a TRDB. This step does not apply if the Transport Class RT is received on a route in BGP address family that does not have SAFI 76.¶

7.4. Readvertising Classful Transport Route by Border Nodes with Next Hop Self

• BNs allocate an MPLS label to advertise upstream in Classful Transport NLRI. A BN also installs an MPLS route for that label that swaps the incoming label with a label received from the downstream BGP speaker or pops the incoming label. It then pushes received traffic to the transport tunnel or direct interface that the Classful Transport route's PNH resolved over.¶
• The label SHOULD be allocated with "per-prefix" label allocation semantics. The IP prefix in the TRDB context (Transport-Class, IP-prefix) is used as the key to do per-prefix label allocation. This helps in avoiding BGP CT route churn throughout the CT network when an instability (e.g. link failure) is experienced in a domain. The failure is not propagated further than the BN closest to the failure. If a different label allocation mode is used, impact on end to end convergence should be considered.¶
• The value of the advertised MPLS label is locally significant, and is dynamic by default. A BN may provide an option to allocate a value from a statically carved out range. This can be achieved using locally configured export policy, or via mechanisms such as the ones described in BGP Prefix-SID [RFC8669].¶

7.5. Border Nodes Receiving Classful Transport Routes on EBGP

• If a route is received with PNH that is known to be directly connected (e.g. EBGP single-hop neighbor address), the directly connected interface is checked for MPLS forwarding capability. No other next hop resolution process is performed, as the inter-AS link can be used for any Transport Class.¶
• If the inter-AS links need to honor Transport Class, then the BN MUST follow procedures of an Ingress node described previously and perform next hop resolution process. In order to make the link Transport Class aware, the route to directly connected PNH is installed in the TRDB belonging to the associated Transport Class.¶

7.6. Avoiding Path Hiding Through Route Reflectors

• When multiple BNs exist such that they advertise a "RD:EP" prefix to Route Reflectors (RRs), the RRs may hide all but one of the BNs, unless ADDPATH [RFC7911] is used for the Classful Transport family. This is similar to L3VPN Option B scenarios. Hence, ADDPATH SHOULD be used for Classful Transport family, to avoid path-hiding through RRs. This improves convergence time when path via one of the multiple BNs fails.¶

7.7. Avoiding Loops Between Route Reflectors in Forwarding Path

• A pair of redundant ABRs, each acting as an RR with next hop self, may choose each other as best path instead of the upstream ASBR, causing a traffic forwarding loop. This happens because of following the path selection rule specified in Section 9 of BGP RR [RFC4456] that tie-breaks on ORIGINATOR_ID before CLUSTER_LIST. RFC4456 considers pure RR which is not in forwarding path. When a RR is in forwarding path and reflects routes with next hop self, as is the case for ABR BNs in a BGP transport network, this rule may cause loops.¶
• Using one or more of the following approaches softens the possibility of such loops in a network with redundant ABRs.¶

7.8. Ingress Nodes Receiving Service Routes with a Mapping Community

• Upon receipt of a BGP service route with a PNH that is not directly connected (e.g. an IBGP-route), a Mapping Community on the route (e.g, Color Extended Community) is used to decide to which resolution scheme this route is to be mapped. The resolution scheme for a Color Extended Community with Color "C1" contains TRDB for Transport Class with same ID, followed by Best Effort TRDB. The administrator MAY customize the resolution scheme to map to a different ordered list of TRDBs.¶
• The routes in the associated TRDBs are used to resolve the received PNH. The order of TRDBs in a resolution scheme is followed when resolving the received PNH, such that a route in backup TRDB is used only when a matching route was not found in the primary TRDBs preceding it. This achieves the fallback desired by the resolution scheme.¶
• If the resolution process does not find a Tunnel Ingress Route in any of the Transport Route Databases, the service route MUST be considered unusable for forwarding purpose and be withdrawn.¶

Note: For an illustration of above procedures in a MPLS network, refer to Section 8.¶

7.9. Best Effort Transport Class

• It is possible to represent 'Best effort' SLA also as a Transport Class. Today, BGP LU (e.g. AFI/SAFI 1/4) is used to extend the best effort intra domain tunnels to other domains.¶
• Alternatively, BGP CT (e.g. AFI/SAFI 1/76) may be used to carry the best effort tunnels also. This document reserves the Transport Class ID value 0 to represent "Best Effort Transport Class ID". However, implementations SHOULD provide configuration to use a different value for this purpose. Procedures to manage differences in Transport Class ID namespaces between domains are provided in Section 11.2.2.¶
• The 'Best Effort Transport Class ID' value is used in the 'Transport Class ID' field of Transport Route Target Extended Community that is attached to the BGP CT route that advertises a best effort tunnel endpoint. The RT thus formed is called the "Best Effort Transport Class Route Target".¶
• When a BN or SN receives a BGP CT route with Best Effort Transport Class Route Target as the mapping community, the Best effort resolution scheme is used for resolving the BGP next hop, and the resultant route is installed in the best effort transport route database. If no best effort tunnel was found to resolve the BGP next hop, the BGP CT route MUST be considered unusable, and not be propagated further.¶
• When a BGP speaker receives an overlay route without any explicit Mapping Community, and absent local policy, the best effort resolution scheme is used for resolving the BGP next hop on the route. This behavior is backward compatible to behavior of an implementation that does not follow procedures described in this document.¶
• Implementations MAY provide configuration to selectively install BGP CT routes to the Forwarding Information Base (FIB), to provide reachability for control plane peering towards endpoints in other domains.¶

7.10. Interaction with BGP Attributes Specifying Next Hop Address and Color

The Tunnel Encapsulation Attribute, described in [RFC9012] can be used to request a specific type of tunnel encapsulation. This attribute may apply to BGP service routes or transport routes, including BGP Classful Transport family routes.¶

The mechanisms described in BGP MultiNexthop Attribute [MULTI-NH-ATTR] allow a BGP route to carry multiple next hop addresses. Specifying 'Transport Class ID' as a qualifier for each next hop address is also allowed.¶

It should be noted that in such cases "Transport Class/Color" can exist in multiple places on the same route, and a precedence order needs to be established to determine which Transport Class the route's next hop should resolve over. This document suggests the following order of precedence, more specific scoping of Color preferred to less specific scoping:¶

• Transport Class ID SubTLV, in MultiNexthop Attribute.¶
• Color SubTLV, in Tunnel Encapsulation Attribute.¶
• Transport Target Extended community, on BGP CT route.¶
• Color Extended community, on BGP service route.¶

Transport Class ID specified for Nexthop-Leg subTLV in a MultiNextHop attribute is a more specific indication of Color than Color subTLV in a TEA, which in turn is more specific than Mapping Community (Transport Target) on a BGP CT transport route, which is in turn more specific than a Service route scoped Mapping Community (Color Extended community).¶

7.11. Applicability to Flowspec Redirect to IP

Flowspec routes using Redirect to IP next hop is described in [FLOWSPEC-REDIR-IP]¶

Such Flowspec BGP routes with Redirect to IP next hop MAY be attached with a Mapping Community (e.g. Color:0:100), which allows redirecting the flow traffic over a tunnel to the IP next hop satisfying the desired SLA (e.g. Transport Class color 100).¶

Flowspec BGP family acts as just another service that can make use of BGP CT architecture to achieve Flow based forwarding with SLAs.¶

7.12. Applicability to IPv6

This section describes applicability of BGP CT to IPv6 at various layers. BGP CT procedures apply equally to an IPv6 enabled Intra-AS or Inter-AS Option A, B, C network.¶

A BGP CT enabled network supports IPv6 service families (e.g., AFI/SAFI 2/1 or 2/128) and IPv6 transport signaling protocols like SRTEv6, LDPv6, RSVP-TEv6.¶

Procedures in this document also apply to a network with Pure IPv6 core, that uses MPLS forwarding for intra-domain tunnels and inter-AS links. BGP CTv6 family (AFI/SAFI: 2/76) is used to carry global IPv6 address tunnel endpoints in the NLRI. Service family routes (e.g. AFI/SAFI: 1/1, 2/1, 1/128, 2/128) are also advertised with those Global IPv6 addresses as next hop.¶

Procedures in this document also apply to a 6PE network with an IPv4 core, that uses MPLS forwarding for intra-domain tunnels and Inter-AS links. BGP CTv6 family (AFI/SAFI: 2/76) is used to carry IPv4 Mapped IPv6 address tunnel endpoints in the NLRI. IPv6 Service family routes (e.g., AFI/SAFI: 2/1, 2/128) are also advertised with those IPv4 Mapped IPv6 addresses as next hop.¶

The PE-CE attachment circuits may use IPv4 addresses only, IPv6 addresses only, or both IPv4 and IPv6 addresses.¶

9.2. Constrained Distribution of PNHs to SNs (On-Demand Next Hop)

• This section describes how the number of Protocol Next hops advertised to a SN or BN can be constrained using BGP Classful Transport and Route Target Constraints (RTC) [RFC4684].¶
• An egress SN MAY advertise a BGP CT route for RD:eSN with two Route Targets: transport-target:0:<TC> and a RT carrying <eSN>:<TC>, where TC is the Transport Class identifier, and eSN is the IP address used by SN as BGP next hop in its service route advertisements.¶
• Note that such use of the IP address specific route target <eSN>:<TC> is optional in a BGP CT network. It is required only if there is a requirement to prune the propagation of the transport route for an egress node eSN to only the set of ingress nodes that need it. When only RT of transport-target:0:<TC> is used, the pruning happens in granularity of Transport Class ID (Color), and not BGP next hop; BGP CT routes will not be advertised into domains with PEs that don't import its transport class.¶
• The transport-target:0:<TC> is the new type of route target (Transport Class RT) defined in this document. It is carried in BGP extended community attribute (BGP attribute code 16).¶
• The RT carrying <eSN>:<TC> MAY be an IP-address specific regular RT (BGP attribute code 16), IPv6-address specific RT (BGP attribute code 25), or a Wide-communities based RT (BGP attribute code 34) as described in Route Target Constrain Extension [RTC-Ext]. This document recommends using Wide-communities based RT for the same.¶
• An ingress SN MAY import BGP CT routes with Route Target carrying <eSN>:<TC>. The ingress SN may learn the eSN values either by configuration, or it may discover them from the BGP next hop field in the BGP VPN service routes received from eSN. A BGP ingress SN receiving a BGP service route with next hop of eSN generates a RTC/Extended-RTC route for Route Target prefix <Origin ASN>:<eSN>/[80|176] in order to learn BGP CT transport routes to reach eSN. This allows constrained distribution of the transport routes to the PNHs actually required by iSN.¶
• When the path of route propagation of BGP CT routes is the same as the RTC routes, a BN would learn the RTC routes advertised by ingress SNs and propagate further. This will allow constraining distribution of BGP CT routes for a PNH to only the necessary BNs in the network, closer to the egress SN.¶
• This mechanism provides "On Demand Next hop" of BGP CT routes, which help with the scaling of MPLS forwarding state at SN and BN.¶
• However, the amount of state carried in RTC family may become proportional to the number of PNHs in the network. To strike a balance, the RTC route advertisements for <Origin ASN>:<eSN>/[80|176] MAY be confined to the BNs in the home region of an ingress SN, or the BNs of a super core.¶
• Such a BN in the core of the network imports BGP CT routes with Transport-Target:0:<TC> and generates an RTC route for <Origin ASN>:0:<TC>/96, while not propagating the more specific RTC requests for specific PNHs. This lets the BN learn transport routes to all eSN nodes but confine their propagation to ingress SNs.¶

9.3. Limiting The Visibility Scope of PE Loopback as PNHs

• It may be even more desirable to limit the number of PNHs that are globally visible in the network. This is possible using mechanism described in Appendix D¶
• Such that advertisement of PE loopback addresses as next-hop in BGP service routes is confined to the region they belong to. An anycast IP-address called "Context Protocol Nexthop Address" (CPNH, Appendix D.3) abstracts the SNs in a region from other regions in the network, swapping the SN scoped service label with a CPNH scoped private namespace label.¶
• This provides much greater advantage in terms of scaling, convergence and security. Changes to implement this feature are required only on the local region's BNs and RRs.¶

11.1. Coordination Between Domains Using Different Community Namespaces

Cooperating Inter-AS Option C domains may sometimes not agree on RT, RD, Mapping community or Transport Route Target values because of differences in community namespaces (e.g. during network mergers or renumbering for expansion). Such deployments may deploy mechanisms to map and rewrite the Route Target values on domain boundaries, using per ASBR import policies. This is no different than any other BGP VPN family. Mechanisms used in inter-AS VPN deployments may be leveraged with the Classful Transport family also.¶

A resolution scheme allows association with multiple Mapping Communities. This minimizes service disruption during renumbering, network merger or transition scenarios.¶

The Transport Class Route Target Extended Community is useful to avoid collision with regular Route Target namespace used by service routes.¶

11.2. Managing Intent at Service and Transport layers.

Illustration of BGP CT Procedures (Section 8) shows multiple domains that agree on a color name space (Agreeing Color Domains) and contain tunnels with equivalent sets of colors (Homogenous Color Domains).¶

However, in the real world, this may not always be guaranteed. Two domains may independently manage their color namespaces; these are known as Non-Agreeing Color Domains. Two domains may have tunnels with unequal sets of colors; these are known as Heterogeneous Color Domains.¶

This section describes how BGP CT is deployed in such scenarios to preserve end-to-end Intent. Examples described in this section use Inter-AS Option C domains. But similar mechanisms will work for Inter-AS Option A and Inter-AS Option B scenarios as well.¶

          Gold(100)              Gold(300)               Gold(500)


     [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31-------[PE31]
            AS1                     AS2                    AS3


          Bronze(200)          Bronze(400)             Bronze(600)

            ----------- Packet Forwarding Direction -------->

           <---------- Service Routes AFI/SAFI 1/128 ------------------------

                                     Gold1(101)
                                     Gold2(102)
          Gold(100)                                             Gold(100)

    [PE11]------[ASBR11]----[ASBR21--------[ASBR22]----[ASBR31--------[PE31]
       AS1-Metro-Ingress            AS2-Core              AS3-Metro-Egress


                ----------- Packet Forwarding Direction -------->

11.3. Migration Scenarios.

              +----------EBGP Multihop CT-------------+
              |                                       |
        AS3   |                   AS2                 |   AS1
  [PE31-----ASBR31]--------[ASBR22---ASBR21]-------[ASBR11---PE11]

                 <-EBGP LU->              <-EBGP LU->
   <---IBGP CT--->          <---IBGP LU--->        <---IBGP CT--->

            ---------Packet Forwarding Direction--------->

                      RR1--+
                             \  +-------R2  [MPLS + SRv6]
                              \ |
                      R1--------P-------R3  [MPLS only]
                [MPLS + SRv6]   |
                                +-------R4  [SRv6 only]

                  <---- Bidirectional Traffic ---->

                      RR1--+
                             \  +-------R2  [MPLS + UDP]
                              \ |
                      R1--------P-------R3  [MPLS only]
                [MPLS + UDP]    |
                                +-------R4  [UDP only]

                  <---- Bidirectional Traffic ---->

15.1. Normative 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>.

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4272]

Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/info/rfc4272>.

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

[RFC4456]

Bates, J., Ed., Chen, Ed., and Chandra, Ed., "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", April 2006, <https://datatracker.ietf.org/doc/html/rfc4456#section-9>.

[RFC4684]

Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, November 2006, <https://www.rfc-editor.org/info/rfc4684>.

[RFC4760]

Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.

[RFC5082]

Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <https://www.rfc-editor.org/info/rfc5082>.

[RFC5925]

Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.

[RFC6811]

Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>.

[RFC7153]

Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <https://www.rfc-editor.org/info/rfc7153>.

[RFC7911]

Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, <https://www.rfc-editor.org/info/rfc7911>.

[RFC8029]

Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>.

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

[RFC8205]

Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.

[RFC8212]

Mauch, J., Snijders, J., and G. Hankins, "Default External BGP (EBGP) Route Propagation Behavior without Policies", RFC 8212, DOI 10.17487/RFC8212, July 2017, <https://www.rfc-editor.org/info/rfc8212>.

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

[RFC8986]

Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.

[RFC9012]

Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, <https://www.rfc-editor.org/info/rfc9012>.

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

[SRTE]

Talaulikar, Ed. and S. Previdi, "Advertising Segment Routing Policies in BGP", 28 January 2023, <https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-20>.

15.2. Informative References

[BGP-CT-UPDATE-PACKING-TEST]

Vairavakkalai, Ed., "BGP CT Update packing Test Results", 25 June 2023, <https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt>.

[BGP-LU-EPE]

Gredler, Ed., "Egress Peer Engineering using BGP-LU", 16 June 2023, <https://datatracker.ietf.org/doc/html/draft-gredler-idr-bgplu-epe-15>.

[Colorful-Prefix-Routing-SRv6]

Wang, Ed., "BGP Colorful Prefix Routing for SRv6 based Services", 26 March 2023, <https://www.ietf.org/archive/id/draft-wang-idr-cpr-01.html>.

[FLOWSPEC-REDIR-IP]

Simpson, Ed., "BGP Flow-Spec Redirect to IP Action", 2 February 2015, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-redirect-ip-02>.

[Intent-Routing-Color]

Hegde, Ed., "Intent-aware Routing using Color", 13 March 2022, <https://datatracker.ietf.org/doc/html/draft-hr-spring-intentaware-routing-using-color-01#section-6.3.2>.

[MNH-ENCAP-DSCP]

Vairavakkalai, Ed., "BGP MultiNexthop Attribute", 10 July 2023, <https://www.ietf.org/archive/id/draft-kaliraj-idr-multinexthop-attribute-08.html#section-5.4.3.4>.

[MNH-ENCAP-MPLS]

Vairavakkalai, Ed., "BGP MultiNexthop Attribute", 10 July 2023, <https://www.ietf.org/archive/id/draft-kaliraj-idr-multinexthop-attribute-08.html#section-5.4.3.1>.

[MNH-EP]

Vairavakkalai, Ed., "BGP MultiNexthop Attribute", 10 July 2023, <https://www.ietf.org/archive/id/draft-kaliraj-idr-multinexthop-attribute-08.html#section-5.4.1>.

[MNH-TC]

Vairavakkalai, Ed., "BGP MultiNexthop Attribute", 10 July 2023, <https://www.ietf.org/archive/id/draft-kaliraj-idr-multinexthop-attribute-08.html#section-5.4.2.2>.

[MPLS-NAMESPACES]

Vairavakkalai, Ed., "BGP signalled MPLS namespaces", 10 July 2023, <https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-bgp-sig-private-mpls-labels-06>.

[MULTI-NH-ATTR]

Vairavakkalai, Ed., "BGP MultiNexthop Attribute", 10 July 2023, <https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-multinexthop-attribute-08>.

[PCEP-RSVP-COLOR]

Rajagopalan, Ed. and Pavan. Beeram, Ed., "Path Computation Element Protocol(PCEP) Extension for RSVP Color", 3 January 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-color-00>.

[PCEP-SRTE-COLOR]

Koldychev, Ed., Sivabalan, Ed., and Barth, Ed., "Path Computation Element Protocol(PCEP) Extension for RSVP Color", 20 June 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-11#name-sr-policy-identifiers>.

[RFC2474]

Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC6890]

Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <https://www.rfc-editor.org/info/rfc6890>.

[RFC9315]

Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, October 2022, <https://www.rfc-editor.org/info/rfc9315>.

[RFC9350]

Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, February 2023, <https://www.rfc-editor.org/info/rfc9350>.

[RTC-Ext]

Zhang, Z., Ed. and Haas, Ed., "Generic Route Constraint Distribution Mechanism for BGP", 26 June 2023, <https://tools.ietf.org/html/draft-zzhang-idr-bgp-rt-constrains-extension-03#section-2>.

[SRV6-INTER-DOMAIN]

K A, Ed., "SRv6 inter-domain mapping SIDs", 23 June 2023, <https://datatracker.ietf.org/doc/html/draft-salih-spring-srv6-inter-domain-sids-03>.

[TEAS-NS]

Farrel, Ed. and Drake, Ed., "A Framework for IETF Network Slices", 12 August 2023, <https://www.ietf.org/archive/id/draft-ietf-teas-ietf-network-slices-23.html#section-4>.