idnits 2.17.1 draft-previdi-idr-segment-routing-te-policy-04.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 (February 20, 2017) is 2621 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-03 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-00 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-05 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-07 Summary: 2 errors (**), 0 flaws (~~), 6 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: August 24, 2017 S. Sivabalan 6 Cisco Systems, Inc. 7 P. Mattes 8 Microsoft 9 E. Rosen 10 Juniper Networks 11 S. Lin 12 Google 13 February 20, 2017 15 Advertising Segment Routing Policies in BGP 16 draft-previdi-idr-segment-routing-te-policy-04 18 Abstract 20 This document defines a new BGP SAFI with a new NLRI in order to 21 advertise an explicit path of a Segment Routing Policy (SR Policy). 22 An SR Policy is a set of dynamic and/or explicit paths each 23 represented by one or more segment lists. The path of the SR Policy 24 is advertised along with the Tunnel Encapsulation Attribute for which 25 this document also defines new sub-TLVs. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 24, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 2. SR TE Policy Encoding . . . . . . . . . . . . . . . . . . . . 4 64 2.1. SR TE Policy SAFI and NLRI . . . . . . . . . . . . . . . 4 65 2.2. SR TE Policy and Tunnel Encapsulation Attribute . . . . . 6 66 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 7 67 2.4. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . . . 7 68 2.4.1. Preference sub-TLV . . . . . . . . . . . . . . . . . 7 69 2.4.2. SR TE Binding SID Sub-TLV . . . . . . . . . . . . . . 8 70 2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 9 71 3. Extended Color Community . . . . . . . . . . . . . . . . . . 21 72 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 21 73 4.1. Configuration and Advertisement of SR TE Policies . . . . 21 74 4.2. Reception of an SR Policy . . . . . . . . . . . . . . . . 22 75 4.2.1. Acceptance of a SR Policy Update . . . . . . . . . . 22 76 4.2.2. Passing an acceptable path to an SR Policy . . . . . 23 77 4.2.3. Propagation of an SR Policy . . . . . . . . . . . . . 24 78 4.3. Steering Traffic into a SR Policy . . . . . . . . . . . . 24 79 4.4. Flowspec and SR Policies . . . . . . . . . . . . . . . . 24 80 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 81 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 83 7.1. Existing Registry: Subsequent Address Family Identifiers 84 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 25 85 7.2. Existing Registry: BGP Tunnel Encapsulation Attribute 86 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 26 87 7.3. Existing Registry: BGP Tunnel Encapsulation Attribute 88 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 26 89 7.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 26 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 27 93 9.2. Informational References . . . . . . . . . . . . . . . . 27 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 96 1. Introduction 98 Segment Routing (SR) technology leverages the source routing and 99 tunneling paradigms. [I-D.ietf-spring-segment-routing] describes the 100 SR architecture. [I-D.ietf-spring-segment-routing-mpls] describes 101 its instantiation on the MPLS data plane and 102 [I-D.ietf-6man-segment-routing-header] describes the Segment Routing 103 instantiation over the IPv6 data plane. 105 This document defines a new BGP SAFI with a new NLRI in order to 106 advertise a Segment Routing Policy (SR Policy) into BGP. 108 While for commodity we often write that BGP advertises an SR Policy, 109 the reader should remember that BGP advertises a path of an SR policy 110 and that this SR Policy might have several other candidate paths 111 provided via BGP, PCEP, NETCONF or local policy configuration. 113 The BGP behavior described in this document is only focused on the 114 signaling of a candidate path to a head-end. 116 The rules to select the best candidate path, to install it in the 117 forwarding plane and to steer traffic on this policy are defined in 118 [I-D.filsfils-spring-segment-routing-policy]. 120 An SR Policy is advertised in the Border Gateway Protocol (BGP) by 121 the BGP speaker being a router or a controller and using extensions 122 defined in this document. Among the information encoded in the BGP 123 message and representing the SR Policy, the steering mechanism is 124 defined in [I-D.filsfils-spring-segment-routing-policy]. This 125 steering mechanism makes also use of the Extended Color Community 126 currently defined in [I-D.ietf-idr-tunnel-encaps]. 128 Typically, a controller defines the set of policies and advertise 129 them to BGP routers (typically ingress routers). The policy 130 advertisement uses BGP extensions defined in this document. The 131 policy advertisement is, in most but not all of the cases, tailored 132 for the receiver. In other words, a policy advertised to a given BGP 133 speaker has significance only for that particular router and is not 134 intended to be propagated anywhere else. Then, the receiver of the 135 policy instantiate the policy in its routing and forwarding tables 136 and steer traffic into it based on both the policy and destination 137 prefix color and next-hop. 139 Alternatively, a router (i.e.: an BGP egress router) advertises SR 140 Policies representing paths to itself. These advertisements are sent 141 to SR policy head-end nodes who instantiate these policies and steer 142 traffic into them according to the color and endpoint/BGP next-hop of 143 both the policy and the destination prefix. 145 An SR Policy intended only for the receiver will, in most cases, not 146 traverse any Route Reflector (RR, [RFC4456]). 148 However, there are cases where a SR Policy is intended for multiple 149 receivers. Also, in a deployment scenario, a controller may also 150 rely on the standard BGP update propagation scheme which makes use of 151 route reflectors. These cases require mechanisms that: 153 o Uniquely identify each SR path of a given policy. 155 o Uniquely identify the intended receiver of a given SR Policy 156 advertisement. 158 The BGP extensions for the advertisement of SR Policies include 159 following components: 161 o A new Subsequent Address Family Identifier (SAFI) identifying the 162 content of the BGP message (i.e.: the SR Policy). 164 o A new NLRI identifying the SR Policy. 166 o A set of new TLVs to be inserted into the Tunnel Encapsulation 167 Attribute (as defined in [I-D.ietf-idr-tunnel-encaps]) and 168 describing the SR Policy. 170 o An IPv4 address format route-target extended community ([RFC4360]) 171 attached to the SR Policy advertisement and that indicates the 172 intended receiver of such SR Policy advertisement. 174 o The Extended Color Community (as defined in 175 [I-D.ietf-idr-tunnel-encaps]) and used in order to steer traffic 176 into an SR Policy. This document (Section 3) modifies the format 177 of the Extended Color Community by using the two leftmost bits of 178 the RESERVED field. 180 1.1. Requirements Language 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in RFC 2119 [RFC2119]. 186 2. SR TE Policy Encoding 188 2.1. SR TE Policy SAFI and NLRI 190 A new SAFI is defined: the SR Policy SAFI (codepoint TBD1 to be 191 assigned by IANA from the "Subsequent Address Family Identifiers 192 (SAFI) Parameters" registry). 194 The SR Policy SAFI uses a new NLRI defined as follows: 196 +-----------------------------------------------+ 197 | Distinguisher (4 octets) | 198 +-----------------------------------------------+ 199 | Policy Color (4 octets) | 200 +-----------------------------------------------+ 201 | Endpoint (4 or 16 octets) | 202 +-----------------------------------------------+ 204 where: 206 o Distinguisher: 4-octet value uniquely identifying the policy in 207 the context of tuple. The distinguisher has no 208 semantic and it's solely used by the SR Policy originator in order 209 to make unique (from a NLRI perspective) multiple occurrences of 210 the same SR Policy. 212 o Policy Color: 4-octet value identifying (with the endpoint) the 213 policy. The color is used to match the color of the destination 214 prefixes in order to steer traffic into the SR Policy 215 [I-D.filsfils-spring-segment-routing-policy]. 217 o Endpoint: identifies the endpoint of a policy. The Endpoint may 218 represent a single node or a set of nodes (e.g.: an anycast 219 address or a summary address). The Endpoint is an IPv4 (4-octet) 220 address or an IPv6 (16-octet) address according to the AFI of the 221 NLRI. 223 The NLRI containing the SR Policy is carried in a BGP UPDATE message 224 [RFC4271] using BGP multiprotocol extensions [RFC4760] with an AFI of 225 1 or 2 (IPv4 or IPv6) and with a SAFI of TBD1 (to be assigned by IANA 226 from the "Subsequent Address Family Identifiers (SAFI) Parameters" 227 registry). 229 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 230 attribute with the SR Policy SAFI MUST also carry the BGP mandatory 231 attributes. In addition, the BGP update message MAY also contain any 232 of the BGP optional attributes. 234 The next-hop of the SR Policy SAFI NLRI is set based on the AFI. For 235 example, if the AFI is set to IPv4 (1), then the next-hop is encoded 236 as a 4-byte IPv4 address. If the AFI is set to IPv6 (2), then the 237 next-hop is encoded as a 16-byte IPv6 address of the router. It is 238 important to note that any BGP speaker receiving a BGP message with 239 an SR Policy NLRI, will process it only if the NLRI is a best path as 240 per the BGP best path selection algorithm. 242 It has to be noted that if several candidate paths of the same SR 243 Policy (endpoint, color) are signaled via BGP to a head-end, we 244 recommend that each NLRI use a different RD. Doing so, BGP passes 245 all the paths to the SR Policy. The selection among all the 246 candidate paths is best done by the SR Policy (BGP is only a conveyor 247 of path, like PCEP, NETCONF or local CLI). 249 2.2. SR TE Policy and Tunnel Encapsulation Attribute 251 The content of the SR Policy is encoded in the Tunnel Encapsulation 252 Attribute originally defined in [I-D.ietf-idr-tunnel-encaps] using a 253 new Tunnel-Type TLV (codepoint is TBD2, to be assigned by IANA from 254 the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry). 256 The SR Policy Encoding structure is as follows: 258 SR Policy SAFI NLRI: 259 Attributes: 260 Tunnel Encaps Attribute (23) 261 Tunnel Type: SR Policy 262 Binding SID 263 Preference 264 Segment List 265 Weight 266 Segment 267 Segment 268 ... 269 ... 270 where: 272 o SR Policy SAFI NLRI is defined in Section 2.1. 274 o Tunnel Encapsulation Attribute is defined in 275 [I-D.ietf-idr-tunnel-encaps]. 277 o Tunnel-Type is set to TBD2 (to be assigned by IANA from the "BGP 278 Tunnel Encapsulation Attribute Tunnel Types" registry). 280 o Preference, Binding SID, Segment-List, Weight and Segment are 281 defined in this document. 283 o Additional sub-TLVs may be defined in the future. 285 A single occurrence of "Tunnel Type: SR Policy" MUST be encoded 286 within the same Tunnel Encapsulation Attribute. 288 Multiple occurrences of "Segment List" MAY be encoded within the same 289 SR Policy. 291 Multiple occurrences of "Segment" MAY be encoded within the same 292 Segment List. 294 2.3. Remote Endpoint and Color 296 The Remote Endpoint and Color sub-TLVs, as defined in 297 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy 298 encodings. 300 If present, the Remote Endpoint sub-TLV MUST match the Endpoint of 301 the SR Policy SAFI NLRI. 303 If present, the Color sub-TLV MUST match the Policy Color of the SR 304 Policy SAFI NLRI. 306 2.4. SR TE Policy Sub-TLVs 308 This section defines the SR Policy sub-TLVs. 310 Preference, Binding SID, Segment-List are allocated from the "BGP 311 Tunnel Encapsulation Attribute sub-TLVs" registry. 313 Weight and Segment Sub-TLVs are allocated from a new registry defined 314 in this document and called: "SR Policy List Sub-TLVs". See 315 Section 7 for the details of the registry. 317 2.4.1. Preference sub-TLV 319 The Preference sub-TLV is used in order to select the best path among 320 a given SR Policy. This selection of the best path among the 321 candidate paths of the SR policy is not done by BGP. BGP is only a 322 conveyor of paths to the SR Policy. Other paths can be provided via 323 NETCONF, PCEP or local CLI. The selection of the best path of an SR 324 policy among its candidate paths is defined in 325 [I-D.filsfils-spring-segment-routing-policy]. 327 The Preference sub-TLV is optional, MAY appear only once in the SR 328 Policy and has following format: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type | Length | Flags | RESERVED | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Preference (4 octets) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 where: 340 o Type: TBD3 (to be assigned by IANA from the "BGP Tunnel 341 Encapsulation Attribute sub-TLVs" registry). 343 o Length: 6. 345 o Flags: 1 octet of flags. None is defined at this stage. Flags 346 SHOULD be unset on transmission and MUST be ignored on receipt. 348 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 349 transmission and MUST be ignored on receipt. 351 o Preference: a 4-octet value. The highest value is preferred. 353 The Preference is used by the the receiver in order to apply a 354 selection rule among different SR paths of the same SR Policy. SR 355 Policies may be originated and advertised through multiple means and 356 protocols (not limited to BGP) therefore, the preference value is 357 opaque to BGP and MUST NOT influence in any way the selection or the 358 propagation of the BGP update. 359 [I-D.filsfils-spring-segment-routing-policy] defines the use of the 360 Preference value. 362 2.4.2. SR TE Binding SID Sub-TLV 364 The Binding SID sub-TLV specifies the BSID of the path. 366 The Binding SID sub-TLV is optional, MAY appear only once in the SR 367 Policy and has the following format: 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Type | Length | Flags | RESERVED | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Binding SID (variable, optional) | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 where: 379 o Type: TBD4 (to be assigned by IANA from the "BGP Tunnel 380 Encapsulation Attribute sub-TLVs" registry). 382 o Length: specifies the length of the value field not including Type 383 and Length fields. Can be 2 or 6 or 18. 385 o Flags: 1 octet of flags. None is defined at this stage. Flags 386 SHOULD be unset on transmission and MUST be ignored on receipt. 388 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 389 transmission and MUST be ignored on receipt. 391 o Binding SID: if length is 2, then no Binding SID is present. If 392 length is 6 then the Binding SID contains a 4-octet SID. If 393 length is 18 then the Binding SID contains a 16-octet IPv6 SID. 395 The Binding SID sub-TLV specifies the BSID of the path. 397 When a controller is used in order to define and advertise SR 398 Policies and when the Binding SID is allocated by the receiver, such 399 Binding SID SHOULD be reported to the controller. The mechanisms 400 and/or APIs used for the reporting of the Binding SID are outside the 401 scope of this document. 403 The Binding SID concept is defined in 404 [I-D.ietf-spring-segment-routing] and its use in the context of SR 405 Policies is defined in [I-D.filsfils-spring-segment-routing-policy]. 407 2.4.3. Segment List Sub-TLV 409 The Segment List sub-TLV is used in order to encode a single explicit 410 path towards the endpoint. The Segment List sub-TLV includes the 411 elements of the paths (i.e.: segments) as well as an optional Weight 412 TLV. 414 The Segment List sub-TLV may exceed 255 bytes length due to large 415 number of segments. Therefore a 2-octet length is required. 416 According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- 417 TLV codepoint defines the size of the length field. Therefore, for 418 the Segment List sub-TLV a code point of 128 (or higher) is used. 419 See Section 7 section for details of codepoints allocation. 421 The Segment List sub-TLV is mandatory, MAY appear multiple times in 422 the SR Policy and has the following format: 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type | Length | RESERVED | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 // sub-TLVs // 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 where: 434 o Type: TBD5 (to be assigned by IANA from the "BGP Tunnel 435 Encapsulation Attribute sub-TLVs" registry). 437 o Length: the total length (not including the Type and Length 438 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 440 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 441 transmission and MUST be ignored on receipt. 443 o sub-TLVs: 445 * An optional single Weight sub-TLV. 447 * One or more Segment sub-TLVs. 449 The Segment List sub-TLV is mandatory. 451 Multiple occurrences of the Segment List sub-TLV MAY appear in the SR 452 Policy. 454 When multiple occurrences of the Segment List sub-TLV appear in the 455 SR Policy, the traffic is load-balanced across them either through an 456 ECMP scheme (if no Weight sub-TLV is present) or through a weighted 457 ECMP scheme according to Section 2.4.3.1. 459 The Segment-List Sub-TLV MUST contain at least one Segment Sub-TLV 460 and MAY contain a Weight Sub-TLV. 462 2.4.3.1. Weight Sub-TLV 464 The Weight sub-TLV specifies the weight associated to a given path 465 (i.e.: a given segment list). The weight is used in order to apply 466 weighted ECMP mechanism when steering traffic into a policy that 467 includes multiple Segment Lists sub-TLVs (i.e.: multiple explicit 468 paths). The use of the weight for ECMP purposes is described in 469 [I-D.filsfils-spring-segment-routing-policy]. 471 The Weight sub-TLV is optional, MAY only appear once inside the 472 Segment List sub-TLV, and has the following format: 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Type | Length | Flags | RESERVED | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Weight | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 where: 484 Type: 9 (to be assigned by IANA from the registry "SR Policy List 485 Sub-TLVs" defined in this document). 487 Length: 6. 489 Flags: 1 octet of flags. None is defined at this stage. Flags 490 SHOULD be unset on transmission and MUST be ignored on receipt. 492 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 493 and MUST be ignored on receipt. 495 The use of the Weight sub-TLV is specified in 496 [I-D.filsfils-spring-segment-routing-policy]. It is important to 497 note that the Weight has no meaning for the BGP speaker and MUST be 498 considered as an opaque information. 500 2.4.3.2. Segment Sub-TLV 502 The Segment sub-TLV describes a single segment in a segment list 503 (i.e.: a single element of the explicit path). Multiple Segment sub- 504 TLVs constitute an explicit path of the SR Policy. 506 The Segment sub-TLV is mandatory and MAY appear multiple times in the 507 Segment List sub-TLV. 509 [I-D.filsfils-spring-segment-routing-policy] defines several types of 510 Segment Sub-TLVs: 512 Type 1: SID only, in the form of MPLS Label 513 Type 2: SID only, in the form of IPv6 address 514 Type 3: IPv4 Node Address with optional SID 515 Type 4: IPv6 Node Address with optional SID 516 Type 5: IPv4 Address + index with optional SID 517 Type 6: IPv4 Local and Remote addresses with optional SID 518 Type 7: IPv6 Address + index with optional SID 519 Type 8: IPv6 Local and Remote addresses with optional SID 521 2.4.3.2.1. Type 1: SID only, in the form of MPLS Label 523 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 524 MPLS label. The format is as follows: 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Type | Length | Flags | RESERVED | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Label | TC |S| TTL | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 where: 536 o Type: 1 (to be assigned by IANA from the registry "SR Policy List 537 Sub-TLVs" defined in this document). 539 o Length is 6. 541 o Flags: 1 octet of flags. None is defined at this stage. Flags 542 SHOULD be unset on transmission and MUST be ignored on receipt. 544 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 545 transmission and MUST be ignored on receipt. 547 o Label: 20 bits of label value. 549 o TC: 3 bits of traffic class. 551 o S: 1 bit of bottom-of-stack. 553 o TTL: 1 octet of TTL. 555 The following applies to the Type-1 Segment sub-TLV: 557 o The S bit SHOULD be zero upon transmission, and MUST be ignored 558 upon reception. 560 o If the originator wants the receiver to choose the TC value, it 561 sets the TC field to zero. 563 o If the originator wants the receiver to choose the TTL value, it 564 sets the TTL field to 255. 566 o If the originator wants to recommend a value for these fields, it 567 puts those values in the TC and/or TTL fields. 569 o The receiver MAY override the originator's values for these 570 fields. This would be determined by local policy at the receiver. 571 One possible policy would be to override the fields only if the 572 fields have the default values specified above. 574 2.4.3.2.2. Type 2: SID only, in the form of IPv6 address 576 The Type-2 Segment Sub-TLV encodes a single SID in the form of an 577 IPv6 SID. The format is as follows: 579 0 1 2 3 580 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 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Type | Length | Flags | RESERVED | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 // IPv6 SID (16 octets) // 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 where: 589 o Type: 2 (to be assigned by IANA from the registry "SR Policy List 590 Sub-TLVs" defined in this document). 592 o Length is 18. 594 o Flags: 1 octet of flags. None is defined at this stage. Flags 595 SHOULD be unset on transmission and MUST be ignored on receipt. 597 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 598 transmission and MUST be ignored on receipt. 600 o IPv6 SID: 16 octets of IPv6 address. 602 The IPv6 Segment Identifier (IPv6 SID) is defined in 603 [I-D.ietf-6man-segment-routing-header]. 605 2.4.3.2.3. Type 3: IPv4 Node Address with optional SID 607 The Type-3 Segment Sub-TLV encodes an IPv4 node address and an 608 optional SID in the form of either an MPLS label or an IPv6 address. 609 The format is as follows: 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Type | Length | Flags | RESERVED | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | IPv4 Node Address (4 octets) | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 // SID (optional, 4 or 16 octets) // 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 where: 623 o Type: 3 (to be assigned by IANA from the registry "SR Policy List 624 Sub-TLVs" defined in this document). 626 o Length is 6 or 10 or 22. 628 o Flags: 1 octet of flags. None is defined at this stage. Flags 629 SHOULD be unset on transmission and MUST be ignored on receipt. 631 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 632 transmission and MUST be ignored on receipt. 634 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 636 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 638 The following applies to the Type-3 Segment sub-TLV: 640 o The IPv4 Node Address MUST be present. 642 o The SID is optional and MAY be of one of the following formats: 644 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 645 defined in Section 2.4.3.2.1. 647 * IPV6 SID: a 16 octet IPv6 address. 649 o If length is 6, then only the IPv4 Node Address is present. 651 o If length is 10, then the IPv4 Node Address and the MPLS SID are 652 present. 654 o If length is 22, then the IPv4 Node Address and the IPv6 SID are 655 present. 657 2.4.3.2.4. Type 4: IPv6 Node Address with optional SID 659 The Type-4 Segment Sub-TLV encodes an IPv6 node address and an 660 optional SID in the form of either an MPLS label or an IPv6 address. 661 The format is as follows: 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Type | Length | Flags | RESERVED | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 // IPv6 Node Address (16 octets) // 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 // SID (optional, 4 or 16 octets) // 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 where: 675 o Type: 4 (to be assigned by IANA from the registry "SR Policy List 676 Sub-TLVs" defined in this document). 678 o Length is 18 or 22 or 34. 680 o Flags: 1 octet of flags. None is defined at this stage. Flags 681 SHOULD be unset on transmission and MUST be ignored on receipt. 683 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 684 transmission and MUST be ignored on receipt. 686 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 688 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 690 The following applies to the Type-4 Segment sub-TLV: 692 o The IPv6 Node Address MUST be present. 694 o The SID is optional and MAY be of one of the following formats: 696 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 697 defined in Section 2.4.3.2.1. 699 * IPV6 SID: a 16 octet IPv6 address. 701 o If length is 18, then only the IPv6 Node Address is present. 703 o If length is 22, then the IPv6 Node Address and the MPLS SID are 704 present. 706 o If length is 34, then the IPv6 Node Address and the IPv6 SID are 707 present. 709 2.4.3.2.5. Type 5: IPv4 Address + index with optional SID 711 The Type-5 Segment Sub-TLV encodes an IPv4 node address, an interface 712 index (IfIndex) and an optional SID in the form of either an MPLS 713 label or an IPv6 address. The format is as follows: 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Type | Length | Flags | RESERVED | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | IfIndex (4 octets) | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | IPv4 Node Address (4 octets) | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 // SID (optional, 4 or 16 octets) // 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 where: 729 o Type: 5 (to be assigned by IANA from the registry "SR Policy List 730 Sub-TLVs" defined in this document). 732 o Length is 10 or 14 or 26. 734 o Flags: 1 octet of flags. None is defined at this stage. Flags 735 SHOULD be unset on transmission and MUST be ignored on receipt. 737 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 738 transmission and MUST be ignored on receipt. 740 o IfIndex: 4 octets of interface index. 742 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 744 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 746 The following applies to the Type-5 Segment sub-TLV: 748 o The IPv4 Node Address MUST be present. 750 o The Interface Index (IfIndex) MUST be present. 752 o The SID is optional and MAY be of one of the following formats: 754 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 755 defined in Section 2.4.3.2.1. 757 * IPV6 SID: a 16 octet IPv6 SID. 759 o If length is 10, then the IPv4 Node Address and IfIndex are 760 present. 762 o If length is 14, then the IPv4 Node Address, the IfIndex and the 763 MPLS SID are present. 765 o If length is 26, then the IPv4 Node Address, the IfIndex and the 766 IPv6 SID are present. 768 2.4.3.2.6. Type 6: IPv4 Local and Remote addresses with optional SID 770 The Type-6 Segment Sub-TLV encodes an IPv4 node address, an adjacency 771 local address, an adjacency remote address and an optional SID in the 772 form of either an MPLS label or an IPv6 address. The format is as 773 follows: 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Type | Length | Flags | RESERVED | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Local IPv4 Address (4 octets) | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Remote IPv4 Address (4 octets) | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 // SID (4 or 16 octets) // 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 where: 789 o Type: 6 (to be assigned by IANA from the registry "SR Policy List 790 Sub-TLVs" defined in this document). 792 o Length is 10 or 14 or 26. 794 o Flags: 1 octet of flags. None is defined at this stage. Flags 795 SHOULD be unset on transmission and MUST be ignored on receipt. 797 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 798 transmission and MUST be ignored on receipt. 800 o Local IPv4 Address: a 4 octet IPv4 address. 802 o Remote IPv4 Address: a 4 octet IPv4 address. 804 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 806 The following applies to the Type-6 Segment sub-TLV: 808 o The Local IPv4 Address MUST be present and represents an adjacency 809 local address. 811 o The Remote IPv4 Address MUST be present and represents the remote 812 end of the adjacency. 814 o The SID is optional and MAY be of one of the following formats: 816 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 817 defined in Section 2.4.3.2.1. 819 * IPV6 SID: a 16 octet IPv6 address. 821 o If length is 10, then only the IPv4 Local and Remote addresses are 822 present. 824 o If length is 14, then the IPv4 Local address, IPv4 Remote address 825 and the MPLS SID are present. 827 o If length is 26, then the IPv4 Local address, IPv4 Remote address 828 and the IPv6 SID are present. 830 2.4.3.2.7. Type 7: IPv6 Address + index with optional SID 832 The Type-7 Segment Sub-TLV encodes an IPv6 node address, an interface 833 index and an optional SID in the form of either an MPLS label or an 834 IPv6 address. The format is as follows: 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Type | Length | Flags | RESERVED | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | IfIndex (4 octets) | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 // IPv6 Node Address (16 octets) // 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 // SID (optional, 4 or 16 octets) // 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 where: 850 o Type: 7 (to be assigned by IANA from the registry "SR Policy List 851 Sub-TLVs" defined in this document). 853 o Length is 22 or 26 or 38. 855 o Flags: 1 octet of flags. None is defined at this stage. Flags 856 SHOULD be unset on transmission and MUST be ignored on receipt. 858 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 859 transmission and MUST be ignored on receipt. 861 o IfIndex: 4 octets of interface index. 863 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 865 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 867 The following applies to the Type-7 Segment sub-TLV: 869 o The IPv6 Node Address MUST be present. 871 o The Interface Index MUST be present. 873 o The SID is optional and MAY be of one of the following formats: 875 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 876 defined in Section 2.4.3.2.1. 878 * IPV6 SID: a 16 octet IPv6 address. 880 o If length is 22, then the IPv6 Node Address and IfIndex are 881 present. 883 o If length is 26, then the IPv6 Node Address, the IfIndex and the 884 MPLS SID are present. 886 o If length is 38, then the IPv6 Node Address, the IfIndex and the 887 IPv6 SID are present. 889 2.4.3.2.8. Type 8: IPv6 Local and Remote addresses with optional SID 891 The Type-8 Segment Sub-TLV encodes an IPv6 node address, an adjacency 892 local address, an adjacency remote address and an optional SID in the 893 form of either an MPLS label or an IPv6 address. The format is as 894 follows: 896 0 1 2 3 897 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 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Type | Length | Flags | RESERVED | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 // Local IPv6 Address (16 octets) // 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 // Remote IPv6 Address (16 octets) // 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 // SID (4 or 16 octets) // 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 where: 910 o Type: 8 (to be assigned by IANA from the registry "SR Policy List 911 Sub-TLVs" defined in this document). 913 o Length is 34 or 38 or 50. 915 o Flags: 1 octet of flags. None is defined at this stage. Flags 916 SHOULD be unset on transmission and MUST be ignored on receipt. 918 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 919 transmission and MUST be ignored on receipt. 921 o Local IPv6 Address: a 16 octet IPv6 address. 923 o Remote IPv6 Address: a 16 octet IPv6 address. 925 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 927 The following applies to the Type-8 Segment sub-TLV: 929 o The Local IPv6 Address MUST be present and represents an adjacency 930 local address. 932 o The Remote IPv6 Address MUST be present and represents the remote 933 end of the adjacency. 935 o The SID is optional and MAY be of one of the following formats: 937 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 938 defined in Section 2.4.3.2.1. 940 * IPV6 SID: a 16 octet IPv6 address. 942 o If length is 34, then only the IPv6 Local and Remote addresses are 943 present. 945 o If length is 38, then the IPv6 Local address, IPv4 Remote address 946 and the MPLS SID are present. 948 o If length is 50, then the IPv6 Local address, IPv4 Remote address 949 and the IPv6 SID are present. 951 3. Extended Color Community 953 The Extended Color Community as defined in 954 [I-D.ietf-idr-tunnel-encaps] is used in order to steer traffic into a 955 policy. This document applies the following changes to the Extended 956 Color Community attribute. 958 The RESERVED field is changed as follows: 960 1 961 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 |C O| RESERVED | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 where CO bits are defined as the "Color-Only" bits. The settings and 967 use of these bits are defined in Section 4.3. 969 4. SR Policy Operations 971 4.1. Configuration and Advertisement of SR TE Policies 973 Typically, but not limited to, a SR Policy is configured into a 974 controller and on the base of each receiver. In other words, each SR 975 Policy configured is related to the intended receiver. It is 976 therefore normal for a given SR Policy to have 977 multiple SR paths with different content where each of these SR paths 978 (of the same policy) is intended to be sent to different receivers. 980 When advertised in BGP, each SR path of the same SR Policy will have 981 a different Distinguisher in order to prevent BGP selection among 982 these SR paths along the distribution of BGP updates. 984 Moreover, a Route-Target extended community SHOULD be attached to the 985 SR Policy and that identifies the intended receiver of the 986 advertisement. 988 If no route-target is attached to the SR Policy NLRI, then it is 989 assumed that the originator sends the SR Policy update directly 990 (e.g.: through iBGP multihop) to the intended receiver. In such 991 case, the NO_ADVERTISE community MUST be attached to the SR Policy 992 update. 994 If no route-target is attached to the SR Policy NLRI, then it is 995 assumed that the originator sends the SR Policy update directly 996 (e.g.: through iBGP multihop) to the intended receiver. In such 997 case, the NO_ADVERTISE community MUST be attached to the SR Policy 998 update. 1000 4.2. Reception of an SR Policy 1002 On reception of a SR Policy, a BGP speaker MUST determine if the SR 1003 Policy is first acceptable, then usable. 1005 While only usable SR Policies are instantiated, acceptable SR 1006 Policies (i.e.: also the non-usable ones) MAY be propagated. 1008 Any SR Policy update that has been determined acceptable is kept in 1009 the BGP database. This includes non-usable SR Policies. 1011 4.2.1. Acceptance of a SR Policy Update 1013 When a BGP speaker receives an SR Policy from a neighbor it has to 1014 determine if the SR Policy advertisement is acceptable. The 1015 following applies: 1017 o The SR Policy NLRI MUST have a color value. 1019 o The SR Policy NLRI MUST have either an IPv4 endpoint address or an 1020 IPv6 endpoint address or a zero-value (either IPv4 or IPv6 1021 format). 1023 o The SR Policy NLRI MUST have distinguisher field. 1025 o The SR Policy update MUST have either the NO_ADV community or at 1026 least one route-target extended community in IPv4-address format. 1028 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1029 Update and MUST have the Tunnel Type set to SR Policy (value to be 1030 assigned by IANA). 1032 o Within the SR Policy, at least one Segment List sub-TLV MUST be 1033 present. 1035 o Within the Segment List sub-TLV at least one Segment sub-TLV MUST 1036 be present. 1038 The use of an endpoint address with a zero-value is described in 1039 Section 4.3. 1041 The Remote Endpoint and Color sub-TLVs, as defined in 1042 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy 1043 encodings. If present, the Remote Endpoint sub-TLV MUST match the 1044 Endpoint of the SR Policy SAFI NLRI. If they don't match, the SR 1045 Policy advertisement MUST be considered as not acceptable. If 1046 present, the Color sub-TLV MUST match the Policy Color of the SR 1047 Policy SAFI NLRI. If they don't match, the SR Policy advertisement 1048 MUST be considered as not acceptable. 1050 A non-acceptable SR Policy update that has a valid NLRI portion with 1051 invalid attribute portion MUST be considered as a withdraw of the SR 1052 Policy. 1054 A non-acceptable SR Policy update that has an invalid NLRI portion 1055 MUST trigger a reset of the BGP session. 1057 The receiver MUST check whether route-target or NO_ADVERTISE 1058 communities are attached to it. If no route-target is present and 1059 the NO_ADVERTISE community is present, then the SR Policy is usable. 1061 If one or more route-targets are present, then at least one route- 1062 target MUST match the BGP Identifier (BGP Router-ID) of the receiver 1063 in order for the update to be considered usable. The BGP Identifier 1064 is defined in [RFC4271] as a 4 octet IPv4 address. Therefore the 1065 route-target extended community MUST be of the same format. 1067 If one or more route-targets are present and no one matches the local 1068 BGP router-ID, then, while the SR Policy is acceptable, the SR Policy 1069 is not usable. It has to be noted that if the receiver has been 1070 explicitly configured to do so, it MAY propagate the SR Policy to its 1071 neighbors as defined in Section 4.2.3. 1073 4.2.2. Passing an acceptable path to an SR Policy 1075 Once BGP has determined that the path is acceptable, BGP passes the 1076 path to the SR Policy. 1078 The SR Policy applies the rules defined in 1079 [I-D.filsfils-spring-segment-routing-policy] to determine whether a 1080 path is valid and to select the best path among the valid paths. 1082 4.2.3. Propagation of an SR Policy 1084 By default, a BGP node receiving an SR Policy MUST NOT not propagate 1085 it to any eBGP neighbor. 1087 However, a node MAY be explicitly configured in order to advertise a 1088 received SR Policy update to neighbors according to normal BGP rules 1089 (iBGP and eBGP propagation), e.g., in the case the node is a Route- 1090 Reflector. 1092 SR Policies that have been determined acceptable and valid can be 1093 propagated, even the ones that are not usable. 1095 Only SR Policies that do not have the NO_ADVERTISE community attached 1096 to them can be propagated. 1098 4.3. Steering Traffic into a SR Policy 1100 The steering of a BGP route onto an SR Policy is defined in 1101 [I-D.filsfils-spring-segment-routing-policy]. 1103 4.4. Flowspec and SR Policies 1105 The SR Policy can be carried in context of a Flowspec NLRI 1106 ([RFC5575]). In this case, when the redirect to IP next-hop is 1107 specified as in [I-D.ietf-idr-flowspec-redirect-ip], the tunnel to 1108 the next-hop is specified by the segment list in the Segment List 1109 sub-TLVs. The Segment List (e.g..: label stack or IPv6 segment list) 1110 is imposed to flows matching the criteria in the Flowspec route in 1111 order to steer them towards the next-hop as specified in the SR 1112 Policy SAFI NLRI. 1114 5. Acknowledgments 1116 The authors of this document would like to thank Dhanendra Jain, 1117 Shyam Sethuram, Acee Lindem, Imtiyaz Mohammad and John Scudder for 1118 their comments and review of this document. 1120 6. Implementation Status 1122 Note to RFC Editor: Please remove this section prior to publication, 1123 as well as the reference to RFC 7942. 1125 This section records the status of known implementations of the 1126 protocol defined by this specification at the time of posting of this 1127 Internet-Draft, and is based on a proposal described in [RFC7942]. 1128 The description of implementations in this section is intended to 1129 assist the IETF in its decision processes in progressing drafts to 1130 RFCs. Please note that the listing of any individual implementation 1131 here does not imply endorsement by the IETF. Furthermore, no effort 1132 has been spent to verify the information presented here that was 1133 supplied by IETF contributors. This is not intended as, and must not 1134 be construed to be, a catalog of available implementations or their 1135 features. Readers are advised to note that other implementations may 1136 exist. 1138 According to [RFC7942], "this will allow reviewers and working groups 1139 to assign due consideration to documents that have the benefit of 1140 running code, which may serve as evidence of valuable experimentation 1141 and feedback that have made the implemented protocols more mature. 1142 It is up to the individual working groups to use this information as 1143 they see fit". 1145 Several early implementations exist and will be reported in detail in 1146 a forthcoming version of this document. For purposes of early 1147 interoperability testing, when no FCFS code point was available, 1148 implementations have made use of the following values: 1150 o Preference sub-TLV: 6 1152 o Binding SID sub-TLV: 7 1154 o Segment List sub-TLV: 128 1156 When IANA-assigned values are available, implementations will be 1157 updated to use them. 1159 7. IANA Considerations 1161 This document defines new Sub-TLVs in following existing registries: 1163 o Subsequent Address Family Identifiers (SAFI) Parameters 1165 o BGP Tunnel Encapsulation Attribute Tunnel Types 1167 o BGP Tunnel Encapsulation Attribute sub-TLVs 1169 This document also defines a new registry: "SR Policy List Sub-TLVs". 1171 7.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1172 Parameters 1174 This document defines a new SAFI in the registry "Subsequent Address 1175 Family Identifiers (SAFI) Parameters": 1177 Codepoint Description Reference 1178 ----------------------------------------------- 1179 TBD1 SR Policy SAFI This document 1181 7.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1183 This document defines a new Tunnel-Type in the registry "BGP Tunnel 1184 Encapsulation Attribute Tunnel Types": 1186 Codepoint Description Reference 1187 -------------------------------------------------- 1188 TBD2 SR Policy Type This document 1190 7.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1192 This document defines new sub-TLVs in the registry "BGP Tunnel 1193 Encapsulation Attribute sub-TLVs": 1195 Codepoint Description Reference 1196 ------------------------------------------------------ 1197 TBD3 Preference sub-TLV This document 1198 TBD4 Binding SID sub-TLV This document 1199 TBD5 Segment List sub-TLV This document 1201 7.4. New Registry: SR Policy List Sub-TLVs 1203 This document defines a new registry called "SR Policy List Sub- 1204 TLVs". The allocation policy of this registry is "First Come First 1205 Served (FCFS)" according to [RFC5226]. 1207 Following Sub-TLV codepoints are defined: 1209 Value Description Reference 1210 ------------------------------------------------------------------ 1211 1 MPLS SID sub-TLV This document 1212 2 IPv6 SID sub-TLV This document 1213 3 IPv4 Node and SID sub-TLV This document 1214 4 IPv6 Node and SID sub-TLV This document 1215 5 IPv4 Node, index and SID sub-TLV This document 1216 6 IPv4 Local/Remote addresses and SID sub-TLV This document 1217 7 IPv6 Node, index and SID sub-TLV This document 1218 8 IPv6 Local/Remote addresses and SID sub-TLV This document 1219 9 Weight sub-TLV This document 1221 8. Security Considerations 1223 TBD. 1225 9. References 1227 9.1. Normative References 1229 [I-D.ietf-idr-tunnel-encaps] 1230 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 1231 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-03 1232 (work in progress), November 2016. 1234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1235 Requirement Levels", BCP 14, RFC 2119, 1236 DOI 10.17487/RFC2119, March 1997, 1237 . 1239 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1240 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1241 DOI 10.17487/RFC4271, January 2006, 1242 . 1244 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1245 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1246 February 2006, . 1248 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1249 "Multiprotocol Extensions for BGP-4", RFC 4760, 1250 DOI 10.17487/RFC4760, January 2007, 1251 . 1253 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1254 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1255 DOI 10.17487/RFC5226, May 2008, 1256 . 1258 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1259 and D. McPherson, "Dissemination of Flow Specification 1260 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1261 . 1263 9.2. Informational References 1265 [I-D.filsfils-spring-segment-routing-policy] 1266 Filsfils, C., Sivabalan, S., Yoyer, D., Nanduri, M., Lin, 1267 S., bogdanov@google.com, b., Horneffer, M., Clad, F., 1268 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 1269 Routing Policy for Traffic Engineering", draft-filsfils- 1270 spring-segment-routing-policy-00 (work in progress), 1271 February 2017. 1273 [I-D.ietf-6man-segment-routing-header] 1274 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 1275 J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, 1276 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1277 segment-routing-header-05 (work in progress), February 1278 2017. 1280 [I-D.ietf-idr-flowspec-redirect-ip] 1281 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 1282 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 1283 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 1284 in progress), February 2015. 1286 [I-D.ietf-spring-segment-routing] 1287 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1288 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1289 spring-segment-routing-11 (work in progress), February 1290 2017. 1292 [I-D.ietf-spring-segment-routing-mpls] 1293 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1294 Litkowski, S., Horneffer, M., Shakir, R., 1295 jefftant@gmail.com, j., and E. Crabbe, "Segment Routing 1296 with MPLS data plane", draft-ietf-spring-segment-routing- 1297 mpls-07 (work in progress), February 2017. 1299 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1300 Reflection: An Alternative to Full Mesh Internal BGP 1301 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1302 . 1304 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1305 Code: The Implementation Status Section", BCP 205, 1306 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1307 . 1309 Authors' Addresses 1311 Stefano Previdi (editor) 1312 Cisco Systems, Inc. 1313 Via Del Serafico, 200 1314 Rome 00142 1315 Italy 1317 Email: sprevidi@cisco.com 1319 Clarence Filsfils 1320 Cisco Systems, Inc. 1321 Brussels 1322 BE 1324 Email: cfilsfil@cisco.com 1326 Arjun Sreekantiah 1327 Cisco Systems, Inc. 1328 170 W. Tasman Drive 1329 San Jose, CA 95134 1330 USA 1332 Email: asreekan@cisco.com 1334 Siva Sivabalan 1335 Cisco Systems, Inc. 1336 170 W. Tasman Drive 1337 San Jose, CA 95134 1338 USA 1340 Email: msiva@cisco.com 1342 Paul Mattes 1343 Microsoft 1344 One Microsoft Way 1345 Redmond, WA 98052 1346 USA 1348 Email: pamattes@microsoft.com 1349 Eric Rosen 1350 Juniper Networks 1351 10 Technology Park Drive 1352 Westford, MA 01886 1353 US 1355 Email: erosen@juniper.net 1357 Steven Lin 1358 Google 1360 Email: stevenlin@google.com