idnits 2.17.1 draft-previdi-idr-segment-routing-te-policy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 18, 2016) is 2961 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) == Unused Reference: 'RFC4364' is defined on line 725, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-01 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-06 ** 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-00 == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-13 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-03 Summary: 2 errors (**), 0 flaws (~~), 8 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: September 19, 2016 S. Sivabalan 6 Cisco Systems, Inc. 7 P. Mattes 8 Microsoft 9 March 18, 2016 11 Advertising Segment Routing Traffic Engineering Policies in BGP 12 draft-previdi-idr-segment-routing-te-policy-00 14 Abstract 16 This document defines a new BGP SAFI with a new NLRI in order to 17 advertise a Segment Routing Traffic Engineering Policy (SR TE 18 Policy). The SR TE Policy is advertised along with the Tunnel 19 Encapsulation Attribute for which this document also defines new sub- 20 TLVs. An SR TE policy is advertised with the information that will 21 be used by the node receiving the advertisement in order to 22 instantiate the policy in its forwarding table and to steer traffic 23 according to the policy. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 19, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2. SR TE Policy Encoding . . . . . . . . . . . . . . . . . . . . 4 62 2.1. SR TE Policy SAFI and NLRI . . . . . . . . . . . . . . . 4 63 2.1.1. SR TE Policies and Add-Paths . . . . . . . . . . . . 5 64 2.2. SR TE Policy and Tunnel Encapsulation Attribute . . . . . 5 65 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 6 66 2.4. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . . . 7 67 2.4.1. SR TE Binding SID Sub-TLV . . . . . . . . . . . . . . 7 68 2.4.2. Weight Sub-TLV . . . . . . . . . . . . . . . . . . . 8 69 2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 9 70 2.4.4. Segment Sub-TLV . . . . . . . . . . . . . . . . . . . 9 71 3. SR TE Policy Operations . . . . . . . . . . . . . . . . . . . 11 72 3.1. Multipath Operation . . . . . . . . . . . . . . . . . . . 12 73 3.2. Binding SID TLV . . . . . . . . . . . . . . . . . . . . . 12 74 3.3. Reception of an SR TE Policy . . . . . . . . . . . . . . 13 75 3.4. Announcing BGP SR TE Policies . . . . . . . . . . . . . . 14 76 3.5. Flowspec and SR TE Policies . . . . . . . . . . . . . . . 14 77 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 7.2. Informational References . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 Segment Routing (SR) technology leverages the source routing and 88 tunneling paradigms. [I-D.ietf-spring-segment-routing] describes the 89 SR architecture. [I-D.ietf-spring-segment-routing-mpls] describes 90 its instantiation on the MPLS data plane and 91 [I-D.ietf-6man-segment-routing-header] describes the Segment Routing 92 instantiation over the IPv6 data plane. 94 This document defines the Segment Routing Traffic Engineering Policy 95 (SR TE Policy) as a set of weighted equal cost multi path (WECMP) 96 segment lists (representing explicit paths) as well as the mechanism 97 allowing a router to steer traffic into an SR TE Policy. 99 The SR TE Policy is advertised in the Border Gateway Protocol (BGP) 100 by the BGP speaker being a router or a controller and using 101 extensions defined in this document. Among the information encoded 102 in the BGP message and representing the SR TE Policy, the steering 103 mechanism makes also use of the Extended Color Community currently 104 defined in [I-D.ietf-idr-tunnel-encaps] 106 Typically, a controller defines the set of policies and advertise 107 them to BGP routers (typically ingress routers). The policy 108 advertisement uses BGP extensions defined in this document. The 109 policy advertisement is, in most but not all of the cases, tailored 110 for the receiver. In other words, a policy advertised to a given BGP 111 speaker has significance only for that particular router and is not 112 intended to be propagated anywhere else. Then, the receiver of the 113 policy instantiate the policy in its routing and forwarding tables 114 and steer traffic into it based on both the policy and destination 115 prefix color and next-hop. 117 Alternatively, a router (i.e.: an BGP egress router) advertises SR TE 118 Policies representing paths to itself. These advertisements are sent 119 to BGP ingress nodes who instantiate these policies and steer traffic 120 into them according to the color and endpoint/BGP next-hop of both 121 the policy and the destination prefix. 123 An SR TE Policy being intended only for the receiver of the 124 advertisement, the SR TE Policies are sent directly to each receiver 125 and, in most of the cases will not traverse any Route Reflector (RR, 126 [RFC4456]). 128 However, in the case where the same SR TE Policy is intended for a 129 group of nodes, nothing prevents the originator to rely on one or 130 more RRs in order to distribute the SR TE Policy to multiple 131 receivers. The encoding of the SR TE Policy defined in this document 132 supports both propagation schemes: direct BGP session and Route 133 Reflectors. 135 The BGP extensions for the advertisement of SR TE Policies include 136 following components: 138 o A new Subsequent Address Family Identifier (SAFI) identifying the 139 content of the BGP message (i.e.: the SR TE Policy). 141 o A new NLRI identifying the SR TE Policy. 143 o A set of new TLVs to be inserted into the Tunnel Encapsulation 144 Attribute (as defined in [I-D.ietf-idr-tunnel-encaps]) and 145 describing the SR TE Policy. 147 o The Extended Color Community (as defined in 148 [I-D.ietf-idr-tunnel-encaps]) and used in order to steer traffic 149 into an SR TE Policy. 151 1.1. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 2. SR TE Policy Encoding 159 2.1. SR TE Policy SAFI and NLRI 161 A new SAFI is defined: the SR TE Policy SAFI (codepoint suggested 162 value 73, to be assigned by IANA). 164 The SR TE Policy SAFI uses a new NLRI defined as follows: 166 +-----------------------------------------------+ 167 | Policy Color (4 octets) | 168 +-----------------------------------------------+ 169 | Endpoint (4 or 16 octets) | 170 +-----------------------------------------------+ 172 where: 174 o Policy Color: 4-octet value identifying (with the endpoint) the 175 policy. The color is used to match the color of the destination 176 prefixes in order to steer traffic into the SR TE Policy. 178 o Endpoint: identifies the endpoint of a policy. The Endpoint may 179 represent a single node or a set of nodes (e.g.: an anycast 180 address or a summary address). The Endpoint may be an IPv4 181 (4-octet) address or an IPv6 (16-octet) address according to the 182 AFI of the NLRI. 184 The NLRI containing the SR TE Policy is carried in a BGP UPDATE 185 message [RFC4271] using BGP multiprotocol extensions [RFC4760] with 186 an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of 73 (suggested 187 value, to be assigned by IANA). 189 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 190 attribute with the SR TE Policy SAFI MUST also carry the BGP 191 mandatory attributes: NEXT_HOP, ORIGIN, AS_PATH, and LOCAL_PREF (for 192 IBGP neighbors), as defined in [RFC4271]. In addition, the BGP 193 update message MAY also contain any of the BGP optional attributes. 195 The NEXT_HOP attribute of the SR TE Policy SAFI NLRI is set based on 196 the AFI. For example, if the AFI is set to IPv4 (1), then the 197 nexthop is encoded as a 4-byte IPv4 address. If the AFI is set to 198 IPv6 (2), then the nexthop is encoded as a 16-byte IPv6 address of 199 the router. It is important to note that any BGP speaker receiving a 200 BGP message with an SR TE Policy NLRI, will process it only if the 201 NLRI is a best path as per the BGP best path selection algorithm. 203 The NEXT_HOP attribute of the SR TE Policy SAFI NLRI MUST be set as 204 one of the local addresses of the BGP speaker originating and 205 advertising the SR TE Policy (either the controller or the BGP egress 206 node). 208 2.1.1. SR TE Policies and Add-Paths 210 The SR TE Policy SAFI NLRI MAY use the Add Paths extension 211 ([I-D.ietf-idr-add-paths]) when the same policy (identified by the 212 same Color and Endpoint) is to be advertised by multiple originators 213 (e.g.: multiple controllers) and all advertisements need to be 214 advertised to a group of receivers (hence these advertisements need 215 to be preserved from a RR selection process). 217 In such case, each controller will use a different path identifier in 218 the advertisement of the SR TE Policy. 220 When Add-Paths extensions is to be used, it MUST be signaled in the 221 BGP capability according to ([I-D.ietf-idr-add-paths]). 223 2.2. SR TE Policy and Tunnel Encapsulation Attribute 225 The content of the SR TE Policy is encoded in the Tunnel 226 Encapsulation Attribute originally defined in 227 [I-D.ietf-idr-tunnel-encaps] using a new Tunnel-Type TLV (suggested 228 codepoint is 14, to be assigned by IANA). 230 The SR TE Policy Encoding structure is as follows: 232 SR TE Policy SAFI NLRI: 233 Attributes: 234 Tunnel Encaps Attribute (23) 235 Tunnel Type: SR TE Policy 236 Binding SID 237 Segment List 238 Weight 239 Segment (sid/nai/flags) 240 Segment (sid/nai/flags) 241 ... 242 ... 243 ... 244 where: 246 o SR TE Policy SAFI NLRI is defined in Section 2.1. 248 o Tunnel Encapsulation Attribute is defined in 249 [I-D.ietf-idr-tunnel-encaps]. 251 o Tunnel-Type is set to a suggested value of 14 (to be assigned by 252 IANA). 254 o Binding SID, Weight, Segment and Segment-List are new sub-TLVs 255 defined in this document. 257 o Additional sub-TLVs may be defined in the future. 259 A single occurrence of "Tunnel Type: SR TE Policy" MUST be encoded 260 within the same Tunnel Encapsulation Attribute. 262 Multiple occurrences of "Segment List" MAY be encoded within the same 263 SR TE Policy. 265 Multiple occurrences of "Segment" MAY be encoded within the same 266 Segment List. 268 2.3. Remote Endpoint and Color 270 The Remote Endpoint and Color sub-TLVs, as defined in 271 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR TE Policy 272 encodings. 274 If present, the Remote Endpoint sub-TLV MUST match the Endpoint of 275 the SR TE Policy SAFI NLRI. If they don't match, the SR TE Policy 276 advertisement MUST be considered as invalid. 278 If present, the Color sub-TLV MUST match the Policy Color of the SR 279 TE Policy SAFI NLRI. If they don't match, the SR TE Policy 280 advertisement MUST be considered as invalid. 282 2.4. SR TE Policy Sub-TLVs 284 This section defines the SR TE Policy sub-TLVs. 286 2.4.1. SR TE Binding SID Sub-TLV 288 The Binding SID sub-TLV requests the allocation of a Binding Segment 289 identifier associated with the SR TE Policy. The Binding SID sub-TLV 290 has the following format: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Binding SID (variable, optional) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 where: 302 o Type: to be assigned by IANA (suggested value is 6). 304 o Length: specifies the length of the value field not including Type 305 and Length fields. Can be 0 or 4 or 16. 307 o Binding SID: if length is 0, then no field is present. If length 308 is 4 then the Binding SID contains a 4-octet SID. If length is 16 309 then the Binding SID contains a 16-octet IPv6 SID. 311 The Binding SID sub-TLV is used to instruct the receiver of the BGP 312 message to allocate a Binding SID to the SR TE Policy. The 313 allocation of the Binding SID in the receiver is done according to 314 following rules: 316 o If length is 0 (no value field is present), then the receiver MUST 317 allocate a local Binding SID whose value is chosen by the 318 receiver. 320 o If length is 4, then the value field contains the 4-octet Binding 321 SID value the receiver SHOULD allocate. 323 o If length is 16, then the value field contains the 16-octet 324 Binding SID value the receiver SHOULD allocate. 326 The Binding SID sub-TLV is mandatory and MUST NOT appear more than 327 once on an SR TE Policy Advertisement. 329 When a controller is used in order to define and advertise SR TE 330 Policies and when the Binding SID is allocated by the receiver, such 331 Binding SID SHOULD be reported to the controller. The mechanisms 332 and/or APIs used for the reporting of the Binding SID are outside the 333 scope of this document. 335 Further use of the Binding SID is described in a subsequent section. 337 2.4.2. Weight Sub-TLV 339 The Weight sub-TLV specifies the weight associated to a given path 340 (i.e.: a given segment list). The weight is used in order to apply 341 weighted-ECMP mechanism when steering traffic into a policy that 342 includes multiple paths (i.e.: multiple segment lists). 344 The Weight sub-TLV has the following format: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Weight | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 where: 356 Type: to be assigned by IANA (suggested value is 7). 358 Length: 4. 360 The Weight sub-TLV is optional and MAY appear only once in the 361 Segment List sub-TLV. 363 When present, the Weight sub-TLV specifies a weight to be associated 364 with the corresponding Segment List, for use in unequal-cost multi 365 path. Weights are applied by summing the total value of all of the 366 weights for all Segment Lists, and then assigning a fraction of the 367 forwarded traffic to each Segment List in proportion its weight's 368 fraction of the total. 370 2.4.3. Segment List Sub-TLV 372 The Segment List sub-TLV is used in order to encode a single explicit 373 path towards the endpoint. The Segment List sub-TLV includes the 374 elements of the paths (i.e.: segments) as well as an optional Weight 375 TLV. 377 The Segment List sub-TLV has the following format: 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Type | Length | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 // sub-TLVs // 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 where: 389 o Type: to be assigned by IANA (suggested value is 8). 391 o Length: the total length (not including the Type and Length 392 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 394 o sub-TLVs: 396 * An optional single Weight sub-TLV. 398 * One or more Segment sub-TLVs. 400 The Segment List sub-TLV is mandatory. 402 Multiple occurrences of the Segment List sub-TLV MAY appear in the SR 403 TE Policy. 405 When multiple occurrences of the Segment List sub-TLV appear in the 406 SR TE Policy, the traffic is load-balanced across them either through 407 an ECMP scheme (if no Weight sub-TLV is present) or through a W-ECMP 408 scheme according to Section 2.4.2. 410 2.4.4. Segment Sub-TLV 412 The Segment sub-TLV describes a single segment in a segment list 413 (i.e.: a single element of the explicit path). Multiple Segment sub- 414 TLVs constitute an explicit path of the SR TE Policy. 416 The encoding format of the Segment sub-TLV is based on the ERO sub- 417 object definition described in [I-D.ietf-pce-segment-routing]): 419 0 1 2 3 420 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type | Length | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | ST | Flags |I|L|F|S|C|M| 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 // SID (32 bits or 128 bits) // 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 // NAI (variable) // 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 where: 433 o Type: to be assigned by IANA (suggested value is 9). 435 o Length: the length of the Segment sub-TLV not including the Type 436 and Length fields. 438 SID Type (ST) indicates the type of the information associated with 439 the SID and NAI contained in the sub-TLV. ST is defined in 440 [I-D.ietf-pce-segment-routing]. 442 SID is the Segment Identifier as defined in 443 [I-D.ietf-pce-segment-routing]. 445 NAI (Node and Adjacency Identifier) contains the NAI associated with 446 the SID. Depending on the value of ST, the NAI can have different 447 formats as described in [I-D.ietf-pce-segment-routing]. 449 Flags carry any additional information related to the SID. 450 Currently, the following flags are defined: 452 I-Flag: IPv6 SID flag. When set, it indicates that the SID is 453 encoded as a 16-octet IPv6 SID (IPv6 SIDs are defined in 454 [I-D.ietf-6man-segment-routing-header]). When clear, the SID is 455 encoded as a 4-octet SID. 457 L-Flag: Loose flag. Indicates whether the encoding represents a 458 loose-hop in the LSP ([RFC3209]). If L-Flag is clear, a BGP 459 speaker MUST NOT overwrite the SID value present in the Segment 460 sub-TLV. Otherwise, a BGP speaker, based on local policy, MAY 461 expand or replace the SID value in the received Segment sub-TLV. 463 F-flag: when set, the NAI value in the object body is null. 465 S-Flag: when set, the SID value in the object body is null. In 466 this case, the receiving BGP speaker is responsible for choosing 467 the SID value, e.g., by looking up its Tunnel DB using the NAI 468 which, in this case, MUST be present in the object. 470 C-Flag: when this flag as well as the M-flag are set, then the SID 471 value represents an MPLS label stack entry as specified in 472 [RFC5462], where all the entry's fields (Label, TC, S, and TTL) 473 are specified by the sending BGP speaker. However, a receiving 474 BGP speaker MAY choose to override TC, S, and TTL values according 475 its local policy and MPLS forwarding rules. 477 M-Flag: when this bit is set, the SID value represents an MPLS 478 label stack entry as specified in [RFC5462] where only the label 479 value is specified by the BGP speaker. Other label fields (i.e: 480 TC, S, and TTL) fields MUST be ignored, and receiving BGP speaker 481 MUST set these fields according to its local policy and MPLS 482 forwarding rules. 484 Other flags may be defined in the future. 486 The NAI encoding is as per corresponding sub-TLV definition in 487 [I-D.ietf-pce-segment-routing] 489 3. SR TE Policy Operations 491 SR TE Policies are advertised in the Tunnel Encapsulation Attribute 492 defined in [I-D.ietf-idr-tunnel-encaps]. The SR TE Policy TLVs 493 specify one (or more for load balancing purposes) list of segment 494 identifiers (SIDs), that define the set of explicit SR TE paths 495 towards the endpoint address encoded in the NLRI. 497 The Color field of the NLRI allows association of destination 498 prefixes with a given SR TE Policy. The BGP speaker SHOULD then 499 attach a Color Extended Community (as defined in [RFC5512]) to 500 destination prefixes (e.g.: IPv4/IPv6 unicast prefixes) in order to 501 allow the receiver of the SR TE Policy and of the destination prefix 502 to steer traffic into the SR TE Policy if the destination prefix: 504 o Has a BGP next-hop attribute matching the SR TE Policy SAFI NLRI 505 Endpoint and 507 o Has an attached Extended Color Community with the same value as 508 the color of the SR TE Policy NLRI Color. 510 A SR TE Policy MAY also be sent by a controller, in lieu of the 511 originating speaker. The controller sends the SR TE Policy SAFI NLRI 512 with a Policy Color and an Endpoint identifying the Policy, where: 514 The Policy Color is to be used in order to steer traffic into the 515 policy in the node receiving the SR TE Policy. 517 The Endpoint (with the Color) identifies the policy. Endpoint is 518 used to match the BGP next-hop attribute of the destination prefix 519 when steering traffic in the node receiving the SR TE Policy. 521 On reception of an SR TE Policy, a BGP speaker SHOULD instantiate the 522 SR TE Policy in its routing and forwarding table with the set of 523 segment lists (i.e.: explicit paths) included in the policy and 524 taking into account the Binding SID and Weight sub-TLVs. 526 On the receiving BGP speaker, all destination prefixes that share the 527 same Extended Color Community value and the same BGP next-hop 528 attribute are steered to the corresponding SR TE Policy that has been 529 instantiated and which matches the Color and Endpoint NLRI values. 531 Similarly, different destination prefixes can be steered into 532 distinct SR TE Policies by coloring them differently. 534 3.1. Multipath Operation 536 The SR TE Policy MAY contain multiple Segment Lists which, in the 537 absence of the Weight TLV, signifies equal cost load balancing 538 amongst them. 540 When a weight sub-TLV is encoded in each Segment List TLV, then the 541 weight value SHOULD be used in order to perform an unequal cost load 542 balance amongst the Segment Lists as specified in Section 2.4.2. 544 3.2. Binding SID TLV 546 When the optional Binding SID sub-TLV is present, it indicates an 547 instruction, to the receiving BGP speaker to allocate a Binding SID 548 for the list of SIDs the Binding sub-TLV is related to. 550 Any incoming packet with the Binding SID as active segment (according 551 to the terminology described in [I-D.ietf-spring-segment-routing]) 552 will then have the Binding SID swapped with the list of SIDs 553 specified in the Segment List sub-TLVs on the allocating BGP speaker. 554 The allocated Binding SID MAY be then advertised by the BGP speaker 555 that created it, through, e.g., BGP-LS in order to, typically, feed a 556 controller with the updated topology and SR TE Policy information. 558 3.3. Reception of an SR TE Policy 560 When a BGP speaker receives an SR TE Policy from a neighbor it has to 561 determine if the SR TE Policy advertisement is acceptable. The 562 following applies: 564 o The SR TE Policy NLRI MUST have a color value and MAY have an 565 Endpoint value. 567 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 568 Update and MUST have the Tunnel Type set to SR TE Policy (value to 569 be assigned by IANA). 571 o Within the SR TE Policy, at least one Segment List sub-TLV MUST be 572 present. 574 o Within the Segment List sub-TLV at least one Segment sub-TLV MUST 575 be present. 577 o Within Segment sub-TLV it is not required that both SID and NAI 578 are encoded however, at least one of the two MUST be present. 580 Any segment (in the segment list sub-TLV) being advertised with an 581 NAI MUST be validated by the receiver. The validation consists of 582 resolving the SID using the NAI information, i.e., the receiver does 583 a lookup in its local table and finds the SID value corresponding to 584 the NAI information. The type of information carried in the NAI is 585 related to the settings of the ST bits in the segment sub-TLV and 586 described in [I-D.ietf-pce-segment-routing]. 588 When a BGP speaker receives an SR TE Policy from a neighbor and 589 according to [I-D.ietf-pce-segment-routing], the receiver MUST check 590 the validity of the first SID of each Segment List sub-TLV of the SR 591 TE Policy. The first SID MUST be known in the receiver local table 592 either as a label (in the case the SID encodes a label value) or as 593 an IPv6 address. 595 When a BGP speaker receives an SR TE Policy from a neighbor with an 596 acceptable SR TE Policy SAFI NLRI and with the I-flag clear, it 597 SHOULD compute the segment list and equivalent MPLS label from the 598 Segment List sub-TLVs and program them in the MPLS data plane. 600 When a BGP speaker receives an SR TE Policy from a neighbor with an 601 acceptable SR TE Policy SAFI NLRI and with the I-flag set, it SHOULD 602 compute the segment list and equivalent IPv6 segment list from the 603 Segment List sub-TLVs and program them in the IPv6 data plane 604 according to [I-D.ietf-6man-segment-routing-header]. 606 Also, the receiver SHOULD program its MPLS or IPv6 data planes so 607 that BGP destination prefixes matching their Extended Color Community 608 and BGP next-hop with the SR TE Policy SAFI NLRI Color and Endpoint 609 are steered into the SR TE Policy and forwarded accordingly. 611 When building the MPLS label stack or the IPv6 Segment list from the 612 Segment List sub-TLV, the receiving BGP speaker MUST interpret the 613 set of Segment sub-TLVs as follows: 615 o The first Segment sub-TLV represents the topmost label or the 616 first IPv6 segment. In the receiving BGP speaker, it identifies 617 the first segment the traffic will be directed towards to (along 618 the SR TE explicit path). 620 o The last Segment sub-TLV represents the bottommost label or the 621 last IPv6 segment. 623 3.4. Announcing BGP SR TE Policies 625 Typically, the value of the SIDs encoded in the Segment sub-TLVs is 626 determined by configuration/provisioning either in the controller or 627 in the node originating the SR TE Policy. 629 A BGP speaker SHOULD follow normal iBGP/eBGP rules to propagate the 630 SR TE Policy. The Add-Paths capability in the SR TE Policy SAFI NLRI 631 allows the propagation of each individual policy through one or more 632 Route Reflectors (RR) without incurring the case where one or more 633 policies are dropped due to RR selection process. 635 Since the SR TE Policies are unique within an SR domain and intended 636 only for the receiver of the SR TE Policy advertisement, a BGP 637 speaker receiving an SR TE Policy, by default, MUST NOT propagate 638 such policy unless explicitly configured to do so. 640 In order to prevent propagation of SR TE Policy advertisement, BGP 641 filters MAY be deployed in addition to the use of the NO_ADVERTISE 642 community ([RFC1997]) that MAY be attached to the advertisement. 644 3.5. Flowspec and SR TE Policies 646 The SR TE Policy can be carried in context of a Flowspec NLRI 647 ([RFC5575]). In this case, when the redirect to IP nexthop is 648 specified as in [I-D.ietf-idr-flowspec-redirect-ip], the tunnel to 649 the nexthop is specified by the segment list in the Segment List sub- 650 TLVs. The Segment List (e.g..: label stack or IPv6 segment list) is 651 imposed to flows matching the criteria in the Flowspec route in order 652 to steer them towards the nexthop as specified in the SR TE Policy 653 SAFI NLRI. 655 4. Acknowledgments 657 The authors of this document would like to thank Eric Rosen for his 658 review of this document. 660 5. IANA Considerations 662 This document defines: 664 o a new SAFI in the registry "Subsequent Address Family Identifiers 665 (SAFI) Parameters": 667 Suggested Description Reference 668 Value 669 ----------------------------------------------------- 670 73 SR TE Policy SAFI This document 672 o a new Tunnel-Type in the registry "BGP Tunnel Encapsulation 673 Attribute Tunnel Types": 675 Suggested Description Reference 676 Value 677 ----------------------------------------------------- 678 14 SR TE Policy Type This document 680 o new sub-TLVs in the registry "BGP Tunnel Encapsulation Attribute 681 sub-TLVs": 683 Suggested Description Reference 684 Value 685 ----------------------------------------------------- 686 6 Binding SID sub-TLV This document 687 7 Weight sub-TLV This document 688 8 Segment List sub-TLV This document 689 9 Segment sub-TLV This document 691 6. Security Considerations 693 TBD. 695 7. References 697 7.1. Normative References 699 [I-D.ietf-idr-tunnel-encaps] 700 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 701 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-01 702 (work in progress), December 2015. 704 [I-D.ietf-pce-segment-routing] 705 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 706 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 707 "PCEP Extensions for Segment Routing", draft-ietf-pce- 708 segment-routing-06 (work in progress), August 2015. 710 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 711 Requirement Levels", BCP 14, RFC 2119, 712 DOI 10.17487/RFC2119, March 1997, 713 . 715 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 716 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 717 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 718 . 720 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 721 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 722 DOI 10.17487/RFC4271, January 2006, 723 . 725 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 726 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 727 2006, . 729 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 730 "Multiprotocol Extensions for BGP-4", RFC 4760, 731 DOI 10.17487/RFC4760, January 2007, 732 . 734 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 735 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 736 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 737 2009, . 739 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 740 Subsequent Address Family Identifier (SAFI) and the BGP 741 Tunnel Encapsulation Attribute", RFC 5512, 742 DOI 10.17487/RFC5512, April 2009, 743 . 745 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 746 and D. McPherson, "Dissemination of Flow Specification 747 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 748 . 750 7.2. Informational References 752 [I-D.ietf-6man-segment-routing-header] 753 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 754 J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment 755 Routing Header (SRH)", draft-ietf-6man-segment-routing- 756 header-00 (work in progress), December 2015. 758 [I-D.ietf-idr-add-paths] 759 Walton, D., Retana, A., Chen, E., and J. Scudder, 760 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 761 add-paths-13 (work in progress), December 2015. 763 [I-D.ietf-idr-flowspec-redirect-ip] 764 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 765 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 766 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 767 in progress), February 2015. 769 [I-D.ietf-spring-segment-routing] 770 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 771 and R. Shakir, "Segment Routing Architecture", draft-ietf- 772 spring-segment-routing-07 (work in progress), December 773 2015. 775 [I-D.ietf-spring-segment-routing-mpls] 776 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 777 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 778 and E. Crabbe, "Segment Routing with MPLS data plane", 779 draft-ietf-spring-segment-routing-mpls-03 (work in 780 progress), February 2016. 782 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 783 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 784 . 786 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 787 Reflection: An Alternative to Full Mesh Internal BGP 788 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 789 . 791 Authors' Addresses 792 Stefano Previdi (editor) 793 Cisco Systems, Inc. 794 Via Del Serafico, 200 795 Rome 00142 796 Italy 798 Email: sprevidi@cisco.com 800 Clarence Filsfils 801 Cisco Systems, Inc. 802 Brussels 803 BE 805 Email: cfilsfil@cisco.com 807 Arjun Sreekantiah 808 Cisco Systems, Inc. 809 170 W. Tasman Drive 810 San Jose, CA 95134 811 USA 813 Email: asreekan@cisco.com 815 Siva Sivabalan 816 Cisco Systems, Inc. 817 170 W. Tasman Drive 818 San Jose, CA 95134 819 USA 821 Email: msiva@cisco.com 823 Paul Mattes 824 Microsoft 825 One Microsoft Way 826 Redmond, WA 98052 827 USA 829 Email: pamattes@microsoft.com