idnits 2.17.1 draft-previdi-idr-segment-routing-te-policy-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 : ---------------------------------------------------------------------------- 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 (May 27, 2016) is 2890 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-01 ** 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-01 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-04 Summary: 2 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: November 28, 2016 S. Sivabalan 6 Cisco Systems, Inc. 7 P. Mattes 8 Microsoft 9 E. Rosen 10 Juniper Networks 11 May 27, 2016 13 Advertising Segment Routing Traffic Engineering Policies in BGP 14 draft-previdi-idr-segment-routing-te-policy-01 16 Abstract 18 This document defines a new BGP SAFI with a new NLRI in order to 19 advertise a Segment Routing Traffic Engineering Policy (SR TE 20 Policy). An SR TE Policy is a set of explicit paths represented by 21 one or more segment lists. The SR TE Policy is advertised along with 22 the Tunnel Encapsulation Attribute for which this document also 23 defines new sub-TLVs. An SR TE policy is advertised with the 24 information that will be used by the node receiving the advertisement 25 in order to instantiate the policy in its forwarding table and to 26 steer traffic according to the policy. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 28, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. SR TE Policy Encoding . . . . . . . . . . . . . . . . . . . . 4 65 2.1. SR TE Policy SAFI and NLRI . . . . . . . . . . . . . . . 4 66 2.2. SR TE Policy and Tunnel Encapsulation Attribute . . . . . 6 67 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 7 68 2.4. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . . . 7 69 2.4.1. Preference sub-TLV . . . . . . . . . . . . . . . . . 7 70 2.4.2. SR TE Binding SID Sub-TLV . . . . . . . . . . . . . . 8 71 2.4.3. Weight Sub-TLV . . . . . . . . . . . . . . . . . . . 9 72 2.4.4. Segment List Sub-TLV . . . . . . . . . . . . . . . . 10 73 2.4.5. Segment Sub-TLV . . . . . . . . . . . . . . . . . . . 11 74 3. SR TE Policy Operations . . . . . . . . . . . . . . . . . . . 21 75 3.1. Steering Traffic into a SR TE Policy . . . . . . . . . . 21 76 3.2. Configuration and Advertisement of SR TE Policies . . . . 21 77 3.3. Multipath Operation . . . . . . . . . . . . . . . . . . . 22 78 3.4. Binding SID TLV . . . . . . . . . . . . . . . . . . . . . 22 79 3.5. Reception of an SR TE Policy . . . . . . . . . . . . . . 22 80 3.6. Flowspec and SR TE Policies . . . . . . . . . . . . . . . 24 81 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 7.1. Normative References . . . . . . . . . . . . . . . . . . 26 86 7.2. Informational References . . . . . . . . . . . . . . . . 26 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 89 1. Introduction 91 Segment Routing (SR) technology leverages the source routing and 92 tunneling paradigms. [I-D.ietf-spring-segment-routing] describes the 93 SR architecture. [I-D.ietf-spring-segment-routing-mpls] describes 94 its instantiation on the MPLS data plane and 95 [I-D.ietf-6man-segment-routing-header] describes the Segment Routing 96 instantiation over the IPv6 data plane. 98 This document defines the Segment Routing Traffic Engineering Policy 99 (SR TE Policy) as a set of weighted equal cost multi path (WECMP) 100 segment lists (representing explicit paths) as well as the mechanism 101 allowing a router to steer traffic into an SR TE Policy. 103 The SR TE Policy is advertised in the Border Gateway Protocol (BGP) 104 by the BGP speaker being a router or a controller and using 105 extensions defined in this document. Among the information encoded 106 in the BGP message and representing the SR TE Policy, the steering 107 mechanism makes also use of the Extended Color Community currently 108 defined in [I-D.ietf-idr-tunnel-encaps] 110 Typically, a controller defines the set of policies and advertise 111 them to BGP routers (typically ingress routers). The policy 112 advertisement uses BGP extensions defined in this document. The 113 policy advertisement is, in most but not all of the cases, tailored 114 for the receiver. In other words, a policy advertised to a given BGP 115 speaker has significance only for that particular router and is not 116 intended to be propagated anywhere else. Then, the receiver of the 117 policy instantiate the policy in its routing and forwarding tables 118 and steer traffic into it based on both the policy and destination 119 prefix color and next-hop. 121 Alternatively, a router (i.e.: an BGP egress router) advertises SR TE 122 Policies representing paths to itself. These advertisements are sent 123 to BGP ingress nodes who instantiate these policies and steer traffic 124 into them according to the color and endpoint/BGP next-hop of both 125 the policy and the destination prefix. 127 An SR TE Policy being intended only for the receiver of the 128 advertisement, the SR TE Policies are sent directly to each receiver 129 and, in most of the cases will not traverse any Route Reflector (RR, 130 [RFC4456]). 132 However, there are cases where a SR TE Policy is intended to a group 133 of nodes. Also, in a deployment scenario, a controller may also rely 134 on the standard BGP update propagation scheme which makes use of 135 route reflectors. This cases require mechanisms that: 137 o Uniquely identify each instance of a given policy. 139 o Uniquely identify the intended receiver of a given SR TE Policy 140 advertisement. 142 The BGP extensions for the advertisement of SR TE Policies include 143 following components: 145 o A new Subsequent Address Family Identifier (SAFI) identifying the 146 content of the BGP message (i.e.: the SR TE Policy). 148 o A new NLRI identifying the SR TE Policy. 150 o A set of new TLVs to be inserted into the Tunnel Encapsulation 151 Attribute (as defined in [I-D.ietf-idr-tunnel-encaps]) and 152 describing the SR TE Policy. 154 o A route-target extended community ([RFC4360]) attached to the SR 155 TE Policy advertisement and that indicates the intended receiver 156 of such SR TE Policy advertisement. 158 o The Extended Color Community (as defined in 159 [I-D.ietf-idr-tunnel-encaps]) and used in order to steer traffic 160 into an SR TE Policy. 162 1.1. Requirements Language 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 2. SR TE Policy Encoding 170 2.1. SR TE Policy SAFI and NLRI 172 A new SAFI is defined: the SR TE Policy SAFI (codepoint suggested 173 value 73, to be assigned by IANA). 175 The SR TE Policy SAFI uses a new NLRI defined as follows: 177 +-----------------------------------------------+ 178 | Distinguisher (4 octets) | 179 +-----------------------------------------------+ 180 | Policy Color (4 octets) | 181 +-----------------------------------------------+ 182 | Endpoint (4 or 16 octets) | 183 +-----------------------------------------------+ 185 where: 187 o Distinguisher: 4-octet value uniquely identifying the policy in 188 the context of tuple. The distinguisher has no 189 semantic and it's solely used by the SR TE Policy originator in 190 order to make unique (from a NLRI perspective) multiple 191 occurrences of the same SR TE Policy. 193 o Policy Color: 4-octet value identifying (with the endpoint) the 194 policy. The color is used to match the color of the destination 195 prefixes in order to steer traffic into the SR TE Policy. 197 o Endpoint: identifies the endpoint of a policy. The Endpoint may 198 represent a single node or a set of nodes (e.g.: an anycast 199 address or a summary address). The Endpoint may be an IPv4 200 (4-octet) address or an IPv6 (16-octet) address according to the 201 AFI of the NLRI. 203 The NLRI containing the SR TE Policy is carried in a BGP UPDATE 204 message [RFC4271] using BGP multiprotocol extensions [RFC4760] with 205 an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of 73 (suggested 206 value, to be assigned by IANA). 208 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 209 attribute with the SR TE Policy SAFI MUST also carry the BGP 210 mandatory attributes: NEXT_HOP, ORIGIN, AS_PATH, and LOCAL_PREF (for 211 IBGP neighbors), as defined in [RFC4271]. In addition, the BGP 212 update message MAY also contain any of the BGP optional attributes. 214 The NEXT_HOP value of the SR TE Policy SAFI NLRI is set based on the 215 AFI. For example, if the AFI is set to IPv4 (1), then the nexthop is 216 encoded as a 4-byte IPv4 address. If the AFI is set to IPv6 (2), 217 then the nexthop is encoded as a 16-byte IPv6 address of the router. 218 It is important to note that any BGP speaker receiving a BGP message 219 with an SR TE Policy NLRI, will process it only if the NLRI is a best 220 path as per the BGP best path selection algorithm. 222 The NEXT_HOP value of the SR TE Policy SAFI NLRI MUST be set as one 223 of the local addresses of the BGP speaker originating and advertising 224 the SR TE Policy (either the controller or the BGP egress node). 226 2.2. SR TE Policy and Tunnel Encapsulation Attribute 228 The content of the SR TE Policy is encoded in the Tunnel 229 Encapsulation Attribute originally defined in 230 [I-D.ietf-idr-tunnel-encaps] using a new Tunnel-Type TLV (suggested 231 codepoint is 14, to be assigned by IANA). 233 The SR TE Policy Encoding structure is as follows: 235 SR TE Policy SAFI NLRI: 236 Attributes: 237 Tunnel Encaps Attribute (23) 238 Tunnel Type: SR TE Policy 239 Binding SID 240 Preference 241 Segment List 242 Weight 243 Segment 244 Segment 245 ... 246 ... 247 ... 248 where: 250 o SR TE Policy SAFI NLRI is defined in Section 2.1. 252 o Tunnel Encapsulation Attribute is defined in 253 [I-D.ietf-idr-tunnel-encaps]. 255 o Tunnel-Type is set to a suggested value of 14 (to be assigned by 256 IANA). 258 o Preference, Binding SID, Weight, Segment and Segment-List are new 259 sub-TLVs defined in this document. 261 o Additional sub-TLVs may be defined in the future. 263 A single occurrence of "Tunnel Type: SR TE Policy" MUST be encoded 264 within the same Tunnel Encapsulation Attribute. 266 Multiple occurrences of "Segment List" MAY be encoded within the same 267 SR TE Policy. 269 Multiple occurrences of "Segment" MAY be encoded within the same 270 Segment List. 272 2.3. Remote Endpoint and Color 274 The Remote Endpoint and Color sub-TLVs, as defined in 275 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR TE Policy 276 encodings. 278 If present, the Remote Endpoint sub-TLV MUST match the Endpoint of 279 the SR TE Policy SAFI NLRI. If they don't match, the SR TE Policy 280 advertisement MUST be considered as invalid. 282 If present, the Color sub-TLV MUST match the Policy Color of the SR 283 TE Policy SAFI NLRI. If they don't match, the SR TE Policy 284 advertisement MUST be considered as invalid. 286 2.4. SR TE Policy Sub-TLVs 288 This section defines the SR TE Policy sub-TLVs. 290 2.4.1. Preference sub-TLV 292 The Preference sub-TLV is used in order to determine the preference 293 among multiple SR TE Policy originators. 295 The Preference sub-TLV is optional, MAY appear only once in the SR TE 296 Policy and has following format: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type | Length | Flags | RESERVED | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Preference (4 octets) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 where: 308 o Type: to be assigned by IANA (suggested value is 6). 310 o Length: 6. 312 o Flags: 1 octet of flags. None is defined at this stage. Flags 313 SHOULD be unset on transmission and MUST be ignored on receipt. 315 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 316 transmission and MUST be ignored on receipt. 318 o Preference: a 4-octet value. The highest value is preferred. 320 The Preference is used when the same policy is 321 advertised by multiple originators of the same SR TE Policy. The 322 Preference is used by the receiver in order to determine which of the 323 received policies are to be installed. The following rules apply to 324 the Preference: 326 o Preference is to be applied to the tuple. The 327 Distinguisher MUST NOT be considered. 329 o Preference is used in order to determine which instance of a given 330 SR TE Policy is to be installed. However, Preference MUST NOT 331 influence the BGP selection algorithm and propagation rules. In 332 other words, the preference selection happens after the BGP path 333 selection. 335 It must be noted that the Preference behavior is different from the 336 Local Preference BGP attribute. In the context of the SR TE Policy 337 advertisement, the Preference is used to determine which policy is 338 installed. It does not influence the BGP selection and propagation 339 mechanisms. 341 2.4.2. SR TE Binding SID Sub-TLV 343 The Binding SID sub-TLV requests the allocation of a Binding Segment 344 identifier associated with the SR TE Policy. 346 The Binding SID sub-TLV is mandatory, MUST appear only once in the SR 347 TE Policy and has the following format: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Type | Length | Flags | RESERVED | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Binding SID (variable, optional) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 where: 359 o Type: to be assigned by IANA (suggested value is 7). 361 o Length: specifies the length of the value field not including Type 362 and Length fields. Can be 2 or 6 or 18. 364 o Flags: 1 octet of flags. None is defined at this stage. Flags 365 SHOULD be unset on transmission and MUST be ignored on receipt. 367 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 368 transmission and MUST be ignored on receipt. 370 o Binding SID: if length is 2, then no Binding SID is present. If 371 length is 6 then the Binding SID contains a 4-octet SID. If 372 length is 18 then the Binding SID contains a 16-octet IPv6 SID. 374 The Binding SID sub-TLV is used to instruct the receiver of the BGP 375 message to allocate a Binding SID to the SR TE Policy. The 376 allocation of the Binding SID in the receiver is done according to 377 following rules: 379 o If length is 2 (no value field is present), then the receiver MUST 380 allocate a local Binding SID whose value is chosen by the 381 receiver. 383 o If length is 6, then the value field contains the 4-octet Binding 384 SID value the receiver SHOULD allocate. 386 o If length is 18, then the value field contains the 16-octet 387 Binding SID value the receiver SHOULD allocate. 389 When a controller is used in order to define and advertise SR TE 390 Policies and when the Binding SID is allocated by the receiver, such 391 Binding SID SHOULD be reported to the controller. The mechanisms 392 and/or APIs used for the reporting of the Binding SID are outside the 393 scope of this document. 395 Further use of the Binding SID is described in a subsequent section. 397 2.4.3. Weight Sub-TLV 399 The Weight sub-TLV specifies the weight associated to a given path 400 (i.e.: a given segment list). The weight is used in order to apply 401 weighted-ECMP mechanism when steering traffic into a policy that 402 includes multiple Segment Lists sub-TLVs (i.e.: multiple explicit 403 paths). 405 The Weight sub-TLV is optional, MAY only appear once in the Segment 406 List sub-TLV, and has the following format: 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type | Length | Flags | RESERVED | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Weight | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 where: 418 Type: to be assigned by IANA (suggested value is 9). 420 Length: 6. 422 Flags: 1 octet of flags. None is defined at this stage. Flags 423 SHOULD be unset on transmission and MUST be ignored on receipt. 425 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 426 and MUST be ignored on receipt. 428 When present, the Weight sub-TLV specifies a weight to be associated 429 with the corresponding Segment List, for use in unequal-cost multi 430 path. Weights are applied by summing the total value of all of the 431 weights for all Segment Lists, and then assigning a fraction of the 432 forwarded traffic to each Segment List in proportion its weight's 433 fraction of the total. 435 2.4.4. Segment List Sub-TLV 437 The Segment List sub-TLV is used in order to encode a single explicit 438 path towards the endpoint. The Segment List sub-TLV includes the 439 elements of the paths (i.e.: segments) as well as an optional Weight 440 TLV. 442 The Segment List sub-TLV may exceed 255 bytes length due to large 443 number of segments. Therefore a 2-octet length is required. 444 According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- 445 TLV code point defines the size of the length field. Therefore, for 446 the Segment List sub-TLV a code point of 128 (suggested value, to be 447 assigned by IANA) is used. 449 The Segment List sub-TLV is mandatory, MAY appear multiple times in 450 the SR TE Policy and has the following format: 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type | Length | RESERVED | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 // sub-TLVs // 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 where: 462 o Type: to be assigned by IANA (suggested value is 128). 464 o Length: the total length (not including the Type and Length 465 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 467 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 468 transmission and MUST be ignored on receipt. 470 o sub-TLVs: 472 * An optional single Weight sub-TLV. 474 * One or more Segment sub-TLVs. 476 The Segment List sub-TLV is mandatory. 478 Multiple occurrences of the Segment List sub-TLV MAY appear in the SR 479 TE Policy. 481 When multiple occurrences of the Segment List sub-TLV appear in the 482 SR TE Policy, the traffic is load-balanced across them either through 483 an ECMP scheme (if no Weight sub-TLV is present) or through a W-ECMP 484 scheme according to Section 2.4.3. 486 2.4.5. Segment Sub-TLV 488 The Segment sub-TLV describes a single segment in a segment list 489 (i.e.: a single element of the explicit path). Multiple Segment sub- 490 TLVs constitute an explicit path of the SR TE Policy. 492 The Segment sub-TLV is mandatory and MAY appear multiple times in the 493 Segment List sub-TLV. 495 This document defines 8 different types of Segment Sub-TLVs: 497 Type 1: SID only, in the form of MPLS Label 498 Type 2: SID only, in the form of IPv6 address 499 Type 3: IPv4 Node Address with optional SID 500 Type 4: IPv6 Node Address with optional SID 501 Type 5: IPv4 Address + index with optional SID 502 Type 6: IPv4 Local and Remote addresses with optional SID 503 Type 7: IPv6 Address + index with optional SID 504 Type 8: IPv6 Local and Remote addresses with optional SID 506 2.4.5.1. Type 1: SID only, in the form of MPLS Label 508 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 509 MPLS label. The format is as follows: 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type | Length | Flags | RESERVED | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Label | TC |S| TTL | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 where: 521 o Type: suggested value 1, to be assigned by IANA. 523 o Length is 6. 525 o Flags: 1 octet of flags. None is defined at this stage. Flags 526 SHOULD be unset on transmission and MUST be ignored on receipt. 528 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 529 transmission and MUST be ignored on receipt. 531 o Label: 20 bits of label value. 533 o TC: 3 bits of traffic class. 535 o S: 1 bit of bottom-of-stack. 537 o TTL: 1 octet of TTL. 539 The following applies to the Type-1 Segment sub-TLV: 541 o The S bit SHOULD be zero upon transmission, and MUST be ignored 542 upon reception. 544 o If the originator wants the receiver to choose the TC value, it 545 sets the TC field to zero. 547 o If the originator wants the receiver to choose the TTL value, it 548 sets the TTL field to 255. 550 o If the originator wants to recommend a value for these fields, it 551 puts those values in the TC and/or TTL fields. 553 o The receiver MAY override the originator's values for these 554 fields. This would be determined by local policy at the receiver. 555 One possible policy would be to override the fields only if the 556 fields have the default values specified above. 558 2.4.5.2. Type 2: SID only, in the form of IPv6 address 560 The Type-2 Segment Sub-TLV encodes a single SID in the form of an 561 IPv6 address. The format is as follows: 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Type | Length | Flags | RESERVED | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 // IPv6 SID (16 octets) // 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 where: 573 o Type: suggested value 2, to be assigned by IANA. 575 o Length is 18. 577 o Flags: 1 octet of flags. None is defined at this stage. Flags 578 SHOULD be unset on transmission and MUST be ignored on receipt. 580 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 581 transmission and MUST be ignored on receipt. 583 o IPv6 SID: 16 octets of IPv6 address. 585 The IPv6 Segment Identifier (IPv6 SID) is defined in 586 [I-D.ietf-6man-segment-routing-header]. 588 2.4.5.3. Type 3: IPv4 Node Address with optional SID 590 The Type-3 Segment Sub-TLV encodes an IPv4 node address and an 591 optional SID in the form of either an MPLS label or an IPv6 address. 592 The format is as follows: 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Type | Length | Flags | RESERVED | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | IPv4 Node Address (4 octets) | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 // SID (optional, 4 or 16 octets) // 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 where: 606 o Type: suggested value 3, to be assigned by IANA. 608 o Length is 6 or 10 or 22. 610 o Flags: 1 octet of flags. None is defined at this stage. Flags 611 SHOULD be unset on transmission and MUST be ignored on receipt. 613 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 614 transmission and MUST be ignored on receipt. 616 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 618 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 620 The following applies to the Type-3 Segment sub-TLV: 622 o The IPv4 Node Address MUST be present. 624 o The SID is optional and MAY be of one of the following formats: 626 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 627 defined in Section 2.4.5.1. 629 * IPV6 SID: a 16 octet IPv6 address. 631 o If length is 6, then only the IPv4 Node Address is present. 633 o If length is 10, then the IPv4 Node Address and the MPLS SID are 634 present. 636 o If length is 22, then the IPv4 Node Address and the IPv6 SID are 637 present. 639 2.4.5.4. Type 4: IPv6 Node Address with optional SID 641 The Type-4 Segment Sub-TLV encodes an IPv6 node address and an 642 optional SID in the form of either an MPLS label or an IPv6 address. 643 The format is as follows: 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Type | Length | Flags | RESERVED | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 // IPv6 Node Address (16 octets) // 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 // SID (optional, 4 or 16 octets) // 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 where: 657 o Type: suggested value 4, to be assigned by IANA. 659 o Length is 18 or 22 or 34. 661 o Flags: 1 octet of flags. None is defined at this stage. Flags 662 SHOULD be unset on transmission and MUST be ignored on receipt. 664 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 665 transmission and MUST be ignored on receipt. 667 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 669 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 671 The following applies to the Type-4 Segment sub-TLV: 673 o The IPv6 Node Address MUST be present. 675 o The SID is optional and MAY be of one of the following formats: 677 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 678 defined in Section 2.4.5.1. 680 * IPV6 SID: a 16 octet IPv6 address. 682 o If length is 18, then only the IPv6 Node Address is present. 684 o If length is 22, then the IPv6 Node Address and the MPLS SID are 685 present. 687 o If length is 34, then the IPv6 Node Address and the IPv6 SID are 688 present. 690 2.4.5.5. Type 5: IPv4 Address + index with optional SID 692 The Type-5 Segment Sub-TLV encodes an IPv4 node address, an interface 693 index (IfIndex) and an optional SID in the form of either an MPLS 694 label or an IPv6 address. The format is as follows: 696 0 1 2 3 697 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 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Type | Length | Flags | RESERVED | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | IfIndex (4 octets) | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | IPv4 Node Address (4 octets) | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 // SID (optional, 4 or 16 octets) // 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 where: 710 o Type: suggested value 5, to be assigned by IANA. 712 o Length is 10 or 14 or 26. 714 o Flags: 1 octet of flags. None is defined at this stage. Flags 715 SHOULD be unset on transmission and MUST be ignored on receipt. 717 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 718 transmission and MUST be ignored on receipt. 720 o IfIndex: 4 octets of interface index. 722 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 724 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 726 The following applies to the Type-5 Segment sub-TLV: 728 o The IPv4 Node Address MUST be present. 730 o The Interface Index (IfIndex) MUST be present. 732 o The SID is optional and MAY be of one of the following formats: 734 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 735 defined in Section 2.4.5.1. 737 * IPV6 SID: a 16 octet IPv6 address. 739 o If length is 10, then the IPv4 Node Address and IfIndex are 740 present. 742 o If length is 14, then the IPv4 Node Address, the IfIndex and the 743 MPLS SID are present. 745 o If length is 26, then the IPv4 Node Address, the IfIndex and the 746 IPv6 SID are present. 748 2.4.5.6. Type 6: IPv4 Local and Remote addresses with optional SID 750 The Type-6 Segment Sub-TLV encodes an IPv4 node address, an adjacency 751 local address, an adjacency remote address and an optional SID in the 752 form of either an MPLS label or an IPv6 address. The format is as 753 follows: 755 0 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Type | Length | Flags | RESERVED | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Local IPv4 Address (4 octets) | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Remote IPv4 Address (4 octets) | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 // SID (4 or 16 octets) // 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 where: 769 o Type: suggested value 6, to be assigned by IANA. 771 o Length is 10 or 14 or 26. 773 o Flags: 1 octet of flags. None is defined at this stage. Flags 774 SHOULD be unset on transmission and MUST be ignored on receipt. 776 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 777 transmission and MUST be ignored on receipt. 779 o Local IPv4 Address: a 4 octet IPv4 address. 781 o Remote IPv4 Address: a 4 octet IPv4 address. 783 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 785 The following applies to the Type-6 Segment sub-TLV: 787 o The Local IPv4 Address MUST be present and represents an adjacency 788 local address. 790 o The Remote IPv4 Address MUST be present and represents the remote 791 end of the adjacency. 793 o The SID is optional and MAY be of one of the following formats: 795 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 796 defined in Section 2.4.5.1. 798 * IPV6 SID: a 16 octet IPv6 address. 800 o If length is 10, then only the IPv4 Local and Remote addresses are 801 present. 803 o If length is 14, then the IPv4 Local address, IPv4 Remote address 804 and the MPLS SID are present. 806 o If length is 26, then the IPv4 Local address, IPv4 Remote address 807 and the IPv6 SID are present. 809 2.4.5.7. Type 7: IPv6 Address + index with optional SID 811 The Type-7 Segment Sub-TLV encodes an IPv6 node address, an interface 812 index and an optional SID in the form of either an MPLS label or an 813 IPv6 address. The format is as follows: 815 0 1 2 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Type | Length | Flags | RESERVED | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | IfIndex (4 octets) | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 // IPv6 Node Address (16 octets) // 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 // SID (optional, 4 or 16 octets) // 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 where: 829 o Type: suggested value 7, to be assigned by IANA. 831 o Length is 22 or 26 or 38. 833 o Flags: 1 octet of flags. None is defined at this stage. Flags 834 SHOULD be unset on transmission and MUST be ignored on receipt. 836 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 837 transmission and MUST be ignored on receipt. 839 o IfIndex: 4 octets of interface index. 841 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 843 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 845 The following applies to the Type-7 Segment sub-TLV: 847 o The IPv6 Node Address MUST be present. 849 o The Interface Index MUST be present. 851 o The SID is optional and MAY be of one of the following formats: 853 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 854 defined in Section 2.4.5.1. 856 * IPV6 SID: a 16 octet IPv6 address. 858 o If length is 22, then the IPv6 Node Address and IfIndex are 859 present. 861 o If length is 26, then the IPv6 Node Address, the IfIndex and the 862 MPLS SID are present. 864 o If length is 38, then the IPv6 Node Address, the IfIndex and the 865 IPv6 SID are present. 867 2.4.5.8. Type 8: IPv6 Local and Remote addresses with optional SID 869 The Type-8 Segment Sub-TLV encodes an IPv6 node address, an adjacency 870 local address, an adjacency remote address and an optional SID in the 871 form of either an MPLS label or an IPv6 address. The format is as 872 follows: 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Type | Length | Flags | RESERVED | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 // Local IPv6 Address (16 octets) // 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 // Remote IPv6 Address (16 octets) // 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 // SID (4 or 16 octets) // 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 where: 888 o Type: suggested value 8, to be assigned by IANA. 890 o Length is 34 or 38 or 50. 892 o Flags: 1 octet of flags. None is defined at this stage. Flags 893 SHOULD be unset on transmission and MUST be ignored on receipt. 895 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 896 transmission and MUST be ignored on receipt. 898 o Local IPv6 Address: a 16 octet IPv6 address. 900 o Remote IPv6 Address: a 16 octet IPv6 address. 902 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 904 The following applies to the Type-8 Segment sub-TLV: 906 o The Local IPv6 Address MUST be present and represents an adjacency 907 local address. 909 o The Remote IPv6 Address MUST be present and represents the remote 910 end of the adjacency. 912 o The SID is optional and MAY be of one of the following formats: 914 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 915 defined in Section 2.4.5.1. 917 * IPV6 SID: a 16 octet IPv6 address. 919 o If length is 34, then only the IPv6 Local and Remote addresses are 920 present. 922 o If length is 38, then the IPv6 Local address, IPv4 Remote address 923 and the MPLS SID are present. 925 o If length is 50, then the IPv6 Local address, IPv4 Remote address 926 and the IPv6 SID are present. 928 3. SR TE Policy Operations 930 3.1. Steering Traffic into a SR TE Policy 932 On the receiving BGP speaker, all destination prefixes that share the 933 same Extended Color Community value and the same BGP next-hop are 934 steered to the corresponding SR TE Policy that has been instantiated 935 and which matches the Color and Endpoint NLRI values. 937 Similarly, different destination prefixes can be steered into 938 distinct SR TE Policies by coloring them differently. 940 The Color field of the NLRI allows association of destination 941 prefixes with a given SR TE Policy. The BGP speaker SHOULD then 942 attach a Color Extended Community (as defined in [RFC5512]) to 943 destination prefixes (e.g.: IPv4/IPv6 unicast prefixes) in order to 944 allow the receiver of the SR TE Policy and of the destination prefix 945 to steer traffic into the SR TE Policy if the destination prefix: 947 o Has a BGP next-hop attribute matching the SR TE Policy SAFI NLRI 948 Endpoint and 950 o Has an attached Extended Color Community with the same value as 951 the color of the SR TE Policy NLRI Color. 953 3.2. Configuration and Advertisement of SR TE Policies 955 Typically, but not limited to, a SR TE Policy is configured into a 956 controller and on the base of each receiver. In other words, each SR 957 TE Policy configured is related to the intended receiver. It is 958 therefore normal for a given SR TE Policy to have 959 multiple instances with different content (i.e.: different segment 960 lists) where each of these instances (of the same policy) is intended 961 to be sent to different receivers. 963 Each instance of the same SR TE Policy will have a different 964 Distinguisher in order to prevent BGP selection among these instances 965 along the distribution of BGP updates. 967 Moreover, a Route-Target extended community SHOULD be attached to the 968 SR TE Policy and that identifies the intended receiver of the 969 advertisement. 971 If no route-target is attached to the SR TE Policy NLRI, then it is 972 assumed that the originator sends the SR TE Policy update directly 973 (e.g.: through iBGP multihop) to the intended receiver. In such 974 case, the NO_ADVERTISE community MUST be attached to the SR TE Policy 975 update. 977 3.3. Multipath Operation 979 The SR TE Policy MAY contain multiple Segment Lists which, in the 980 absence of the Weight TLV, signifies equal cost load balancing 981 amongst them. 983 When a weight sub-TLV is encoded in each Segment List TLV, then the 984 weight value SHOULD be used in order to perform an unequal cost load 985 balance amongst the Segment Lists as specified in Section 2.4.3. 987 3.4. Binding SID TLV 989 When the optional Binding SID sub-TLV is present, it indicates an 990 instruction, to the receiving BGP speaker to allocate a Binding SID 991 for the list of SIDs the Binding sub-TLV is related to. 993 Any incoming packet with the Binding SID as active segment (according 994 to the terminology described in [I-D.ietf-spring-segment-routing]) 995 will then have the Binding SID swapped with the list of SIDs 996 specified in the Segment List sub-TLVs on the allocating BGP speaker. 997 The allocated Binding SID MAY be then advertised by the BGP speaker 998 that created it, through, e.g., BGP-LS in order to, typically, feed a 999 controller with the updated topology and SR TE Policy information. 1001 3.5. Reception of an SR TE Policy 1003 When a BGP speaker receives an SR TE Policy from a neighbor it has to 1004 determine if the SR TE Policy advertisement is acceptable. The 1005 following applies: 1007 o The SR TE Policy NLRI MUST have a color value and MAY have an 1008 Endpoint value. 1010 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1011 Update and MUST have the Tunnel Type set to SR TE Policy (value to 1012 be assigned by IANA). 1014 o Within the SR TE Policy, at least one Segment List sub-TLV MUST be 1015 present. 1017 o Within the Segment List sub-TLV at least one Segment sub-TLV MUST 1018 be present. 1020 Any segment sub-TLV of type 3 to 8 that is present in the segment 1021 list MUST be either validated or resolved: 1023 o if the SID portion of the sub-TLV is present, then the segment 1024 MUST be validated by the receiver. Validation consists of 1025 verifying that the SID value is related to the network address. 1027 o if the SID portion of the sub-TLV is not present, then the segment 1028 MUST be resolved by the receiver. Resolution consists of taking 1029 from the receiver database (e.g.; from the link-state or routing 1030 information base) that the SID value related to the network 1031 address in the sub-TLV. 1033 When a BGP speaker receives an SR TE Policy from a neighbor, the 1034 receiver MUST check the validity of the first SID of each Segment 1035 List sub-TLV of the SR TE Policy. The first SID MUST be known in the 1036 receiver local table either as a label (in the case the SID encodes a 1037 label value) or as an IPv6 address. 1039 Also, the receiver SHOULD program its MPLS or IPv6 data planes so 1040 that BGP destination prefixes matching their Extended Color Community 1041 and BGP next-hop with the SR TE Policy SAFI NLRI Color and Endpoint 1042 are steered into the SR TE Policy and forwarded accordingly. 1044 On reception of an SR TE Policy, a BGP speaker SHOULD instantiate the 1045 SR TE Policy in its routing and forwarding table with the set of 1046 segment lists (i.e.: explicit paths) included in the policy and 1047 taking into account the Binding SID and Weight sub-TLVs. 1049 When building the MPLS label stack or the IPv6 Segment list from the 1050 Segment List sub-TLV, the receiving BGP speaker MUST interpret the 1051 set of Segment sub-TLVs as follows: 1053 o The first Segment sub-TLV represents the topmost label or the 1054 first IPv6 segment. In the receiving BGP speaker, it identifies 1055 the first segment the traffic will be directed towards to (along 1056 the SR TE explicit path). 1058 o The last Segment sub-TLV represents the bottommost label or the 1059 last IPv6 segment. 1061 When the receiver receives the SR TE Policy advertisement it MUST 1062 check whether the Route-Target is attached to it. If yes, the route- 1063 target MUST match one of the local addresses of the receiver in order 1064 for the update to be accepted as valid. 1066 If no route-target is attached, then the receiver checks whether the 1067 NO_ADVERTISE community ([RFC1997]) is present. If no, then the 1068 update MUST be considered as invalid. 1070 If no route-target is attached and the NO_ADVERTISE community is 1071 present, then the receiver accepts the SR TE Policy update and 1072 process it accordingly. 1074 Since the SR TE Policies are unique within an SR domain and intended 1075 only for the receiver of the SR TE Policy advertisement, a BGP 1076 speaker receiving an SR TE Policy, by default, MUST NOT propagate 1077 such policy unless explicitly configured to do so. 1079 3.6. Flowspec and SR TE Policies 1081 The SR TE Policy can be carried in context of a Flowspec NLRI 1082 ([RFC5575]). In this case, when the redirect to IP nexthop is 1083 specified as in [I-D.ietf-idr-flowspec-redirect-ip], the tunnel to 1084 the nexthop is specified by the segment list in the Segment List sub- 1085 TLVs. The Segment List (e.g..: label stack or IPv6 segment list) is 1086 imposed to flows matching the criteria in the Flowspec route in order 1087 to steer them towards the nexthop as specified in the SR TE Policy 1088 SAFI NLRI. 1090 4. Acknowledgments 1092 The authors of this document would like to thank Dhanendra Jain for 1093 his review of this document. 1095 5. IANA Considerations 1097 This document defines: 1099 o a new SAFI in the registry "Subsequent Address Family Identifiers 1100 (SAFI) Parameters": 1102 Suggested Description Reference 1103 Value 1104 ----------------------------------------------------- 1105 73 SR TE Policy SAFI This document 1107 o a new Tunnel-Type in the registry "BGP Tunnel Encapsulation 1108 Attribute Tunnel Types": 1110 Suggested Description Reference 1111 Value 1112 ----------------------------------------------------- 1113 14 SR TE Policy Type This document 1115 o new sub-TLVs in the registry "BGP Tunnel Encapsulation Attribute 1116 sub-TLVs": 1118 Suggested Description Reference 1119 Value 1120 ----------------------------------------------------- 1121 6 Preference sub-TLV This document 1122 7 Binding SID sub-TLV This document 1123 8 Segment List sub-TLV This document 1125 o A new registry called "SR TE Policy List Sub-TLVs" with following 1126 codepoints: 1128 Suggested Description Reference 1129 Value 1130 ------------------------------------------------------------ 1131 1 MPLS SID This document 1132 2 IPv6 SID This document 1133 3 IPv4 Node and SID This document 1134 4 IPv6 Node and SID This document 1135 5 IPv4 Node, index and SID This document 1136 6 IPv4 Local/Remote addresses and SID This document 1137 7 IPv6 Node, index and SID This document 1138 8 IPv6 Local/Remote addresses and SID This document 1139 9 Weight sub-TLV This document 1141 6. Security Considerations 1143 TBD. 1145 7. References 1146 7.1. Normative References 1148 [I-D.ietf-idr-tunnel-encaps] 1149 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 1150 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-01 1151 (work in progress), December 2015. 1153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1154 Requirement Levels", BCP 14, RFC 2119, 1155 DOI 10.17487/RFC2119, March 1997, 1156 . 1158 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1159 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1160 DOI 10.17487/RFC4271, January 2006, 1161 . 1163 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1164 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1165 February 2006, . 1167 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1168 "Multiprotocol Extensions for BGP-4", RFC 4760, 1169 DOI 10.17487/RFC4760, January 2007, 1170 . 1172 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 1173 Subsequent Address Family Identifier (SAFI) and the BGP 1174 Tunnel Encapsulation Attribute", RFC 5512, 1175 DOI 10.17487/RFC5512, April 2009, 1176 . 1178 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1179 and D. McPherson, "Dissemination of Flow Specification 1180 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1181 . 1183 7.2. Informational References 1185 [I-D.ietf-6man-segment-routing-header] 1186 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 1187 J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment 1188 Routing Header (SRH)", draft-ietf-6man-segment-routing- 1189 header-01 (work in progress), March 2016. 1191 [I-D.ietf-idr-flowspec-redirect-ip] 1192 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 1193 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 1194 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 1195 in progress), February 2015. 1197 [I-D.ietf-spring-segment-routing] 1198 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1199 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1200 spring-segment-routing-08 (work in progress), May 2016. 1202 [I-D.ietf-spring-segment-routing-mpls] 1203 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1204 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1205 and E. Crabbe, "Segment Routing with MPLS data plane", 1206 draft-ietf-spring-segment-routing-mpls-04 (work in 1207 progress), March 2016. 1209 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 1210 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 1211 . 1213 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1214 Reflection: An Alternative to Full Mesh Internal BGP 1215 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1216 . 1218 Authors' Addresses 1220 Stefano Previdi (editor) 1221 Cisco Systems, Inc. 1222 Via Del Serafico, 200 1223 Rome 00142 1224 Italy 1226 Email: sprevidi@cisco.com 1228 Clarence Filsfils 1229 Cisco Systems, Inc. 1230 Brussels 1231 BE 1233 Email: cfilsfil@cisco.com 1234 Arjun Sreekantiah 1235 Cisco Systems, Inc. 1236 170 W. Tasman Drive 1237 San Jose, CA 95134 1238 USA 1240 Email: asreekan@cisco.com 1242 Siva Sivabalan 1243 Cisco Systems, Inc. 1244 170 W. Tasman Drive 1245 San Jose, CA 95134 1246 USA 1248 Email: msiva@cisco.com 1250 Paul Mattes 1251 Microsoft 1252 One Microsoft Way 1253 Redmond, WA 98052 1254 USA 1256 Email: pamattes@microsoft.com 1258 Eric Rosen 1259 Juniper Networks 1260 10 Technology Park Drive 1261 Westford, MA 01886 1262 US 1264 Email: erosen@juniper.net