idnits 2.17.1 draft-previdi-idr-segment-routing-te-policy-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (October 30, 2016) is 2735 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-02 ** 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-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-05 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: May 3, 2017 S. Sivabalan 6 Cisco Systems, Inc. 7 P. Mattes 8 Microsoft 9 E. Rosen 10 Juniper Networks 11 S. Lin 12 Google 13 October 30, 2016 15 Advertising Segment Routing Traffic Engineering Policies in BGP 16 draft-previdi-idr-segment-routing-te-policy-02 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 May 3, 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. Weight Sub-TLV . . . . . . . . . . . . . . . . . . . 9 74 2.4.4. Segment List Sub-TLV . . . . . . . . . . . . . . . . 10 75 2.4.5. Segment Sub-TLV . . . . . . . . . . . . . . . . . . . 11 76 3. SR TE Policy Operations . . . . . . . . . . . . . . . . . . . 20 77 3.1. Configuration and Advertisement of SR TE Policies . . . . 20 78 3.2. Multipath Operation . . . . . . . . . . . . . . . . . . . 21 79 3.3. Binding SID TLV . . . . . . . . . . . . . . . . . . . . . 21 80 3.4. Reception of an SR TE Policy . . . . . . . . . . . . . . 21 81 3.4.1. Acceptance of a SR TE Policy Update . . . . . . . . . 22 82 3.4.2. Usable SR TE Policy . . . . . . . . . . . . . . . . . 23 83 3.4.3. Instantiation of an SR TE Policy . . . . . . . . . . 24 84 3.4.4. Propagation of an SR TE Policy . . . . . . . . . . . 25 85 3.5. Steering Traffic into a SR TE Policy . . . . . . . . . . 25 86 3.6. Flowspec and SR TE Policies . . . . . . . . . . . . . . . 26 87 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 91 7.1. Normative References . . . . . . . . . . . . . . . . . . 27 92 7.2. Informational References . . . . . . . . . . . . . . . . 28 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 95 1. Introduction 97 Segment Routing (SR) technology leverages the source routing and 98 tunneling paradigms. [I-D.ietf-spring-segment-routing] describes the 99 SR architecture. [I-D.ietf-spring-segment-routing-mpls] describes 100 its instantiation on the MPLS data plane and 101 [I-D.ietf-6man-segment-routing-header] describes the Segment Routing 102 instantiation over the IPv6 data plane. 104 This document defines the Segment Routing Traffic Engineering Policy 105 (SR TE Policy) as a set of unequal equal cost multi-path (UCMP) 106 segment lists (representing explicit paths) as well as the mechanism 107 allowing a router to steer traffic into an SR TE Policy. 109 The SR TE Policy is advertised in the Border Gateway Protocol (BGP) 110 by the BGP speaker being a router or a controller and using 111 extensions defined in this document. Among the information encoded 112 in the BGP message and representing the SR TE Policy, the steering 113 mechanism makes also use of the Extended Color Community currently 114 defined in [I-D.ietf-idr-tunnel-encaps] 116 Typically, a controller defines the set of policies and advertise 117 them to BGP routers (typically ingress routers). The policy 118 advertisement uses BGP extensions defined in this document. The 119 policy advertisement is, in most but not all of the cases, tailored 120 for the receiver. In other words, a policy advertised to a given BGP 121 speaker has significance only for that particular router and is not 122 intended to be propagated anywhere else. Then, the receiver of the 123 policy instantiate the policy in its routing and forwarding tables 124 and steer traffic into it based on both the policy and destination 125 prefix color and next-hop. 127 Alternatively, a router (i.e.: an BGP egress router) advertises SR TE 128 Policies representing paths to itself. These advertisements are sent 129 to BGP ingress nodes who instantiate these policies and steer traffic 130 into them according to the color and endpoint/BGP next-hop of both 131 the policy and the destination prefix. 133 An SR TE Policy being intended only for the receiver of the 134 advertisement, the SR TE Policies are sent directly to each receiver 135 and, in most of the cases will not traverse any Route Reflector (RR, 136 [RFC4456]). 138 However, there are cases where a SR TE Policy is intended to a group 139 of nodes. Also, in a deployment scenario, a controller may also rely 140 on the standard BGP update propagation scheme which makes use of 141 route reflectors. This cases require mechanisms that: 143 o Uniquely identify each instance of a given policy. 145 o Uniquely identify the intended receiver of a given SR TE Policy 146 advertisement. 148 The BGP extensions for the advertisement of SR TE Policies include 149 following components: 151 o A new Subsequent Address Family Identifier (SAFI) identifying the 152 content of the BGP message (i.e.: the SR TE Policy). 154 o A new NLRI identifying the SR TE Policy. 156 o A set of new TLVs to be inserted into the Tunnel Encapsulation 157 Attribute (as defined in [I-D.ietf-idr-tunnel-encaps]) and 158 describing the SR TE Policy. 160 o An IPv4 address format route-target extended community ([RFC4360]) 161 attached to the SR TE Policy advertisement and that indicates the 162 intended receiver of such SR TE Policy advertisement. 164 o The Extended Color Community (as defined in 165 [I-D.ietf-idr-tunnel-encaps]) and used in order to steer traffic 166 into an SR TE Policy. 168 1.1. Requirements Language 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 2. SR TE Policy Encoding 176 2.1. SR TE Policy SAFI and NLRI 178 A new SAFI is defined: the SR TE Policy SAFI (codepoint suggested 179 value 73, to be assigned by IANA). 181 The SR TE Policy SAFI uses a new NLRI defined as follows: 183 +-----------------------------------------------+ 184 | Distinguisher (4 octets) | 185 +-----------------------------------------------+ 186 | Policy Color (4 octets) | 187 +-----------------------------------------------+ 188 | Endpoint (4 or 16 octets) | 189 +-----------------------------------------------+ 191 where: 193 o Distinguisher: 4-octet value uniquely identifying the policy in 194 the context of tuple. The distinguisher has no 195 semantic and it's solely used by the SR TE Policy originator in 196 order to make unique (from a NLRI perspective) multiple 197 occurrences of the same SR TE Policy. 199 o Policy Color: 4-octet value identifying (with the endpoint) the 200 policy. The color is used to match the color of the destination 201 prefixes in order to steer traffic into the SR TE Policy. 203 o Endpoint: identifies the endpoint of a policy. The Endpoint may 204 represent a single node or a set of nodes (e.g.: an anycast 205 address or a summary address). The Endpoint is an IPv4 (4-octet) 206 address or an IPv6 (16-octet) address according to the AFI of the 207 NLRI. 209 The NLRI containing the SR TE Policy is carried in a BGP UPDATE 210 message [RFC4271] using BGP multiprotocol extensions [RFC4760] with 211 an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of 73 (suggested 212 value, to be assigned by IANA). 214 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 215 attribute with the SR TE Policy SAFI MUST also carry the BGP 216 mandatory attributes. In addition, the BGP update message MAY also 217 contain any of the BGP optional attributes. 219 The next-hop of the SR TE Policy SAFI NLRI is set based on the AFI. 220 For example, if the AFI is set to IPv4 (1), then the next-hop is 221 encoded as a 4-byte IPv4 address. If the AFI is set to IPv6 (2), 222 then the next-hop is encoded as a 16-byte IPv6 address of the router. 223 It is important to note that any BGP speaker receiving a BGP message 224 with an SR TE Policy NLRI, will process it only if the NLRI is a best 225 path as per the BGP best path selection algorithm. 227 2.2. SR TE Policy and Tunnel Encapsulation Attribute 229 The content of the SR TE Policy is encoded in the Tunnel 230 Encapsulation Attribute originally defined in 231 [I-D.ietf-idr-tunnel-encaps] using a new Tunnel-Type TLV (suggested 232 codepoint is 14, to be assigned by IANA). 234 The SR TE Policy Encoding structure is as follows: 236 SR TE Policy SAFI NLRI: 237 Attributes: 238 Tunnel Encaps Attribute (23) 239 Tunnel Type: SR TE Policy 240 Binding SID 241 Preference 242 Segment List 243 Weight 244 Segment 245 Segment 246 ... 247 ... 248 ... 249 where: 251 o SR TE Policy SAFI NLRI is defined in Section 2.1. 253 o Tunnel Encapsulation Attribute is defined in 254 [I-D.ietf-idr-tunnel-encaps]. 256 o Tunnel-Type is set to a suggested value of 14 (to be assigned by 257 IANA). 259 o Preference, Binding SID, Weight, Segment and Segment-List are new 260 sub-TLVs defined in this document. 262 o Additional sub-TLVs may be defined in the future. 264 A single occurrence of "Tunnel Type: SR TE Policy" MUST be encoded 265 within the same Tunnel Encapsulation Attribute. 267 Multiple occurrences of "Segment List" MAY be encoded within the same 268 SR TE Policy. 270 Multiple occurrences of "Segment" MAY be encoded within the same 271 Segment List. 273 2.3. Remote Endpoint and Color 275 The Remote Endpoint and Color sub-TLVs, as defined in 276 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR TE Policy 277 encodings. 279 If present, the Remote Endpoint sub-TLV MUST match the Endpoint of 280 the SR TE Policy SAFI NLRI. 282 If present, the Color sub-TLV MUST match the Policy Color of the SR 283 TE Policy SAFI NLRI. 285 2.4. SR TE Policy Sub-TLVs 287 This section defines the SR TE Policy sub-TLVs. 289 2.4.1. Preference sub-TLV 291 The Preference sub-TLV is used in order to determine the preference 292 among multiple SR TE Policy originators. 294 The Preference sub-TLV is optional, MAY appear only once in the SR TE 295 Policy and has following format: 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type | Length | Flags | RESERVED | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Preference (4 octets) | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 where: 307 o Type: to be assigned by IANA (suggested value is 6). 309 o Length: 6. 311 o Flags: 1 octet of flags. None is defined at this stage. Flags 312 SHOULD be unset on transmission and MUST be ignored on receipt. 314 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 315 transmission and MUST be ignored on receipt. 317 o Preference: a 4-octet value. The highest value is preferred. 319 The Preference is used when the same policy is 320 advertised by multiple originators of the same SR TE Policy. The 321 Preference is used by the receiver in order to determine which of the 322 received policies are to be installed. The following rules apply to 323 the Preference: 325 o Preference is to be applied to the tuple. The 326 Distinguisher MUST NOT be considered. 328 o Preference is used in order to determine which instance of a given 329 SR TE Policy is to be installed. However, Preference MUST NOT 330 influence the BGP selection algorithm and propagation rules. In 331 other words, the preference selection happens after the BGP path 332 selection. 334 2.4.2. SR TE Binding SID Sub-TLV 336 The Binding SID sub-TLV requests the allocation of a Binding Segment 337 identifier associated with the SR TE Policy. 339 The Binding SID sub-TLV is optional, MAY appear only once in the SR 340 TE Policy and has the following format: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type | Length | Flags | RESERVED | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Binding SID (variable, optional) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 where: 352 o Type: to be assigned by IANA (suggested value is 7). 354 o Length: specifies the length of the value field not including Type 355 and Length fields. Can be 2 or 6 or 18. 357 o Flags: 1 octet of flags. None is defined at this stage. Flags 358 SHOULD be unset on transmission and MUST be ignored on receipt. 360 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 361 transmission and MUST be ignored on receipt. 363 o Binding SID: if length is 2, then no Binding SID is present. If 364 length is 6 then the Binding SID contains a 4-octet SID. If 365 length is 18 then the Binding SID contains a 16-octet IPv6 SID. 367 The Binding SID sub-TLV is used to instruct the receiver of the BGP 368 message to allocate a Binding SID to the SR TE Policy. The 369 allocation of the Binding SID in the receiver is done according to 370 following rules: 372 o If length is 2 (no value field is present), then the receiver MUST 373 allocate a local Binding SID whose value is chosen by the 374 receiver. 376 o If length is 6, then the value field contains the 4-octet Binding 377 SID value the receiver SHOULD allocate. 379 o If length is 18, then the value field contains the 16-octet 380 Binding SID value the receiver SHOULD allocate. 382 When a controller is used in order to define and advertise SR TE 383 Policies and when the Binding SID is allocated by the receiver, such 384 Binding SID SHOULD be reported to the controller. The mechanisms 385 and/or APIs used for the reporting of the Binding SID are outside the 386 scope of this document. 388 Further use of the Binding SID is described in a subsequent section. 390 2.4.3. Weight Sub-TLV 392 The Weight sub-TLV specifies the weight associated to a given path 393 (i.e.: a given segment list). The weight is used in order to apply 394 weighted UCMP mechanism when steering traffic into a policy that 395 includes multiple Segment Lists sub-TLVs (i.e.: multiple explicit 396 paths). 398 The Weight sub-TLV is optional, MAY only appear once in the Segment 399 List sub-TLV, and has the following format: 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Type | Length | Flags | RESERVED | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Weight | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 where: 411 Type: to be assigned by IANA (suggested value is 9). 413 Length: 6. 415 Flags: 1 octet of flags. None is defined at this stage. Flags 416 SHOULD be unset on transmission and MUST be ignored on receipt. 418 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 419 and MUST be ignored on receipt. 421 When present, the Weight sub-TLV specifies a weight to be associated 422 with the corresponding Segment List, for use in unequal cost multi- 423 path. Weights are applied by summing the total value of all of the 424 weights for all Segment Lists, and then assigning a fraction of the 425 forwarded traffic to each Segment List in proportion its weight's 426 fraction of the total. 428 2.4.4. Segment List Sub-TLV 430 The Segment List sub-TLV is used in order to encode a single explicit 431 path towards the endpoint. The Segment List sub-TLV includes the 432 elements of the paths (i.e.: segments) as well as an optional Weight 433 TLV. 435 The Segment List sub-TLV may exceed 255 bytes length due to large 436 number of segments. Therefore a 2-octet length is required. 437 According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- 438 TLV code point defines the size of the length field. Therefore, for 439 the Segment List sub-TLV a code point of 128 (suggested value, to be 440 assigned by IANA) is used. 442 The Segment List sub-TLV is mandatory, MAY appear multiple times in 443 the SR TE Policy and has the following format: 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Type | Length | RESERVED | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 // sub-TLVs // 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 where: 455 o Type: to be assigned by IANA (suggested value is 128). 457 o Length: the total length (not including the Type and Length 458 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 460 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 461 transmission and MUST be ignored on receipt. 463 o sub-TLVs: 465 * An optional single Weight sub-TLV. 467 * One or more Segment sub-TLVs. 469 The Segment List sub-TLV is mandatory. 471 Multiple occurrences of the Segment List sub-TLV MAY appear in the SR 472 TE Policy. 474 When multiple occurrences of the Segment List sub-TLV appear in the 475 SR TE Policy, the traffic is load-balanced across them either through 476 an ECMP scheme (if no Weight sub-TLV is present) or through a 477 weighted UCMP scheme according to Section 2.4.3. 479 2.4.5. Segment Sub-TLV 481 The Segment sub-TLV describes a single segment in a segment list 482 (i.e.: a single element of the explicit path). Multiple Segment sub- 483 TLVs constitute an explicit path of the SR TE Policy. 485 The Segment sub-TLV is mandatory and MAY appear multiple times in the 486 Segment List sub-TLV. 488 This document defines 8 different types of Segment Sub-TLVs: 490 Type 1: SID only, in the form of MPLS Label 491 Type 2: SID only, in the form of IPv6 address 492 Type 3: IPv4 Node Address with optional SID 493 Type 4: IPv6 Node Address with optional SID 494 Type 5: IPv4 Address + index with optional SID 495 Type 6: IPv4 Local and Remote addresses with optional SID 496 Type 7: IPv6 Address + index with optional SID 497 Type 8: IPv6 Local and Remote addresses with optional SID 499 2.4.5.1. Type 1: SID only, in the form of MPLS Label 501 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 502 MPLS label. The format is as follows: 504 0 1 2 3 505 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 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Type | Length | Flags | RESERVED | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Label | TC |S| TTL | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 where: 514 o Type: suggested value 1, to be assigned by IANA. 516 o Length is 6. 518 o Flags: 1 octet of flags. None is defined at this stage. Flags 519 SHOULD be unset on transmission and MUST be ignored on receipt. 521 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 522 transmission and MUST be ignored on receipt. 524 o Label: 20 bits of label value. 526 o TC: 3 bits of traffic class. 528 o S: 1 bit of bottom-of-stack. 530 o TTL: 1 octet of TTL. 532 The following applies to the Type-1 Segment sub-TLV: 534 o The S bit SHOULD be zero upon transmission, and MUST be ignored 535 upon reception. 537 o If the originator wants the receiver to choose the TC value, it 538 sets the TC field to zero. 540 o If the originator wants the receiver to choose the TTL value, it 541 sets the TTL field to 255. 543 o If the originator wants to recommend a value for these fields, it 544 puts those values in the TC and/or TTL fields. 546 o The receiver MAY override the originator's values for these 547 fields. This would be determined by local policy at the receiver. 548 One possible policy would be to override the fields only if the 549 fields have the default values specified above. 551 2.4.5.2. Type 2: SID only, in the form of IPv6 address 553 The Type-2 Segment Sub-TLV encodes a single SID in the form of an 554 IPv6 address. The format is as follows: 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Type | Length | Flags | RESERVED | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 // IPv6 SID (16 octets) // 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 where: 566 o Type: suggested value 2, to be assigned by IANA. 568 o Length is 18. 570 o Flags: 1 octet of flags. None is defined at this stage. Flags 571 SHOULD be unset on transmission and MUST be ignored on receipt. 573 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 574 transmission and MUST be ignored on receipt. 576 o IPv6 SID: 16 octets of IPv6 address. 578 The IPv6 Segment Identifier (IPv6 SID) is defined in 579 [I-D.ietf-6man-segment-routing-header]. 581 2.4.5.3. Type 3: IPv4 Node Address with optional SID 583 The Type-3 Segment Sub-TLV encodes an IPv4 node address and an 584 optional SID in the form of either an MPLS label or an IPv6 address. 585 The format is as follows: 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Type | Length | Flags | RESERVED | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | IPv4 Node Address (4 octets) | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 // SID (optional, 4 or 16 octets) // 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 where: 599 o Type: suggested value 3, to be assigned by IANA. 601 o Length is 6 or 10 or 22. 603 o Flags: 1 octet of flags. None is defined at this stage. Flags 604 SHOULD be unset on transmission and MUST be ignored on receipt. 606 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 607 transmission and MUST be ignored on receipt. 609 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 611 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 613 The following applies to the Type-3 Segment sub-TLV: 615 o The IPv4 Node Address MUST be present. 617 o The SID is optional and MAY be of one of the following formats: 619 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 620 defined in Section 2.4.5.1. 622 * IPV6 SID: a 16 octet IPv6 address. 624 o If length is 6, then only the IPv4 Node Address is present. 626 o If length is 10, then the IPv4 Node Address and the MPLS SID are 627 present. 629 o If length is 22, then the IPv4 Node Address and the IPv6 SID are 630 present. 632 2.4.5.4. Type 4: IPv6 Node Address with optional SID 634 The Type-4 Segment Sub-TLV encodes an IPv6 node address and an 635 optional SID in the form of either an MPLS label or an IPv6 address. 636 The format is as follows: 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Type | Length | Flags | RESERVED | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 // IPv6 Node Address (16 octets) // 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 // SID (optional, 4 or 16 octets) // 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 where: 650 o Type: suggested value 4, to be assigned by IANA. 652 o Length is 18 or 22 or 34. 654 o Flags: 1 octet of flags. None is defined at this stage. Flags 655 SHOULD be unset on transmission and MUST be ignored on receipt. 657 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 658 transmission and MUST be ignored on receipt. 660 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 662 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 664 The following applies to the Type-4 Segment sub-TLV: 666 o The IPv6 Node Address MUST be present. 668 o The SID is optional and MAY be of one of the following formats: 670 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 671 defined in Section 2.4.5.1. 673 * IPV6 SID: a 16 octet IPv6 address. 675 o If length is 18, then only the IPv6 Node Address is present. 677 o If length is 22, then the IPv6 Node Address and the MPLS SID are 678 present. 680 o If length is 34, then the IPv6 Node Address and the IPv6 SID are 681 present. 683 2.4.5.5. Type 5: IPv4 Address + index with optional SID 685 The Type-5 Segment Sub-TLV encodes an IPv4 node address, an interface 686 index (IfIndex) and an optional SID in the form of either an MPLS 687 label or an IPv6 address. The format is as follows: 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Type | Length | Flags | RESERVED | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | IfIndex (4 octets) | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | IPv4 Node Address (4 octets) | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 // SID (optional, 4 or 16 octets) // 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 where: 703 o Type: suggested value 5, to be assigned by IANA. 705 o Length is 10 or 14 or 26. 707 o Flags: 1 octet of flags. None is defined at this stage. Flags 708 SHOULD be unset on transmission and MUST be ignored on receipt. 710 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 711 transmission and MUST be ignored on receipt. 713 o IfIndex: 4 octets of interface index. 715 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 717 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 719 The following applies to the Type-5 Segment sub-TLV: 721 o The IPv4 Node Address MUST be present. 723 o The Interface Index (IfIndex) MUST be present. 725 o The SID is optional and MAY be of one of the following formats: 727 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 728 defined in Section 2.4.5.1. 730 * IPV6 SID: a 16 octet IPv6 address. 732 o If length is 10, then the IPv4 Node Address and IfIndex are 733 present. 735 o If length is 14, then the IPv4 Node Address, the IfIndex and the 736 MPLS SID are present. 738 o If length is 26, then the IPv4 Node Address, the IfIndex and the 739 IPv6 SID are present. 741 2.4.5.6. Type 6: IPv4 Local and Remote addresses with optional SID 743 The Type-6 Segment Sub-TLV encodes an IPv4 node address, an adjacency 744 local address, an adjacency remote address and an optional SID in the 745 form of either an MPLS label or an IPv6 address. The format is as 746 follows: 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Type | Length | Flags | RESERVED | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Local IPv4 Address (4 octets) | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Remote IPv4 Address (4 octets) | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 // SID (4 or 16 octets) // 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 where: 762 o Type: suggested value 6, to be assigned by IANA. 764 o Length is 10 or 14 or 26. 766 o Flags: 1 octet of flags. None is defined at this stage. Flags 767 SHOULD be unset on transmission and MUST be ignored on receipt. 769 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 770 transmission and MUST be ignored on receipt. 772 o Local IPv4 Address: a 4 octet IPv4 address. 774 o Remote IPv4 Address: a 4 octet IPv4 address. 776 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 778 The following applies to the Type-6 Segment sub-TLV: 780 o The Local IPv4 Address MUST be present and represents an adjacency 781 local address. 783 o The Remote IPv4 Address MUST be present and represents the remote 784 end of the adjacency. 786 o The SID is optional and MAY be of one of the following formats: 788 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 789 defined in Section 2.4.5.1. 791 * IPV6 SID: a 16 octet IPv6 address. 793 o If length is 10, then only the IPv4 Local and Remote addresses are 794 present. 796 o If length is 14, then the IPv4 Local address, IPv4 Remote address 797 and the MPLS SID are present. 799 o If length is 26, then the IPv4 Local address, IPv4 Remote address 800 and the IPv6 SID are present. 802 2.4.5.7. Type 7: IPv6 Address + index with optional SID 804 The Type-7 Segment Sub-TLV encodes an IPv6 node address, an interface 805 index and an optional SID in the form of either an MPLS label or an 806 IPv6 address. The format is as follows: 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Type | Length | Flags | RESERVED | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | IfIndex (4 octets) | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 // IPv6 Node Address (16 octets) // 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 // SID (optional, 4 or 16 octets) // 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 where: 822 o Type: suggested value 7, to be assigned by IANA. 824 o Length is 22 or 26 or 38. 826 o Flags: 1 octet of flags. None is defined at this stage. Flags 827 SHOULD be unset on transmission and MUST be ignored on receipt. 829 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 830 transmission and MUST be ignored on receipt. 832 o IfIndex: 4 octets of interface index. 834 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 836 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 838 The following applies to the Type-7 Segment sub-TLV: 840 o The IPv6 Node Address MUST be present. 842 o The Interface Index MUST be present. 844 o The SID is optional and MAY be of one of the following formats: 846 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 847 defined in Section 2.4.5.1. 849 * IPV6 SID: a 16 octet IPv6 address. 851 o If length is 22, then the IPv6 Node Address and IfIndex are 852 present. 854 o If length is 26, then the IPv6 Node Address, the IfIndex and the 855 MPLS SID are present. 857 o If length is 38, then the IPv6 Node Address, the IfIndex and the 858 IPv6 SID are present. 860 2.4.5.8. Type 8: IPv6 Local and Remote addresses with optional SID 862 The Type-8 Segment Sub-TLV encodes an IPv6 node address, an adjacency 863 local address, an adjacency remote address and an optional SID in the 864 form of either an MPLS label or an IPv6 address. The format is as 865 follows: 867 0 1 2 3 868 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 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Type | Length | Flags | RESERVED | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 // Local IPv6 Address (16 octets) // 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 // Remote IPv6 Address (16 octets) // 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 // SID (4 or 16 octets) // 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 where: 881 o Type: suggested value 8, to be assigned by IANA. 883 o Length is 34 or 38 or 50. 885 o Flags: 1 octet of flags. None is defined at this stage. Flags 886 SHOULD be unset on transmission and MUST be ignored on receipt. 888 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 889 transmission and MUST be ignored on receipt. 891 o Local IPv6 Address: a 16 octet IPv6 address. 893 o Remote IPv6 Address: a 16 octet IPv6 address. 895 o SID: either 4 octet MPLS SID or a 16 octet IPv6 address. 897 The following applies to the Type-8 Segment sub-TLV: 899 o The Local IPv6 Address MUST be present and represents an adjacency 900 local address. 902 o The Remote IPv6 Address MUST be present and represents the remote 903 end of the adjacency. 905 o The SID is optional and MAY be of one of the following formats: 907 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 908 defined in Section 2.4.5.1. 910 * IPV6 SID: a 16 octet IPv6 address. 912 o If length is 34, then only the IPv6 Local and Remote addresses are 913 present. 915 o If length is 38, then the IPv6 Local address, IPv4 Remote address 916 and the MPLS SID are present. 918 o If length is 50, then the IPv6 Local address, IPv4 Remote address 919 and the IPv6 SID are present. 921 3. SR TE Policy Operations 923 3.1. Configuration and Advertisement of SR TE Policies 925 Typically, but not limited to, a SR TE Policy is configured into a 926 controller and on the base of each receiver. In other words, each SR 927 TE Policy configured is related to the intended receiver. It is 928 therefore normal for a given SR TE Policy to have 929 multiple instances with different content (i.e.: different segment 930 lists) where each of these instances (of the same policy) is intended 931 to be sent to different receivers. 933 Each instance of the same SR TE Policy will have a different 934 Distinguisher in order to prevent BGP selection among these instances 935 along the distribution of BGP updates. 937 Moreover, a Route-Target extended community SHOULD be attached to the 938 SR TE Policy and that identifies the intended receiver of the 939 advertisement. 941 If no route-target is attached to the SR TE Policy NLRI, then it is 942 assumed that the originator sends the SR TE Policy update directly 943 (e.g.: through iBGP multihop) to the intended receiver. In such 944 case, the NO_ADVERTISE community MUST be attached to the SR TE Policy 945 update. 947 3.2. Multipath Operation 949 The SR TE Policy MAY contain multiple Segment Lists which, in the 950 absence of the Weight TLV, signifies equal cost load balancing 951 amongst them. 953 When a weight sub-TLV is encoded in each Segment List TLV, then the 954 weight value SHOULD be used in order to perform an unequal cost load 955 balance amongst the Segment Lists as specified in Section 2.4.3. 957 3.3. Binding SID TLV 959 When the optional Binding SID sub-TLV is present, it indicates an 960 instruction, to the receiving BGP speaker to allocate a Binding SID 961 for the list of SIDs the Binding sub-TLV is related to. 963 Any incoming packet with the Binding SID as active segment (according 964 to the terminology described in [I-D.ietf-spring-segment-routing]) 965 will then have the Binding SID swapped with the list of SIDs 966 specified in the Segment List sub-TLVs on the allocating BGP speaker. 967 The allocated Binding SID MAY be then advertised by the BGP speaker 968 that created it, through, e.g., BGP-LS in order to, typically, feed a 969 controller with the updated topology and SR TE Policy information. 971 3.4. Reception of an SR TE Policy 973 On reception of a SR TE Policy, a BGP speaker MUST determine if the 974 SR TE Policy is first acceptable, then usable. 976 While only usable SR TE Policies are instantiated, acceptable SR TE 977 Policies (i.e.: also the non-usable ones) MAY be propagated. 979 Any SR TE Policy update that has been determined acceptable is kept 980 in the BGP database. This includes non-usable SR TE Policies. 982 3.4.1. Acceptance of a SR TE Policy Update 984 When a BGP speaker receives an SR TE Policy from a neighbor it has to 985 determine if the SR TE Policy advertisement is acceptable. The 986 following applies: 988 o The SR TE Policy NLRI MUST have a color value and MUST have an 989 endpoint value. 991 o The SR TE Policy NLRI MUST have distinguisher field. 993 o The SR TE Policy update MUST have either the NO_ADV community or 994 at least one route-target extended community in IPv4-address 995 format. 997 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 998 Update and MUST have the Tunnel Type set to SR TE Policy (value to 999 be assigned by IANA). 1001 o Within the SR TE Policy, at least one Segment List sub-TLV MUST be 1002 present. 1004 o Within the Segment List sub-TLV at least one Segment sub-TLV MUST 1005 be present. 1007 The Remote Endpoint and Color sub-TLVs, as defined in 1008 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR TE Policy 1009 encodings. If present, the Remote Endpoint sub-TLV MUST match the 1010 Endpoint of the SR TE Policy SAFI NLRI. If they don't match, the SR 1011 TE Policy advertisement MUST be considered as not acceptable. If 1012 present, the Color sub-TLV MUST match the Policy Color of the SR TE 1013 Policy SAFI NLRI. If they don't match, the SR TE Policy 1014 advertisement MUST be considered as not acceptable. 1016 A non-acceptable SR TE Policy update that has a valid NLRI portion 1017 with invalid attribute portion MUST be considered as a withdraw of 1018 the SR TE Policy. 1020 A non-acceptable SR TE Policy update that has an invalid NLRI portion 1021 MUST trigger a reset of the BGP session. 1023 3.4.2. Usable SR TE Policy 1025 When the receiver has determined that the received SR TE Policy is 1026 acceptable according to previous section, it has to determine if the 1027 received SR TE Policy is usable. 1029 The receiver MUST check whether route-target or NO_ADVERTISE 1030 communities are attached to it. If no route-target is present and 1031 the NO_ADVERTISE community is present, then the SR TE Policy is 1032 usable. 1034 If one or more route-targets are present, then at least one route- 1035 target MUST match the BGP Identifier (BGP Router-ID) of the receiver 1036 in order for the update to be considered usable. The BGP Identifier 1037 is defined in [RFC4271] as a 4 octet IPv4 address. Therefore the 1038 route-target extended community MUST be of the same format. 1040 If one or more route-targets are present and no one matches the local 1041 BGP router-ID, then, while the SR TE Policy is acceptable, the SR TE 1042 Policy is not usable. It has to be noted that if the receiver has 1043 been explicitly configured to do so, it MAY propagate the SR TE 1044 Policy to its neighbors as defined in Section 3.4.4. 1046 The following applies to usable SR TE Policies: 1048 o Any segment sub-TLV of type 3 to 8 that is present in the segment 1049 list MUST be either validated or resolved: 1051 if the SID portion of the sub-TLV is present, then the segment 1052 MUST be validated by the receiver. Validation consists of 1053 verifying that the SID value is related to the network address. 1055 if the SID portion of the sub-TLV is not present, then the 1056 segment MUST be resolved by the receiver. Resolution consists 1057 of taking from the receiver database (e.g.; from the link-state 1058 or routing information base) that the SID value related to the 1059 network address in the sub-TLV. 1061 o The receiver MUST check the validity of the first SID of each 1062 Segment List sub-TLV of the SR TE Policy. The first SID MUST be 1063 known in the receiver local table either as a label (in the case 1064 the SID encodes a label value) or as an IPv6 address. 1066 o Any invalid segment of the segment list MUST cause an invalidation 1067 of the whole segment list. However, the SR TE Policy is still 1068 usable if at least one segment list is valid. 1070 o The receiver much keep track of the validated segment (i.e.: the 1071 first segment and any segment encoded in Sub-TLV type 3 to 8). A 1072 segment who failed validation may become valid after a network 1073 event and vice versa. The receiver SHOULD keep the state of the 1074 received SR TE Policies based on latest state of the segments 1075 requires validation. 1077 It has to be noted that an SR-TE policy may be received by a server 1078 that is not a router, and that does not have the necessary state that 1079 allows him to infer the next-hop from the first segment. In that 1080 case, if the server needs to send a packet according to a particular 1081 SR-TE policy, it SHOULD push on the label stack that the policy 1082 specifies, and then send the packet to a default router (or default 1083 gateway). 1085 3.4.3. Instantiation of an SR TE Policy 1087 On reception of an acceptable, valid and usable SR TE Policy, a BGP 1088 speaker SHOULD instantiate the SR TE Policy in its routing and 1089 forwarding table with the set of segment lists (i.e.: explicit paths) 1090 included in the policy and taking into account the Binding SID and 1091 Weight sub-TLVs. 1093 The receiver of the SR TE Policy SHOULD program its MPLS or IPv6 data 1094 planes so that BGP destination prefixes matching their Extended Color 1095 Community and BGP next-hop with the SR TE Policy SAFI NLRI Color and 1096 Endpoint are steered into the SR TE Policy and forwarded accordingly. 1098 When building the MPLS label stack or the IPv6 Segment list from the 1099 Segment List sub-TLV, the receiving BGP speaker MUST interpret the 1100 set of Segment sub-TLVs as follows: 1102 o The first Segment sub-TLV represents the topmost label or the 1103 first IPv6 segment. In the receiving BGP speaker, it identifies 1104 the first segment the traffic will be directed towards to (along 1105 the SR TE explicit path). 1107 o The last Segment sub-TLV represents the bottommost label or the 1108 last IPv6 segment. 1110 As described in Section 2.4.3, when present, the Weight sub-TLV 1111 specifies a weight to be associated with the corresponding Segment 1112 List, for use in unequal-cost multi path. Weights are applied by 1113 summing the total value of all of the weights for all Segment Lists, 1114 and then assigning a fraction of the forwarded traffic to each 1115 Segment List in proportion its weight's fraction of the total. 1117 If in a SR TE Policy only some of the segment lists have a Weight 1118 Sub-TLV present, then for those who haven't any weight, a value of 1 1119 is assumed. 1121 3.4.4. Propagation of an SR TE Policy 1123 By default, a BGP node receiving an SR TE Policy MUST NOT not 1124 propagate it to any eBGP neighbor. 1126 However, a node MAY be explicitly configured in order to advertise a 1127 received SR TE Policy update to neighbors according to normal BGP 1128 rules (iBGP and eBGP propagation), e.g., in the case the node is a 1129 Route-Reflector. 1131 SR TE Policies that have been determined acceptable and valid can be 1132 propagated, even the ones that are not usable. 1134 Only SR TE Policies that do not have the NO_ADVERTISE community 1135 attached to them can be propagated. 1137 3.5. Steering Traffic into a SR TE Policy 1139 The Color field of the NLRI allows association of destination 1140 prefixes with a given SR TE Policy. The BGP speaker SHOULD then 1141 attach a Color Extended Community (as defined in [RFC5512]) to 1142 destination prefixes (e.g.: IPv4/IPv6 unicast prefixes) in order to 1143 allow the receiver of the SR TE Policy and of the destination prefix 1144 to steer traffic into the SR TE Policy if the destination prefix: 1146 o Has a BGP next-hop matching the SR TE Policy SAFI NLRI Endpoint 1147 and 1149 o Has an attached Extended Color Community with the same value as 1150 the color of the SR TE Policy NLRI Color. 1152 On the receiving BGP speaker, all destination prefixes that share the 1153 same Extended Color Community value and the same BGP next-hop are 1154 steered to the corresponding SR TE Policy that has been instantiated 1155 and which matches the Color and Endpoint NLRI values. 1157 It is assumed that only one Extended Color Community is attached to a 1158 destination prefix. In case a destination prefix is received with 1159 multiple Extended Color Communities, the receiver MUST consider the 1160 color corresponding to the SR TE Policy having the highest Preference 1161 TLV value. In case of multiple policies having the same preference, 1162 as a breaking tie, the router SHOULD select the policy having the 1163 lowest color value. 1165 Different destination prefixes can be steered into distinct SR TE 1166 Policies by coloring them differently. 1168 3.6. Flowspec and SR TE Policies 1170 The SR TE Policy can be carried in context of a Flowspec NLRI 1171 ([RFC5575]). In this case, when the redirect to IP next-hop is 1172 specified as in [I-D.ietf-idr-flowspec-redirect-ip], the tunnel to 1173 the next-hop is specified by the segment list in the Segment List 1174 sub-TLVs. The Segment List (e.g..: label stack or IPv6 segment list) 1175 is imposed to flows matching the criteria in the Flowspec route in 1176 order to steer them towards the next-hop as specified in the SR TE 1177 Policy SAFI NLRI. 1179 4. Acknowledgments 1181 The authors of this document would like to thank Dhanendra Jain, 1182 Shyam Sethuram, Acee Lindem and Imtiyaz Mohammad for their comments 1183 and review of this document. 1185 5. IANA Considerations 1187 This document defines: 1189 o a new SAFI in the registry "Subsequent Address Family Identifiers 1190 (SAFI) Parameters": 1192 Suggested Description Reference 1193 Value 1194 ----------------------------------------------------- 1195 73 SR TE Policy SAFI This document 1197 o a new Tunnel-Type in the registry "BGP Tunnel Encapsulation 1198 Attribute Tunnel Types": 1200 Suggested Description Reference 1201 Value 1202 ----------------------------------------------------- 1203 14 SR TE Policy Type This document 1205 o new sub-TLVs in the registry "BGP Tunnel Encapsulation Attribute 1206 sub-TLVs": 1208 Suggested Description Reference 1209 Value 1210 ----------------------------------------------------- 1211 6 Preference sub-TLV This document 1212 7 Binding SID sub-TLV This document 1213 8 Segment List sub-TLV This document 1215 o A new registry called "SR TE Policy List Sub-TLVs" with following 1216 codepoints: 1218 Suggested Description Reference 1219 Value 1220 ------------------------------------------------------------ 1221 1 MPLS SID This document 1222 2 IPv6 SID This document 1223 3 IPv4 Node and SID This document 1224 4 IPv6 Node and SID This document 1225 5 IPv4 Node, index and SID This document 1226 6 IPv4 Local/Remote addresses and SID This document 1227 7 IPv6 Node, index and SID This document 1228 8 IPv6 Local/Remote addresses and SID This document 1229 9 Weight sub-TLV This document 1231 6. Security Considerations 1233 TBD. 1235 7. References 1237 7.1. Normative References 1239 [I-D.ietf-idr-tunnel-encaps] 1240 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 1241 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-02 1242 (work in progress), May 2016. 1244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1245 Requirement Levels", BCP 14, RFC 2119, 1246 DOI 10.17487/RFC2119, March 1997, 1247 . 1249 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1250 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1251 DOI 10.17487/RFC4271, January 2006, 1252 . 1254 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1255 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1256 February 2006, . 1258 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1259 "Multiprotocol Extensions for BGP-4", RFC 4760, 1260 DOI 10.17487/RFC4760, January 2007, 1261 . 1263 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 1264 Subsequent Address Family Identifier (SAFI) and the BGP 1265 Tunnel Encapsulation Attribute", RFC 5512, 1266 DOI 10.17487/RFC5512, April 2009, 1267 . 1269 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1270 and D. McPherson, "Dissemination of Flow Specification 1271 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1272 . 1274 7.2. Informational References 1276 [I-D.ietf-6man-segment-routing-header] 1277 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 1278 J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, 1279 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1280 segment-routing-header-02 (work in progress), September 1281 2016. 1283 [I-D.ietf-idr-flowspec-redirect-ip] 1284 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 1285 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 1286 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 1287 in progress), February 2015. 1289 [I-D.ietf-spring-segment-routing] 1290 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1291 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1292 spring-segment-routing-09 (work in progress), July 2016. 1294 [I-D.ietf-spring-segment-routing-mpls] 1295 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1296 Litkowski, S., Horneffer, M., Shakir, R., 1297 jefftant@gmail.com, j., and E. Crabbe, "Segment Routing 1298 with MPLS data plane", draft-ietf-spring-segment-routing- 1299 mpls-05 (work in progress), July 2016. 1301 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1302 Reflection: An Alternative to Full Mesh Internal BGP 1303 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1304 . 1306 Authors' Addresses 1308 Stefano Previdi (editor) 1309 Cisco Systems, Inc. 1310 Via Del Serafico, 200 1311 Rome 00142 1312 Italy 1314 Email: sprevidi@cisco.com 1316 Clarence Filsfils 1317 Cisco Systems, Inc. 1318 Brussels 1319 BE 1321 Email: cfilsfil@cisco.com 1323 Arjun Sreekantiah 1324 Cisco Systems, Inc. 1325 170 W. Tasman Drive 1326 San Jose, CA 95134 1327 USA 1329 Email: asreekan@cisco.com 1331 Siva Sivabalan 1332 Cisco Systems, Inc. 1333 170 W. Tasman Drive 1334 San Jose, CA 95134 1335 USA 1337 Email: msiva@cisco.com 1338 Paul Mattes 1339 Microsoft 1340 One Microsoft Way 1341 Redmond, WA 98052 1342 USA 1344 Email: pamattes@microsoft.com 1346 Eric Rosen 1347 Juniper Networks 1348 10 Technology Park Drive 1349 Westford, MA 01886 1350 US 1352 Email: erosen@juniper.net 1354 Steven Lin 1355 Google 1357 Email: stevenlin@google.com