idnits 2.17.1 draft-previdi-idr-segment-routing-te-policy-03.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 -- The document date (December 17, 2016) is 2680 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) == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-03 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-02 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-10 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-05 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track A. Sreekantiah 5 Expires: June 20, 2017 S. Sivabalan 6 Cisco Systems, Inc. 7 P. Mattes 8 Microsoft 9 E. Rosen 10 Juniper Networks 11 S. Lin 12 Google 13 December 17, 2016 15 Advertising Segment Routing Traffic Engineering Policies in BGP 16 draft-previdi-idr-segment-routing-te-policy-03 18 Abstract 20 This document defines a new BGP SAFI with a new NLRI in order to 21 advertise a Segment Routing Traffic Engineering Policy (SR TE 22 Policy). An SR TE Policy is a set of explicit paths represented by 23 one or more segment lists. The SR TE Policy is advertised along with 24 the Tunnel Encapsulation Attribute for which this document also 25 defines new sub-TLVs. An SR TE policy is advertised with the 26 information that will be used by the node receiving the advertisement 27 in order to instantiate the policy in its forwarding table and to 28 steer traffic according to the policy. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 20, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2. SR TE Policy Encoding . . . . . . . . . . . . . . . . . . . . 4 67 2.1. SR TE Policy SAFI and NLRI . . . . . . . . . . . . . . . 4 68 2.2. SR TE Policy and Tunnel Encapsulation Attribute . . . . . 6 69 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 7 70 2.4. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . . . 7 71 2.4.1. Preference sub-TLV . . . . . . . . . . . . . . . . . 7 72 2.4.2. SR TE Binding SID Sub-TLV . . . . . . . . . . . . . . 8 73 2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 9 74 3. SR TE Policy Operations . . . . . . . . . . . . . . . . . . . 21 75 3.1. Configuration and Advertisement of SR TE Policies . . . . 21 76 3.2. Multipath Operation . . . . . . . . . . . . . . . . . . . 21 77 3.3. Binding SID TLV . . . . . . . . . . . . . . . . . . . . . 22 78 3.4. Reception of an SR TE Policy . . . . . . . . . . . . . . 22 79 3.4.1. Acceptance of a SR TE Policy Update . . . . . . . . . 22 80 3.4.2. Usable SR TE Policy . . . . . . . . . . . . . . . . . 23 81 3.4.3. Instantiation of an SR TE Policy . . . . . . . . . . 24 82 3.4.4. Propagation of an SR TE Policy . . . . . . . . . . . 25 83 3.5. Steering Traffic into a SR TE Policy . . . . . . . . . . 25 84 3.6. Flowspec and SR TE Policies . . . . . . . . . . . . . . . 26 85 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 86 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 88 6.1. Existing Registry: Subsequent Address Family Identifiers 89 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 28 90 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute 91 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 28 92 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute 93 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 28 94 6.4. New Registry: SR TE Policy List Sub-TLVs . . . . . . . . 28 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 98 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 99 8.2. Informational References . . . . . . . . . . . . . . . . 30 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 102 1. Introduction 104 Segment Routing (SR) technology leverages the source routing and 105 tunneling paradigms. [I-D.ietf-spring-segment-routing] describes the 106 SR architecture. [I-D.ietf-spring-segment-routing-mpls] describes 107 its instantiation on the MPLS data plane and 108 [I-D.ietf-6man-segment-routing-header] describes the Segment Routing 109 instantiation over the IPv6 data plane. 111 This document defines the Segment Routing Traffic Engineering Policy 112 (SR TE Policy) as a set of unequal equal cost multi-path (UCMP) 113 segment lists (representing explicit paths) as well as the mechanism 114 allowing a router to steer traffic into an SR TE Policy. 116 The SR TE Policy is advertised in the Border Gateway Protocol (BGP) 117 by the BGP speaker being a router or a controller and using 118 extensions defined in this document. Among the information encoded 119 in the BGP message and representing the SR TE Policy, the steering 120 mechanism makes also use of the Extended Color Community currently 121 defined in [I-D.ietf-idr-tunnel-encaps] 123 Typically, a controller defines the set of policies and advertise 124 them to BGP routers (typically ingress routers). The policy 125 advertisement uses BGP extensions defined in this document. The 126 policy advertisement is, in most but not all of the cases, tailored 127 for the receiver. In other words, a policy advertised to a given BGP 128 speaker has significance only for that particular router and is not 129 intended to be propagated anywhere else. Then, the receiver of the 130 policy instantiate the policy in its routing and forwarding tables 131 and steer traffic into it based on both the policy and destination 132 prefix color and next-hop. 134 Alternatively, a router (i.e.: an BGP egress router) advertises SR TE 135 Policies representing paths to itself. These advertisements are sent 136 to BGP ingress nodes who instantiate these policies and steer traffic 137 into them according to the color and endpoint/BGP next-hop of both 138 the policy and the destination prefix. 140 An SR TE Policy being intended only for the receiver of the 141 advertisement, the SR TE Policies are sent directly to each receiver 142 and, in most of the cases will not traverse any Route Reflector (RR, 143 [RFC4456]). 145 However, there are cases where a SR TE Policy is intended to a group 146 of nodes. Also, in a deployment scenario, a controller may also rely 147 on the standard BGP update propagation scheme which makes use of 148 route reflectors. This cases require mechanisms that: 150 o Uniquely identify each instance of a given policy. 152 o Uniquely identify the intended receiver of a given SR TE Policy 153 advertisement. 155 The BGP extensions for the advertisement of SR TE Policies include 156 following components: 158 o A new Subsequent Address Family Identifier (SAFI) identifying the 159 content of the BGP message (i.e.: the SR TE Policy). 161 o A new NLRI identifying the SR TE Policy. 163 o A set of new TLVs to be inserted into the Tunnel Encapsulation 164 Attribute (as defined in [I-D.ietf-idr-tunnel-encaps]) and 165 describing the SR TE Policy. 167 o An IPv4 address format route-target extended community ([RFC4360]) 168 attached to the SR TE Policy advertisement and that indicates the 169 intended receiver of such SR TE Policy advertisement. 171 o The Extended Color Community (as defined in 172 [I-D.ietf-idr-tunnel-encaps]) and used in order to steer traffic 173 into an SR TE Policy. 175 1.1. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [RFC2119]. 181 2. SR TE Policy Encoding 183 2.1. SR TE Policy SAFI and NLRI 185 A new SAFI is defined: the SR TE Policy SAFI (codepoint TBD1 to be 186 assigned by IANA from the "Subsequent Address Family Identifiers 187 (SAFI) Parameters" registry). 189 The SR TE Policy SAFI uses a new NLRI defined as follows: 191 +-----------------------------------------------+ 192 | Distinguisher (4 octets) | 193 +-----------------------------------------------+ 194 | Policy Color (4 octets) | 195 +-----------------------------------------------+ 196 | Endpoint (4 or 16 octets) | 197 +-----------------------------------------------+ 199 where: 201 o Distinguisher: 4-octet value uniquely identifying the policy in 202 the context of tuple. The distinguisher has no 203 semantic and it's solely used by the SR TE Policy originator in 204 order to make unique (from a NLRI perspective) multiple 205 occurrences of the same SR TE Policy. 207 o Policy Color: 4-octet value identifying (with the endpoint) the 208 policy. The color is used to match the color of the destination 209 prefixes in order to steer traffic into the SR TE Policy. 211 o Endpoint: identifies the endpoint of a policy. The Endpoint may 212 represent a single node or a set of nodes (e.g.: an anycast 213 address or a summary address). The Endpoint is an IPv4 (4-octet) 214 address or an IPv6 (16-octet) address according to the AFI of the 215 NLRI. 217 The NLRI containing the SR TE Policy is carried in a BGP UPDATE 218 message [RFC4271] using BGP multiprotocol extensions [RFC4760] with 219 an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of TBD1 (to be 220 assigned by IANA from the "Subsequent Address Family Identifiers 221 (SAFI) Parameters" registry). 223 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 224 attribute with the SR TE Policy SAFI MUST also carry the BGP 225 mandatory attributes. In addition, the BGP update message MAY also 226 contain any of the BGP optional attributes. 228 The next-hop of the SR TE Policy SAFI NLRI is set based on the AFI. 229 For example, if the AFI is set to IPv4 (1), then the next-hop is 230 encoded as a 4-byte IPv4 address. If the AFI is set to IPv6 (2), 231 then the next-hop is encoded as a 16-byte IPv6 address of the router. 232 It is important to note that any BGP speaker receiving a BGP message 233 with an SR TE Policy NLRI, will process it only if the NLRI is a best 234 path as per the BGP best path selection algorithm. 236 2.2. SR TE Policy and Tunnel Encapsulation Attribute 238 The content of the SR TE Policy is encoded in the Tunnel 239 Encapsulation Attribute originally defined in 240 [I-D.ietf-idr-tunnel-encaps] using a new Tunnel-Type TLV (codepoint 241 is TBD2, to be assigned by IANA from the "BGP Tunnel Encapsulation 242 Attribute Tunnel Types" registry). 244 The SR TE Policy Encoding structure is as follows: 246 SR TE Policy SAFI NLRI: 247 Attributes: 248 Tunnel Encaps Attribute (23) 249 Tunnel Type: SR TE Policy 250 Binding SID 251 Preference 252 Segment List 253 Weight 254 Segment 255 Segment 256 ... 257 ... 258 ... 259 where: 261 o SR TE Policy SAFI NLRI is defined in Section 2.1. 263 o Tunnel Encapsulation Attribute is defined in 264 [I-D.ietf-idr-tunnel-encaps]. 266 o Tunnel-Type is set to TBD2 (to be assigned by IANA from the "BGP 267 Tunnel Encapsulation Attribute Tunnel Types" registry). 269 o Preference, Binding SID, Segment-List, Weight and Segment are 270 defined in this document. 272 o Additional sub-TLVs may be defined in the future. 274 A single occurrence of "Tunnel Type: SR TE Policy" MUST be encoded 275 within the same Tunnel Encapsulation Attribute. 277 Multiple occurrences of "Segment List" MAY be encoded within the same 278 SR TE Policy. 280 Multiple occurrences of "Segment" MAY be encoded within the same 281 Segment List. 283 2.3. Remote Endpoint and Color 285 The Remote Endpoint and Color sub-TLVs, as defined in 286 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR TE Policy 287 encodings. 289 If present, the Remote Endpoint sub-TLV MUST match the Endpoint of 290 the SR TE Policy SAFI NLRI. 292 If present, the Color sub-TLV MUST match the Policy Color of the SR 293 TE Policy SAFI NLRI. 295 2.4. SR TE Policy Sub-TLVs 297 This section defines the SR TE Policy sub-TLVs. 299 Preference, Binding SID, Segment-List are allocated from the "BGP 300 Tunnel Encapsulation Attribute sub-TLVs" registry. 302 Weight and Segment Sub-TLVs are allocated from a new registry defined 303 in this document and called: "SR TE Policy List Sub-TLVs". See 304 Section 6 for the details of the registry. 306 2.4.1. Preference sub-TLV 308 The Preference sub-TLV is used in order to determine the preference 309 among multiple SR TE Policy originators. 311 The Preference sub-TLV is optional, MAY appear only once in the SR TE 312 Policy and has following format: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | Length | Flags | RESERVED | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Preference (4 octets) | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 where: 324 o Type: TBD3 (to be assigned by IANA from the "BGP Tunnel 325 Encapsulation Attribute sub-TLVs" registry). 327 o Length: 6. 329 o Flags: 1 octet of flags. None is defined at this stage. Flags 330 SHOULD be unset on transmission and MUST be ignored on receipt. 332 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 333 transmission and MUST be ignored on receipt. 335 o Preference: a 4-octet value. The highest value is preferred. 337 The Preference is used when the same policy is 338 advertised by multiple originators of the same SR TE Policy. The 339 Preference is used by the receiver in order to determine which of the 340 received policies are to be installed. The following rules apply to 341 the Preference: 343 o Preference is to be applied to the tuple. The 344 Distinguisher MUST NOT be considered. 346 o Preference is used in order to determine which instance of a given 347 SR TE Policy is to be installed. However, Preference MUST NOT 348 influence the BGP selection algorithm and propagation rules. In 349 other words, the preference selection happens after the BGP path 350 selection. 352 2.4.2. SR TE Binding SID Sub-TLV 354 The Binding SID sub-TLV requests the allocation of a Binding Segment 355 identifier associated with the SR TE Policy. 357 The Binding SID sub-TLV is optional, MAY appear only once in the SR 358 TE Policy and has the following format: 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type | Length | Flags | RESERVED | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Binding SID (variable, optional) | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 where: 370 o Type: TBD4 (to be assigned by IANA from the "BGP Tunnel 371 Encapsulation Attribute sub-TLVs" registry). 373 o Length: specifies the length of the value field not including Type 374 and Length fields. Can be 2 or 6 or 18. 376 o Flags: 1 octet of flags. None is defined at this stage. Flags 377 SHOULD be unset on transmission and MUST be ignored on receipt. 379 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 380 transmission and MUST be ignored on receipt. 382 o Binding SID: if length is 2, then no Binding SID is present. If 383 length is 6 then the Binding SID contains a 4-octet SID. If 384 length is 18 then the Binding SID contains a 16-octet IPv6 SID. 386 The Binding SID sub-TLV is used to instruct the receiver of the BGP 387 message to allocate a Binding SID to the SR TE Policy. The 388 allocation of the Binding SID in the receiver is done according to 389 following rules: 391 o If length is 2 (no value field is present), then the receiver MUST 392 allocate a local Binding SID whose value is chosen by the 393 receiver. 395 o If length is 6, then the value field contains the 4-octet Binding 396 SID value the receiver SHOULD allocate. 398 o If length is 18, then the value field contains the 16-octet 399 Binding SID value the receiver SHOULD allocate. 401 When a controller is used in order to define and advertise SR TE 402 Policies and when the Binding SID is allocated by the receiver, such 403 Binding SID SHOULD be reported to the controller. The mechanisms 404 and/or APIs used for the reporting of the Binding SID are outside the 405 scope of this document. 407 Further use of the Binding SID is described in a subsequent section. 409 2.4.3. Segment List Sub-TLV 411 The Segment List sub-TLV is used in order to encode a single explicit 412 path towards the endpoint. The Segment List sub-TLV includes the 413 elements of the paths (i.e.: segments) as well as an optional Weight 414 TLV. 416 The Segment List sub-TLV may exceed 255 bytes length due to large 417 number of segments. Therefore a 2-octet length is required. 418 According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- 419 TLV code point defines the size of the length field. Therefore, for 420 the Segment List sub-TLV a code point of 128 (or higher) is used. 421 See Section 6 section for details of codepoints allocation. 423 The Segment List sub-TLV is mandatory, MAY appear multiple times in 424 the SR TE Policy and has the following format: 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type | Length | RESERVED | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 // sub-TLVs // 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 where: 436 o Type: TBD5 (to be assigned by IANA from the "BGP Tunnel 437 Encapsulation Attribute sub-TLVs" registry). 439 o Length: the total length (not including the Type and Length 440 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 442 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 443 transmission and MUST be ignored on receipt. 445 o sub-TLVs: 447 * An optional single Weight sub-TLV. 449 * One or more Segment sub-TLVs. 451 The Segment List sub-TLV is mandatory. 453 Multiple occurrences of the Segment List sub-TLV MAY appear in the SR 454 TE Policy. 456 When multiple occurrences of the Segment List sub-TLV appear in the 457 SR TE Policy, the traffic is load-balanced across them either through 458 an ECMP scheme (if no Weight sub-TLV is present) or through a 459 weighted UCMP scheme according to Section 2.4.3.1. 461 The Segment-List Sub-TLV MUST contain at least one Segment Sub-TLV 462 and MAY contain a Weight Sub-TLV. 464 2.4.3.1. Weight Sub-TLV 466 The Weight sub-TLV specifies the weight associated to a given path 467 (i.e.: a given segment list). The weight is used in order to apply 468 weighted UCMP mechanism when steering traffic into a policy that 469 includes multiple Segment Lists sub-TLVs (i.e.: multiple explicit 470 paths). 472 The Weight sub-TLV is optional, MAY only appear once inside the 473 Segment List sub-TLV, and has the following format: 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type | Length | Flags | RESERVED | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Weight | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 where: 485 Type: 9 (to be assigned by IANA from the registry "SR TE Policy List 486 Sub-TLVs" defined in this document). 488 Length: 6. 490 Flags: 1 octet of flags. None is defined at this stage. Flags 491 SHOULD be unset on transmission and MUST be ignored on receipt. 493 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 494 and MUST be ignored on receipt. 496 When present, the Weight sub-TLV specifies a weight to be associated 497 with the corresponding Segment List, for use in unequal cost multi- 498 path. Weights are applied by summing the total value of all of the 499 weights for all Segment Lists, and then assigning a fraction of the 500 forwarded traffic to each Segment List in proportion its weight's 501 fraction of the total. 503 2.4.3.2. Segment Sub-TLV 505 The Segment sub-TLV describes a single segment in a segment list 506 (i.e.: a single element of the explicit path). Multiple Segment sub- 507 TLVs constitute an explicit path of the SR TE Policy. 509 The Segment sub-TLV is mandatory and MAY appear multiple times in the 510 Segment List sub-TLV. 512 This document defines 8 different types of Segment Sub-TLVs: 514 Type 1: SID only, in the form of MPLS Label 515 Type 2: SID only, in the form of IPv6 address 516 Type 3: IPv4 Node Address with optional SID 517 Type 4: IPv6 Node Address with optional SID 518 Type 5: IPv4 Address + index with optional SID 519 Type 6: IPv4 Local and Remote addresses with optional SID 520 Type 7: IPv6 Address + index with optional SID 521 Type 8: IPv6 Local and Remote addresses with optional SID 523 2.4.3.2.1. Type 1: SID only, in the form of MPLS Label 525 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 526 MPLS label. The format is as follows: 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Type | Length | Flags | RESERVED | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Label | TC |S| TTL | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 where: 538 o Type: 1 (to be assigned by IANA from the registry "SR TE Policy 539 List Sub-TLVs" defined in this document). 541 o Length is 6. 543 o Flags: 1 octet of flags. None is defined at this stage. Flags 544 SHOULD be unset on transmission and MUST be ignored on receipt. 546 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 547 transmission and MUST be ignored on receipt. 549 o Label: 20 bits of label value. 551 o TC: 3 bits of traffic class. 553 o S: 1 bit of bottom-of-stack. 555 o TTL: 1 octet of TTL. 557 The following applies to the Type-1 Segment sub-TLV: 559 o The S bit SHOULD be zero upon transmission, and MUST be ignored 560 upon reception. 562 o If the originator wants the receiver to choose the TC value, it 563 sets the TC field to zero. 565 o If the originator wants the receiver to choose the TTL value, it 566 sets the TTL field to 255. 568 o If the originator wants to recommend a value for these fields, it 569 puts those values in the TC and/or TTL fields. 571 o The receiver MAY override the originator's values for these 572 fields. This would be determined by local policy at the receiver. 573 One possible policy would be to override the fields only if the 574 fields have the default values specified above. 576 2.4.3.2.2. Type 2: SID only, in the form of IPv6 address 578 The Type-2 Segment Sub-TLV encodes a single SID in the form of an 579 IPv6 address. The format is as follows: 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type | Length | Flags | RESERVED | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 // IPv6 SID (16 octets) // 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 where: 591 o Type: 2 (to be assigned by IANA from the registry "SR TE Policy 592 List Sub-TLVs" defined in this document). 594 o Length is 18. 596 o Flags: 1 octet of flags. None is defined at this stage. Flags 597 SHOULD be unset on transmission and MUST be ignored on receipt. 599 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 600 transmission and MUST be ignored on receipt. 602 o IPv6 SID: 16 octets of IPv6 address. 604 The IPv6 Segment Identifier (IPv6 SID) is defined in 605 [I-D.ietf-6man-segment-routing-header]. 607 2.4.3.2.3. Type 3: IPv4 Node Address with optional SID 609 The Type-3 Segment Sub-TLV encodes an IPv4 node address and an 610 optional SID in the form of either an MPLS label or an IPv6 address. 611 The format is as follows: 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type | Length | Flags | RESERVED | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | IPv4 Node Address (4 octets) | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 // SID (optional, 4 or 16 octets) // 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 where: 625 o Type: 3 (to be assigned by IANA from the registry "SR TE Policy 626 List Sub-TLVs" defined in this document). 628 o Length is 6 or 10 or 22. 630 o Flags: 1 octet of flags. None is defined at this stage. Flags 631 SHOULD be unset on transmission and MUST be ignored on receipt. 633 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 634 transmission and MUST be ignored on receipt. 636 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 638 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 640 The following applies to the Type-3 Segment sub-TLV: 642 o The IPv4 Node Address MUST be present. 644 o The SID is optional and MAY be of one of the following formats: 646 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 647 defined in Section 2.4.3.2.1. 649 * IPV6 SID: a 16 octet IPv6 address. 651 o If length is 6, then only the IPv4 Node Address is present. 653 o If length is 10, then the IPv4 Node Address and the MPLS SID are 654 present. 656 o If length is 22, then the IPv4 Node Address and the IPv6 SID are 657 present. 659 2.4.3.2.4. Type 4: IPv6 Node Address with optional SID 661 The Type-4 Segment Sub-TLV encodes an IPv6 node address and an 662 optional SID in the form of either an MPLS label or an IPv6 address. 663 The format is as follows: 665 0 1 2 3 666 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 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Type | Length | Flags | RESERVED | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 // IPv6 Node Address (16 octets) // 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 // SID (optional, 4 or 16 octets) // 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 where: 677 o Type: 4 (to be assigned by IANA from the registry "SR TE Policy 678 List Sub-TLVs" defined in this document). 680 o Length is 18 or 22 or 34. 682 o Flags: 1 octet of flags. None is defined at this stage. Flags 683 SHOULD be unset on transmission and MUST be ignored on receipt. 685 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 686 transmission and MUST be ignored on receipt. 688 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 690 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 692 The following applies to the Type-4 Segment sub-TLV: 694 o The IPv6 Node Address MUST be present. 696 o The SID is optional and MAY be of one of the following formats: 698 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 699 defined in Section 2.4.3.2.1. 701 * IPV6 SID: a 16 octet IPv6 address. 703 o If length is 18, then only the IPv6 Node Address is present. 705 o If length is 22, then the IPv6 Node Address and the MPLS SID are 706 present. 708 o If length is 34, then the IPv6 Node Address and the IPv6 SID are 709 present. 711 2.4.3.2.5. Type 5: IPv4 Address + index with optional SID 713 The Type-5 Segment Sub-TLV encodes an IPv4 node address, an interface 714 index (IfIndex) and an optional SID in the form of either an MPLS 715 label or an IPv6 address. The format is as follows: 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Type | Length | Flags | RESERVED | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | IfIndex (4 octets) | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | IPv4 Node Address (4 octets) | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 // SID (optional, 4 or 16 octets) // 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 where: 731 o Type: 5 (to be assigned by IANA from the registry "SR TE Policy 732 List Sub-TLVs" defined in this document). 734 o Length is 10 or 14 or 26. 736 o Flags: 1 octet of flags. None is defined at this stage. Flags 737 SHOULD be unset on transmission and MUST be ignored on receipt. 739 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 740 transmission and MUST be ignored on receipt. 742 o IfIndex: 4 octets of interface index. 744 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 746 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 748 The following applies to the Type-5 Segment sub-TLV: 750 o The IPv4 Node Address MUST be present. 752 o The Interface Index (IfIndex) MUST be present. 754 o The SID is optional and MAY be of one of the following formats: 756 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 757 defined in Section 2.4.3.2.1. 759 * IPV6 SID: a 16 octet IPv6 address. 761 o If length is 10, then the IPv4 Node Address and IfIndex are 762 present. 764 o If length is 14, then the IPv4 Node Address, the IfIndex and the 765 MPLS SID are present. 767 o If length is 26, then the IPv4 Node Address, the IfIndex and the 768 IPv6 SID are present. 770 2.4.3.2.6. Type 6: IPv4 Local and Remote addresses with optional SID 772 The Type-6 Segment Sub-TLV encodes an IPv4 node address, an adjacency 773 local address, an adjacency remote address and an optional SID in the 774 form of either an MPLS label or an IPv6 address. The format is as 775 follows: 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Type | Length | Flags | RESERVED | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Local IPv4 Address (4 octets) | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Remote IPv4 Address (4 octets) | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 // SID (4 or 16 octets) // 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 where: 791 o Type: 6 (to be assigned by IANA from the registry "SR TE Policy 792 List Sub-TLVs" defined in this document). 794 o Length is 10 or 14 or 26. 796 o Flags: 1 octet of flags. None is defined at this stage. Flags 797 SHOULD be unset on transmission and MUST be ignored on receipt. 799 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 800 transmission and MUST be ignored on receipt. 802 o Local IPv4 Address: a 4 octet IPv4 address. 804 o Remote IPv4 Address: a 4 octet IPv4 address. 806 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 808 The following applies to the Type-6 Segment sub-TLV: 810 o The Local IPv4 Address MUST be present and represents an adjacency 811 local address. 813 o The Remote IPv4 Address MUST be present and represents the remote 814 end of the adjacency. 816 o The SID is optional and MAY be of one of the following formats: 818 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 819 defined in Section 2.4.3.2.1. 821 * IPV6 SID: a 16 octet IPv6 address. 823 o If length is 10, then only the IPv4 Local and Remote addresses are 824 present. 826 o If length is 14, then the IPv4 Local address, IPv4 Remote address 827 and the MPLS SID are present. 829 o If length is 26, then the IPv4 Local address, IPv4 Remote address 830 and the IPv6 SID are present. 832 2.4.3.2.7. Type 7: IPv6 Address + index with optional SID 834 The Type-7 Segment Sub-TLV encodes an IPv6 node address, an interface 835 index and an optional SID in the form of either an MPLS label or an 836 IPv6 address. The format is as follows: 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Type | Length | Flags | RESERVED | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | IfIndex (4 octets) | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 // IPv6 Node Address (16 octets) // 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 // SID (optional, 4 or 16 octets) // 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 where: 852 o Type: 7 (to be assigned by IANA from the registry "SR TE Policy 853 List Sub-TLVs" defined in this document). 855 o Length is 22 or 26 or 38. 857 o Flags: 1 octet of flags. None is defined at this stage. Flags 858 SHOULD be unset on transmission and MUST be ignored on receipt. 860 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 861 transmission and MUST be ignored on receipt. 863 o IfIndex: 4 octets of interface index. 865 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 867 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 869 The following applies to the Type-7 Segment sub-TLV: 871 o The IPv6 Node Address MUST be present. 873 o The Interface Index MUST be present. 875 o The SID is optional and MAY be of one of the following formats: 877 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 878 defined in Section 2.4.3.2.1. 880 * IPV6 SID: a 16 octet IPv6 address. 882 o If length is 22, then the IPv6 Node Address and IfIndex are 883 present. 885 o If length is 26, then the IPv6 Node Address, the IfIndex and the 886 MPLS SID are present. 888 o If length is 38, then the IPv6 Node Address, the IfIndex and the 889 IPv6 SID are present. 891 2.4.3.2.8. Type 8: IPv6 Local and Remote addresses with optional SID 893 The Type-8 Segment Sub-TLV encodes an IPv6 node address, an adjacency 894 local address, an adjacency remote address and an optional SID in the 895 form of either an MPLS label or an IPv6 address. The format is as 896 follows: 898 0 1 2 3 899 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 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Type | Length | Flags | RESERVED | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 // Local IPv6 Address (16 octets) // 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 // Remote IPv6 Address (16 octets) // 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 // SID (4 or 16 octets) // 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 where: 912 o Type: 8 (to be assigned by IANA from the registry "SR TE Policy 913 List Sub-TLVs" defined in this document). 915 o Length is 34 or 38 or 50. 917 o Flags: 1 octet of flags. None is defined at this stage. Flags 918 SHOULD be unset on transmission and MUST be ignored on receipt. 920 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 921 transmission and MUST be ignored on receipt. 923 o Local IPv6 Address: a 16 octet IPv6 address. 925 o Remote IPv6 Address: a 16 octet IPv6 address. 927 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 929 The following applies to the Type-8 Segment sub-TLV: 931 o The Local IPv6 Address MUST be present and represents an adjacency 932 local address. 934 o The Remote IPv6 Address MUST be present and represents the remote 935 end of the adjacency. 937 o The SID is optional and MAY be of one of the following formats: 939 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 940 defined in Section 2.4.3.2.1. 942 * IPV6 SID: a 16 octet IPv6 address. 944 o If length is 34, then only the IPv6 Local and Remote addresses are 945 present. 947 o If length is 38, then the IPv6 Local address, IPv4 Remote address 948 and the MPLS SID are present. 950 o If length is 50, then the IPv6 Local address, IPv4 Remote address 951 and the IPv6 SID are present. 953 3. SR TE Policy Operations 955 3.1. Configuration and Advertisement of SR TE Policies 957 Typically, but not limited to, a SR TE Policy is configured into a 958 controller and on the base of each receiver. In other words, each SR 959 TE Policy configured is related to the intended receiver. It is 960 therefore normal for a given SR TE Policy to have 961 multiple instances with different content (i.e.: different segment 962 lists) where each of these instances (of the same policy) is intended 963 to be sent to different receivers. 965 Each instance of the same SR TE Policy will have a different 966 Distinguisher in order to prevent BGP selection among these instances 967 along the distribution of BGP updates. 969 Moreover, a Route-Target extended community SHOULD be attached to the 970 SR TE Policy and that identifies the intended receiver of the 971 advertisement. 973 If no route-target is attached to the SR TE Policy NLRI, then it is 974 assumed that the originator sends the SR TE Policy update directly 975 (e.g.: through iBGP multihop) to the intended receiver. In such 976 case, the NO_ADVERTISE community MUST be attached to the SR TE Policy 977 update. 979 3.2. Multipath Operation 981 The SR TE Policy MAY contain multiple Segment Lists which, in the 982 absence of the Weight TLV, signifies equal cost load balancing 983 amongst them. 985 When a weight sub-TLV is encoded in each Segment List TLV, then the 986 weight value SHOULD be used in order to perform an unequal cost load 987 balance amongst the Segment Lists as specified in Section 2.4.3.1. 989 3.3. Binding SID TLV 991 When the optional Binding SID sub-TLV is present, it indicates an 992 instruction, to the receiving BGP speaker to allocate a Binding SID 993 for the list of SIDs the Binding sub-TLV is related to. 995 Any incoming packet with the Binding SID as active segment (according 996 to the terminology described in [I-D.ietf-spring-segment-routing]) 997 will then have the Binding SID swapped with the list of SIDs 998 specified in the Segment List sub-TLVs on the allocating BGP speaker. 999 The allocated Binding SID MAY be then advertised by the BGP speaker 1000 that created it, through, e.g., BGP-LS in order to, typically, feed a 1001 controller with the updated topology and SR TE Policy information. 1003 3.4. Reception of an SR TE Policy 1005 On reception of a SR TE Policy, a BGP speaker MUST determine if the 1006 SR TE Policy is first acceptable, then usable. 1008 While only usable SR TE Policies are instantiated, acceptable SR TE 1009 Policies (i.e.: also the non-usable ones) MAY be propagated. 1011 Any SR TE Policy update that has been determined acceptable is kept 1012 in the BGP database. This includes non-usable SR TE Policies. 1014 3.4.1. Acceptance of a SR TE Policy Update 1016 When a BGP speaker receives an SR TE Policy from a neighbor it has to 1017 determine if the SR TE Policy advertisement is acceptable. The 1018 following applies: 1020 o The SR TE Policy NLRI MUST have a color value and MUST have an 1021 endpoint value. 1023 o The SR TE Policy NLRI MUST have distinguisher field. 1025 o The SR TE Policy update MUST have either the NO_ADV community or 1026 at least one route-target extended community in IPv4-address 1027 format. 1029 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1030 Update and MUST have the Tunnel Type set to SR TE Policy (value to 1031 be assigned by IANA). 1033 o Within the SR TE Policy, at least one Segment List sub-TLV MUST be 1034 present. 1036 o Within the Segment List sub-TLV at least one Segment sub-TLV MUST 1037 be present. 1039 The Remote Endpoint and Color sub-TLVs, as defined in 1040 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR TE Policy 1041 encodings. If present, the Remote Endpoint sub-TLV MUST match the 1042 Endpoint of the SR TE Policy SAFI NLRI. If they don't match, the SR 1043 TE Policy advertisement MUST be considered as not acceptable. If 1044 present, the Color sub-TLV MUST match the Policy Color of the SR TE 1045 Policy SAFI NLRI. If they don't match, the SR TE Policy 1046 advertisement MUST be considered as not acceptable. 1048 A non-acceptable SR TE Policy update that has a valid NLRI portion 1049 with invalid attribute portion MUST be considered as a withdraw of 1050 the SR TE Policy. 1052 A non-acceptable SR TE Policy update that has an invalid NLRI portion 1053 MUST trigger a reset of the BGP session. 1055 3.4.2. Usable SR TE Policy 1057 When the receiver has determined that the received SR TE Policy is 1058 acceptable according to previous section, it has to determine if the 1059 received SR TE Policy is usable. 1061 The receiver MUST check whether route-target or NO_ADVERTISE 1062 communities are attached to it. If no route-target is present and 1063 the NO_ADVERTISE community is present, then the SR TE Policy is 1064 usable. 1066 If one or more route-targets are present, then at least one route- 1067 target MUST match the BGP Identifier (BGP Router-ID) of the receiver 1068 in order for the update to be considered usable. The BGP Identifier 1069 is defined in [RFC4271] as a 4 octet IPv4 address. Therefore the 1070 route-target extended community MUST be of the same format. 1072 If one or more route-targets are present and no one matches the local 1073 BGP router-ID, then, while the SR TE Policy is acceptable, the SR TE 1074 Policy is not usable. It has to be noted that if the receiver has 1075 been explicitly configured to do so, it MAY propagate the SR TE 1076 Policy to its neighbors as defined in Section 3.4.4. 1078 The following applies to usable SR TE Policies: 1080 o Any segment sub-TLV of type 3 to 8 that is present in the segment 1081 list MUST be either validated or resolved: 1083 if the SID portion of the sub-TLV is present, then the segment 1084 MUST be validated by the receiver. Validation consists of 1085 verifying that the SID value is related to the network address. 1087 if the SID portion of the sub-TLV is not present, then the 1088 segment MUST be resolved by the receiver. Resolution consists 1089 of taking from the receiver database (e.g.; from the link-state 1090 or routing information base) that the SID value related to the 1091 network address in the sub-TLV. 1093 o The receiver MUST check the validity of the first SID of each 1094 Segment List sub-TLV of the SR TE Policy. The first SID MUST be 1095 known in the receiver local table either as a label (in the case 1096 the SID encodes a label value) or as an IPv6 address. 1098 o Any invalid segment of the segment list MUST cause an invalidation 1099 of the whole segment list. However, the SR TE Policy is still 1100 usable if at least one segment list is valid. 1102 o The receiver much keep track of the validated segment (i.e.: the 1103 first segment and any segment encoded in Sub-TLV type 3 to 8). A 1104 segment who failed validation may become valid after a network 1105 event and vice versa. The receiver SHOULD keep the state of the 1106 received SR TE Policies based on latest state of the segments 1107 requires validation. 1109 It has to be noted that an SR-TE policy may be received by a server 1110 that is not a router, and that does not have the necessary state that 1111 allows him to infer the next-hop from the first segment. In that 1112 case, if the server needs to send a packet according to a particular 1113 SR-TE policy, it SHOULD push on the label stack that the policy 1114 specifies, and then send the packet to a default router (or default 1115 gateway). 1117 3.4.3. Instantiation of an SR TE Policy 1119 On reception of an acceptable, valid and usable SR TE Policy, a BGP 1120 speaker SHOULD instantiate the SR TE Policy in its routing and 1121 forwarding table with the set of segment lists (i.e.: explicit paths) 1122 included in the policy and taking into account the Binding SID and 1123 Weight sub-TLVs. 1125 The receiver of the SR TE Policy SHOULD program its MPLS or IPv6 data 1126 planes so that BGP destination prefixes matching their Extended Color 1127 Community and BGP next-hop with the SR TE Policy SAFI NLRI Color and 1128 Endpoint are steered into the SR TE Policy and forwarded accordingly. 1130 When building the MPLS label stack or the IPv6 Segment list from the 1131 Segment List sub-TLV, the receiving BGP speaker MUST interpret the 1132 set of Segment sub-TLVs as follows: 1134 o The first Segment sub-TLV represents the topmost label or the 1135 first IPv6 segment. In the receiving BGP speaker, it identifies 1136 the first segment the traffic will be directed towards to (along 1137 the SR TE explicit path). 1139 o The last Segment sub-TLV represents the bottommost label or the 1140 last IPv6 segment. 1142 As described in Section 2.4.3.1, when present, the Weight sub-TLV 1143 specifies a weight to be associated with the corresponding Segment 1144 List, for use in unequal-cost multi path. Weights are applied by 1145 summing the total value of all of the weights for all Segment Lists, 1146 and then assigning a fraction of the forwarded traffic to each 1147 Segment List in proportion its weight's fraction of the total. 1149 If in a SR TE Policy only some of the segment lists have a Weight 1150 Sub-TLV present, then for those who haven't any weight, a value of 1 1151 is assumed. 1153 3.4.4. Propagation of an SR TE Policy 1155 By default, a BGP node receiving an SR TE Policy MUST NOT not 1156 propagate it to any eBGP neighbor. 1158 However, a node MAY be explicitly configured in order to advertise a 1159 received SR TE Policy update to neighbors according to normal BGP 1160 rules (iBGP and eBGP propagation), e.g., in the case the node is a 1161 Route-Reflector. 1163 SR TE Policies that have been determined acceptable and valid can be 1164 propagated, even the ones that are not usable. 1166 Only SR TE Policies that do not have the NO_ADVERTISE community 1167 attached to them can be propagated. 1169 3.5. Steering Traffic into a SR TE Policy 1171 The Color field of the NLRI allows association of destination 1172 prefixes with a given SR TE Policy. The BGP speaker SHOULD then 1173 attach a Color Extended Community (as defined in [RFC5512]) to 1174 destination prefixes (e.g.: IPv4/IPv6 unicast prefixes) in order to 1175 allow the receiver of the SR TE Policy and of the destination prefix 1176 to steer traffic into the SR TE Policy if the destination prefix: 1178 o Has a BGP next-hop matching the SR TE Policy SAFI NLRI Endpoint 1179 and 1181 o Has an attached Extended Color Community with the same value as 1182 the color of the SR TE Policy NLRI Color. 1184 On the receiving BGP speaker, all destination prefixes that share the 1185 same Extended Color Community value and the same BGP next-hop are 1186 steered to the corresponding SR TE Policy that has been instantiated 1187 and which matches the Color and Endpoint NLRI values. 1189 It is assumed that only one Extended Color Community is attached to a 1190 destination prefix. In case a destination prefix is received with 1191 multiple Extended Color Communities, the receiver MUST consider the 1192 color corresponding to the SR TE Policy having the highest Preference 1193 TLV value. In case of multiple policies having the same preference, 1194 as a breaking tie, the router SHOULD select the policy having the 1195 lowest color value. 1197 Different destination prefixes can be steered into distinct SR TE 1198 Policies by coloring them differently. 1200 3.6. Flowspec and SR TE Policies 1202 The SR TE Policy can be carried in context of a Flowspec NLRI 1203 ([RFC5575]). In this case, when the redirect to IP next-hop is 1204 specified as in [I-D.ietf-idr-flowspec-redirect-ip], the tunnel to 1205 the next-hop is specified by the segment list in the Segment List 1206 sub-TLVs. The Segment List (e.g..: label stack or IPv6 segment list) 1207 is imposed to flows matching the criteria in the Flowspec route in 1208 order to steer them towards the next-hop as specified in the SR TE 1209 Policy SAFI NLRI. 1211 4. Acknowledgments 1213 The authors of this document would like to thank Dhanendra Jain, 1214 Shyam Sethuram, Acee Lindem, Imtiyaz Mohammad and John Scudder for 1215 their comments and review of this document. 1217 5. Implementation Status 1219 Note to RFC Editor: Please remove this section prior to publication, 1220 as well as the reference to RFC 7942. 1222 This section records the status of known implementations of the 1223 protocol defined by this specification at the time of posting of this 1224 Internet-Draft, and is based on a proposal described in [RFC7942]. 1225 The description of implementations in this section is intended to 1226 assist the IETF in its decision processes in progressing drafts to 1227 RFCs. Please note that the listing of any individual implementation 1228 here does not imply endorsement by the IETF. Furthermore, no effort 1229 has been spent to verify the information presented here that was 1230 supplied by IETF contributors. This is not intended as, and must not 1231 be construed to be, a catalog of available implementations or their 1232 features. Readers are advised to note that other implementations may 1233 exist. 1235 According to [RFC7942], "this will allow reviewers and working groups 1236 to assign due consideration to documents that have the benefit of 1237 running code, which may serve as evidence of valuable experimentation 1238 and feedback that have made the implemented protocols more mature. 1239 It is up to the individual working groups to use this information as 1240 they see fit". 1242 Several early implementations exist and will be reported in detail in 1243 a forthcoming version of this document. For purposes of early 1244 interoperability testing, when no FCFS code point was available, 1245 implementations have made use of the following values: 1247 o Preference sub-TLV: 6 1249 o Binding SID sub-TLV: 7 1251 o Segment List sub-TLV: 128 1253 When IANA-assigned values are available, implementations will be 1254 updated to use them. 1256 6. IANA Considerations 1258 This document defines new Sub-TLVs in following existing registries: 1260 o Subsequent Address Family Identifiers (SAFI) Parameters 1262 o BGP Tunnel Encapsulation Attribute Tunnel Types 1264 o BGP Tunnel Encapsulation Attribute sub-TLVs 1266 This document also defines a new registry: "SR TE Policy List Sub- 1267 TLVs". 1269 6.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1270 Parameters 1272 This document defines a new SAFI in the registry "Subsequent Address 1273 Family Identifiers (SAFI) Parameters": 1275 Codepoint Description Reference 1276 ----------------------------------------------- 1277 TBD1 SR TE Policy SAFI This document 1279 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1281 This document defines a new Tunnel-Type in the registry "BGP Tunnel 1282 Encapsulation Attribute Tunnel Types": 1284 Codepoint Description Reference 1285 -------------------------------------------------- 1286 TBD2 SR TE Policy Type This document 1288 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1290 This document defines new sub-TLVs in the registry "BGP Tunnel 1291 Encapsulation Attribute sub-TLVs": 1293 Codepoint Description Reference 1294 ------------------------------------------------------ 1295 TBD3 Preference sub-TLV This document 1296 TBD4 Binding SID sub-TLV This document 1297 TBD5 Segment List sub-TLV This document 1299 6.4. New Registry: SR TE Policy List Sub-TLVs 1301 This document defines a new registry called "SR TE Policy List Sub- 1302 TLVs". The allocation policy of this registry is "First Come First 1303 Served (FCFS)" according to [RFC5226]. 1305 Following Sub-TLV codepoints are defined: 1307 Value Description Reference 1308 ------------------------------------------------------------------ 1309 1 MPLS SID sub-TLV This document 1310 2 IPv6 SID sub-TLV This document 1311 3 IPv4 Node and SID sub-TLV This document 1312 4 IPv6 Node and SID sub-TLV This document 1313 5 IPv4 Node, index and SID sub-TLV This document 1314 6 IPv4 Local/Remote addresses and SID sub-TLV This document 1315 7 IPv6 Node, index and SID sub-TLV This document 1316 8 IPv6 Local/Remote addresses and SID sub-TLV This document 1317 9 Weight sub-TLV This document 1319 7. Security Considerations 1321 TBD. 1323 8. References 1325 8.1. Normative References 1327 [I-D.ietf-idr-tunnel-encaps] 1328 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 1329 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-03 1330 (work in progress), November 2016. 1332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1333 Requirement Levels", BCP 14, RFC 2119, 1334 DOI 10.17487/RFC2119, March 1997, 1335 . 1337 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1338 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1339 DOI 10.17487/RFC4271, January 2006, 1340 . 1342 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1343 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1344 February 2006, . 1346 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1347 "Multiprotocol Extensions for BGP-4", RFC 4760, 1348 DOI 10.17487/RFC4760, January 2007, 1349 . 1351 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1352 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1353 DOI 10.17487/RFC5226, May 2008, 1354 . 1356 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 1357 Subsequent Address Family Identifier (SAFI) and the BGP 1358 Tunnel Encapsulation Attribute", RFC 5512, 1359 DOI 10.17487/RFC5512, April 2009, 1360 . 1362 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1363 and D. McPherson, "Dissemination of Flow Specification 1364 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1365 . 1367 8.2. Informational References 1369 [I-D.ietf-6man-segment-routing-header] 1370 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 1371 J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, 1372 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1373 segment-routing-header-02 (work in progress), September 1374 2016. 1376 [I-D.ietf-idr-flowspec-redirect-ip] 1377 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 1378 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 1379 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 1380 in progress), February 2015. 1382 [I-D.ietf-spring-segment-routing] 1383 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1384 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1385 spring-segment-routing-10 (work in progress), November 1386 2016. 1388 [I-D.ietf-spring-segment-routing-mpls] 1389 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1390 Litkowski, S., Horneffer, M., Shakir, R., 1391 jefftant@gmail.com, j., and E. Crabbe, "Segment Routing 1392 with MPLS data plane", draft-ietf-spring-segment-routing- 1393 mpls-05 (work in progress), July 2016. 1395 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1396 Reflection: An Alternative to Full Mesh Internal BGP 1397 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1398 . 1400 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1401 Code: The Implementation Status Section", BCP 205, 1402 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1403 . 1405 Authors' Addresses 1407 Stefano Previdi (editor) 1408 Cisco Systems, Inc. 1409 Via Del Serafico, 200 1410 Rome 00142 1411 Italy 1413 Email: sprevidi@cisco.com 1415 Clarence Filsfils 1416 Cisco Systems, Inc. 1417 Brussels 1418 BE 1420 Email: cfilsfil@cisco.com 1422 Arjun Sreekantiah 1423 Cisco Systems, Inc. 1424 170 W. Tasman Drive 1425 San Jose, CA 95134 1426 USA 1428 Email: asreekan@cisco.com 1430 Siva Sivabalan 1431 Cisco Systems, Inc. 1432 170 W. Tasman Drive 1433 San Jose, CA 95134 1434 USA 1436 Email: msiva@cisco.com 1438 Paul Mattes 1439 Microsoft 1440 One Microsoft Way 1441 Redmond, WA 98052 1442 USA 1444 Email: pamattes@microsoft.com 1445 Eric Rosen 1446 Juniper Networks 1447 10 Technology Park Drive 1448 Westford, MA 01886 1449 US 1451 Email: erosen@juniper.net 1453 Steven Lin 1454 Google 1456 Email: stevenlin@google.com