idnits 2.17.1 draft-dskc-bess-bgp-car-problem-statement-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'S1' is mentioned on line 750, but not defined == Missing Reference: 'S2' is mentioned on line 750, but not defined == Missing Reference: 'S3' is mentioned on line 753, but not defined == Missing Reference: 'RFC8604' is mentioned on line 806, but not defined == Unused Reference: 'I-D.agrawal-spring-srv6-mpls-interworking' is defined on line 1087, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-srv6-services' is defined on line 1092, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-bgp-ipv6-rt-constrain' is defined on line 1098, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lsr-flex-algo' is defined on line 1109, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-srv6-network-programming' is defined on line 1127, but no explicit reference was found in the text == Unused Reference: 'I-D.voyer-pim-sr-p2mp-policy' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1139, but no explicit reference was found in the text == Unused Reference: 'RFC4360' is defined on line 1144, but no explicit reference was found in the text == Unused Reference: 'RFC4684' is defined on line 1148, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 1155, but no explicit reference was found in the text == Unused Reference: 'RFC5512' is defined on line 1160, but no explicit reference was found in the text == Unused Reference: 'RFC5701' is defined on line 1166, but no explicit reference was found in the text == Unused Reference: 'RFC7311' is defined on line 1170, but no explicit reference was found in the text == Unused Reference: 'RFC7606' is defined on line 1175, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 1180, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 1185, but no explicit reference was found in the text == Unused Reference: 'RFC8277' is defined on line 1189, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 1193, but no explicit reference was found in the text == Unused Reference: 'RFC8664' is defined on line 1198, but no explicit reference was found in the text == Unused Reference: 'RFC8669' is defined on line 1204, but no explicit reference was found in the text == Unused Reference: 'I-D.filsfils-spring-sr-policy-considerations' is defined on line 1212, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-performance-routing' is defined on line 1218, but no explicit reference was found in the text == Unused Reference: 'RFC3906' is defined on line 1229, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 1234, but no explicit reference was found in the text == Unused Reference: 'RFC4272' is defined on line 1239, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: 'RFC6952' is defined on line 1247, but no explicit reference was found in the text == Unused Reference: 'RFC7911' is defined on line 1253, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-agrawal-spring-srv6-mpls-interworking-03 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-05 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-21 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-03 ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) == Outdated reference: A later version (-09) exists of draft-filsfils-spring-sr-policy-considerations-06 Summary: 4 errors (**), 0 flaws (~~), 40 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WorkGroup D. Rao 3 Internet-Draft S. Agrawal 4 Intended status: Informational C. Filsfils 5 Expires: August 26, 2021 K. Talaulikar 6 Cisco Systems 7 B. Decraene 8 Orange 9 D. Steinberg 10 Steinberg Consulting 11 L. Jalil 12 Verizon 13 J. Guichard 14 Futurewei 15 W. Henderickx 16 Nokia 17 February 22, 2021 19 BGP Color-Aware Routing Problem Statement 20 draft-dskc-bess-bgp-car-problem-statement-02 22 Abstract 24 This document explores the scope, use-cases and requirements for a 25 BGP based routing solution to establish end-to-end intent-aware paths 26 across a multi-domain service provider network environment. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 26, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. State-of-the-art . . . . . . . . . . . . . . . . . . . . 4 65 1.2.1. Color . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1.2.2. Colored vs Color-Aware . . . . . . . . . . . . . . . 5 67 1.2.3. Per-Destination and Per-Flow Steering . . . . . . . . 6 68 1.3. Why a BGP-based alternative is needed . . . . . . . . . . 6 69 1.4. Color Domains . . . . . . . . . . . . . . . . . . . . . . 6 70 1.5. BGP Color-Aware Routing . . . . . . . . . . . . . . . . . 7 71 2. Intent bound to a Color . . . . . . . . . . . . . . . . . . . 7 72 3. BGP CAR Use-cases . . . . . . . . . . . . . . . . . . . . . . 7 73 3.1. BGP Transport CAR . . . . . . . . . . . . . . . . . . . . 7 74 3.1.1. Use-case of minimization of a cost metric vs a 75 latency metric . . . . . . . . . . . . . . . . . . . 9 76 3.1.2. Use-case of exclusion/inclusion of link affinity . . 10 77 3.1.3. Use-case of exclusion/inclusion of domains . . . . . 10 78 3.1.4. Use-case of virtual network function chains in local 79 and core domains . . . . . . . . . . . . . . . . . . 11 80 3.2. BGP VPN CAR . . . . . . . . . . . . . . . . . . . . . . . 12 81 3.2.1. Use-case of minimization of a cost metric vs a 82 latency metric . . . . . . . . . . . . . . . . . . . 15 83 3.2.2. Use-case of exclusion/inclusion of link affinity . . 16 84 3.2.3. Use-case of virtual network function chains in local 85 and core domains . . . . . . . . . . . . . . . . . . 17 86 4. Deployment Requirements . . . . . . . . . . . . . . . . . . . 18 87 5. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 5.1. Scale Requirements . . . . . . . . . . . . . . . . . . . 19 89 5.2. Scale Analysis . . . . . . . . . . . . . . . . . . . . . 20 90 6. Network Availability . . . . . . . . . . . . . . . . . . . . 22 91 7. BGP Protocol Requirements . . . . . . . . . . . . . . . . . . 23 92 8. Future Considerations . . . . . . . . . . . . . . . . . . . . 24 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 96 10.2. Informative References . . . . . . . . . . . . . . . . . 28 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 99 1. Introduction 101 1.1. Objective 103 This document explores the scope, use-cases and requirements for a 104 BGP based routing solution to establish end-to-end intent-aware paths 105 across a multi-domain service provider network environment. 107 The targeted design outcome is to define the technology and protocol 108 extensions that may be required in a manner that addresses the widest 109 application. 111 To introduce the problem space that the document focuses on, let us 112 start with the BGP-based delivery of an intent across several SR- 113 MPLS/MPLS domains. 115 +-----+ +-----+ V/v via PE2 +-----+ 116 .......|S-RR1|<...............|S-RR2|<.................|S-RR3| <.. 117 : +-----+ +-----+ Color C +-----+ : 118 : : 119 : : 120 +--:----------+-------------+--------------+-------------+----------:--+ 121 | : | | | | : | 122 | : | | | | : | 123 | : +---+ +---+ +---+ +---+ : | 124 | : |121| |231| |341| |451| : | 125 | : +---+ +---+ +---+ +---+ : | 126 |----+ | | | | +----| 127 | PE1| | | | | |PE2 | 128 |----+ | | | | +----| 129 | +---+ +---+ +---+ +---+ | 130 | |122| |232| |342| |452| | 131 | +---+ +---+ +---+ +---+ | 132 | Access | Metro | Core | Metro | Access | 133 | domain 1 | domain 2 | domain 3 | domain 4 | domain 5 | 134 +-------------+-------------+--------------+-------------+-------------+ 135 iPE iBRM iBRC eBRC eBRM ePE 137 Figure 1: Reference large-scale multi-domain network topology 139 The figure above shows a reference large-scale multi-domain network 140 topology. PE1 and PE2 are PEs; the other nodes are border routers 141 (BR) between domains in different tiers of the network. A VPN route 142 is advertised via service RRs (S-RR) between an egress PE (PE2) and 143 an ingress PE (PE1). 145 BGP must provide reachability from PE1 to PE2 based on various 146 intent. For instance, BGP may provide reachability to PE2 using 147 either low latency or best effort. 149 A VPN route having a requirement of low latency routing will select 150 the BGP reachability information to PE2 that is based on low latency. 152 The problem space is then widened to include any intent (including 153 NFV chains and their location), any dataplane and the application of 154 the intent-based routing to the Service/VPN routes. All of this is 155 detailed in the rest of the document. 157 1.2. State-of-the-art 159 The following solution is widely deployed - 160 [I-D.ietf-spring-segment-routing-policy]: 162 o In reference figure above, an Egress PE PE2 advertises a BGP VPN 163 route V/v with a BGP Color Extended Community C 164 [I-D.ietf-idr-tunnel-encaps] to indicate the service intent that 165 PE2 requests for the traffic bound to V/v. Note: The Color 166 Extended Community may be applied to any BGP service route. For 167 simplicity in this document, we will use a VPN route example. 169 o An ingress PE1 steers V-destined packets onto an SR Policy bound 170 to (C, PE2). 172 o C may express any of the following requirements: 174 * Minimization of a cost metric vs a latency metric. 176 * Exclusion/Inclusion of SRLG and/or Link Affinity. 178 + In inter-domain context, exclusion/inclusion of entire 179 domains. 181 * Inclusion of virtual network function chains 182 [I-D.ietf-spring-sr-service-programming]. 184 o An SR-PCE (or a set of them) computes the end-to-end path and 185 installs it at PE1 as an SR Policy. The end-to-end path may 186 seamlessly cross multiple domains. 188 The SR-PCE solution being defined at the IETF [RFC8664]and being 189 widely deployed is reminded in this introduction as a useful "state- 190 of-the-art" context to consider when defining the BGP-based 191 alternative solution. 193 1.2.1. Color 195 The solution must reuse the Color concept defined in [I-D.ietf- 196 spring-segment-routing-policy]. The color is a 32-bit numerical 197 value that, today, associates an SR-policy with an intent (e.g., low 198 latency). 200 1.2.2. Colored vs Color-Aware 202 The solution must support the ability to distinguish BGP routes that 203 require the usage of a particular intent from BGP routes that are 204 actually satisfying a particular intent. Hence, this document 205 defines the notion of colored and color-aware routes. 207 o Colored: Egress PE PE2 colored its BGP VPN route V/v to indicate 208 the intent that it requests for the traffic bound to V/v. 210 o Color-Aware: A new BGP solution which signals multiple "ways" to 211 reach a given destination (e.g. PE2) 213 o Steering a colored VPN route to a color-aware route 215 * If PE2 signals a VPN route V/v with color C 217 * If PE1 installs that VPN route 219 * If PE1 learns about a BGP Color-Aware Route R/r to PE2 for 220 color C 222 * Then PE1 steers packets destined to V/v via R/r 224 o Note the similarity with the state-of-the-art reference: 226 * The steering onto an SR Policy bound to (C, PE2) is replaced by 227 the steering on a Color-Aware BGP route (C, PE2) 229 * The data model is the same "resolution via (C, PE2)" 231 * The difference is how the (C, PE2) path is obtained: BGP 232 signaling vs SR-PCE signaling 234 1.2.3. Per-Destination and Per-Flow Steering 236 Ingress PE PE1 steers packets destined for a service (VPN) route V/v 237 via BGP Color-Aware Route R/r to PE2 239 o Per-Destination Steering: Incoming packets on PE1 match BGP 240 service route V/v to be steered based on the destination IP 241 address of the packets. 243 o Per-Flow Steering: Incoming packets on PE1 match BGP service route 244 V/v to be steered based on the combination of the destination IP 245 address and additional elements in the packet header (i.e., IP 246 flow). Such a packet lookup may recurse on a forwarding array 247 where some of the entries are BGP color-aware routes to PE2. A 248 given flow is mapped to a specific entry in this array i.e. via a 249 specific BGP color-aware route to PE2. 251 1.3. Why a BGP-based alternative is needed 253 o An operator with an existing Seamless-MPLS/BGP-LU deployment 254 [I-D.ietf-mpls-seamless-mpls] may consider a BGP based extension 255 as a more incremental approach. 257 o There may be an expectation that BGP would support a larger scale. 259 o Opacity of a remote domain due to trust boundaries within an 260 inter-domain construction. 262 1.4. Color Domains 264 With the use of Color to represent intent, it is useful to describe 265 the concept of a color domain distinct from a network domain. 267 o Domain: A domain (or network domain) refers to a unit of isolation 268 or hierarchy in the network topology; for example, access, metro 269 and or core domains. From a routing perspective, a domain may 270 have a distinct IGP area or instance; or a distinct BGP ASN. 272 o Color Domain: A color domain may represent a collection of one or 273 more network domains with a single, consistent color/intent 274 mapping. 276 o Color re-mapping may happen at color domain boundaries. 278 o Deployments under a single authority are expected to use the same 279 color/intent mapping across all network domains. 281 A solution must distinguish the actual protocol boundaries (IGP, ASN) 282 from the color domain boundaries. 284 1.5. BGP Color-Aware Routing 286 A BGP solution that is solving this problem statement is called BGP 287 Color-Aware Routing, and is referred to as BGP CAR in this document. 289 2. Intent bound to a Color 291 The BGP CAR solution must support the following intents bound to a 292 color: 294 o Minimization of a cost metric vs a latency metric 296 * Minimization of different metric types, static and dynamic 298 o Exclusion/Inclusion of SRLG and/or Link Affinity and/or minimum 299 MTU/number of hops 301 o Bandwidth management 303 o In the inter-domain context, exclusion/inclusion of entire 304 domains, and border routers 306 o Inclusion of one or several virtual network function chains 308 * Located in a regional domain and/or core domain, in a DC 310 o Localization of the virtual network function chains 312 * Some functions may be desired in the regional DC or vice versa 314 o Per-Destination and Per-Flow steering 316 3. BGP CAR Use-cases 318 The BGP CAR route may be a transport route or a service route (in 319 this document, we use the term VPN instead of service for 320 simplicity). 322 3.1. BGP Transport CAR 324 o Transport Intent 326 * Intent-aware routing between PEs connected across multiple 327 transit domains 328 + Set up BGP based end-to-end paths stitching intent-aware 329 intra-domain segments 331 o The network diagram below illustrates the reference network 332 topology used in this section for Transport CAR: 334 +-----+ +-----+ +-----+ 335 .....|S-RR1| <............. |S-RR2| <............... |S-RR3| <... 336 : +-----+ +-----+ +-----+ : 337 : : 338 : : 339 : : 340 +--:--------------+ +-----------------+ +--------------:--+ 341 | : | | | | : | 342 | : | | | | : | 343 | : +---| D=20 |---+ +---| D=25 |---+ : | 344 | : |121|-------|211| |231|-------|321| : | 345 | : +---| \ / |---+ +---| \ / |---+ : | 346 |----+ | \ / | | \ / | +----| 347 |PE11| | V | | V | |PE31| 348 |----+ | / \ | | / \ | +----| 349 | +---| / \ |---+ +---| / \ |---+ | 350 | |122|-------|212| |232|-------|322| | 351 | +---| D=15 |---+ +---| D=10 |---+ | 352 | | | | | | 353 | Domain 1 | | Domain 2 | | Domain 3 | 354 +-----------------+ +-----------------+ +------------------+ 356 Figure 2: Transport CAR Reference Topology 358 The following network design assumptions apply to the reference 359 topology above, as an example: 361 * Independent ISIS/OSPF SR instance in each domain. 363 * eBGP peering link between ASBRs (121-211, 121-212, 122-211, 364 122-212, 231-321, 231-322, 232-321 and 232-322). 366 * Peering links have equal cost metric. 368 * Peering links have delay configured or measured as shown by 369 "D". D=50 for cross peering links. 371 * VPN service is running from PE31 to PE11 via service RRs (S-RRn 372 in figure). 374 o The following sections illustrate a few examples of intent use- 375 cases applicable to transport routes. 377 3.1.1. Use-case of minimization of a cost metric vs a latency metric 379 o In the reference topology of Figure 2 381 Each domain has Algo 0 and Flex Algo 128 383 Algo 0 is for minimum cost metric(cost optimized). 385 Flex Algo 128 definition is for minimum delay (low latency). 387 o Cost Optimized 389 * Color C1 - Minimum cost intent. (Here, a BGP CAR route with 390 Color C1 is being used, instead of BGP-LU.) 392 * On PE11, VPN routes colored with C1 are steered via (C1, PE31) 393 BGP CAR route 395 + BGP CAR for C1 sets up path(s) between PEs for end-to-end 396 minimum cost. 398 + (2) These paths traverse over intra-domain Algo 0 in each 399 domain and account for the peering link cost between ASBRs. 401 + Example: PE11 learns (C1, PE31) CAR route via several equal 402 paths: 404 1. One such path is through FA0 to node 121, links 121-211, 405 FA0 to 231, link 231-321, FA0 to PE31 407 2. Another such path is through FA0 to node 122, link 408 122-212, FA0 to 232, link 232-322, FA0 to PE31. 410 o Minimize latency 412 * Color C2 - Minimum latency intent. 414 * On PE11, VPN routes colored with C2 are steered via (C2, PE31) 415 BGP CAR route. 417 + BGP CAR for C2 advertises paths between PEs for minimum end- 418 to-end delay. 420 + (2) These paths traverse over intra-domain Flex Algo 128 in 421 each domain and account for peering link delay between 422 ASBRs. 424 + (3) Example: PE11 learns (C2, PE31) BGP CAR route and best 425 path is through FA128 to node 122, link 122-212, FA128 to 426 232, link 232-322, FA128 to PE31. 428 3.1.2. Use-case of exclusion/inclusion of link affinity 430 o Color C3 - Intent to Minimize cost metric and avoid purple links 432 o In the reference topology of Figure 2 434 Each domain has Flex Algo 129 and some links have purple 435 affinity. 437 Flex Algo 129 definition is set to minimum cost metric and 438 avoid purple links (within domain). 440 Peering cross links are colored purple by policy. 442 o On PE11, VPN routes colored with C3 are steered via (C3, PE31) BGP 443 CAR route. 445 * BGP CAR for C3 sets up paths between PEs for minimum end-to-end 446 cost and avoiding purple link affinity. 448 * These paths traverse over intra domain Flex Algo 129 in each 449 domain and accounts for peering link cost between ASBR and 450 avoiding purple links. 452 * Example: PE11 learns (C3, PE31) BGP CAR route via 2 paths. 454 1. First path is through FA 129 to node 121, link 121-211, 455 FA129 to 231, link 231-321, FA129 to PE31. 457 2. Second path is through FA129 to node 122, link 122-212, 458 FA129 to 232, link 232-322, FA129 to PE31. 460 3.1.3. Use-case of exclusion/inclusion of domains 461 +-----+ +-----+ +-----+ 462 ....|S-RR1| <............. |S-RR2| <.............. |S-RR3| <.... 463 : +-----+ +-----+ +-----+ : 464 : : 465 : +----------------+ : 466 : | | : 467 +--:--------------+ |---+ +---| +--------------:--+ 468 | : | |---|211| |241|---| | : | 469 | : | | |---+ +---| | | : | 470 | : +---| | | Domain 2 | | |---+ : | 471 | : |121|---| +----------------+ |---|421| : | 472 | : +---| |---+ : | 473 |----+ | | +----| 474 |PE11| | | |PE41| 475 |----+ | | +----| 476 | +---| |---+ | 477 | |131|---| +----------------+ |---|431| | 478 | +---| | | | | |---+ | 479 | | | |---+ +---| | | | 480 | Domain 1 | |---|311| |341|---| | Domain 4 | 481 +-----------------+ |---+ +---| +-----------------+ 482 | Domain 3 | 483 +----------------+ 485 Figure 3 487 Color C4 - Avoid sending selected traffic via Domain 3 489 o VPN routes advertised from PEs with Color C4 491 o BGP CAR for Color C4 should only set up paths between PE11 and 492 PE41 that exclude Domain 3 494 3.1.4. Use-case of virtual network function chains in local and core 495 domains 496 ____ ____ 497 / \ / \ 498 | NFV1 | | NFV2 | 499 \ / \ / 500 +---------------------+ +--------------------+ +-------------------+ 501 | |E11| | | |E21| | | | 502 | +---+ | | +---+ | | | 503 | | | | | | 504 | | | | | | 505 |----+ +------+ +------+ +----| 506 |PE11| | 121 | | 231 | |PE31| 507 |----+ +------+ +------+ +----| 508 | | | | | | 509 | | | | | | 510 | | | | | | 511 | | | | | | 512 | Domain 1 | | Domain 2 | | Domain 3 | 513 +---------------------+ +--------------------+ +-------------------+ 515 Figure 4 517 o Color intent 519 * C5 - Routing via min-cost paths 521 * C6 - Routing via a local NFV service chain situated at E11 523 * C7 - Routing via a centrally located NFV service chain situated 524 at E21 526 o Forwarding of packets from PE11 towards PE31: 528 * (C5, PE31) mapped packets are sent via nodes 121, 231 to PE31 530 * (C6, PE31) mapped packets are sent to E11 and then post-service 531 chain, via 121, 231 to PE31 533 * (C7, PE31) mapped packets are sent via 121 to E21 and then 534 post-service chain, via 231 to PE31 536 3.2. BGP VPN CAR 538 o VPN (Service layer) intent 540 * Extend the signaling of intent awareness end-to-end: CE site to 541 CE site across provider networks 542 + Provide ability for a CE to select paths through specific 543 PEs for a given intent 545 - Example-1: Certain intent in transport not available via 546 specific PEs 548 - Example-2: Certain CE-PE connection does not support 549 specific intent 551 - Example-3: Site access via certain CE does not support 552 specific intent. For instance, link connecting a 553 specific CE to a DC hosting loss-sensitive service may 554 have better quality than a link from another CE 556 + Provide ability for a CE to send traffic indicating a 557 specific intent (via suitable encapsulation) to the PE for 558 optimal steering. 560 * Intent aware routing support for multiple service (VPN) 561 interworking models 563 + Beyond options such as iBGP or Inter-AS Option C that 564 inherently extend from PE to PE 566 1. Inter-AS Option A 568 2. Inter-AS Option B 570 3. GW based interworking(L3VPN, EVPN) 572 + Interworking with existing L3VPN deployments, both PEs and 573 CEs 575 o The network diagram below illustrates the reference network 576 topology used in this section for VPN CAR. 578 +-------------------+ +-------------------+ 579 | ....|S-RR|.... | | ....|S-RR|..... | 580 | : +----+ : | | : +----+ : | 581 | : : : : | | : : : : | 582 |----+ : : +---| D=20 |---+ : : +----| 583 /|PE11| : : |121|-----------|211| : : |PE21|\ 584 D=25/ |----+ : : +---| X X |---+ : : +----| \ D=25 585 / | : : | X X | : : | \ V/24 586 CE1 | : : | X D=50| : : | CE2<--- 587 X | : : | X X | : : | X 588 D=15 X |----+ : : +---| X X |---+ : : +----| X D=10 589 X|PE12|...: :...|212|-----------|232|...: :...|PE22|X 590 |----+ +---| D=10 |---+ +----| 591 | | | | 592 | AS 1 | | AS 2 | 593 +-------------------+ +-------------------+ 595 Figure 5: VPN CAR reference topology 597 The following network design assumptions apply to the reference 598 topology above, as an example: 600 * Independent ISIS/OSPF SR instance in each AS. 602 * eBGP peering link between VPN ASBRs 121-211, 121-212, 122-211, 603 122-212. 605 * VPN service is running between PEs via service RRs in each AS 606 to local ASBRs. Between ASBRs, its Option-B i.e. next hop self 607 for VPN SAFI. 609 * CE1 is dual homed to PE11 and PE12. Similarly, CE2 is dual 610 homed to PE21 and PE22. 612 * Peering links have equal cost metric 614 * Peering links have delay configured or measured as shown by 615 "D". 617 * CE2 advertises prefix V/24 to CE1. It is advertised as RD:V/24 618 between PEs, including color-awareness 620 o The following sections illustrate a few examples of intent use- 621 cases applicable to VPN (service) routes. 623 3.2.1. Use-case of minimization of a cost metric vs a latency metric 625 o In the reference topology of Figure 5 627 Each AS has Flex Algo 0 and 128. 629 Flex Algo 0 is for minimum cost metric(cost optimized). 631 Flex Algo 128 definition is for minimum delay (low latency). 633 o Cost Optimized 635 * Color C1 - Minimum cost intent. 637 * On CE1, flows requiring cost optimized paths to V/24 are 638 steered over (C1, V/24) route. 640 + BGP CAR for C1 sets up paths between CEs for minimum end-to- 641 end cost. 643 + This advertisement needs BGP CAR between PE-CE for V/24 644 prefix and color C1 awareness. 646 + It also needs BGP VPN CAR between PEs and ASBRs for RD:V/24 647 prefix and color C1 awareness (C1, RD:V/24). 649 + Paths traverse over PE-CE links, intra-domain Flex Algo 0 in 650 each AS and peering links between ASBRs, minimizing cost for 651 VPN. 653 + Example: CE1 learns (C1, V/24) CAR route through several 654 equal cost paths: 656 1. One path is through link CE1-PE11, FA0 to 121, link 657 121-211, FA0 to PE21 and link PE21-CE2. 659 2. Another such path is through CE1-PE12, FA0 to node 122, 660 link 122-212, FA0 to PE22, link PE22-CE2. 662 o Minimize latency 664 * Color C2 - Minimum latency intent 666 * On CE1, flows requiring low latency paths to prefix V/24 are 667 steered over (C2, V/24) CAR route. 669 + BGP CAR for C2 sets up paths between CEs for minimum end-to- 670 end delay. 672 + This advertisement needs BGP CAR between PE-CE for V/24 673 prefix and color C2 awareness. 675 + It also needs BGP VPN CAR between PEs and ASBR for RD:V/24 676 prefix and color C2 awareness (C2, RD:V/24). 678 + Paths traverse over intra-domain Flex Algo 128 in each AS 679 and accounts for inter ASBR link delays and PE-CE link 680 delays for the VPN. 682 + Example: CE1 learns (C2, V/24) CAR best route through link 683 CE1-PE12, FA128 to 122, link 122-212, FA128 to PE22 and link 684 PE22-CE2. 686 3.2.2. Use-case of exclusion/inclusion of link affinity 688 o Color C3 - Intent to Minimize cost metric and avoid purple links 690 o In the reference topology of Figure 5 692 Each AS has Flex Algo 129 and some links have purple affinity. 694 Flex Algo 129 definition is set to minimum cost metric and 695 avoid purple links (within AS). 697 ASBR cross links are colored purple by policy. Bottom PE-CE 698 links are colored purple as well by policy 700 o On CE1, flows requiring minimum cost path avoiding purple links to 701 V/24 are steered over (C3, V/24) BGP CAR route. 703 * BGP CAR for C3 setup paths between CEs for minimum end-to-end 704 cost and avoiding purple link affinity. 706 * This advertisement needs BGP CAR between PE-CE for V/24 prefix 707 and color C3 awareness 709 * It also needs BGP VPN CAR between PEs and ASBRs for RD:V/24 710 prefix and color C3 awareness (C3, RD:V/24). 712 * The path avoids purple PE-CE links, traverses over intra-domain 713 Flex Algo 129 in each AS and avoids purple links between VPN 714 ASBRs. 716 * Example: CE1 learns (C3, V/24) CAR route through link CE1-PE11, 717 FA129 to 121, link 121-211, FA129 to PE21 and link PE21-CE2. 719 3.2.3. Use-case of virtual network function chains in local and core 720 domains 722 +-----+ 723 ........................|S-RR | <................. 724 : +-----+ <........... : 725 : : : 726 : : : 727 : ___ ___ ___ : : 728 : / \ / \ / \ : : 729 :| S1 | | S2 | | S3 | : : 730 : \ / \ / \ / : : 731 +-:---------------+ +--------------+ +------:----:--+ 732 | : |E11| |E12| | | |E21| | | : : | 733 | : +---+ +---+ | | +---+ | | : +----|<-(V1/24,C1) 734 | : | | | | : |PE31|--CE2 735 | V | | | | : +----| 736 |----+ +------+ +------+ : | 737 CE1--|PE11| | 121 | | 231 | : | 738 |----+ +------+ +------+ : +----|<-(V2/24/C2) 739 | | | | | :..|PE32|--CE3 740 | | | | | +----| 741 | | | | | | 742 | | | | | | 743 | Domain 1 | | Domain 2 | | Domain 3 | 744 +-----------------+ +--------------+ +--------------+ 746 Figure 6 748 o Color intent 750 * C1 - Routing via NFV service chain comprising of [S1, S2] 751 attached to E11 and E12 753 * C2 - Routing via NFV service [S3] attached to E21 755 o CE1, CE2, CE3 are sites of VPN1. 757 o Prefix V1/24 colored with C1 from CE2, and advertised as RD:V1/24 758 with C1 by PE31 to PE11 via S-RR 760 o Prefix V2/24 colored with C2 from CE3, and advertised as RD:V2/24 761 with C2 by PE32 to PE11 via SS-RR 763 o From PE11: 765 * [V1/24, C1] mapped packets are sent via S1, S2 and then routed 766 to PE31, CE2 768 * [V2/24, C2] mapped packets are sent via S3 and then routed to 769 PE32, CE3 771 4. Deployment Requirements 773 o Co-existence, compatibility and interworking with currently 774 deployed SR-PCE based multi-domain color-aware solution 776 o Support different multi-domain deployment designs 778 * Multiple IGP domains within a single AS (Seamless MPLS) 780 + Inter-connect at node level (ABR) 782 * Multiple BGP AS domains 784 + Inter-connect via peering links (ASBR) 786 o Support end-to-end path crossing transport domains with different 787 technologies and encapsulations 789 * LDP-MPLS 791 * RSVP-TE-MPLS 793 * SR-MPLS 795 * SRv6 797 * IPv4/IPv6 799 o Support interworking between domains with different encapsulations 800 (e.g, SR-MPLS and SRv6) 802 o Support multiple transport encapsulations within a domain for co- 803 existence and migration 805 o Provide a BGP-based control-plane solution for the use-case 806 illustrated in [RFC8604] together with deployment design 807 guidelines for the leverage of anycast and binding SIDs. 809 5. Scalability 811 5.1. Scale Requirements 813 o Support for massive scaled transport network 815 * Number of Remote PE's: >= 300k 817 * Number of Colors C: >= 5 819 o Scalable MPLS dataplane solution 821 * With one label per (C, Remote PE), the 1M MPLS dataplane does 822 not work. 824 * A notion of hierarchy or segment list is required. 826 + E.g. the SR-PCE builds the end-to-end path as a list of 827 segments such that no single node needs to support a data- 828 plane scaling in the order of (Remote PE * C) 830 + The solution is thus not a direct extension of BGP-LU 832 * Additionally, PE and transit nodes (ABRs) may be devices with 833 limited forwarding table space 835 * Devices may have constraints on packet processing (e.g., label 836 operations, number of labels pushed) and performance 838 o Ability to abstract the topology from remote domains - for scale, 839 stability and faster convergence 841 * Abstracting PE and/or ABR related state and network events 843 o Support for an Emulated-PULL model for the BGP signaling 845 * The SR-PCE solution natively supports a PULL model: when PE1 846 installs a VPN route V/v via (C, PE2), PE1 requests its serving 847 SR-PCE to compute the SR Policy to (C, PE2). I.e. PE1 does 848 not learn unneeded SR policies. 850 * BGP Signaling is natively a PUSH model. 852 * Emulated-PULL refers to the ability for a BGP CAR node PE1 to 853 "subscribe" to (C, PE2) route such that only the related paths 854 are signaled to PE1. 856 * The subscription and related filtering solution must apply to 857 any BGP CAR node 859 + Transport CAR routes 861 1. Ability for a node (PE/ABR/RR) to signal interest for 862 routes of specific colors. 864 2. PEs only learn routes that they need - remote VPN 865 endpoints (PEs/ASBRs) or transit nodes (ABRs, ASBRs). 867 3. ABRs also only learn and propagate routes they need 868 locally in domain 870 + Service/VPN CAR routes 872 1. Ability for a node (PE) to signal interest for a 873 specific (Egress PE, Color) transport route 875 2. CEs learn routes that they need - interested colors 877 3. PEs learn routes that they need - interested VPNs, 878 colors 880 + Automation of the subscription/filter route 882 1. Similar to the SR-PCE solution, when an ingress PE1 883 installs VPN V/v via (C, PE2), PE1 originates its 884 subscription/filter route for (C, PE2). 886 + Efficient propagation and processing of subscription/filter 887 routes. 889 + Ability to perform aggregation and suppression of 890 subscription/filter routes at nodes in the route propagation 891 path to reduce explosion and churn in propagation of the 892 filter routes themselves. 894 + The solution may be optional for networks that do not have 895 the large scaling requirements 897 5.2. Scale Analysis 899 It is useful to analyze the multiple scaling requirements and 900 specifically the data plane constraints in the context of a few 901 common reference designs and use-cases. 903 A couple of example scenarios are listed below for reference. 905 o Seamless-MPLS design, with IGP Flex-Algo in each domain 907 +-----+ 908 .............................. |S-RR | <........................ 909 : +-----+ : 910 : : 911 : : 912 +--:-----------------+ +--------------------+ +-----------------:--+ 913 | : | | | | : | 914 | : | | | | : | 915 | : +------+ +------+ : | 916 | : | 121 | | 231 | : | 917 | V +------+ +------+ : | 918 |----+ | | | | +----| 919 |PE11| | | | | |PE31| 920 |----+ | | | | +----| 921 | +------+ +------+ | 922 | | 122 | | 232 | | 923 | +------+ +------+ | 924 | | | | | | 925 | Domain 1 | | Domain 2 | | Domain 3 | 926 +--------------------+ +--------------------+ +--------------------+ 928 Figure 7 930 o Inter-AS Option C VPN design, with IGP Flex-Algo in each domain, 931 and eBGP peering between domains 932 +-----+ +-----+ +-----+ 933 ....|S-RR1| <............. |S-RR2| <............... |S-RR3| <... 934 : +-----+ +-----+ +-----+ : 935 : : 936 : : 937 : : 938 +--:---------------+ +------------------+ +--------------:--+ 939 | : | | | | : | 940 | : | | | | : | 941 | : +---| |---+ +---| |---+ : | 942 | : |121|------|211| |231|------|321| : | 943 | : +---| |---+ +---| |---+ : | 944 |----+ | | | | +----| 945 |PE11| | | | | |PE31| 946 |----+ | | | | +----| 947 | +---| |---+ +---| |---+ | 948 | |122|------|212| |232|------|322| | 949 | +---| |---+ +---| |---+ | 950 | | | | | | 951 | Domain 1 | | Domain 2 | | Domain 3 | 952 +------------------+ +------------------+ +-----------------+ 954 Figure 8 956 6. Network Availability 958 o The BGP CAR solution should provide high network availability for 959 typical deployment topologies, with minimum loss of connectivity 960 in different network failure scenarios. 962 o The network failure scenarios, applicable technologies and design 963 options described in [I-D.ietf-mpls-seamless-mpls] should be used 964 as a reference. 966 o In the Seamless-MPLS reference topology in previous section: 968 * Failure of intra-domain links should limit loss of connectivity 969 (LoC) to < 50ms. E.g., PE11 to a P node (not shown), 121 to a 970 P node in Domain1 or Domain2) 972 * Failure of an intra-domain node (P node in any domain) should 973 limit LoC to < 50ms 975 * Failure of an ABR node (e.g., 121, 231) should limit LoC to < 976 1sec 978 * Failure of a remote PE node (e.g., PE3) should limit LoC to < 979 1sec 981 o In the Inter-AS Option C VPN reference topology in previous 982 section: 984 * Failure of intra-domain links should limit LoC to < 50ms. 985 E.g., PE11 to a P node (not shown), 121 to a P node in Domain1 986 or Domain2) 988 * Failure of an intra-domain node (P node in any domain) should 989 limit LoC to < 50ms 991 * Failure of an ASBR node (e.g., 121, 211) should limit LoC to < 992 1sec 994 * Failure of a remote PE node (e.g., PE3) should limit LoC to < 995 1sec 997 * Failure of an external link (e.g., 121-211) should limit LoC to 998 < 1sec 1000 o The solution should explore and describe additional techniques and 1001 design options that are applicable to further improve handling of 1002 the failure cases listed above. 1004 7. BGP Protocol Requirements 1006 o Support signaling and distribution of different Color-Aware routes 1007 to reach a participating node, e.g., a PE. Intent should be 1008 indicated by the notion of a Color as defined in SR Policy 1009 Architecture. 1011 * Signal different instances of a prefix distinguished by color 1013 * Signal intent associated with a given route 1015 o Support for a flexible NLRI definition to accommodate both 1016 efficiency of processing (e.g., packing) and future extensibility 1018 * Avoid limitations associated with existing SAFI NLRI 1019 definitions. For example, 24-bit label. 1021 o Support for validation of paths 1023 * Reachability of next-hop in control plane 1025 * Availability and programming of encapsulation in data plane 1026 * Validation of intent 1028 o Next-hop resolution for Color-Aware route 1030 * Flexibility to use different intra-domain and inter-domain 1031 mechanisms - IGP-FA, SR-TE, RSVP-TE, IGP, BGP-LU etc. 1033 * Recursive resolution over BGP Color-Aware routes 1035 * Ability to carry end-to-end cumulative metric for a given color 1037 * Support setting up an end-to-end Color-Aware path using a 1038 different/less preferred or best-effort paths in domains where 1039 a particular intent is not available 1041 o Separation of transport and VPN service semantics. 1043 * Allow for different route distribution planes for service vs 1044 transport routes. 1046 o Support signaling of different transport encapsulations 1048 o Support for signaling multiple encapsulations for co-existence and 1049 migration 1051 o Generation of BGP Color-Aware routes sourced from IGP-FA, SR-TE 1052 policies and BGP-LU from a domain 1054 o Support signaling across domains with different color mappings for 1055 a given intent. 1057 8. Future Considerations 1059 Multicast service intent 1061 9. Acknowledgements 1063 Many people contributed to this document. 1065 The authors would especially like to thank Jim Uttaro for his 1066 guidance on the work and feedback on many aspects of the problem 1067 statement. We would also like to thank Daniel Voyer, Luay Jalil and 1068 Robert Raszuk for their review and valuable suggestions. 1070 We also express our appreciation to Bruno Decreane, Keyur Patel, Jim 1071 Guichard, Alex Bogdanov, Dirk Steinberg, Hannes Gredler and Xiaohu Hu 1072 for discussions on several topics that have helped provide input to 1073 the document. We also thank Huaimo Chen for his valuable review 1074 comments. 1076 The authors would like to thank Stephane Litkowski for his detailed 1077 review and for making valuable suggestions to improve the quality of 1078 the document. We would also like to thank Kamran Raza and Kris 1079 Michelson for their review and comments on the document and to Simon 1080 Spraggs, Jose Liste and Jiri Chaloupka for their early inputs on the 1081 problem statement. 1083 10. References 1085 10.1. Normative References 1087 [I-D.agrawal-spring-srv6-mpls-interworking] 1088 Agrawal, S., Ali, Z., Filsfils, C., Voyer, D., and Z. Li, 1089 "SRv6 and MPLS interworking", draft-agrawal-spring-srv6- 1090 mpls-interworking-03 (work in progress), August 2020. 1092 [I-D.ietf-bess-srv6-services] 1093 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 1094 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 1095 Overlay services", draft-ietf-bess-srv6-services-05 (work 1096 in progress), November 2020. 1098 [I-D.ietf-idr-bgp-ipv6-rt-constrain] 1099 Patel, K., Raszuk, R., Djernaes, M., Dong, J., and M. 1100 Chen, "IPv6 Extensions for Route Target Distribution", 1101 draft-ietf-idr-bgp-ipv6-rt-constrain-12 (work in 1102 progress), April 2018. 1104 [I-D.ietf-idr-tunnel-encaps] 1105 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 1106 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 1107 encaps-21 (work in progress), January 2021. 1109 [I-D.ietf-lsr-flex-algo] 1110 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1111 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1112 algo-13 (work in progress), October 2020. 1114 [I-D.ietf-spring-segment-routing-policy] 1115 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1116 P. Mattes, "Segment Routing Policy Architecture", draft- 1117 ietf-spring-segment-routing-policy-09 (work in progress), 1118 November 2020. 1120 [I-D.ietf-spring-sr-service-programming] 1121 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1122 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1123 Henderickx, W., and S. Salsano, "Service Programming with 1124 Segment Routing", draft-ietf-spring-sr-service- 1125 programming-03 (work in progress), September 2020. 1127 [I-D.ietf-spring-srv6-network-programming] 1128 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 1129 Matsushima, S., and Z. Li, "SRv6 Network Programming", 1130 draft-ietf-spring-srv6-network-programming-28 (work in 1131 progress), December 2020. 1133 [I-D.voyer-pim-sr-p2mp-policy] 1134 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 1135 Zhang, "Segment Routing Point-to-Multipoint Policy", 1136 draft-voyer-pim-sr-p2mp-policy-02 (work in progress), July 1137 2020. 1139 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1140 Requirement Levels", BCP 14, RFC 2119, 1141 DOI 10.17487/RFC2119, March 1997, 1142 . 1144 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1145 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1146 February 2006, . 1148 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 1149 R., Patel, K., and J. Guichard, "Constrained Route 1150 Distribution for Border Gateway Protocol/MultiProtocol 1151 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 1152 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 1153 November 2006, . 1155 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1156 "Multiprotocol Extensions for BGP-4", RFC 4760, 1157 DOI 10.17487/RFC4760, January 2007, 1158 . 1160 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 1161 Subsequent Address Family Identifier (SAFI) and the BGP 1162 Tunnel Encapsulation Attribute", RFC 5512, 1163 DOI 10.17487/RFC5512, April 2009, 1164 . 1166 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 1167 Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, 1168 . 1170 [RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, 1171 "The Accumulated IGP Metric Attribute for BGP", RFC 7311, 1172 DOI 10.17487/RFC7311, August 2014, 1173 . 1175 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1176 Patel, "Revised Error Handling for BGP UPDATE Messages", 1177 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1178 . 1180 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1181 Writing an IANA Considerations Section in RFCs", BCP 26, 1182 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1183 . 1185 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1186 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1187 May 2017, . 1189 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 1190 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 1191 . 1193 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1194 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1195 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1196 July 2018, . 1198 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1199 and J. Hardwick, "Path Computation Element Communication 1200 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1201 DOI 10.17487/RFC8664, December 2019, 1202 . 1204 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 1205 A., and H. Gredler, "Segment Routing Prefix Segment 1206 Identifier Extensions for BGP", RFC 8669, 1207 DOI 10.17487/RFC8669, December 2019, 1208 . 1210 10.2. Informative References 1212 [I-D.filsfils-spring-sr-policy-considerations] 1213 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1214 P. Mattes, "SR Policy Implementation and Deployment 1215 Considerations", draft-filsfils-spring-sr-policy- 1216 considerations-06 (work in progress), October 2020. 1218 [I-D.ietf-idr-performance-routing] 1219 Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C. 1220 Jacquenet, "Performance-based BGP Routing Mechanism", 1221 draft-ietf-idr-performance-routing-03 (work in progress), 1222 December 2020. 1224 [I-D.ietf-mpls-seamless-mpls] 1225 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 1226 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 1227 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 1229 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 1230 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 1231 RFC 3906, DOI 10.17487/RFC3906, October 2004, 1232 . 1234 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1235 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1236 DOI 10.17487/RFC4271, January 2006, 1237 . 1239 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1240 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1241 . 1243 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1244 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1245 2006, . 1247 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1248 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1249 and Authentication for Routing Protocols (KARP) Design 1250 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1251 . 1253 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 1254 "Advertisement of Multiple Paths in BGP", RFC 7911, 1255 DOI 10.17487/RFC7911, July 2016, 1256 . 1258 Authors' Addresses 1260 Dhananjaya Rao 1261 Cisco Systems 1262 USA 1264 Email: dhrao@cisco.com 1266 Swadesh Agrawal 1267 Cisco Systems 1268 USA 1270 Email: swaagraw@cisco.com 1272 Clarence Filsfils 1273 Cisco Systems 1274 Belgium 1276 Email: cfilsfil@cisco.com 1278 Ketan Talaulikar 1279 Cisco Systems 1280 India 1282 Email: ketant@cisco.com 1284 Bruno Decraene 1285 Orange 1286 France 1288 Email: bruno.decraene@orange.com 1290 Dirk Steinberg 1291 Steinberg Consulting 1292 Germany 1294 Email: dws@dirksteinberg.de 1295 Luay Jalil 1296 Verizon 1297 USA 1299 Email: luay.jalil@verizon.com 1301 Jim Guichard 1302 Futurewei 1303 USA 1305 Email: james.n.guichard@futurewei.com 1307 Wim Henderickx 1308 Nokia 1309 Belgium 1311 Email: wim.henderickx@nokia.com