idnits 2.17.1 draft-shen-idr-flexible-color-tunnel-selection-01.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Color Tunnel Selection Scheme sub-TLV is used to carry the information of a tunnel selection scheme. The sub-TLV is contained in a Tunnel Encapsulation Attribute TLV. If the Tunnel Encapsulation Attribute TLV's tunnel type is Wildcard, the tunnel selection scheme is regardless of tunnel type. If the Tunnel Encapsulation Attribute TLV's tunnel type is a specific type, the tunnel selection scheme is applicable to tunnels of that type. In any case, a Tunnel Encapsulation Attribute TLV MUST not contain more than one Color Tunnel Selection Scheme sub-TLV. -- The document date (February 3, 2020) is 1515 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) ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Yimin Shen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track Ravi Singh 5 Expires: August 6, 2020 Individual Contributor 6 Yuji Kamite 7 NTT Communications 8 February 3, 2020 10 BGP Flexible Color-Based Tunnel Selection 11 draft-shen-idr-flexible-color-tunnel-selection-01 13 Abstract 15 This document discusses color-based tunnel selection for BGP payload 16 prefixes. It defines a set of extended mapping modes, and describes 17 how to use them to construct tunnel selection schemes for flexible 18 tunnel selection. Tunnel selection schemes can be implemented as 19 policies on routers performing tunnel selection, or signaled by next 20 hop routers or a central controller by using the BGP extensions 21 specified in this document. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 6, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 59 3. Extended Mapping Modes . . . . . . . . . . . . . . . . . . . 4 60 4. Tunnel Selection Scheme and Operation . . . . . . . . . . . . 6 61 5. Provisioning of Tunnel Selection Schemes . . . . . . . . . . 7 62 6. BGP Tunnel Encapsulation Attribute Extensions . . . . . . . . 8 63 6.1. Wildcard Tunnel Type . . . . . . . . . . . . . . . . . . 8 64 6.2. Color Tunnel Selection Scheme Sub-TLV . . . . . . . . . . 8 65 6.2.1. Extended Mapping Mode Sub-sub-TLV . . . . . . . . . . 9 66 6.2.2. Encoding . . . . . . . . . . . . . . . . . . . . . . 10 67 6.2.3. Decoding . . . . . . . . . . . . . . . . . . . . . . 10 68 6.3. Association between Color Tunnel Selection Scheme Sub-TLV 69 and Tunnel Type . . . . . . . . . . . . . . . . . . . . . 11 70 7. Relationship with Color-Only Bits of Color Extended Community 11 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 11.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 In an overlay network using BGP for payload prefix distribution, 82 transporting the packets of a payload prefix from a BGP router to the 83 next BGP router relies on the selection of a transport tunnel. This 84 selection may be based on various attributes of the prefix, such as 85 BGP next hop, color, and information in the Tunnel Encapsulation 86 Attribute [BGP-TUNNEL-ENCAP], etc. 88 In one tunnel selection model, color is used as a primary criterion 89 along with BGP next hop or tunnel endpoint address (contained in a 90 Tunnel Endpoint sub-TLV of the Tunnel Encapsulation Attribute). This 91 model is referred to as "color-based" tunnel selection in this 92 document. The model is gaining many use cases today due to its 93 general applicability. In particular, color as a generic notion may 94 be used to represent a broad range of network attributes, such as 95 virtual topology, network slice, path computation algorithm, TE 96 constraint, administrative profile, etc. For some of the attributes, 97 there may not be a convenient mechanism to associate them with 98 payload prefixes or tunnels, or to distribute them in a network, 99 especially across domains or to a central controller. When these 100 attributes need to be considered in tunnel selection, mapping them to 101 colors and performing color-based tunnel selection will provide a 102 generic solution. 104 The procedures in this document is relevant to color-based tunnel 105 selection. In general, payload prefixes may be associated with 106 colors through configuration or a Color Extended Community [RFC5512]. 107 Transport tunnels may also be associated with colors through 108 configuration (e.g. RSVP and LDP tunnels), a Color Extended 109 Community (e.g. BGP LU), or a color embedded in BGP NLRI (e.g. BGP 110 SR-TE policy [BGP-SR-POLICY]), etc. These payload prefixes and 111 tunnels are called "colored payload prefixes" and "colored tunnels", 112 respectively. 114 Normally, a payload prefix of color X is intended to be mapped to a 115 tunnel of the same color X. This is considered as the default 116 mapping mode of color-based tunnel selection. In some cases, when a 117 tunnel of color X cannot be found or established, or when a 118 previously mapped tunnel of color X fails, a network operator may 119 want to map the payload prefix by attempting other modes, e.g. 120 selecting a tunnel of another color Y, a tunnel without a color, a 121 tunnel of color X but with an IPv4-mapped IPv6 endpoint address, and 122 so on. Note that the colors may represent network slices, virtual 123 topologies, path computation algorithms, etc. Hence, these modes 124 will provide the flexibility and enable the operator to take the full 125 transport capability of the network. In this document, these modes 126 are called "extended mapping modes", and the procedure of 127 automatically executing them in a user-defined order is called 128 "fallback". 130 This document defines a set of extended mapping modes to complement 131 the default mapping mode. It introduces the notion of "tunnel 132 selection scheme". A tunnel selection scheme is an ordered list of 133 extended mapping modes to be automatically executed in tunnel 134 selection. When a tunnel is not selected by using the first mode in 135 the list, fallback is performed by attempting the second mode, the 136 third mode, and so on, until a tunnel is selected or the list is 137 exhausted. 139 Color-based tunnel selection for uncolored payload prefixes is also 140 considered in this document as a special case. By using a tunnel 141 selection scheme, a colored or uncolored tunnel may be selected for 142 an uncolored payload prefix in a flexible manner. 144 2. Specification of Requirements 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119] and 149 [RFC8174]. 151 3. Extended Mapping Modes 153 This document defines a set of extended mapping modes for flexible 154 color-based tunnel selection. Each mode specifies how a payload 155 prefix's endpoint IP address (derived from BGP next hop or a Tunnel 156 Endpoint sub-TLV in the Tunnel Encapsulation Attribute 157 [BGP-TUNNEL-ENCAP]) and color are used to select a tunnel. The 158 document assumes that each payload prefix SHOULD have a single color 159 for tunnel selection purpose or no color, and each tunnel SHOULD have 160 a single color or no color. 162 In the definitions of the extended mapping modes below, N represents 163 a payload prefix's endpoint IP address, and C represents its color. 164 An uncolored payload prefix does not have a color. An extended 165 mapping mode may have multiple steps for sub-level fallback within 166 it. The steps are executed sequentially. The mode is completed as 167 soon as a tunnel is successfully selected in one of the steps, and 168 the rest steps are skipped. 170 (1) IP-color, optionally with a fallback color list of {C1, ...,Cn} 172 - If the payload prefix has a color C, select a tunnel with 173 endpoint address N and color C. 175 - Select a tunnel with endpoint address N and color C1. 177 - ... 179 - Select a tunnel with endpoint address N and color Cn. 181 (2) Color-only, optionally with a fallback color list of {C1, ..., 182 Cn} 184 - If the payload prefix has a color C, select a tunnel with color 185 C, regardless of the tunnel's endpoint address. 187 - Select a tunnel with color C1, regardless of tunnel's endpoint 188 address. 190 - ... 192 - Select a tunnel with color Cn, regardless of tunnel's endpoint 193 address. 195 (3) IP-any-color 197 - Select a tunnel with endpoint address N and any color. 199 (4) IP-only 201 - Select a tunnel with endpoint address N and without a color. 203 (5) Converted-IPv6 205 This mode is applicable when N is an IPv4 address. Assume N' is the 206 IPv6 address mapped from N. 208 - Select a tunnel with endpoint address N' and without a color. 210 (6) Converted-IPv6-color, optionally a fallback color list of {C1, 211 ..., Cn} 213 This mode is applicable when N is an IPv4 address. Assume N' is the 214 IPv6 address mapped from N. 216 - If the payload prefix has a color C, select a tunnel with 217 endpoint address N' and color C. 219 - Select a tunnel with endpoint address N' and color C1. 221 - ... 223 - Select a tunnel with endpoint address N' and color Cn. 225 (7) Converted-IPv6-any-color 227 This mode is applicable when N is an IPv4 address. Assume N' is the 228 IPv6 address mapped from N. 230 - Select a tunnel with endpoint address N' and any color. 232 (8) Color-profile 234 - If the payload prefix has a color C, use C as key to look up a 235 profile to construct tunnel selection criteria and select a 236 tunnel. 238 As shown above, the IP-color, Color-only, and Converted-IPv6-color 239 modes may have a fallback color list for sub-level fallback across 240 the colors. 242 This list is not exhaustive. More modes MAY be defined in the 243 future. 245 4. Tunnel Selection Scheme and Operation 247 A tunnel selection scheme is defined as an ordered list of extended 248 mapping modes (Section 3) to be automatically executed in tunnel 249 selection. The first mode in the list is called a "primary" mode, 250 and all the subsequent modes are called "fallback" modes. A scheme 251 MUST have a primary mode, but MAY or MAY not have any fallback mode. 253 When a scheme is executed for a payload prefix, the modes in the list 254 are executed sequentially, and within each mode, the steps of sub- 255 level fallback are executed sequentially. When a tunnel is selected 256 in a particular step in a particular mode, the scheme is completed, 257 and all subsequent steps of the mode and all the subsequent modes in 258 the list are skipped. If no tunnel is selected when the list is 259 exhausted, the payload prefix will remain in unresolved state for 260 transport. 262 In the case where a previously selected tunnel becomes inoperative, 263 the scheme SHOULD be run to reselect a tunnel. In the case where a 264 tunnel was previously selected and later another tunnel of higher 265 preference (in the tunnel selection scheme or in a fallback color 266 list) becomes available, the new tunnel MAY be selected to replace 267 the current tunnel. This procedure is called a reversion. It may be 268 performed manually by a network operator, or triggered automatically 269 by the situation. 271 The following are some examples of tunnel selection schemes. 273 Example 1: 275 A payload prefix has a tunnel endpoint IPv4 address 203.0.113.1 and a 276 color RED. It is associated with the following tunnel selection 277 scheme: 279 (1) IP-color 281 (2) Converted-IPv6-color 283 (3) IP-only 285 The intended tunnel selection procedure is: 287 (1) Find a tunnel with endpoint IPv4 address 203.0.113.1 and color 288 RED. 290 (2) If the above is unsuccessful, convert the IPv4 address to an 291 IPv6 address 2002:cb00:7101::/64. Find a tunnel with endpoint 292 IPv6 address 2002:cb00:7101::/64 and color RED. 294 (3) If the above is unsuccessful, find a tunnel with endpoint IPv4 295 address 203.0.113.1 and without a color. 297 Example 2: 299 A prefix has a tunnel endpoint IPv4 address 203.0.113.1 and a color 300 RED. It is associated with the following tunnel selection scheme: 302 (1) IP-color, with a fallback color list = {BLUE, GREEN} 304 (2) Converted-IPv6-color, with a fallback color list = {WHITE} 306 (3) IP-only 308 The intended tunnel selection procedure is: 310 (1) Find a tunnel with endpoint IPv4 address 203.0.113.1 and color 311 RED. If it is unsuccessful, find a tunnel with endpoint IPv4 312 address 203.0.113.1 and color BLUE. If it is unsuccessful, find a 313 tunnel with endpoint IPv4 address 203.0.113.1 and color GREEN. 315 (2) If the above is unsuccessful, convert the IPv4 address to an 316 IPv6 address 2002:cb00:7101::/64. Find a tunnel with endpoint 317 IPv6 address 2002:cb00:7101::/64 and color RED. If it is 318 unsuccessful, find a tunnel with endpoint IPv6 address 319 2002:cb00:7101::/64 and color WHITE. 321 (3) If the above is unsuccessful, find a tunnel with endpoint IPv4 322 address 203.0.113.1 and without a color. 324 5. Provisioning of Tunnel Selection Schemes 326 A tunnel selection scheme MAY be provisioned for a payload prefix on 327 a router which performs tunnel selection. In this case, the scheme 328 may be implemented as a policy on the router. The configuration of 329 such policy varies by vendors, and hence is out of the scope of this 330 document. 332 A tunnel selection scheme MAY also be provisioned on a router or a 333 central controller which originates the UPDATE message of a payload 334 prefix, and then distributed to a router(s) which will perform tunnel 335 selection. To facilitate this, the document introduces a new "Color 336 Tunnel Selection Scheme" sub-TLV (Section 6) to the Tunnel 337 Encapsulation Attribute to carry the information. As color-based 338 tunnel selection is typically across all tunnel types, the document 339 also introduces a new "Wildcard" tunnel type to the Tunnel 340 Encapsulation Attribute. When the tunnel selection scheme contained 341 in a Color Tunnel Selection Scheme sub-TLV is applicable to all 342 tunnel types, the top-level Tunnel Encapsulation Attribute TLV SHOULD 343 set tunnel type to Wildcard. 345 In the case where a payload prefix has one scheme configured as a 346 policy on a router, and another scheme received in a Color Tunnel 347 Selection Scheme sub-TLV, the router SHOULD treat the policy in 348 preference to the received information. 350 If a payload prefix does not have a tunnel selection scheme, the 351 default mapping mode applicable to colored or non-colored payload 352 prefixes SHOULD be used accordingly. 354 6. BGP Tunnel Encapsulation Attribute Extensions 356 This section specifies a new "Wildcard" tunnel type and a new Color 357 Tunnel Selection Scheme sub-TLV for the Tunnel Encapsulation 358 Attribute. 360 6.1. Wildcard Tunnel Type 362 The Wildcard tunnel type has the semantics of "any tunnel types". It 363 allows a Tunnel Encapsulation Attribute TLV to carry information 364 which is regardless of tunnel type or applicable to all tunnel types. 365 In this document, it is used when a Tunnel Encapsulation Attribute 366 TLV contains a Color Tunnel Selection Scheme sub-TLV which is 367 applicable to all tunnel types. 369 6.2. Color Tunnel Selection Scheme Sub-TLV 371 The Color Tunnel Selection Scheme sub-TLV is used to carry the 372 information of a tunnel selection scheme. The sub-TLV is contained 373 in a Tunnel Encapsulation Attribute TLV. If the Tunnel Encapsulation 374 Attribute TLV's tunnel type is Wildcard, the tunnel selection scheme 375 is regardless of tunnel type. If the Tunnel Encapsulation Attribute 376 TLV's tunnel type is a specific type, the tunnel selection scheme is 377 applicable to tunnels of that type. In any case, a Tunnel 378 Encapsulation Attribute TLV MUST not contain more than one Color 379 Tunnel Selection Scheme sub-TLV. 381 The sub-TLV's Type is TBD (to be allocated by IANA). The sub-TLV's 382 Length is the number of the octets of the sub-TLV's Value field. The 383 sub-TLV's Value field is composed of one or multiple Extended Mapping 384 Mode sub-sub-TLVs. 386 6.2.1. Extended Mapping Mode Sub-sub-TLV 388 An Extended Mapping Mode sub-sub-TLV contains the information of an 389 extended mapping mode. Its encoding is shown in Figure 1. 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | 0x01 | Length | Mode | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Color_1 (optional) | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | ~ | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Color_n (optional) | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 1 405 The Extended Mapping Mode sub-sub-TLV's Type is 0x01. 407 The Extended Mapping Mode sub-sub-TLV's Length is the total number of 408 octets of the sub-sub-TLV's Value field. 410 The Extended Mapping Mode sub-sub-TLV's Value field contains a 411 2-octet extended mapping mode defined as below, and an optional 412 fallback color list. 414 1 - IP-color 416 2 - Color-only 418 3 - IP-any-color 420 4 - IP-only 422 5 - Converted-IPv6 424 6 - Converted-IPv6-color 426 7 - Converted-IPv6-any-color 428 8 - Color-profile 430 The IP-color, Color-only and Converted-IPv6-color modes MAY have an 431 optional fallback color list. The list contains one or multiple 432 4-octet color values, i.e. Color_1, ..., Color_n, in the order from 433 the highest preference to the lowest preference. 435 6.2.2. Encoding 437 Given a tunnel selection scheme, a Color Tunnel Selection Scheme sub- 438 TLV is constructed in the following manner: 440 o First, an Extended Mapping Mode sub-sub-TLV containing the primary 441 mode is added. If this mode is IP-Color, Color-Only, or 442 Converted-IPv6-Color, and if cross-color fallback is applicable to 443 this mode, a fallback color list is added to the sub-sub-TLV. 445 o If there is one or multiple desired fallback modes, an Extended 446 Mapping Mode sub-sub-TLV containing the first fallback mode is 447 added. If this mode is IP-Color, Color-Only, or Converted- 448 IPv6-Color, and if cross-color fallback is applicable to this 449 mode, a fallback color list is added to the sub-sub-TLV. 451 o This process continues, until an Extended Mapping Mode sub-sub-TLV 452 containing the last fallback mode is added. If this mode is IP- 453 Color, Color-Only, or Converted-IPv6-Color, and if cross-color 454 fallback is applicable to this mode, a fallback color list is 455 added to the sub-sub-TLV. 457 6.2.3. Decoding 459 When decoding a Color Tunnel Selection Scheme sub-TLV, a receiving 460 router MUST interpret the preference of the contained Extended 461 Mapping Mode sub-sub-TLVs as the order in which they are encoded. If 462 an Extended Mapping Mode sub-sub-TLV contains a mode which is not IP- 463 Color, Color-Only, or Converted-IPv6-Color but has a fallback color 464 list, the entire Color Tunnel Selection Scheme sub-TLV SHOULD be 465 considered as malformatted and ignored. 467 A receiving router MUST consider a payload prefix as having a 468 modified tunnel selection scheme in any of the following situations, 469 and perform tunnel selection accordingly: 471 o The payload prefix did not have a valid Color Tunnel Selection 472 Scheme sub-TLV in the previous UPDATE message, and it has one in 473 the latest UPDATE message. Tunnel selection MUST be performed 474 based on the latest tunnel selection scheme. 476 o The payload prefix had a valid Color Tunnel Selection Scheme sub- 477 TLV in the previous UPDATE message, but it does not have one in 478 the latest UPDATE message. Tunnel selection MUST revert to the 479 default color or non-color mapping mode. 481 o The payload prefix had a valid Color Tunnel Selection Scheme sub- 482 TLV in the previous UPDATE message, and it has one with different 483 content in the latest UPDATE message. Tunnel selection MUST be 484 performed based on the latest tunnel selection scheme. 486 6.3. Association between Color Tunnel Selection Scheme Sub-TLV and 487 Tunnel Type 489 A Color Tunnel Selection Scheme sub-TLV MAY be contained in a Tunnel 490 Encapsulation Attribute TLV of Wildcard tunnel type, indicating that 491 the scheme SHOULD be performed regardless of tunnel type. The sub- 492 TLV MAY also be contained in a Tunnel Encapsulation Attribute TLV of 493 a specific tunnel type, indicating that the scheme SHOULD consider 494 only the tunnels of that type. In the case where a Tunnel 495 Encapsulation Attribute contains a TLV of Wildcard tunnel type and 496 another TLV of a specific tunnel type, and both TLVs contain a Color 497 Tunnel Selection Scheme sub-TLV, tunnel selection for that specific 498 tunnel type SHOULD be based on the corresponding Color Tunnel 499 Selection Scheme sub-TLV. 501 7. Relationship with Color-Only Bits of Color Extended Community 503 [RFC8402] and [BGP-SR-POLICY] define two "Color-Only" bits (i.e. CO 504 bits) in the BGP Color Extended Community for color-based tunnel 505 selection in the context of segment routing. Each of the four 506 combinations of the CO bits corresponds to a predefined fallback 507 scheme. 509 This document complements these documents by supporting more generic 510 and flexible fallback schemes which are user definable. In fact, the 511 predefined fallback schemes of the CO bits can be fully supported by 512 using the Color Tunnel Selection Scheme sub-TLV. When a router 513 advertises an UPDATE message, it SHOULD NOT use a Color Extended 514 Community with CO bits and a Color Tunnel Selection Scheme sub-TLV at 515 the same time, in order to avoid collision between them. If a router 516 receives an UPDATE message containing both objects, it SHOULD give 517 preference to CO bits, and ignore the other. If the tunnel selection 518 scheme is implemented as a policy on the receiving router, the router 519 SHOULD give the preference to the policy. 521 8. IANA Considerations 523 This document requires the IANA to allocate a value for the Wildcard 524 tunnel type as a new BGP Tunnel Encapsulation Attribute Type, and a 525 type value for the new Color Tunnel Selection Scheme sub-TLV. 527 9. Security Considerations 529 This document introduces procedures for color-based tunnel selection 530 to use tunnel selection schemes. The procedures can cause traffic to 531 be diverted from default path(s). This requires measures to be taken 532 at a number of levels to avoid undesirable transport behaviors and 533 security risks. First, network coloring (i.e. color assignment to 534 network resources, attributes, payload prefixes, tunnels, etc.) MUST 535 be carefully planned and validated at a global level to avoid errors 536 and collisions. Second, tunnel selection schemes MUST be legitimate 537 and always select valid tunnels leading to desired endpoints. For 538 schemes implemented as policies, this SHOULD be ensured by policy 539 configuration. For schemes distributed via Color Tunnel Selection 540 Scheme sub-TLV of BGP Tunnel Encapsulation Attribute, receivers 541 SHOULD use BGP security procedures to validate each originator's 542 identity and detect unauthorized content modification during 543 distribution. 545 10. Acknowledgements 547 This document leverages work done by Junan Chen. Thanks to Jeff Hass 548 and Srihari Sangli for their kind reviews and comments which helped 549 to improve the clarity of this document. 551 11. References 553 11.1. Normative References 555 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 556 Subsequent Address Family Identifier (SAFI) and the BGP 557 Tunnel Encapsulation Attribute", RFC 5512, 558 DOI 10.17487/RFC5512, April 2009, 559 . 561 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 562 Decraene, B., Litkowski, S., and R. Shakir, "Segment 563 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 564 July 2018, . 566 [BGP-SR-POLICY] 567 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., Jain, 568 D., and S. Lin, "Advertising Segment Routing Policies in 569 BGP", draft-previdi-idr-segment-routing-te-policy (work in 570 progress), 2019. 572 [BGP-TUNNEL-ENCAP] 573 Patel, K., Velde, G., and S. Sangli, "The BGP Tunnel 574 Encapsulation Attribute", draft-vandevelde-idr-remote- 575 next-hop (work in progress), 2019. 577 11.2. Informative References 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, 581 DOI 10.17487/RFC2119, March 1997, 582 . 584 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 585 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 586 May 2017, . 588 Authors' Addresses 590 Yimin Shen 591 Juniper Networks 592 10 Technology Park Drive 593 Westford, MA 01886 594 USA 596 Phone: +1 9785890722 597 Email: yshen@juniper.net 599 Ravi Singh 600 Individual Contributor 602 Email: ravi.singh.ietf@gmail.com 604 Yuji Kamite 605 NTT Communications 607 Email: y.kamite@ntt.com