idnits 2.17.1 draft-dskc-bess-bgp-car-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 859 has weird spacing: '... policy v :...' -- The document date (February 22, 2021) is 1159 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BGP-CAR-Problem-Statement' is mentioned on line 1404, but not defined == Unused Reference: 'I-D.ietf-idr-bgp-ipv6-rt-constrain' is defined on line 1657, but no explicit reference was found in the text == Unused Reference: 'RFC4360' is defined on line 1690, but no explicit reference was found in the text == Unused Reference: 'RFC4684' is defined on line 1694, but no explicit reference was found in the text == Unused Reference: 'RFC5512' is defined on line 1706, but no explicit reference was found in the text == Unused Reference: 'RFC5701' is defined on line 1712, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mpls-seamless-mpls' is defined on line 1752, but no explicit reference was found in the text == Unused Reference: 'RFC3906' is defined on line 1757, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 1762, but no explicit reference was found in the text == Unused Reference: 'RFC4272' is defined on line 1767, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 1771, but no explicit reference was found in the text == Unused Reference: 'RFC6952' is defined on line 1775, but no explicit reference was found in the text == Unused Reference: 'RFC7911' is defined on line 1781, but no explicit reference was found in the text == 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 ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) Summary: 1 error (**), 0 flaws (~~), 19 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: Standards Track C. Filsfils 5 Expires: August 26, 2021 K. Talaulikar 6 Cisco Systems 7 February 22, 2021 9 BGP Color-Aware Routing(CAR) 10 draft-dskc-bess-bgp-car-00 12 Abstract 14 This document describes a BGP based routing solution to establish 15 end-to-end intent-aware paths across a multi-domain service provider 16 transport network. This solution is called BGP Color-Aware Routing 17 (BGP CAR). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 26, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Color . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Colored vs Color-Aware . . . . . . . . . . . . . . . . . 4 59 2.3. Color Domains . . . . . . . . . . . . . . . . . . . . . . 4 60 2.4. BGP Color-Aware Routing . . . . . . . . . . . . . . . . . 5 61 3. BGP extensions for CAR . . . . . . . . . . . . . . . . . . . 5 62 3.1. Why a new SAFI is required . . . . . . . . . . . . . . . 5 63 3.2. Data Model of New SAFI . . . . . . . . . . . . . . . . . 5 64 3.3. Extensible, future-proof encoding . . . . . . . . . . . . 6 65 3.4. BGP CAR Family . . . . . . . . . . . . . . . . . . . . . 6 66 3.4.1. BGP CAR SAFI NLRI Format . . . . . . . . . . . . . . 7 67 3.4.2. CAR NLRI Type . . . . . . . . . . . . . . . . . . . . 8 68 3.4.3. Local-Color-Mapping (LCM) Extended Community . . . . 12 69 3.5. BGP transport CAR Route Origination . . . . . . . . . . . 13 70 3.6. BGP CAR Next-Hop Processing . . . . . . . . . . . . . . . 13 71 3.6.1. Validation . . . . . . . . . . . . . . . . . . . . . 13 72 3.6.2. Resolution . . . . . . . . . . . . . . . . . . . . . 14 73 3.7. AIGP Metric Computation . . . . . . . . . . . . . . . . . 15 74 3.8. Multiple color domains . . . . . . . . . . . . . . . . . 15 75 4. Steering a Colored Service Route onto an (E, C) BGP CAR route 17 76 4.1. E2E BGP transport CAR intent realized using IGP FA . . . 17 77 4.2. E2E BGP transport CAR intent realized using SR Policy . . 19 78 4.3. BGP transport CAR intent realized in a section of the 79 network . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 4.4. Transit network domains that do not support CAR . . . . . 23 81 5. Color Mapping Scenarios . . . . . . . . . . . . . . . . . . . 24 82 5.1. Single color domain containing network domains with N:N 83 color distribution . . . . . . . . . . . . . . . . . . . 24 84 5.2. Single color domain containing network domains with N:M 85 color distribution . . . . . . . . . . . . . . . . . . . 25 86 5.3. Multiple color domains . . . . . . . . . . . . . . . . . 25 87 6. Intent Use-cases . . . . . . . . . . . . . . . . . . . . . . 26 88 7. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 89 7.1. Data plane does not have to scale to Colors * PEs . . . . 27 90 7.1.1. Inter-Domain Hop by hop BGP CAR for PE routes . . . . 27 91 7.1.2. Hierarchical Design with Next-hop self at ingress 92 domain BR . . . . . . . . . . . . . . . . . . . . . . 29 93 7.1.3. Hierarchical Design with Next Hop Unchanged at 94 ingress domain BR . . . . . . . . . . . . . . . . . . 31 95 7.2. Automated Emulated-Pull Model to learn BGP CAR (PE, C) . 33 96 7.2.1. Subscription based BGP CAR Signaling . . . . . . . . 34 97 7.3. Additional Design Options . . . . . . . . . . . . . . . . 36 98 7.3.1. Anycast SID for transit inter-domain nodes . . . . . 36 99 7.3.2. Anycast SID for transport color endpoints i.e PEs . . 36 100 7.4. Convergence . . . . . . . . . . . . . . . . . . . . . . . 36 101 8. Interworking Scenarios . . . . . . . . . . . . . . . . . . . 37 102 9. Fault Handling . . . . . . . . . . . . . . . . . . . . . . . 37 103 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 104 10.1. BGP CAR NLRI Types Registry . . . . . . . . . . . . . . 37 105 10.2. BGP CAR NLRI TLV Registry . . . . . . . . . . . . . . . 38 106 10.3. Guidance for Designated Experts . . . . . . . . . . . . 38 107 10.4. BGP Extended Community Registry . . . . . . . . . . . . 38 108 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 109 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 110 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 111 13.1. Normative References . . . . . . . . . . . . . . . . . . 39 112 13.2. Informative References . . . . . . . . . . . . . . . . . 41 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 115 1. Introduction 117 1.1. Objectives 119 o Address the Transport problem statement and requirements described 120 in [dskc-bess-bgp-car-problem-statement] 122 o Define an inter-domain BGP-based Color-Aware Routing proposal to 123 steer traffic for a C-colored service route V/v from a PE onto a 124 BGP color-aware path to (PE, C) 126 * Provide an alternative to the SR-PCE based design 127 [I-D.ietf-spring-segment-routing-policy] 129 1.2. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 2. Concepts 139 A refresher on core concepts used in this document, some of which are 140 described in [BGP-CAR-Problem-Statement] 142 2.1. Color 144 The solution must reuse the color concept defined in [I-D.ietf- 145 spring-segment-routing-policy]. The color is a 32-bit numerical 146 value that, today, associates an SR-policy with an intent (e.g., low 147 latency). 149 2.2. Colored vs Color-Aware 151 o Colored: Egress PE PE2 colored its BGP VPN route V/v to indicate 152 the intent that it requests for the traffic bound to V/v. 154 o Color-Aware: a new BGP solution which signals multiple "ways" to 155 reach a given destination (e.g. PE2) 157 o Steering a colored VPN route to a color-aware route 159 * If PE2 signals a VPN route V/v with color C 161 * If PE1 installs that VPN route 163 * If PE1 learns about a BGP Color-Aware Route R/r to PE2 for 164 color C 166 * Then PE1 steers packets destined to V/v via R/r 168 2.3. Color Domains 170 A domain (or network domain) generally refers to a unit of isolation 171 or hierarchy in the network topology; for example, access, metro and 172 or core domains. From a routing perspective, a domain may have a 173 distinct IGP area or instance; or a distinct BGP ASN. 175 With the use of a 'Color' to represent intent, it is useful to 176 describe the distinct concept of a color domain. 178 A color domain refers to a collection of one or more network domains 179 with a single, consistent color-to-intent mapping. 181 When a route gets distributed into a domain with a different color- 182 to-intent mapping scheme, the color associated with the route needs 183 to be mapped to the locally assigned value in that domain. 185 Deployments under a single authority are expected to use the same 186 color-to-intent mapping across all network domains. 188 A solution must distinguish the actual protocol boundaries (IGP, ASN) 189 from the color domain boundaries. 191 2.4. BGP Color-Aware Routing 193 In the remainder of this document, the BGP Color-Aware Routing 194 Solution is referred to as BGP CAR. 196 3. BGP extensions for CAR 198 This section analyzes the requirements for BGP CAR and proposes 199 extensions, specifically for Transport Color-Aware-Routing 201 3.1. Why a new SAFI is required 203 o Existing BGP SAFI for BGP-LU (AFI 1 or 2 and SAFI 4) signals 204 transport destination (likely PE loopback) with just an IP prefix 205 in NLRI. 207 * BGP CAR needs to signal multiple "ways" to reach a transport 208 destination, each for a different intent or color; i.e., it 209 needs a Color-Aware NLRI 211 o Hence, a new SAFI is needed for BGP Transport CAR which can encode 212 IP prefix and Color 214 3.2. Data Model of New SAFI 216 The essential elements of the data model for the transport CAR SAFI 217 are as follows: 219 o NLRI Key: E, C 221 * E: IPv4/IPv6 prefix: Prefix is unique in inter-domain network. 223 * Color: Distinguishes per-intent instances of a prefix. 224 Additionally, it signals the intent provided by with the route 225 in originator color domain. 32-bit value as per [I-D.ietf- 226 spring-segment-routing-policy] 228 o NLRI non key data 230 * To encode multiple encapsulations with efficient packing 232 + MPLS label stack 234 + Label Index (hint for label allocation from SRGB - same as 235 BGP SR Prefix SID Attr Label Index TLV) 237 + SRv6 SID(s) 238 + Etc. 240 o Next-Hop 242 * BGP Next-Hop 244 o AIGP Metric 246 * To accumulate color/intent specific metric across domains 248 * AIGP Attribute provides extensibility via TLVs, enabling 249 definition of additional metric semantics for a color as needed 250 for an intent 252 o Local-Color-Mapping Extended-Community (LCM-EC) 254 * 32-bit Color value 256 * Optional, used when a CAR route propagates across domains with 257 different or inconsistent color-to-intent mapping schemes 259 The detailed protocol operations for these elements are described in 260 later sections. 262 3.3. Extensible, future-proof encoding 264 Since a new SAFI is required, it is prudent to define an 265 extensible encoding so that additional use-cases can be supported 266 in future, without imposing limitations 268 Key design aspects for an extensible encoding: 270 Encode a NLRI (Route) Type field. This provides extensibility 271 to add new NLRI formats for new route-types 273 Encode a key length field. This enables handling unsupported 274 route-types opaquely, enabling transitivity via RRs 276 Define non-key NLRI data using TLVs. This enables flexible and 277 efficient encoding of data such as multiple encapsulations 279 3.4. BGP CAR Family 281 BGP CAR leverages the BGP multi-protocol extensions [RFC4760] and 282 uses the MP_REACH_NLRI and MP_UNREACH_NLRI attributes for routes 283 updates by using the SAFI value TBD1 along with AFI 1 for IPv4 284 prefixes and AFI 2 for IPv6 prefixes. 286 BGP speakers MUST use BGP Capabilities Advertisement to ensure 287 support for processing of BGP CAR updates. This is done as specified 288 in [RFC4760], by using capability code 1 (multi-protocol BGP), with 289 AFI 1 and 2 (as required) and SAFI TBD1. 291 The sub-sections below specify the generic encoding of the BGP CAR 292 NLRI followed by the encoding for specific NLRI types introduced in 293 this document. 295 3.4.1. BGP CAR SAFI NLRI Format 297 The generic format for the BGP CAR Address-Family NLRI is shown 298 below: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | NLRI Length | Key Length | NLRI Type | // 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 305 | Type-specific Key Fields // 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type-specific Non-Key Fields (if applicable) // 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 where: 312 o NLRI Length: 1 octet field that indicates the length in octets of 313 the NLRI excluding the NLRI Length field itself. 315 o Key Length: 1 octet field that indicates the length in octets of 316 the NLRI type-specific key fields. Key length MUST be at least 2 317 less than the NLRI length. 319 o NLRI Type: 1 octet field that indicates the type of the BGP 320 Transport CAR NLRI. 322 o Type-Specific Key Fields: Depend on the NLRI type and of length 323 indicated by the Key Length. 325 o Type-Specific Non-Key Fields: optional and variable depending on 326 the NLRI type. The NLRI encoding allows for encoding of specific 327 non-key information associated with the route (i.e. the key) as 328 part of the NLRI for efficient packing of BGP updates. 330 The indication of the key length enables BGP Speakers to determine 331 the key portion of the NLRI and use it along with the NLRI Type field 332 in an opaque manner for handling of unknown or unsupported NLRI 333 types. This can help Route Reflectors (RR) to propagate NLRI types 334 introduced in the future in a transparent manner. 336 The NLRI encoding allows for encoding of specific non-key information 337 associated with the route (i.e. the key) as part of the NLRI for 338 efficient packing of BGP updates. 340 The non-key portion of the NLRI MUST be omitted while carrying it 341 within the MP_UNREACH_NLRI when withdrawing the route advertisement. 343 3.4.2. CAR NLRI Type 345 The Color-Aware Routes NLRI Type is used for advertisement of color- 346 aware routes and has the following format: 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | NLRI Length | Key Length | NLRI Type | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 |Prefix Length | IP Prefix (variable) // 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Color (4 octets) | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Followed by optional TLVs encoded as below: 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Type | Length | Value (variable) // 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 where: 366 o NLRI Length: variable 368 o Key Length: variable 370 o NLRI Type: 1 372 o Type-Specific Key Fields: as below 374 * Prefix Length: 1 octet field that carries the length of prefix 375 in bits. Length MUST be less than or equal to 32 for IPv4 376 (AFI=1) and less than or equal to 128 for IPv6 (AFI=2). 378 * IP Prefix: IPv4 or IPv6 prefix (based on the AFI). A variable 379 size field that contains the most significant octets of the 380 prefix, i.e., 1 octet for prefix length 1 to 8, 2 octets for 381 prefix length 9 to 16, 3 octets for prefix length 17 up to 24, 382 4 octets for prefix length 25 up to 32, and so on. The size of 383 the field MUST be less than or equal to 4 for IPv4 (AFI=1) and 384 less than or equal to 16 for IPv6 (AFI=2). 386 * Color: 4 octets that contains color value associated with the 387 prefix. It distinguish different instances of a prefix. 388 Additionally, it signals the intent associated with the route 389 in originator color domain. 391 o Type-Specific Non-Key Fields: specified in the form of optional 392 TLVs as below: 394 * Type: 1 octet field that contains the type of the non-key TLV 396 * Length: 1 octet field that contains the length of the value 397 portion of the non-key TLV in terms of octets 399 * Value: variable length field as indicated by the length field 400 and to be interpreted as per the type field. 402 The prefix is routable across the administrative domain where BGP 403 Transport CAR is deployed. It is possible that the same prefix is 404 originated by multiple BGP Transport CAR speakers in the case of 405 anycast addressing or multi-homing. 407 The Color is introduced to enable multiple route advertisements for 408 the same prefix. The color is associated with an intent (e.g. low- 409 latency) in originator color-domain. 411 The following sub-sections specify the non-key TLVs associated with 412 the Color-Aware Routes NLRI type. 414 3.4.2.1. Label TLV 416 The Label TLV is used for advertisement of color-aware routes along 417 with their MPLS labels and has the following format: 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type | Length | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Followed by one (or more) Labels encoded as below: 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Label |Rsrv |S| 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 where: 433 o Type : 1 435 o Length: variable, MUST be a multiple of 3 437 o Label Information: multiples of 3 octet fields to convey the MPLS 438 label(s) associated with the advertised color-aware route. It is 439 used for encoding a single label or a stack of labels as per 440 procedures specified in [RFC8277]. 442 When a BGP Transport CAR speaker is propagating the route further 443 after setting itself as the nexthop, it allocates a local label for 444 the specific prefix and color combination which it updates in this 445 TLV. It also MUST program a label cross-connect that would result in 446 the label swap operation for the incoming label that it advertises 447 with the label received from its best-path router(s). 449 3.4.2.2. Label Index TLV 451 The Label Index TLV is used for advertisement of Segment Routing MPLS 452 (SR-MPLS) Segment Identifier (SID) [RFC8402] information associated 453 with the labelled color-aware routes and has the following format: 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type | Length | Reserved | Flags ~ 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 ~ | Label Index ~ 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 ~ | 463 +-+-+-+-+-+-+-+-+ 465 where: 467 o Type : 2 469 o Length: 7 471 o Reserved: 1 octet field that MUST be set to 0 and ignored on 472 receipt. 474 o Flags: 2 octet field that maps to the Flags field of the Label- 475 Index TLV of the BGP Prefix SID Attribute [RFC8277]. 477 o Label Index: 4 octet field that maps to the Label Index field of 478 the Label-Index TLV of the BGP Prefix SID Attribute [RFC8277]. 480 This TLV provides the equivalent functionality as Label-Index TLV of 481 [RFC8669] for Transport CAR in SR-MPLS deployments. The BGP Prefix 482 SID Attribute SHOULD be omitted from the labeled color-aware routes 483 when the attribute is being used to only convey the Label Index TLV 484 for better BGP packing efficiency. 486 When a BGP Transport CAR speaker is propagating the route further 487 after setting itself as the nexthop, it allocates a local label for 488 the specific prefix and color combination. When the received update 489 has the Label Index TLV, it SHOULD use that hint to allocate the 490 local label from the SR Global Block (SRGB) using procedures as 491 specified in [RFC8669]. 493 3.4.2.3. SRv6 SID TLV 495 BGP Transport CAR can be also used to setup end-to-end color-aware 496 connectivity using Segment Routing over IPv6 (SRv6) [RFC8402]. 497 [I-D.ietf-spring-srv6-network-programming] specifies the SRv6 498 Endpoint behaviors (e.g. End PSP) which MAY be leveraged for BGP CAR 499 with SRv6.The SRv6 SID TLV is used for advertisement of color-aware 500 routes along with their SRv6 SIDs and has the following format: 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Type | Length | SRv6 SID Info (variable) // 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 where: 510 o Type : 3 512 o Length: variable, MUST be either less than or equal to 16, or be a 513 multiple of 16 515 o SRv6 SID Information: field of size as indicated by the length 516 that either carries the SRv6 SID(s) for the advertised color-aware 517 route as one of the following: 519 * A single 128-bit SRv6 SID or a stack of 128-bit SRv6 SIDs 521 * A transposed portion (refer [I-D.ietf-bess-srv6-services]) of 522 the SRv6 SID that MUST be of size in multiples of one octet and 523 less than 16. 525 The BGP color-aware route update for SRv6 MUST include the BGP 526 Prefix-SID attribute along with the TLV carrying the SRv6 SID 527 information as specified in [I-D.ietf-bess-srv6-services] when using 528 the transposition scheme of encoding for packing efficiency of BGP 529 updates. 531 3.4.3. Local-Color-Mapping (LCM) Extended Community 533 This document defines a new BGP Extended Community called "LCM". The 534 LCM is a Transitive Opaque Extended Community with the following 535 encoding: 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Type=0x3 | Sub-Type=TBD2 | Reserved | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Color | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 where: 547 o Type: 0x3 549 o Sub-Type: TBD2. 551 o Reserved: 2 octet of reserved field that MUST be set to zero on 552 transmission and ignored on reception. 554 o Color: 4-octet field that carries the 32-bit color value. 556 When CAR route crosses the original color domain boundary, LCM EC is 557 added. LCM EC associate the local color mapping for the intent (e.g. 558 low latency) in transit or remote color domain. Note: reminder "BGP 559 CAR needs to signal multiple "ways" to reach a transport destination, 560 each for a different intent or color". Original BGP CAR route (E, C) 561 still signal multiple "ways" to reach E, but once LCM EC is added, 562 intent is carried in it and not by C in NLRI. 564 The LCM EC MAY be used for filtering of BGP CAR routes and/or for 565 applying routing policies for the intent. 567 3.5. BGP transport CAR Route Origination 569 o BGP CAR routes may be originated from a node via local injection 570 (e.g., loopback) 572 * Routes will be advertised with Implicit-NULL (or equivalent), 573 and optionally may include Label-Index 575 o BGP Transport CAR routes may also be originated from a node, 576 sourced from another mechanism 578 * IGP Flexible Algorithm(FA) [I-D.ietf-lsr-flex-algo] 579 redistribution 581 + FA identifier mapping to BGP transport CAR color or vice 582 versa by local policy. This will allow redistribution of 583 prefixes, prefix SID between FA and BGP CAR 585 * SR Policy [I-D.ietf-spring-segment-routing-policy] 587 + An SR Policy is identified through the tuple (color, E) 588 where color is a 32-bit numerical value that associates the 589 SR Policy with an intent (e.g. low-latency). When color of 590 SR policy maps directly into BGP CAR color because of same 591 intent or through some local configuration, endpoint of 592 policy can be advertised in BGP Transport CAR to rest of 593 network for end to end color-aware transport connectivity. 595 * BGP-LU [RFC8277] 597 + Redistribution between BGP-LU and BGP CAR color table and 598 vice versa. Most likely(but not limited) color represents 599 best effort intent in BGP CAR domain. This provide 600 connectivity between BGP-LU only domain and BGP CAR domain 601 with best effort color-awareness. 603 3.6. BGP CAR Next-Hop Processing 605 3.6.1. Validation 607 o Validation of BGP Next-Hop: Reachability verified via underlying 608 routing control plane. Local policy should be provided to verify 609 it 611 * Strictly within intent of BGP CAR route i.e "color" 612 * Default routing table 614 * Skip it when updates are propagated out of band 616 o Validation of Encapsulation: Validate data-plane availability of 617 encapsulation before using and propagating further. 619 o Validation of the intent: Validate the intent provided by the 620 underlying transport (e.g., via OAM), where applicable. 622 3.6.2. Resolution 624 BGP color-aware routes may be resolved over various intra-domain and 625 inter-domain mechanisms that provide connectivity to the BGP next-Hop 626 with the desired intent 628 o Leverage the notion of "color" in NLRI or LCM-EC to determine the 629 matching intent-aware mechanism and instance. 631 o Leverage ODN/AS mechanisms where needed, for instance to use SR- 632 PCE for an SR-policy to the BGP next-hop 634 o Flexible for all encapsulations 636 * (SR-)MPLS 638 * SRv6, IPv4/IPv6, etc. 640 o Flexible over various underlay mechanisms 642 * SR Policy: Color from BGP CAR route and policy endpoint from 643 BGP CAR Next hop 645 * IGP Flexible Algorithm: Color from BGP CAR mapped to Flex Algo 646 by configuration. 648 * IGP/BGP best effort (SR, LDP, RSVP-TE, BGP-LU etc.) 650 * BGP CAR in hierarchical CAR design 652 o Support selection preference among available mechanisms 654 o Fallback to a different color or best effort path 656 3.7. AIGP Metric Computation 658 o BGP CAR nodes update the Accumulated IGP (AIGP) Attribute as the 659 BGP CAR route propagates across the network. 661 o The value set (or appropriately incremented) in the AIGP TLV 662 corresponds to the metric associated with the underlying intent of 663 the color. Example. when the color is associated with a low- 664 latency path, the metric value is set based on the delay metric. 666 * Information regarding the metric type used by the underlying 667 intra-domain mechanism can also be set 669 o If BGP CAR routes traverse across a discontinuity in the transport 670 path for a given intent, add penalty in accumulated IGP 672 o If BGP CAR routes traverse across a discontinuity in the transport 673 path for a given intent, the AIGP TLV is used to indicate this 674 e.g. with a discontinuity bit. 676 o AIGP metric computation is recursive. 678 o To avoid continuous IGP metric churn causing end to end BGP CAR 679 churn, implementation should provide thresholds to trigger AIGP 680 update. 682 o Additional AIGP extensions may be defined to signal state for 683 specific use-cases. 685 * MSD along the BGP CAR advertisement. 687 * Minimum MTU along the BGP CAR advertisement. 689 3.8. Multiple color domains 691 o When BGP CAR routes get distributed to a domain with a different 692 color-to-intent mapping, the color signaled must be re-mapped to 693 the local color being used within the receiving domain 695 o A key requirement to consider is the separation and independence 696 of the administrative authority in different color domains. 698 * Each color domain needs to use its own local color. The route 699 can traverse multiple such color domains where the color 700 mappings change 702 o This requirement is addressed by the following steps : 704 * The NLRI of the CAR route is never changed 706 + E is globally unique. Hence even if C is local-domain 707 significant, E-C in that order is globally unique 709 * Each color domain needs to use its own local color. The route 710 can traverse multiple such color domains where the color 711 mappings change 713 + To address this requirement, a border node in a color domain 714 encodes its local color mapping in a Local-Color-Mapping 715 Extended-Community when sending the route to a peer in a 716 different color domain 718 + The border routers within the receiving domain map the 719 received LCM-EC Color value to a local color assigned for 720 that intent and rewrite the LCM-EC 722 + The nodes within the receiving domain use the local color 723 encoded in the LCM-EC for next-hop resolution and BGP CAR 724 route installation 726 o The LCM-EC is only used when a CAR route needs to be distributed 727 across a color domain boundary. The likely case (color 728 consistency) is supported with the simplest and most efficient 729 scheme (E, C) key and no LCM-EC. 731 o Example: When going from a domain D1 to a domain D2 where D1 uses 732 the color scheme is the NLRI but D2 uses another color scheme, 733 then on the peering session from D1 to D2, D1 on egress or D2 on 734 ingress inserts the LCM-EC which carries the mapped local color 735 that will be used in D2. When the route travels from D2 to a 736 domain D3 which uses the color scheme in the NLRI then either the 737 LCM-EC is kept but its internal C is remapped to the color scheme 738 of D3 or the LCM-EC is removed 740 o Color intent encoded in the service routes in the Color Ext- 741 community should also be re-mapped consistently 743 o A color boundary is typically well-defined, at a BGP peering 744 session on a border Router, and at a service/transport RR. 746 o A color domain may extend across one or more BGP ASNs 748 4. Steering a Colored Service Route onto an (E, C) BGP CAR route 750 BGP colored service routes (i.e., containing Color extended community 751 [I-D.ietf-idr-tunnel-encaps]) resolve over BGP transport CAR routes 752 i.e. (E, C), conceptually identical to the steering mechanism used 753 with SR Policies. 755 All steering options are supported: Automated, on-demand steering, 756 per-destination, per-flow, CO-only 758 Co-existence with SR-policy based steering is also supported 760 By default, when BGP CAR is enabled, a BGP CAR route will be 761 preferred. 763 Similarly, if an IGP Flex-Algo route exists, typically for an 764 intra-domain endpoint, it is preferred over a BGP CAR route to 765 the same endpoint. 767 A node may support a local policy to set the preferences 768 between different mechanisms. 770 The following sub-sections illustrate example scenarios of Colored 771 Service Route Steering over E2E BGP CAR resolving over different 772 intra-domain mechanisms 774 4.1. E2E BGP transport CAR intent realized using IGP FA 775 RD:V/v via E2 776 +-----+ vpn label: 30030 +-----+ 777 ...... |S-RR1| <..................................|S-RR2| <....... 778 : +-----+ Color C1 +-----+ : 779 : : 780 : : 781 : : 782 +-:-----------------------+----------------------+------------------:--+ 783 | : | | : | 784 | : | | : | 785 | : (E2,C1) via 121 | (E2,C1) via 231 | (E2,C1)via E2 : | 786 | : L=168002,AIGP=110 +---+ L=168002,AIGP=10 +---+ L=0x3,LI=8002 : | 787 | : |-------------------|121|<-----------------|231|<-------------| : | 788 | : V LI=8002 +---+ LI=8002 +---+ | : | 789 |----+ | | +-----| 790 | E1 | | | | E2 | 791 |----+(E2,C1) via 122 | (E2,C1) via 232 | (E2,C1)via E2+-----| 792 | ^ L=168002,AIGP=210 +---+ L=168002,AIGP=20 +---+ L=0x3 | | 793 | |---------------- |122|<-----------------|232|<-------------| | 794 | LI=8002 +---+ LI=8002 +---+ LI=8002 | 795 | | | | 796 | ISIS SR | ISIS SR | ISIS SR | 797 | FA 128 | FA 128 | FA 128 | 798 +-------------------------+----------------------+---------------------+ 799 iPE iABR eABR ePE 801 +------+ +------+ 802 |168121| |168231| 803 +------+ +------+ 804 +------+ +------+ +------+ 805 |168002| |168002| |168002| 806 +------+ +------+ +------+ 807 +------+ +------+ +------+ 808 |30030 | |30030 | |30030 | 809 +------+ +------+ +------+ 811 Figure 1: BGP FA Aware transport CAR path 813 Use case: Provide end to end intent for service flows. 815 o With reference to the topology above: 817 * IGP FA 128 is running in each domain. 819 * Egress PE E2 advertises a VPN route RD:V/v colored with (color 820 extended community) C1 to steer traffic to BGP transport CAR 821 (E2, C1). VPN route propagates via service RRs to ingress PE 822 E1. 824 * BGP CAR route (E2, C1) with next-hop, label-index and label as 825 shown above are advertised through border routers in each 826 domain. 828 * Local policy on each hop maps intent C1 to resolve CAR route 829 next-hop over IGP FA 128 of the domain. AIGP attribute 830 influences BGP CAR route best path decision as per [RFC7311]. 831 BGP CAR label swap entry is installed that goes over FA 128 LSP 832 to next-hop providing intent in each IGP domain. Update AIGP 833 metric to reflect FA 128 metric to next-hop. 835 * Ingress PE E1 learns CAR route (E2, C1). It steers colored VPN 836 route RD:V/v into (E2, C1) 838 o Important: 840 * IGP FA 128 top label provides intent in each domain. 842 * BGP CAR label (e.g. 168002) carries end to end intent. Thus 843 stitches intent over intra domain FA 128. 845 4.2. E2E BGP transport CAR intent realized using SR Policy 846 RD:1/8 via E2 847 +-----+ vpn label: 30030 +-----+ 848 ...... |S-RR1| <..................................|S-RR2| <...... 849 : +-----+ Color C1 +-----+ : 850 : : 851 : : 852 : : 853 +-:-----------------------+----------------------+------------------:-+ 854 | : | | : | 855 | : | | : | 856 | : <-(E2,C1) via 121 | <-(E2,C1) via 231 | <-(E2,C1)via E2 : | 857 | : +---+ +---+ : | 858 | : ------------------>|121|----------------->|231|--------------| : | 859 | : | SR policy(C,121) +---+ SR policy(C1,231)+---+ SR policy v : | 860 |----+ | | (C1,E2) +---| 861 | E1 | | | |E2 | 862 |----+ <-(E2,C1) via 122 | (E2,C1) via 232 | <-(E2,C1)via E2+---| 863 | | +---+ +---+ ^ | 864 | ------------------>|122|----------------->|232|---------------| | 865 | SR policy(C,122) +---+ SR policy(C1,232)+---+ SR policy(C1,E2) | 866 | | | | 867 | | | | 868 | ISIS SR | ISIS SR | ISIS SR | 869 +-------------------------+----------------------+--------------------+ 870 iPE iABR eABR ePE 872 Figure 2: BGP SR policy Aware transport CAR path 874 Use case: Provide end to end intent for service flows 876 o With reference to the topology above: 878 * SR Policy provide intra domain intent. 880 * Egress PE E2 advertises a VPN route RD:V/v colored with (color 881 extended community) C1 to steer traffic to BGP transport CAR 882 (E2, C1). VPN route propagates via service RRs to ingress PE 883 E1. 885 * BGP CAR route (E2, C1) with next-hop, label-index and label as 886 shown above are advertised through border routers in each 887 domain. 889 * Local policy on each hop maps intent C1 to resolve CAR route 890 next-hop over an SR policy(C1, next-hop). BGP CAR label swap 891 entry is installed that goes over SR policy segment list. 893 * Ingress PE E1 learns CAR route (E2, C1). It steers colored VPN 894 route RD:V/v into (E2, C1). 896 o Important: 898 * SR policy provides intent in each domain. 900 * BGP CAR label (e.g. 168002) carries end to end intent. Thus 901 stitches intent over intra domain SR policies. 903 4.3. BGP transport CAR intent realized in a section of the network 904 RD:1/8 via E2 905 +-----+ vpn label: 30030 +-----+ 906 ...... |S-RR1| <..................................|S-RR2| <....... 907 : +-----+ Color C1 +-----+ : 908 : : 909 : : 910 : : 911 +-:-----------------------+----------------------+------------------:--+ 912 | : | | : | 913 | : | | : | 914 | : (E2,C1) via 121 | (E2,C1) via 231 | (E2,C1) via E2 : | 915 | : L=168002,AIGP=1110+---+L=168002,AIGP=1010+---+ L=0x3 : | 916 | : |-------------------|121|<-----------------|231|<-------------| : | 917 | : V LI=8002 +---+ LI=8002 +---+ | : | 918 |----+ | | +-----| 919 | E1 | | | | E2 | 920 |----+(E2,C1) via 122 | (E2,C1) via 232 | (E2,C1) via E2+-----| 921 | ^ L=168002,AIGP=1210+---+L=168002,AIGP=1020+---+ L=0x3 | | 922 | |---------------- |122|<-----------------|232|<-------------| | 923 | LI=8002 +---+ LI=8002 +---+ | 924 | | | | 925 | ISIS SR | ISIS SR | ISIS SR | 926 | FA 0 | FA 128 | FA 0 | 927 | Access | Core | Access 928 +-------------------------+----------------------+---------------------+ 929 iPE iABR eABR ePE 931 +------+ +------+ 932 |160121| |168231| 933 +------+ +------+ 934 +------+ +------+ +------+ 935 |168002| |168002| |160002| 936 +------+ +------+ +------+ 937 +------+ +------+ +------+ 938 |30030 | |30030 | |30030 | 939 +------+ +------+ +------+ 941 Figure 3: BGP Hybrid FA Aware transport CAR path 943 Use case: Provide intent for service flows only in Core domain. 945 o With reference to the topology above: 947 * IGP FA 128 is only enabled in Core (e.g. WAN network). Access 948 only has base algo 0. 950 * Egress PE E2 advertises a VPN route RD:V/v colored with (color 951 extended community) C1 to steer traffic to BGP transport CAR 952 (E2, C1). VPN route propagates via service RRs to ingress PE 953 E1. 955 * BGP CAR route (E2, C1) with next-hop, label-index and label as 956 shown above are advertised through border routers in each 957 domain. 959 * Local policy on 231 and 232 maps intent C1 to resolve CAR route 960 next-hop over IGP base algo 0 in right access domain. BGP CAR 961 label swap entry is installed that goes over algo 0 LSP to 962 next-hop. Update AIGP metric to reflect algo 0 metric to next- 963 hop most likely with additional penalty. 965 * Local policy on 121 and 122 maps intent C1 to resolve CAR route 966 next-hop learnt from Core domain over IGP FA 128. BGP CAR 967 label swap entry is installed that goes over FA 128 LSP to 968 next-hop providing intent in Core IGP domain. 970 * Ingress PE E1 learns CAR route (E2, C1). It maps intent C1 to 971 resolve CAR route next-hop over IGP base algo 0. It steers 972 colored VPN route RD:V/v into (E2, C1) 974 o Important: 976 * IGP FA 128 top label provides intent in Core domain. 978 * BGP CAR label (e.g. 168002) carries intent from PEs which is 979 realized in core domain 981 4.4. Transit network domains that do not support CAR 983 o In a brownfield deployment, color-aware paths between two PEs may 984 need to go through a transit domain that does not support CAR. 985 Example include an MPLS LDP network with IGP best-effort; or a 986 BGP-LU based multi-domain network. MPLS LDP network with best 987 effort IGP can adopt above scheme. Below is the example for BGP 988 LU. 990 o Reference topology: 992 E1 --- BR1 --- BR2 ......... BR3 ---- BR4 --- E2 993 Ci <----LU----> Ci 995 * Network between BR2 and BR3 comprises of multiple BGP-LU hops 996 (over IGP-LDP domains). 998 * E1, BR1, BR4 and E2 are enabled for BGP CAR, with Ci colors 999 * BR1 and BR2 are directly connected; BR3 and BR4 are directly 1000 connected 1002 o BR1 and BR4 form an over-the-top peering (via RRs as needed) to 1003 exchange BGP CAR routes 1005 o BR1 and BR4 also form direct BGP-LU sessions to BR2 and BR3 1006 respectively, to establish labeled paths between each other 1007 through the BGP-LU network 1009 o BR1 recursively resolves the BGP CAR next-hop for CAR routes 1010 learnt from BR4 via the BGP-LU path to BR4 1012 o BR1 signals the transport discontinuity to E1 via the AIGP TLV, so 1013 that E1 can prefer other paths if available 1015 o BR4 does the same in the reverse direction 1017 o Thus, the color-awareness of the routes and hence the paths in the 1018 data plane are maintained between E1 and E2, even if the intent is 1019 not available within the BGP-LU island 1021 o A similar design can be used for going over network islands of 1022 other types 1024 5. Color Mapping Scenarios 1026 There are a variety of deployment scenarios that arise w.r.t 1027 different color mappings in an inter-domain environment. This 1028 section attempts to enumerate them to provide clarity into the usage 1029 of the color related protocol constructs. 1031 5.1. Single color domain containing network domains with N:N color 1032 distribution 1034 All network domains (ingress, egress and all transit domains) are 1035 enabled for the same N colors 1037 A color may of course be realized by different technologies in 1038 different domains as described above 1040 The N intents are both signaled end-to-end via BGP CAR routes; as 1041 well as realized in the data plane 1043 Section 4.1 is an example of this case 1045 5.2. Single color domain containing network domains with N:M color 1046 distribution 1048 Certain network domains may not be enabled for some of the colors, 1049 but may still be required to provide transit. 1051 When a (E, C) route traverses a domain where color C is not 1052 available, the operator may decide to use a different intent of color 1053 c that is available in that domain to resolve the next-hop and 1054 establish a path through the domain 1056 o The next-hop resolution may occur via paths of any intra-domain 1057 protocol or even via paths provided by BGP CAR 1059 o The next-hop resolution color c may be defined as a local policy 1060 at ingress or transit nodes of the domain 1062 o It may also be automatically signaled from egress border nodes by 1063 attaching a color extended community with value c to the BGP CAR 1064 routes 1066 Hence, routes of N colors may be resolved via a smaller set of M 1067 colored paths in a transit domain, while preserving the original 1068 intent end-to-end. 1070 Any ingress PE that installs a service (VPN) route with a color C, 1071 must have C enabled locally to install IP routes to (E, C) and 1072 resolve the service route next-hop 1074 A degenerate case of these scenario is where a transit domain does 1075 not support any color. Section 4.3 describes an example of this case 1077 5.3. Multiple color domains 1079 When the routes are distributed between domains with different color- 1080 to-intent mapping schemes, both N:N and N:M ratios are possible, 1081 although an N:M mapping is more likely to occur. 1083 Reference topology: 1085 D1 ----- D2 ----- D3 1086 C1 C2 C3 1088 o C1 in D1 maps to C2 in D2 and to C3 in D3 1090 o BGP CAR is enabled in all three domains 1091 The reference topology above is used to elaborate on the design 1092 described in Section-X 1094 When the route originates in color domain D1 and gets advertised to a 1095 different color domain D2, following procedures apply: 1097 The original intent in BGP CAR route is preserved; i.e. route is 1098 (E, C1) 1100 A BR of D1 attaches LCM-EC with value C1 when advertising to a BR 1101 in D2 1103 A BR in D2 receiving (E, C1) maps C1 in received LCM-EC to local 1104 color, say C2 1106 Within D2, this LCM-EC value of C2 is used instead of the Color in 1107 CAR route NLRI (E, C1). This applies to all procedures described 1108 in the earlier section for a single color domain, such as next-hop 1109 resolution and route installation. 1111 A colored service route V/v originated in domain D1 with next-hop 1112 E and color C1 will also have its color extended-community value 1113 re-mapped to C2, typically at a service RR 1115 On an ingress PE in D2, V/v will resolve via C2 1117 When a BR in D2 advertises the route to a BR in D3, a similar 1118 process is followed 1120 6. Intent Use-cases 1122 This section will describe how BGP CAR addresses the various intent 1123 use-cases described in [ref:dskc-bess-bgp-car-problem-statement]. 1124 Details will be added in a later revision of the document. 1126 7. Scaling 1128 A key requirement of [ref:dskc-bess-bgp-car-problem-statement] is 1129 scale, specifically: 1131 o No intermediate node dataplane should need to scale to (Colors * 1132 PEs) 1134 o No node should learn and install a BGP CAR route to (E,C) if it 1135 does not install a Colored service route to E 1137 * An intermediate node may learn a BGP CAR route to (E, C) in 1138 control plane if it is an inline RR to an ingress PE 1140 * An intermediate node may learn and install a BGP CAR route to 1141 (E, C) if it is set up to be the next-hop for an ingress PE 1142 that installs the BGP CAR route 1144 7.1. Data plane does not have to scale to Colors * PEs 1146 Depending on the scale of the network as well as the constraints 1147 associated with the nodes at different tiers, an appropriate design 1148 should be adopted. Three design variations are illustrated below. 1150 7.1.1. Inter-Domain Hop by hop BGP CAR for PE routes 1152 Reference topology is shown below, with the BGP signaling and the 1153 resulting BGP and example IGP label stack at different hops 1154 RD:V/v via E2 1155 +-----+ +-----+ vpn label:30030 +-----+ 1156 ....... |S-RR1| <........... |S-RR2| <...............|S-RR3| <...... 1157 : +-----+ +-----+ Color C1 +-----+ : 1158 : : 1159 : : 1160 : : 1161 +:------------+--------------+--------------+--------------+--------:-+ 1162 |: | | | | : | 1163 |: | (E2,C1) | (E2,C1) | (E2,C1) | : | 1164 |: +---+ via 231 +---+ via 341 +---+ via 451 +---+ : | 1165 |:(E2,C1) |121|<---------|231|<---------|341|<---------|451| : | 1166 |: via 121 /+---+ L=168002 +---+ L=168002 +---+ L=168002 +---+ : | 1167 |---+ / | | | | +---| 1168 | E1| <--/ | | | | | E2| 1169 |---+ L=168002| | | | +---| 1170 | +---+ +---+ +---+ +---+ | 1171 | |122| |232| |342| |452| | 1172 | +---+ +---+ +---+ +---+ | 1173 | Access | Metro | Core | Metro | Access | 1174 | domain 1 | domain 2 | domain 3 | domain 4 | domain 5 | 1175 +-------------+--------------+--------------+--------------+----------+ 1176 iPE iBRM iBRC eBRC eBRM ePE 1178 ------ ------ ------ ------ 1179 168121 168231 168341 168451 1180 ------ ------ ------ ------ 1181 ------ ------ ------ ------ ------ 1182 168002 168002 168002 168002 168002 1183 ------ ------ ------ ------ ------ 1184 ------ ------ ------ ------ ------ ----- 1185 30030 30030 30030 30030 30030 30030 1186 ------ ------ ------ ------ ------ ----- 1188 Figure 4: Single BGP transport CAR level 1190 o With reference to the topology above: 1192 * Consider egress PE E2 advertises a VPN (service) route RD:V/v 1193 that propagates via service RRs to ingress PE E1. 1195 * A BGP CAR route (E2, C1) is advertised by egress BRM node 451. 1196 The route may be sourced locally, for instance by 1197 redistribution from an IGP-FA, and is distributed hop-by-hop 1198 through egress Metro, Core, ingress Metro to Access 1200 * Node 451, 341, 231 and 121 learns BGP CAR route (E2, C1). Each 1201 allocate local label and program swap entry in forwarding and 1202 set itself as next-hop. 1204 * E1 receives route. It recursively resolves (E2, C1) to build 1205 an outgoing label/SID stack to forward via nodes 121 1207 o This is the simplest design, with a single BGP transport CAR level 1209 o This results in the minimum label/SID stack at each inter-domain 1210 hop. However, it can significantly build up the scale overhead on 1211 the core BRs, and can easily exceed the FIB capacity as well as 1212 the MPLS label space on these nodes. 1214 o A subscription based Emulated-Pull solution is required with this 1215 flat design to enable all the intermediate nodes to be able to 1216 avoid learning and installing all the (PE, C) entries in the 1217 network. 1219 7.1.2. Hierarchical Design with Next-hop self at ingress domain BR 1221 Reference topology is shown below, with the BGP signaling and the 1222 resulting BGP and example IGP label stack at different hops 1223 RD:V/v via E2 1224 +-----+ +-----+ vpn label:30030 +-----+ 1225 ....... |S-RR1| <........... |S-RR2| <...............|S-RR3| <...... 1226 : +-----+ +-----+ Color C1 +-----+ : 1227 : : 1228 : (E2,C1) : 1229 : +-----+ via 451 +-----+ : 1230 : |T-RR1| <-------------- |T-RR2| : 1231 : / +-----+ L=168002 +-----+\ : 1232 : / \ : 1233 +:------------+---/----------+--------------+-----------\--+--------:-+ 1234 |: | / | | \ | : | 1235 |: (E2,C1) | / (451,C1) | (451,C1) | \| : | 1236 |: via 121 +---+ via 231 +---+ via 341 +---+ +---+ : | 1237 |: L=168002 |121| <======= |231| <========|341| <======= |451| : | 1238 |: / +---+ L=168451 +---+ L=168451 +---+ +---+ : | 1239 |---+ / | | | | +---| 1240 | E1|<--/ | | | | | E2| 1241 |---+ | | | | +---| 1242 | +---+ +---+ +---+ +---+ | 1243 | |122| |232| |342| |452| | 1244 | +---+ +---+ +---+ +---+ | 1245 | Access | Metro | Core | Metro | Access | 1246 | domain 1 | domain 2 | domain 3 | domain 4 | domain 5 | 1247 +-------------+--------------+--------------+--------------+----------+ 1248 iPE iBRM iBRC eBRC eBRM ePE 1250 ------ ------ 1251 168231 168341 1252 ------ ------ 1253 ------ ------ ------ ------ 1254 168121 168451 168451 168451 1255 ------ ------ ------ ------ 1256 ------ ------ ------ ------ ------ 1257 168002 168002 168002 168002 168002 1258 ------ ------ ------ ------ ------ 1259 ------ ------ ------ ------ ------ ----- 1260 30030 30030 30030 30030 30030 30030 1261 ------ ------ ------ ------ ------ ----- 1263 Figure 5: Heirarchical BGP transport CAR, NH at iBR 1265 o With reference to the topology above: 1267 * Consider egress PE E2 advertises a VPN (service) route RD:V/v 1268 that propagates via service RRs to ingress PE E1. 1270 * A BGP CAR route (E2, C1) is also advertised by egress BRM node 1271 451. The route may be sourced locally, for instance by 1272 redistribution from an IGP-FA, and is distributed via a 1273 Transport RR plane. 1275 * Ingress BRM node 121 learns about BGP CAR route (E2, C1) via 1276 node 451. 1278 * Node 121 also learns about BGP CAR route (451, C1) via node 1279 231. 1281 * Node 121 advertise (E2, C1) received from T-RR to E1 with next- 1282 hop as it-self. It recursively resolves (E2, C1) to build an 1283 outgoing label/SID stack to forward traffic to (E1, C1) via 1284 (451, C1) 1286 * (451, C1) is not advertised to node 121 1288 * E1 receives route. It recursively resolves (E2, C1) to build 1289 an outgoing label/SID stack to forward via nodes 121 1291 * Ingress BRM node 121 needs to install data plane entry for 1292 (451, C1), and for (E2, C1). 1294 o This hierarchical design avoids the need for core BRs to learn and 1295 install entries for (PE, C) 1297 o An ingress BR (e.g., node 121) advertises the received remote (PE, 1298 C) routes to it's local ingress PE, setting next-hop to itself 1300 * Hence, the ingress BR need to install (PE, C) entries for 1301 egress PEs that it's local ingress PEs have installed BGP CAR 1302 routes for, as well as support a swap and push operation. 1304 o This design keeps simple label programming on the ingress PE i.e. 1305 like single BGP transport CAR level. It is not exposed to 1306 hierarchical BGP CAR design at ingress BRM 1308 o A subscription based Emulated-Pull model should be used with this 1309 design if the ingress BR has limited FIB capacity, and should only 1310 learn and install the necessary subset of (PE, C) routes. 1312 7.1.3. Hierarchical Design with Next Hop Unchanged at ingress domain BR 1314 Reference topology is shown below, with the BGP signaling and the 1315 resulting BGP and example IGP label stack at different hops. 1317 RD:V/v via E2 1318 +-----+ +-----+ vpn label:30030 +-----+ 1319 ....... |S-RR1| <........... |S-RR2| <...............|S-RR3| <...... 1320 : +-----+ +-----+ Color C1 +-----+ : 1321 : : 1322 : (E2,C1) : 1323 : +-----+ via 451 +-----+ : 1324 : |T-RR1| <-------------- |T-RR2| : 1325 : / +-----+ L=168002 +-----+\ : 1326 : / \ : 1327 +:------------+---/----------+--------------+-----------\--+--------:-+ 1328 |: | / | | \ | : | 1329 |: (E2,C1) | / (451,C1) | (451,C1) | \| : | 1330 |: via 451 +---+ via 231 +---+ via 341 +---+ +---+ : | 1331 |: L=168002/|121| <======= |231| <========|341| <======= |451| : | 1332 |: / +---+ L=168451 +---+ L=168451 +---+ +---+ : | 1333 |---+ <--/ //| | | | +---| 1334 | E1| // | | | | | E2| 1335 |---+ <===// | | | | +---| 1336 | (451,C1) +---+ +---+ +---+ +---+ | 1337 | via 121 |122| |232| |342| |452| | 1338 | L=168451 +---+ +---+ +---+ +---+ | 1339 | | | | | | 1340 | Access | Metro | Core | Metro | Access | 1341 | domain 1 | domain 2 | domain 3 | domain 4 | domain 5 | 1342 +-------------+--------------+--------------+--------------+----------+ 1343 iPE iBRM iBRC eBRC eBRM ePE 1345 ------ ------ ------ 1346 168121 168231 168341 1347 ------ ------ ------ 1348 ------ ------ ------ ------ 1349 168451 168451 168451 168451 1350 ------ ------ ------ ------ 1351 ------ ------ ------ ------ ------ 1352 168002 168002 168002 168002 168002 1353 ------ ------ ------ ------ ------ 1354 ------ ------ ------ ------ ------ ----- 1355 30030 30030 30030 30030 30030 30030 1356 ------ ------ ------ ------ ------ ----- 1358 Figure 6: Heirarchical BGP transport CAR, NHU at iBR 1360 o With reference to the topology above: 1362 * Consider egress PE E2 advertises a VPN (service) route RD:V/v 1363 that propagates via service RRs to ingress PE E1. 1365 * A BGP CAR route (E2, C1) is also advertised by egress BRM node 1366 451. The route may be sourced locally, for instance by 1367 redistribution from an IGP-FA, and is distributed via a 1368 Transport RR plane. 1370 * Ingress BRM node 121 learns about BGP CAR route (E2, C1) via 1371 node 451. 1373 * Node 121 also learns about BGP CAR route (451, C1) via node 1374 231. 1376 * Node 121 advertises both routes to E1. 1378 * (E2, C1) is advertised with NH via node 451; i.e., next-hop 1379 unchanged 1381 * (451, C1) is advertised with next-hop 121 i.e., next-hop self 1382 and local label 16451 1384 * Hence, E1 receives both routes. It recursively resolves (E2, 1385 C1) to build an outgoing label/SID stack to forward traffic to 1386 E1, via nodes 121 and 451. 1388 * Ingress BRM node 121 only needs to install data plane entry for 1389 (451, C1), and not for (E2, C1). 1391 o In summary, with this design: 1393 * Only E1 needs to learn and install (E2, C1) because it has to 1394 install a service route RD:V/v with next-hop E2, and associated 1395 with a Color C1 1397 * However, E1 incurs additional complexity to perform the 1398 additional recursion to build and program the label stack. The 1399 complexity increases when there are multiple paths to be load- 1400 balanced across. 1402 7.2. Automated Emulated-Pull Model to learn BGP CAR (PE, C) 1404 From [BGP-CAR-Problem-Statement], we remind: 1406 o The SR-PCE solution natively supports a PULL model: when E1 1407 installs a VPN route V/v via (E2, C1), E1 requests its serving SR- 1408 PCE to compute the SR Policy to (E2, C1). I.e. E1 does not learn 1409 unneeded SR policies. 1411 o BGP Signaling is natively a PUSH model. 1413 o Emulated-PULL refers to the ability for a BGP CAR node E1 to 1414 "subscribe" to (E2, C1) route such that only the related paths are 1415 signaled to E1. 1417 7.2.1. Subscription based BGP CAR Signaling 1419 RD:V/v via E2 1420 +-----+ +-----+ vpn label:30030 +-----+ 1421 ....... |S-RR1| <........... |S-RR2| <...............|S-RR3| <...... 1422 : +-----+ +-----+ Color C1 +-----+ : 1423 : : 1424 : (E2,C1) : 1425 : F:(E2,C1) +-----+ via 451 +-----+ : 1426 : ========>|T-RR1| <-------------- |T-RR2| : 1427 : || +-----+ L=168002 +-----+ : 1428 : || | \ : 1429 +:---------------||-+---------|----+---------+----------\--+--------:-+ 1430 |: || | | | | \ | : | 1431 |: F:(E2,C1) || | | | | \| : | 1432 |: =====> +-----+ | +---+ +---+ +---+ : | 1433 |: || | 121 | <------ |231| |341| |451| : | 1434 |: || -- +-----+ (E2,C1) +---+ +---+ +---+ : | 1435 |---+ === | | via 451 | | | +---| 1436 | E1| | | L=168002 | | | | E2| 1437 |---+ <------- | | | | +---| 1438 | (E2,C1) +---+ +---+ +---+ +---+ | 1439 | via 451 |122| |232| |342| |452| | 1440 | L=168002 +---+ +---+ +---+ +---+ | 1441 | | | | | | 1442 | Access | Metro | Core | Metro | Access | 1443 | domain 1 | domain 2 | domain 3| domain 4 | domain 5 | 1444 +-------------------+--------------+---------+----------+-------+ 1445 iPE iBRM iBRC eBRC eBRM ePE 1447 Figure 7: BGP transport CAR route Subscription 1449 o Using the reference figure above that illustrates the use-case in 1450 section Figure 6 1452 * Ingress PE E1 subscribes to (E2, C1) using a BGP CAR filter 1453 route F (E2, C1), sent via Ingress BRM node 121 1455 + node 121 may act as an RR to E1 1457 * Node 121 propagates F(E2, C1) to Transport-RR T-RR1. 1459 * Assume Transport-RR has learnt routes for all PEs in network. 1461 * Based on received F(E2, C1), T-RR1 selectively sends (E2, C1) 1462 route to node 121, with Next-Hop of node 451 (i.e., egress 1463 BRM). 1465 * node 121 propagates the received (E2, C1) route to E1 that 1466 subscribed for it, with Next-Hop of node 451 (i.e., with BGP 1467 Next-Hop unchanged), and received label 168002. 1469 * Hence E1 learns (E2, C1) that it needs for resolving the 1470 received VPN route next-hop for colored route RD:V/v. 1472 * Note, redundant control flows that exist, for instance via node 1473 122, are not shown above for simplicity. 1475 o In addition, the subscription can be recursive triggered (not 1476 shown in the reference diagram above): 1478 * Upon receiving (E2, C1), E1 further subscribes to (451, C1) 1479 using a BGP CAR filter route F (451, C1) sent via node 121 1481 * Node 121 may not have learnt (451, C1), and hence propagates F 1482 (451, C1) to node 231 1484 * Assuming node 231 has learnt (451, C1), it will selectively 1485 send (451, C1) to node 121 1487 * Node 121 propagates received (451, C1) route to E1, with next- 1488 hop set to self and local label 168451 1490 * Node 121 also installs a data plane entry in this case for 1491 label 168451 and BGP recursive next-hop 231 1493 * Hence, E1 also learns (451, C1) that it needs for resolving the 1494 next-hop for (E2, C1) 1496 * This recursive subscription procedure can be used to minimize 1497 state further on ingress BRM nodes, if necessary 1499 o The subscription based selective route signaling technique 1500 minimizes the state learnt and installed on both the ingress PEs 1501 as well as transit nodes. 1503 * The solution applies to all the design variants described in 1504 section Section 7.1 1506 o This subscription-based selective route signaling has another 1507 benefit 1508 * It minimizes routing state that nodes such as BRs or T-RRs need 1509 to push to each of their subscription clients 1511 * When a remote node such as an egress BR or egress PE fails, the 1512 withdrawal of these routes can also be faster as a result, 1513 leading to faster convergence 1515 o Details regarding the subscription based signaling will be 1516 described in a later version. 1518 7.3. Additional Design Options 1520 Other related well-known techniques that may be used to complement 1521 the solution design or provide an alternative as needed 1523 7.3.1. Anycast SID for transit inter-domain nodes 1525 Redundant BRs (e.g. egress BRMs) advertise their local domain's PE 1526 routes with same SID (based on label-index) 1528 Anycast SID assigned to the egress BRMs abstracts state and hence 1529 avoids necessity to propagate failure of an egress BRM to ingress 1530 BRMs and PEs. 1532 It also avoids traffic convergence issues for traffic from a 1533 remote ingress PE 1535 7.3.2. Anycast SID for transport color endpoints i.e PEs 1537 Anycast SID may be assigned to a redundant pair of PEs that have a 1538 common, dedicated set of service (VPN) attachments 1540 Used with Anycast SID/static labels for services (e.g., per-VRF 1541 VPN label/SID) 1543 This technique, similarly, abstracts state for the egress PEs and 1544 hence failure events from remote ingress PEs. 1546 7.4. Convergence 1548 Both existing and additional techniques are used to provide fast 1549 convergence for various network failure and change events 1551 BGP Add-Path should be enabled for BGP CAR to signal multiple next 1552 hops through RR for fast convergence. 1554 8. Interworking Scenarios 1556 Details regarding various interworking scenarios will be added in a 1557 later version. 1559 9. Fault Handling 1561 This the fault management actions as described in [RFC7606] are 1562 applicable for handling of BGP update messages for BGP-CAR. 1564 When the error determined allows for the router to skip the malformed 1565 NLRI(s) and continue processing of the rest of the update message, 1566 then it MUST handle such malformed NLRIs as 'Treat-as-withdraw'. In 1567 other cases, where the error in the NLRI encoding results in the 1568 inability to process the BGP update message (e.g. length related 1569 encoding errors), then the router SHOULD handle such malformed NLRIs 1570 as 'AFI/SAFI disable' when other AFI/SAFI besides BGP-CAR are being 1571 advertised over the same session. Alternately, the router MUST 1572 perform 'session reset' when the session is only being used for BGP- 1573 CAR. 1575 10. IANA Considerations 1577 IANA is requested to assign SAFI value TBD1 (BGP CAR) from the "SAFI 1578 Values" sub-registry under the "Subsequent Address Family Identifiers 1579 (SAFI) Parameters" registry with this document as a reference. 1581 10.1. BGP CAR NLRI Types Registry 1583 IANA is requested to create a "BGP CAR NLRI Types" sub-registry under 1584 the "Border Gateway Protocol (BGP) Parameters" registry with this 1585 document as a reference. The registry is for assignment of the one 1586 octet sized code-points for BGP CAR NLRI types and populated with the 1587 values shown below: 1589 Type NLRI Type Reference 1590 ----------------------------------------------------------------- 1591 0 Reserved (not to be used) [This document] 1592 1 Color-Aware Routes NLRI [This document] 1593 2-255 Unassigned 1595 Allocations within the registry are to be made under the 1596 "Specification Required" policy as specified in [RFC8126]). 1598 10.2. BGP CAR NLRI TLV Registry 1600 IANA is requested to create a "BGP CAR NLRI TLV Types" sub-registry 1601 under the "Border Gateway Protocol (BGP) Parameters" registry with 1602 this document as a reference. The registry is for assignment of the 1603 one octet sized code-points for BGP-CAR NLRI non-key TLV types and 1604 populated with the values shown below: 1606 Type NLRI Type Reference 1607 ----------------------------------------------------------------- 1608 0 Reserved (not to be used) [This document] 1609 1 Label TLV [This document] 1610 2 Label Index TLV [This document] 1611 3 SRv6 SID TLV [This document] 1612 4-255 Unassigned 1614 Allocations within the registry are to be made under the 1615 "Specification Required" policy as specified in [RFC8126]). 1617 10.3. Guidance for Designated Experts 1619 In all cases of review by the Designated Expert (DE) described here, 1620 the DE is expected to ascertain the existence of suitable 1621 documentation (a specification) as described in [RFC8126]. The DE is 1622 also expected to check the clarity of purpose and use of the 1623 requested code points. Additionally, the DE must verify that any 1624 request for one of these code points has been made available for 1625 review and comment within the IETF: the DE will post the request to 1626 the IDR Working Group mailing list (or a successor mailing list 1627 designated by the IESG). If the request comes from within the IETF, 1628 it should be documented in an Internet-Draft. Lastly, the DE must 1629 ensure that any other request for a code point does not conflict with 1630 work that is active or already published within the IETF. 1632 10.4. BGP Extended Community Registry 1634 IANA is requested to allocate the sub-type TBD2 for "Local Color 1635 Mapping (LCM)" under the "BGP Transitive Opaque Extended Community" 1636 registry under the "BGP Extended Community" parameter registry. 1638 11. Security Considerations 1640 TBD 1642 12. Acknowledgements 1644 The authors would like to acknowledge the review and inputs from many 1645 people.TBD 1647 13. References 1649 13.1. Normative References 1651 [I-D.ietf-bess-srv6-services] 1652 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 1653 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 1654 Overlay services", draft-ietf-bess-srv6-services-05 (work 1655 in progress), November 2020. 1657 [I-D.ietf-idr-bgp-ipv6-rt-constrain] 1658 Patel, K., Raszuk, R., Djernaes, M., Dong, J., and M. 1659 Chen, "IPv6 Extensions for Route Target Distribution", 1660 draft-ietf-idr-bgp-ipv6-rt-constrain-12 (work in 1661 progress), April 2018. 1663 [I-D.ietf-idr-tunnel-encaps] 1664 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 1665 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 1666 encaps-21 (work in progress), January 2021. 1668 [I-D.ietf-lsr-flex-algo] 1669 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1670 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1671 algo-13 (work in progress), October 2020. 1673 [I-D.ietf-spring-segment-routing-policy] 1674 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1675 P. Mattes, "Segment Routing Policy Architecture", draft- 1676 ietf-spring-segment-routing-policy-09 (work in progress), 1677 November 2020. 1679 [I-D.ietf-spring-srv6-network-programming] 1680 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 1681 Matsushima, S., and Z. Li, "SRv6 Network Programming", 1682 draft-ietf-spring-srv6-network-programming-28 (work in 1683 progress), December 2020. 1685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1686 Requirement Levels", BCP 14, RFC 2119, 1687 DOI 10.17487/RFC2119, March 1997, 1688 . 1690 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1691 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1692 February 2006, . 1694 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 1695 R., Patel, K., and J. Guichard, "Constrained Route 1696 Distribution for Border Gateway Protocol/MultiProtocol 1697 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 1698 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 1699 November 2006, . 1701 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1702 "Multiprotocol Extensions for BGP-4", RFC 4760, 1703 DOI 10.17487/RFC4760, January 2007, 1704 . 1706 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 1707 Subsequent Address Family Identifier (SAFI) and the BGP 1708 Tunnel Encapsulation Attribute", RFC 5512, 1709 DOI 10.17487/RFC5512, April 2009, 1710 . 1712 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 1713 Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, 1714 . 1716 [RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, 1717 "The Accumulated IGP Metric Attribute for BGP", RFC 7311, 1718 DOI 10.17487/RFC7311, August 2014, 1719 . 1721 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1722 Patel, "Revised Error Handling for BGP UPDATE Messages", 1723 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1724 . 1726 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1727 Writing an IANA Considerations Section in RFCs", BCP 26, 1728 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1729 . 1731 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1732 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1733 May 2017, . 1735 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 1736 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 1737 . 1739 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1740 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1741 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1742 July 2018, . 1744 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 1745 A., and H. Gredler, "Segment Routing Prefix Segment 1746 Identifier Extensions for BGP", RFC 8669, 1747 DOI 10.17487/RFC8669, December 2019, 1748 . 1750 13.2. Informative References 1752 [I-D.ietf-mpls-seamless-mpls] 1753 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 1754 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 1755 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 1757 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 1758 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 1759 RFC 3906, DOI 10.17487/RFC3906, October 2004, 1760 . 1762 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1763 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1764 DOI 10.17487/RFC4271, January 2006, 1765 . 1767 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1768 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1769 . 1771 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1772 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1773 2006, . 1775 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1776 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1777 and Authentication for Routing Protocols (KARP) Design 1778 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1779 . 1781 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 1782 "Advertisement of Multiple Paths in BGP", RFC 7911, 1783 DOI 10.17487/RFC7911, July 2016, 1784 . 1786 Authors' Addresses 1788 Dhananjaya Rao 1789 Cisco Systems 1790 USA 1792 Email: dhrao@cisco.com 1794 Swadesh Agrawal 1795 Cisco Systems 1796 USA 1798 Email: swaagraw@cisco.com 1800 Clarence Filsfils 1801 Cisco Systems 1802 Belgium 1804 Email: cfilsfil@cisco.com 1806 Ketan Talaulikar 1807 Cisco Systems 1808 India 1810 Email: ketant@cisco.com