Internet-Draft | BGP CAR Problem Statement | November 2021 |
Rao, et al. | Expires 26 May 2022 | [Page] |
This document explores the scope, use-cases and requirements for a BGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider network environment.¶
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 26 May 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
This document explores the scope, use-cases and requirements for a BGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider network environment.¶
The targeted design outcome is to define the technology and protocol extensions that may be required in a manner that addresses the widest application.¶
The problem that the document initially focuses on is the BGP-based delivery of an intent across several transport domains. To do this, it describes existing intent-aware routing solutions that are deployed and then extends the solution scope and architecture to BGP.¶
The problem space is then widened to include any intent (including NFV chains and their location), any dataplane and the application of the intent-based routing to the Service/VPN routes. All of this is detailed in the rest of the document.¶
Color-Aware Routing (CAR) establishes routed paths that satisfy specific intent in a network. This section describes the basic concepts that define CAR and the protocols that currently support it.¶
The figure below is used as reference.¶
Intent in routing may be any combination of the following behaviors:¶
An intent-aware routed path may be within a single network domain or across multiple domains.¶
Color is a 32-bit numerical value that is associated with an intent, as defined in [I-D.ietf-spring-segment-routing-policy]¶
An Egress PE E2 colors a BGP service (e.g., VPN) route V/v to indicate the particular intent that E2 requests for the traffic bound to V/v. The color (C) is encoded as a BGP Color Extended community [I-D.ietf-idr-tunnel-encaps].¶
(E2, C) is a color-aware route to E2 which satisfies the intent associated with color C.¶
Multiple technologies already provide color-aware paths in solutions that are widely deployed.¶
In the context of large-scale SR-MPLS networks, SR Policy is applicable to both intra-domain and inter-domain deployments; whereas IGP Flex-Algo is better suited to intra-domain scenarios.¶
An ingress PE E1 automatically steers V-destined packets onto a Color-Aware path bound to (E2, C). If several such paths exist, a preference scheme is used to select the best path: E.g. IGP Flex-Algo first, then SR Policy.¶
If E1 and E2 are in different domains, E1 may request an SR-PCE in its domain for a path to (E2, C). The SR-PCE (or a set of them) computes the end-to-end path and installs it at E1 as an SR Policy. The end-to-end color-aware path may seamlessly cross multiple domains.¶
BGP Color-Aware Routing (CAR) is a new BGP solution which signals intent-aware routes to reach a given destination (e.g., E2). (E2, C) represents a BGP hop-by-hop distributed route that builds an inter-domain color-aware path to E2 for color C.¶
As seen above, multiple technologies exist that provide color-aware routing in a network. A BGP based solution must be compliant with the existing principles that apply to them:¶
Service routes MUST be colored using BGP Color Extended-Community to request intent¶
Colored service routes MUST be automatically steered on an appropriate color-aware path¶
Color-aware routes MAY resolve recursively via other color-aware routes¶
Here is a brief example that illustrates these principles.¶
In the figure above, all the nodes are part of an inter-domain network under a single authority and with a consistent color-to-intent mapping:¶
Color C1 is mapped to "low delay"¶
Color C2 is mapped to "low delay and avoid resource R"¶
E1 receives two BGP colored service routes from E2:¶
E1 has the following inter-domain color-aware paths:¶
(E2, C1) provided by BGP CAR which recursively resolves via intra-domain color-aware paths:¶
E1 automatically steers the received colored service routes as follows:¶
The example illustrates the benefits provided by leveraging the architectural principles:¶
Seamless co-existence of multiple color-aware technologies, e.g., BGP CAR and SR Policy¶
Seamless and complementary interworking between different color-aware technologies¶
Ingress PE E1 steers packets destined for a service (VPN) route V/v via BGP Color-Aware Route R/r to E2¶
The BGP CAR solution must support the following intents bound to a color:¶
Minimization of a cost metric vs a latency metric¶
Inclusion of one or several virtual network function chains¶
Localization of the virtual network function chains¶
The BGP CAR route may be a transport route or a service route (in this document, we use the term VPN instead of service for simplicity).¶
Transport Intent¶
The network diagram below illustrates the reference network topology used in this section for Transport CAR:¶
The following network design assumptions apply to the reference topology above, as an example:¶
Cost Optimized¶
On PE11, VPN routes colored with C1 are steered via (C1, PE31) BGP CAR route¶
Minimize latency¶
On PE11, VPN routes colored with C2 are steered via (C2, PE31) BGP CAR route.¶
On PE11, VPN routes colored with C3 are steered via (C3, PE31) BGP CAR route.¶
Example: PE11 learns (C3, PE31) BGP CAR route via 2 paths.¶
Color C4 - Avoid sending selected traffic via Domain 3¶
VPN (Service layer) intent¶
Extend the signaling of intent awareness end-to-end: CE site to CE site across provider networks¶
Provide ability for a CE to select paths through specific PEs for a given intent¶
Intent aware routing support for multiple service (VPN) interworking models¶
The network diagram below illustrates the reference network topology used in this section for VPN CAR.¶
The following network design assumptions apply to the reference topology above, as an example:¶
Cost Optimized¶
On CE1, flows requiring cost optimized paths to V/24 are steered over (C1, V/24) route.¶
Example: CE1 learns (C1, V/24) CAR route through several equal cost paths:¶
Minimize latency¶
On CE1, flows requiring low latency paths to prefix V/24 are steered over (C2, V/24) CAR route.¶
On CE1, flows requiring minimum cost path avoiding purple links to V/24 are steered over (C3, V/24) BGP CAR route.¶
The figure below shows a reference large-scale multi-domain network topology for targeted deployments. E1 and E2 are PEs; the other nodes are border routers between domains in different tiers of the network. A VPN route is advertised via service RRs (S-RR) between an egress PE (E2) and an ingress PE (E1). BGP must provide reachability from E1 to E2 based on various intent.¶
The solution must support the following :¶
Support different multi-domain deployment designs¶
Support end-to-end path crossing transport domains with different technologies and encapsulations¶
Support for massive scaled transport network¶
Scalable MPLS dataplane solution¶
A notion of hierarchy or segment list is required.¶
Ability to abstract the topology from remote domains - for scale, stability and faster convergence¶
Support for an Emulated-PULL model for the BGP signaling¶
The subscription and related filtering solution must apply to any BGP CAR node¶
Transport CAR routes¶
Service/VPN CAR routes¶
Automation of the subscription/filter route¶
It is useful to analyze the multiple scaling requirements and specifically the data plane constraints in the context of a few common reference designs and use-cases.¶
A couple of example scenarios are listed below for reference.¶
In the Seamless-MPLS reference topology in previous section:¶
In the Inter-AS Option C VPN reference topology in previous section:¶
Support signaling and distribution of different Color-Aware routes to reach a participating node, e.g., a PE. Intent should be indicated by the notion of a Color as defined in SR Policy Architecture.¶
Support for a flexible NLRI definition to accommodate both efficiency of processing (e.g., packing) and future extensibility¶
Support for validation of paths¶
Next-hop resolution for Color-Aware route¶
Separation of transport and VPN service semantics.¶
Multicast service intent¶
Many people contributed to this document.¶
The authors would especially like to thank Jim Uttaro for his guidance on the work and feedback on many aspects of the problem statement. We would also like to thank Daniel Voyer, Luay Jalil and Robert Raszuk for their review and valuable suggestions.¶
We also express our appreciation to Bruno Decreane, Keyur Patel, Jim Guichard, Alex Bogdanov, Dirk Steinberg, Hannes Gredler and Xiaohu Hu for discussions on several topics that have helped provide input to the document. We also thank Huaimo Chen for his valuable review comments.¶
The authors would like to thank Stephane Litkowski for his detailed review and for making valuable suggestions to improve the quality of the document. We would also like to thank Kamran Raza and Kris Michelson for their review and comments on the document and to Simon Spraggs, Jose Liste and Jiri Chaloupka for their early inputs on the problem statement.¶