idnits 2.17.1 draft-previdi-idr-segment-routing-te-policy-06.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 (June 15, 2017) is 2506 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-06 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-09 ** 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-06 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 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 Cisco Systems, Inc. 5 Expires: December 17, 2017 P. Mattes 6 Microsoft 7 E. Rosen 8 Juniper Networks 9 S. Lin 10 Google 11 June 15, 2017 13 Advertising Segment Routing Policies in BGP 14 draft-previdi-idr-segment-routing-te-policy-06 16 Abstract 18 This document defines a new BGP SAFI with a new NLRI in order to 19 advertise a candidate path of a Segment Routing Policy (SR Policy). 20 An SR Policy is a set of candidate paths consisting of one or more 21 segment lists. The headend of an SR Policy may learn multiple 22 candidate paths for an SR Policy. Candidate paths may be learned via 23 a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. 24 This document specifies the way in which BGP may be used to 25 distribute candidate paths. New sub-TLVs for the Tunnel 26 Encapsulation Attribute are defined. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 17, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 64 2. SR TE Policy Encoding . . . . . . . . . . . . . . . . . . . . 5 65 2.1. SR TE Policy SAFI and NLRI . . . . . . . . . . . . . . . 5 66 2.2. SR TE Policy and Tunnel Encapsulation Attribute . . . . . 7 67 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 68 2.4. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . . . 8 69 2.4.1. Preference sub-TLV . . . . . . . . . . . . . . . . . 8 70 2.4.2. SR TE Binding SID Sub-TLV . . . . . . . . . . . . . . 9 71 2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 10 72 3. Extended Color Community . . . . . . . . . . . . . . . . . . 21 73 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 21 74 4.1. Configuration and Advertisement of SR TE Policies . . . . 22 75 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 22 76 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 22 77 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 23 78 4.2.3. Passing a usable SR Policy NLRI to the SRTE Process . 24 79 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 24 80 4.3. Flowspec and SR Policies . . . . . . . . . . . . . . . . 24 81 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 82 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 83 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 85 8.1. Existing Registry: Subsequent Address Family Identifiers 86 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 26 87 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute 88 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 26 89 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute 90 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 27 91 8.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 27 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 95 10.2. Informational References . . . . . . . . . . . . . . . . 28 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 98 1. Introduction 100 Segment Routing (SR) allows a headend node to steer a packet flow 101 along any path. Intermediate per-flow states are eliminated thanks 102 to source routing [I-D.ietf-spring-segment-routing]. 104 The headend node is said to steer a flow into an Segment Routing 105 Policy (SR Policy). 107 The header of a packet steered in an SR Policy is augmented with the 108 ordered list of segments associated with that SR Policy. 110 [I-D.filsfils-spring-segment-routing-policy] details the concepts of 111 SR Policy and steering into an SR Policy. These apply equally to the 112 MPLS and SRv6 instantiations of segment routing. 114 As highlighted in section 2 of 115 [I-D.filsfils-spring-segment-routing-policy]: 117 o an SR policy may have multiple candidate paths learned via various 118 mechanisms (CLI, NetConf, PCEP or BGP); 120 o the SRTE process selects the best candidate path for a Policy; 122 o the SRTE process binds a BSID to the selected path of the Policy; 124 o the SRTE process installs the selected path and its BSID in the 125 forwarding plane. 127 This document specifies the way to use BGP to distribute one or more 128 of the candidate paths of an SR policy to the headend of that policy. 129 The SRTE process ([I-D.filsfils-spring-segment-routing-policy]) of 130 the headend receives candidate paths from BGP, and possibly other 131 sources as well, and the SRTE process then determines the selected 132 path of the policy. 134 This document specifies a way of representing SR policies and their 135 candidate paths in BGP UPDATE messages. BGP can then be used to 136 propagate the SR policies and candidate paths. The usual BGP rules 137 for BGP propagation and "bestpath selection" are used. At the 138 headend of a specific policy, this will result in one or more 139 candidate paths being installed into the "BGP table". These paths 140 are then passed to the SRTE process. The SRTE process may compare 141 them to candidate paths learned via other mechanisms, and will choose 142 one or more paths to be installed in the data plane. BGP itself does 143 not install SRTE candidate paths into the data plane. 145 This document defines a new BGP address family (SAFI). In UPDATE 146 messages of that address family, the NLRI identifies an SR policy, 147 and the attributes specify candidate paths of that policy. 149 While for simplicity we may write that BGP advertises an SR Policy, 150 it has to be understood that BGP advertises a candidate path of an SR 151 policy and that this SR Policy might have several other candidate 152 paths provided via BGP (via an NLRI with a different distinguisher as 153 defined in this document), PCEP, NETCONF or local policy 154 configuration. 156 Typically, a controller defines the set of policies and advertise 157 them to policy head-end routers (typically ingress routers). The 158 policy advertisement uses BGP extensions defined in this document. 159 The policy advertisement is, in most but not all of the cases, 160 tailored for a specific policy head-end. In this case the 161 advertisement may sent on a BGP session to that head-end and not 162 propagated any further. 164 Alternatively, a router (i.e.: an BGP egress router) advertises SR 165 Policies representing paths to itself. In this case, it is possible 166 to send the policy to each head-end over a BGP session to that head- 167 end, without requiring any further propagation of the policy. 169 An SR Policy intended only for the receiver will, in most cases, not 170 traverse any Route Reflector (RR, [RFC4456]). 172 In some situations, it is undesirable for a controller or BGP egress 173 router to have a BGP session to each policy head-end. In these 174 situations, BGP Route Reflectors may be used to propagate the 175 advertisements, or it may be necessary for the advertisement to 176 propagate through a sequence of one or more ASes. To make this 177 possible, an attribute needs to be attached to the advertisement that 178 enables a BGP speaker to determine whether it is intended to be a 179 head-end for the advertised policy. This is done by attaching one or 180 more Route Target Extended Communities to the advertisement 181 ([RFC4360]). 183 The BGP extensions for the advertisement of SR Policies include 184 following components: 186 o A new Subsequent Address Family Identifier (SAFI) whose NLRI 187 identifies an SR Policy. 189 o A set of new TLVs to be inserted into the Tunnel Encapsulation 190 Attribute (as defined in [I-D.ietf-idr-tunnel-encaps]) specifying 191 candidate paths of the SR policy, as well as other information 192 about the SR policy. 194 o One or more IPv4 address format route-target extended community 195 ([RFC4360]) attached to the SR Policy advertisement and that 196 indicates the intended head-end of such SR Policy advertisement. 198 o The Color Extended Community (as defined in 199 [I-D.ietf-idr-tunnel-encaps]) and used in order to steer traffic 200 into an SR Policy, as described in 201 [I-D.filsfils-spring-segment-routing-policy]. This document 202 (Section 3) modifies the format of the Color Extended Community by 203 using the two leftmost bits of the RESERVED field. 205 1.1. Requirements Language 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119 [RFC2119]. 211 2. SR TE Policy Encoding 213 2.1. SR TE Policy SAFI and NLRI 215 A new SAFI is defined: the SR Policy SAFI, (codepoint 73 assigned by 216 IANA (see Section 8) from the "Subsequent Address Family Identifiers 217 (SAFI) Parameters" registry). 219 The SR Policy SAFI uses a new NLRI defined as follows: 221 +-----------------------------------------------+ 222 | Distinguisher (4 octets) | 223 +-----------------------------------------------+ 224 | Policy Color (4 octets) | 225 +-----------------------------------------------+ 226 | Endpoint (4 or 16 octets) | 227 +-----------------------------------------------+ 229 where: 231 o Distinguisher: 4-octet value uniquely identifying the policy in 232 the context of tuple. The distinguisher has no 233 semantic value and is solely used by the SR Policy originator to 234 make unique (from an NLRI perspective) multiple occurrences of the 235 same SR Policy. 237 o Policy Color: 4-octet value identifying (with the endpoint) the 238 policy. The color is used to match the color of the destination 239 prefixes to steer traffic into the SR Policy 240 [I-D.filsfils-spring-segment-routing-policy]. 242 o Endpoint: identifies the endpoint of a policy. The Endpoint may 243 represent a single node or a set of nodes (e.g., an anycast 244 address or a summary address). The Endpoint is an IPv4 (4-octet) 245 address or an IPv6 (16-octet) address according to the AFI of the 246 NLRI. 248 The color and endpoint are used to automate the steering of BGP 249 Payload prefixes on SR policy 250 ([I-D.filsfils-spring-segment-routing-policy]). 252 The NLRI containing the SR Policy is carried in a BGP UPDATE message 253 [RFC4271] using BGP multiprotocol extensions [RFC4760] with an AFI of 254 1 or 2 (IPv4 or IPv6) and with a SAFI of 73 (assigned by IANA from 255 the "Subsequent Address Family Identifiers (SAFI) Parameters" 256 registry). 258 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 259 attribute with the SR Policy SAFI MUST also carry the BGP mandatory 260 attributes. In addition, the BGP update message MAY also contain any 261 of the BGP optional attributes. 263 The next-hop of the SR Policy SAFI NLRI is set based on the AFI. For 264 example, if the AFI is set to IPv4 (1), then the next-hop is encoded 265 as a 4-byte IPv4 address. If the AFI is set to IPv6 (2), then the 266 next-hop is encoded as a 16-byte IPv6 address of the router. 268 It is important to note that any BGP speaker receiving a BGP message 269 with an SR Policy NLRI, will process it only if the NLRI is among the 270 best paths as per the BGP best path selection algorithm. In other 271 words, this document does not modify the BGP propagation or bestpath 272 selection rules. 274 It has to be noted that if several candidate paths of the same SR 275 Policy (endpoint, color) are signaled via BGP to a head-end, it is 276 recommended that each NLRI use a different distinguisher. If BGP has 277 installed into the BGP table two advertisements whose respective 278 NLRIs have the same color and endpoint, but different distinguishers, 279 both advertisements are passed to the SRTE process. 281 2.2. SR TE Policy and Tunnel Encapsulation Attribute 283 The content of the SR Policy is encoded in the Tunnel Encapsulation 284 Attribute originally defined in [I-D.ietf-idr-tunnel-encaps] using a 285 new Tunnel-Type TLV (codepoint is 15, assigned by IANA (see 286 Section 8) from the "BGP Tunnel Encapsulation Attribute Tunnel Types" 287 registry). 289 The SR Policy Encoding structure is as follows: 291 SR Policy SAFI NLRI: 292 Attributes: 293 Tunnel Encaps Attribute (23) 294 Tunnel Type: SR Policy 295 Binding SID 296 Preference 297 Segment List 298 Weight 299 Segment 300 Segment 301 ... 302 ... 303 where: 305 o SR Policy SAFI NLRI is defined in Section 2.1. 307 o Tunnel Encapsulation Attribute is defined in 308 [I-D.ietf-idr-tunnel-encaps]. 310 o Tunnel-Type is set to 15 (assigned by IANA from the "BGP Tunnel 311 Encapsulation Attribute Tunnel Types" registry). 313 o Preference, Binding SID, Segment-List, Weight and Segment are 314 defined in this document. 316 o Additional sub-TLVs may be defined in the future. 318 A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV 319 of type "SR Policy". 321 Multiple occurrences of "Segment List" MAY be encoded within the same 322 SR Policy. 324 Multiple occurrences of "Segment" MAY be encoded within the same 325 Segment List. 327 2.3. Remote Endpoint and Color 329 The Remote Endpoint and Color sub-TLVs, as defined in 330 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy 331 encodings. 333 If present, the Remote Endpoint sub-TLV MUST match the Endpoint of 334 the SR Policy SAFI NLRI. 336 If present, the Color sub-TLV MUST match the Policy Color of the SR 337 Policy SAFI NLRI. 339 2.4. SR TE Policy Sub-TLVs 341 This section defines the SR Policy sub-TLVs. 343 Preference, Binding SID, Segment-List are assigned from the "BGP 344 Tunnel Encapsulation Attribute sub-TLVs" registry. 346 Weight and Segment Sub-TLVs are assigned from a new registry defined 347 in this document and called: "SR Policy List Sub-TLVs". See 348 Section 8 for the details of the registry. 350 2.4.1. Preference sub-TLV 352 The Preference sub-TLV does not have any effect on the BGP bestpath 353 selection or propagation procedures. The contents of this sub-TLV 354 are used by the SRTE process 355 ([I-D.filsfils-spring-segment-routing-policy]). 357 The Preference sub-TLV is optional, MUST NOT appear more than once in 358 the SR Policy and has following format: 360 0 1 2 3 361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type | Length | Flags | RESERVED | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Preference (4 octets) | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 where: 370 o Type: TBD3 (to be assigned by IANA from the "BGP Tunnel 371 Encapsulation Attribute sub-TLVs" registry). 373 o Length: 6. 375 o Flags: 1 octet of flags. None are defined at this stage. Flags 376 SHOULD be set to zero on transmission and MUST be ignored on 377 receipt. 379 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 380 transmission and MUST be ignored on receipt. 382 o Preference: a 4-octet value. The highest value is preferred. 384 2.4.2. SR TE Binding SID Sub-TLV 386 The Binding SID sub-TLV is not used by BGP. The contents of this 387 sub-TLV are used by the SRTE process 388 ([I-D.filsfils-spring-segment-routing-policy]). 390 The Binding SID sub-TLV is optional, MUST NOT appear more than once 391 in the SR Policy and has the following format: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type | Length | Flags | RESERVED | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Binding SID (variable, optional) | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 where: 403 o Type: TBD4 (to be assigned by IANA from the "BGP Tunnel 404 Encapsulation Attribute sub-TLVs" registry). 406 o Length: specifies the length of the value field not including Type 407 and Length fields. Can be 2 or 6 or 18. 409 o Flags: 1 octet of flags. None are defined at this stage. Flags 410 SHOULD be set to zero on transmission and MUST be ignored on 411 receipt. 413 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 414 transmission and MUST be ignored on receipt. 416 o Binding SID: if length is 2, then no Binding SID is present. If 417 length is 6 then the Binding SID contains a 4-octet SID. If 418 length is 18 then the Binding SID contains a 16-octet IPv6 SID. 420 2.4.3. Segment List Sub-TLV 422 The Segment List TLV encodes a single explicit path towards the 423 endpoint. The Segment List sub-TLV includes the elements of the 424 paths (i.e.: segments) as well as an optional Weight TLV. 426 The Segment List sub-TLV may exceed 255 bytes length due to large 427 number of segments. Therefore a 2-octet length is required. 428 According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- 429 TLV codepoint defines the size of the length field. Therefore, for 430 the Segment List sub-TLV a code point of 128 (or higher) is used. 431 See Section 8 for details of codepoints allocation. 433 The Segment List sub-TLV is mandatory and MAY appear multiple times 434 in the SR Policy. 436 The Segment-List Sub-TLV MUST contain at least one Segment Sub-TLV 437 and MAY contain a Weight Sub-TLV. 439 The Segment List sub-TLV has the following format: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type | Length | RESERVED | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 // sub-TLVs // 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 where: 451 o Type: TBD5 (to be assigned by IANA from the "BGP Tunnel 452 Encapsulation Attribute sub-TLVs" registry). 454 o Length: the total length (not including the Type and Length 455 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 457 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 458 transmission and MUST be ignored on receipt. 460 o sub-TLVs: 462 * An optional single Weight sub-TLV. 464 * One or more Segment sub-TLVs. 466 2.4.3.1. Weight Sub-TLV 468 The Weight sub-TLV specifies the weight associated to a given 469 candidate path (i.e.: a given segment list). The contents of this 470 sub-TLV are used only by the SRTE process 471 ([I-D.filsfils-spring-segment-routing-policy]). 473 The Weight sub-TLV is optional, MUST NOT appear more than once inside 474 the Segment List sub-TLV, and has the following format: 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Type | Length | Flags | RESERVED | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Weight | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 where: 486 Type: 9 (to be assigned by IANA from the registry "SR Policy List 487 Sub-TLVs" defined in this document). 489 Length: 6. 491 Flags: 1 octet of flags. None are defined at this stage. Flags 492 SHOULD be set to zero on transmission and MUST be ignored on receipt. 494 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 495 and MUST be ignored on receipt. 497 2.4.3.2. Segment Sub-TLV 499 The Segment sub-TLV describes a single segment in a segment list 500 (i.e., a single element of the explicit path). Multiple Segment sub- 501 TLVs constitute an explicit path of the SR Policy. 503 The Segment sub-TLV is mandatory and MAY appear multiple times in the 504 Segment List sub-TLV. 506 The Segment sub-TLV does not have any effect on the BGP bestpath 507 selection or propagation procedures. The contents of this sub-TLV 508 are used only by the SRTE process 509 ([I-D.filsfils-spring-segment-routing-policy]). 511 [I-D.filsfils-spring-segment-routing-policy] defines several types of 512 Segment Sub-TLVs: 514 Type 1: SID only, in the form of MPLS Label 515 Type 2: SID only, in the form of IPv6 address 516 Type 3: IPv4 Node Address with optional SID 517 Type 4: IPv6 Node Address with optional SID 518 Type 5: IPv4 Address + index with optional SID 519 Type 6: IPv4 Local and Remote addresses with optional SID 520 Type 7: IPv6 Address + index with optional SID 521 Type 8: IPv6 Local and Remote addresses with optional SID 523 2.4.3.2.1. Type 1: SID only, in the form of MPLS Label 525 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 526 MPLS label. The format is as follows: 528 0 1 2 3 529 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Type | Length | Flags | RESERVED | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Label | TC |S| TTL | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 where: 538 o Type: 1 (to be assigned by IANA from the registry "SR Policy List 539 Sub-TLVs" defined in this document). 541 o Length is 6. 543 o Flags: 1 octet of flags. None are defined at this stage. Flags 544 SHOULD be set to zero on transmission and MUST be ignored on 545 receipt. 547 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 548 transmission and MUST be ignored on receipt. 550 o Label: 20 bits of label value. 552 o TC: 3 bits of traffic class. 554 o S: 1 bit of bottom-of-stack. 556 o TTL: 1 octet of TTL. 558 The following applies to the Type-1 Segment sub-TLV: 560 o The S bit SHOULD be zero upon transmission, and MUST be ignored 561 upon reception. 563 o If the originator wants the receiver to choose the TC value, it 564 sets the TC field to zero. 566 o If the originator wants the receiver to choose the TTL value, it 567 sets the TTL field to 255. 569 o If the originator wants to recommend a value for these fields, it 570 puts those values in the TC and/or TTL fields. 572 o The receiver MAY override the originator's values for these 573 fields. This would be determined by local policy at the receiver. 574 One possible policy would be to override the fields only if the 575 fields have the default values specified above. 577 2.4.3.2.2. Type 2: SID only, in the form of IPv6 address 579 The Type-2 Segment Sub-TLV encodes a single SID in the form of an 580 IPv6 SID. The format is as follows: 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Type | Length | Flags | RESERVED | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 // IPv6 SID (16 octets) // 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 where: 592 o Type: 2 (to be assigned by IANA from the registry "SR Policy List 593 Sub-TLVs" defined in this document). 595 o Length is 18. 597 o Flags: 1 octet of flags. None are defined at this stage. Flags 598 SHOULD be set to zero on transmission and MUST be ignored on 599 receipt. 601 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 602 transmission and MUST be ignored on receipt. 604 o IPv6 SID: 16 octets of IPv6 address. 606 The IPv6 Segment Identifier (IPv6 SID) is defined in 607 [I-D.ietf-6man-segment-routing-header]. 609 2.4.3.2.3. Type 3: IPv4 Node Address with optional SID 611 The Type-3 Segment Sub-TLV encodes an IPv4 node address and an 612 optional SID in the form of either an MPLS label or an IPv6 address. 613 The format is as follows: 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Type | Length | Flags | RESERVED | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | IPv4 Node Address (4 octets) | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 // SID (optional, 4 or 16 octets) // 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 where: 627 o Type: 3 (to be assigned by IANA from the registry "SR Policy List 628 Sub-TLVs" defined in this document). 630 o Length is 6 or 10 or 22. 632 o Flags: 1 octet of flags. None are defined at this stage. Flags 633 SHOULD be set to zero on transmission and MUST be ignored on 634 receipt. 636 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 637 transmission and MUST be ignored on receipt. 639 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 641 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 643 The following applies to the Type-3 Segment sub-TLV: 645 o The IPv4 Node Address MUST be present. 647 o The SID is optional and MAY be of one of the following formats: 649 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 650 defined in Section 2.4.3.2.1. 652 * IPV6 SID: a 16 octet IPv6 address. 654 o If length is 6, then only the IPv4 Node Address is present. 656 o If length is 10, then the IPv4 Node Address and the MPLS SID are 657 present. 659 o If length is 22, then the IPv4 Node Address and the IPv6 SID are 660 present. 662 2.4.3.2.4. Type 4: IPv6 Node Address with optional SID 664 The Type-4 Segment Sub-TLV encodes an IPv6 node address and an 665 optional SID in the form of either an MPLS label or an IPv6 address. 666 The format is as follows: 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Type | Length | Flags | RESERVED | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 // IPv6 Node Address (16 octets) // 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 // SID (optional, 4 or 16 octets) // 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 where: 680 o Type: 4 (to be assigned by IANA from the registry "SR Policy List 681 Sub-TLVs" defined in this document). 683 o Length is 18 or 22 or 34. 685 o Flags: 1 octet of flags. None are defined at this stage. Flags 686 SHOULD be set to zero on transmission and MUST be ignored on 687 receipt. 689 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 690 transmission and MUST be ignored on receipt. 692 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 694 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 696 The following applies to the Type-4 Segment sub-TLV: 698 o The IPv6 Node Address MUST be present. 700 o The SID is optional and MAY be of one of the following formats: 702 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 703 defined in Section 2.4.3.2.1. 705 * IPV6 SID: a 16 octet IPv6 address. 707 o If length is 18, then only the IPv6 Node Address is present. 709 o If length is 22, then the IPv6 Node Address and the MPLS SID are 710 present. 712 o If length is 34, then the IPv6 Node Address and the IPv6 SID are 713 present. 715 2.4.3.2.5. Type 5: IPv4 Address + Local Interface ID with optional SID 717 The Type-5 Segment Sub-TLV encodes an IPv4 node address, a local 718 interface Identifier (Local Interface ID) and an optional SID in the 719 form of either an MPLS label or an IPv6 address. The format is as 720 follows: 722 0 1 2 3 723 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 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Type | Length | Flags | RESERVED | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Local Interface ID (4 octets) | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | IPv4 Node Address (4 octets) | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 // SID (optional, 4 or 16 octets) // 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 where: 736 o Type: 5 (to be assigned by IANA from the registry "SR Policy List 737 Sub-TLVs" defined in this document). 739 o Length is 10 or 14 or 26. 741 o Flags: 1 octet of flags. None are defined at this stage. Flags 742 SHOULD be set to zero on transmission and MUST be ignored on 743 receipt. 745 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 746 transmission and MUST be ignored on receipt. 748 o Local Interface ID: 4 octets as defined in 749 [I-D.ietf-pce-segment-routing]. 751 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 753 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 755 The following applies to the Type-5 Segment sub-TLV: 757 o The IPv4 Node Address MUST be present. 759 o The Local Interface ID MUST be present. 761 o The SID is optional and MAY be of one of the following formats: 763 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 764 defined in Section 2.4.3.2.1. 766 * IPV6 SID: a 16 octet IPv6 SID. 768 o If length is 10, then the IPv4 Node Address and Local Interface ID 769 are present. 771 o If length is 14, then the IPv4 Node Address, the Local Interface 772 ID and the MPLS SID are present. 774 o If length is 26, then the IPv4 Node Address, the Local Interface 775 ID and the IPv6 SID are present. 777 2.4.3.2.6. Type 6: IPv4 Local and Remote addresses with optional SID 779 The Type-6 Segment Sub-TLV encodes an adjacency local address, an 780 adjacency remote address and an optional SID in the form of either an 781 MPLS label or an IPv6 address. The format is as follows: 783 0 1 2 3 784 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 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Type | Length | Flags | RESERVED | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Local IPv4 Address (4 octets) | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Remote IPv4 Address (4 octets) | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 // SID (4 or 16 octets) // 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 where: 797 o Type: 6 (to be assigned by IANA from the registry "SR Policy List 798 Sub-TLVs" defined in this document). 800 o Length is 10 or 14 or 26. 802 o Flags: 1 octet of flags. None are defined at this stage. Flags 803 SHOULD be set to zero on transmission and MUST be ignored on 804 receipt. 806 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 807 transmission and MUST be ignored on receipt. 809 o Local IPv4 Address: a 4 octet IPv4 address. 811 o Remote IPv4 Address: a 4 octet IPv4 address. 813 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 815 The following applies to the Type-6 Segment sub-TLV: 817 o The Local IPv4 Address MUST be present and represents an adjacency 818 local address. 820 o The Remote IPv4 Address MUST be present and represents the remote 821 end of the adjacency. 823 o The SID is optional and MAY be of one of the following formats: 825 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 826 defined in Section 2.4.3.2.1. 828 * IPV6 SID: a 16 octet IPv6 address. 830 o If length is 10, then only the IPv4 Local and Remote addresses are 831 present. 833 o If length is 14, then the IPv4 Local address, IPv4 Remote address 834 and the MPLS SID are present. 836 o If length is 26, then the IPv4 Local address, IPv4 Remote address 837 and the IPv6 SID are present. 839 2.4.3.2.7. Type 7: IPv6 Address + Local Interface ID with optional SID 841 The Type-7 Segment Sub-TLV encodes an IPv6 node address, a local 842 interface identifier (Local Interface ID) and an optional SID in the 843 form of either an MPLS label or an IPv6 address. The format is as 844 follows: 846 0 1 2 3 847 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 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Type | Length | Flags | RESERVED | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Local Interface ID (4 octets) | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 // IPv6 Node Address (16 octets) // 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 // SID (optional, 4 or 16 octets) // 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 where: 860 o Type: 7 (to be assigned by IANA from the registry "SR Policy List 861 Sub-TLVs" defined in this document). 863 o Length is 22 or 26 or 38. 865 o Flags: 1 octet of flags. None are defined at this stage. Flags 866 SHOULD be set to zero on transmission and MUST be ignored on 867 receipt. 869 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 870 transmission and MUST be ignored on receipt. 872 o Local Interface ID: 4 octets of interface index. 874 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 876 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 878 The following applies to the Type-7 Segment sub-TLV: 880 o The IPv6 Node Address MUST be present. 882 o The Local Interface ID MUST be present. 884 o The SID is optional and MAY be of one of the following formats: 886 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 887 defined in Section 2.4.3.2.1. 889 * IPV6 SID: a 16 octet IPv6 address. 891 o If length is 22, then the IPv6 Node Address and Local Interface ID 892 are present. 894 o If length is 26, then the IPv6 Node Address, the Local Interface 895 ID and the MPLS SID are present. 897 o If length is 38, then the IPv6 Node Address, the Local Interface 898 ID and the IPv6 SID are present. 900 2.4.3.2.8. Type 8: IPv6 Local and Remote addresses with optional SID 902 The Type-8 Segment Sub-TLV encodes an adjacency local address, an 903 adjacency remote address and an optional SID in the form of either an 904 MPLS label or an IPv6 address. The format is as follows: 906 0 1 2 3 907 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 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Type | Length | Flags | RESERVED | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 // Local IPv6 Address (16 octets) // 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 // Remote IPv6 Address (16 octets) // 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 // SID (4 or 16 octets) // 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 where: 920 o Type: 8 (to be assigned by IANA from the registry "SR Policy List 921 Sub-TLVs" defined in this document). 923 o Length is 34 or 38 or 50. 925 o Flags: 1 octet of flags. None are defined at this stage. Flags 926 SHOULD be set to zero on transmission and MUST be ignored on 927 receipt. 929 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 930 transmission and MUST be ignored on receipt. 932 o Local IPv6 Address: a 16 octet IPv6 address. 934 o Remote IPv6 Address: a 16 octet IPv6 address. 936 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 938 The following applies to the Type-8 Segment sub-TLV: 940 o The Local IPv6 Address MUST be present and represents an adjacency 941 local address. 943 o The Remote IPv6 Address MUST be present and represents the remote 944 end of the adjacency. 946 o The SID is optional and MAY be of one of the following formats: 948 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 949 defined in Section 2.4.3.2.1. 951 * IPV6 SID: a 16 octet IPv6 address. 953 o If length is 34, then only the IPv6 Local and Remote addresses are 954 present. 956 o If length is 38, then the IPv6 Local address, IPv4 Remote address 957 and the MPLS SID are present. 959 o If length is 50, then the IPv6 Local address, IPv4 Remote address 960 and the IPv6 SID are present. 962 3. Extended Color Community 964 The Color Extended Community as defined in 965 [I-D.ietf-idr-tunnel-encaps] is used to steer traffic into a policy. 967 When the Color Extended Community is used for the purpose of steering 968 the traffic into an SRTE policy, the RESERVED field (as defined in 969 [I-D.ietf-idr-tunnel-encaps] is changed as follows: 971 1 972 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 |C O| RESERVED | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 where CO bits are defined as the "Color-Only" bits. 978 [I-D.filsfils-spring-segment-routing-policy]defines the influence of 979 these bits on the automated steering of BGP Payload traffic onto SRTE 980 policies. 982 4. SR Policy Operations 984 As described in this document, the consumer of a SR Policy NLRI is 985 not the BGP process. The BGP process is in charge of the origination 986 and propagation of the SR Policy NLRI but its installation and use is 987 outside the scope of BGP 988 ([I-D.filsfils-spring-segment-routing-policy]). 990 4.1. Configuration and Advertisement of SR TE Policies 992 Typically, but not limited to, an SR Policy is configured into a 993 controller. 995 Multiple SR Policy NLRIs may be present with the same tuple but with different content when these SR policies are 997 intended to different head-ends. 999 The distinguisher of each SR Policy NLRI prevents undesired BGP route 1000 selection among these SR Policy NLRIs and allow their propagation 1001 across route reflectors [RFC4456]. 1003 Moreover, one or more route-target SHOULD be attached to the 1004 advertisement, where each route-target identifies one or more 1005 intended head-ends for the advertised SR policy. 1007 If no route-target is attached to the SR Policy NLRI, then it is 1008 assumed that the originator sends the SR Policy update directly 1009 (e.g., through a BGP session) to the intended receiver. In such 1010 case, the NO_ADVERTISE community MUST be attached to the SR Policy 1011 update. 1013 4.2. Reception of an SR Policy NLRI 1015 On reception of an SR Policy NLRI, a BGP speaker MUST determine if 1016 it's first acceptable, then it determines if it is usable. 1018 4.2.1. Acceptance of an SR Policy NLRI 1020 When a BGP speaker receives an SR Policy NLRI from a neighbor it has 1021 to determine if it's acceptable. The following applies: 1023 o The SR Policy NLRI MUST include a distinguisher, color and 1024 endpoint field which implies that the length of the NLRI MUST be 1025 either 12 or 24 octets (depending on the address family of the 1026 endpoint). If the NLRI is not one of the legal lengths, a router 1027 supporting this document and that imports the route MUST consider 1028 it to be malformed and MUST apply the "treat-as-withdraw" strategy 1029 of [RFC7606]. 1031 o The SR Policy update MUST have either the NO_ADVERTISE community 1032 or at least one route-target extended community in IPv4-address 1033 format. If a router supporting this document receives an SR 1034 policy update with no route-target extended communities and no 1035 NO_ADVERTISE community, the update MUST NOT be sent to the SRTE 1036 process. Furthermore, it SHOULD be considered to be malformed, 1037 and the "treat-as-withdraw" strategy of [RFC7606] applied. 1039 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1040 Update and MUST have the Tunnel Type set to SR Policy (value to be 1041 assigned by IANA). 1043 o Within the SR Policy NLRI, at least one Segment List sub-TLV MUST 1044 be present. 1046 o Within the Segment List sub-TLV at least one Segment sub-TLV MUST 1047 be present. 1049 A router that receives an SR Policy update that is not valid 1050 according to these criteria MUST treat the update as malformed. The 1051 route MUST NOT be passed to the SRTE process, and the "treat-as- 1052 withdraw" strategy of [RFC7606]. 1054 The Remote Endpoint and Color sub-TLVs, as defined in 1055 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy 1056 NLRI encodings. If present, the Remote Endpoint sub-TLV MUST match 1057 the Endpoint of the SR Policy SAFI NLRI. If they don't match, the SR 1058 Policy advertisement MUST be considered as unacceptable. If present, 1059 the Color sub-TLV MUST match the Policy Color of the SR Policy SAFI 1060 NLRI. If they don't match, the SR Policy advertisement MUST be 1061 considered as unacceptable. 1063 A unacceptable SR Policy update that has a valid NLRI portion with 1064 invalid attribute portion MUST be considered as a withdraw of the SR 1065 Policy. 1067 A unacceptable SR Policy update that has an invalid NLRI portion MUST 1068 trigger a reset of the BGP session. 1070 4.2.2. Usable SR Policy NLRI 1072 If one or more route-targets are present, then at least one route- 1073 target MUST match one of the BGP Identifiers of the receiver in order 1074 for the update to be considered usable. The BGP Identifier is 1075 defined in [RFC4271] as a 4 octet IPv4 address. Therefore the route- 1076 target extended community MUST be of the same format. 1078 If one or more route-targets are present and no one matches any of 1079 the local BGP Identifiers, then, while the SR Policy NLRI is 1080 acceptable, it is not usable. It has to be noted that if the 1081 receiver has been explicitly configured to do so, it MAY propagate 1082 the SR Policy NLRI to its neighbors as defined in Section 4.2.4. 1084 Usable SR Policy NLRIs are sent to the Segment Routing Traffic 1085 Engineering (SRTE) process. The description of the SRTE process is 1086 outside the scope of this document and it's described in 1087 [I-D.filsfils-spring-segment-routing-policy]. 1089 4.2.3. Passing a usable SR Policy NLRI to the SRTE Process 1091 Once BGP has determined that the SR Policy NLRI is usable, BGP passes 1092 the path to the SRTE process 1093 ([I-D.filsfils-spring-segment-routing-policy]). 1095 The SRTE process applies the rules defined in 1096 [I-D.filsfils-spring-segment-routing-policy]to determine whether a 1097 path is valid and to select the best path among the valid paths. 1099 4.2.4. Propagation of an SR Policy 1101 By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate 1102 it to any EBGP neighbor. 1104 However, a node MAY be explicitly configured to advertise a received 1105 SR Policy NLRI to neighbors according to normal BGP rules (i.e., EBGP 1106 propagation by an ASBR or iBGP propagation by a Route-Reflector). 1108 SR Policy NLRIs that have been determined acceptable and valid can be 1109 propagated, even the ones that are not usable. 1111 Only SR Policy NLRIs that do not have the NO_ADVERTISE community 1112 attached to them can be propagated. 1114 4.3. Flowspec and SR Policies 1116 The SR Policy can be carried in context of a Flowspec NLRI 1117 ([RFC5575]). In this case, when the redirect to IP next-hop is 1118 specified as in [I-D.ietf-idr-flowspec-redirect-ip], the tunnel to 1119 the next-hop is specified by the segment list in the Segment List 1120 sub-TLVs. The Segment List (e.g., label stack or IPv6 segment list) 1121 is imposed to flows matching the criteria in the Flowspec route to 1122 steer them towards the next-hop as specified in the SR Policy SAFI 1123 NLRI. 1125 5. Contributors 1127 Arjun Sreekantiah 1128 Cisco Systems 1129 US 1131 Email: asreekan@cisco.com 1132 Dhanendra Jain 1133 Cisco Systems 1134 US 1136 Email: dhjain@cisco.com 1138 Acee Lindem 1139 Cisco Systems 1140 US 1142 Email: acee@cisco.com 1144 Siva Sivabalan 1145 Cisco Systems 1146 US 1148 Email: msiva@cisco.com 1150 Imtiyaz Mohammad 1151 Arista Networks 1152 India 1154 Email: imtiyaz@arista.com 1156 6. Acknowledgments 1158 The authors of this document would like to thank Shyam Sethuram and 1159 John Scudder for their comments and review of this document. 1161 7. Implementation Status 1163 Note to RFC Editor: Please remove this section prior to publication, 1164 as well as the reference to RFC 7942. 1166 This section records the status of known implementations of the 1167 protocol defined by this specification at the time of posting of this 1168 Internet-Draft, and is based on a proposal described in [RFC7942]. 1169 The description of implementations in this section is intended to 1170 assist the IETF in its decision processes in progressing drafts to 1171 RFCs. Please note that the listing of any individual implementation 1172 here does not imply endorsement by the IETF. Furthermore, no effort 1173 has been spent to verify the information presented here that was 1174 supplied by IETF contributors. This is not intended as, and must not 1175 be construed to be, a catalog of available implementations or their 1176 features. Readers are advised to note that other implementations may 1177 exist. 1179 According to [RFC7942], "this will allow reviewers and working groups 1180 to assign due consideration to documents that have the benefit of 1181 running code, which may serve as evidence of valuable experimentation 1182 and feedback that have made the implemented protocols more mature. 1183 It is up to the individual working groups to use this information as 1184 they see fit". 1186 Several early implementations exist and will be reported in detail in 1187 a forthcoming version of this document. For purposes of early 1188 interoperability testing, when no FCFS code point was available, 1189 implementations have made use of the following values: 1191 o Preference sub-TLV: 6 1193 o Binding SID sub-TLV: 7 1195 o Segment List sub-TLV: 128 1197 When IANA-assigned values are available, implementations will be 1198 updated to use them. 1200 8. IANA Considerations 1202 This document defines new Sub-TLVs in following existing registries: 1204 o Subsequent Address Family Identifiers (SAFI) Parameters 1206 o BGP Tunnel Encapsulation Attribute Tunnel Types 1208 o BGP Tunnel Encapsulation Attribute sub-TLVs 1210 This document also defines a new registry: "SR Policy List Sub-TLVs". 1212 8.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1213 Parameters 1215 This document defines a new SAFI in the registry "Subsequent Address 1216 Family Identifiers (SAFI) Parameters" that has been assigned by IANA: 1218 Codepoint Description Reference 1219 ----------------------------------------------- 1220 73 SR Policy SAFI This document 1222 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1224 This document defines a new Tunnel-Type in the registry "BGP Tunnel 1225 Encapsulation Attribute Tunnel Types" that has been assigned by IANA: 1227 Codepoint Description Reference 1228 -------------------------------------------------- 1229 15 SR Policy Type This document 1231 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1233 This document defines new sub-TLVs in the registry "BGP Tunnel 1234 Encapsulation Attribute sub-TLVs" to be assigned by IANA: 1236 Codepoint Description Reference 1237 ------------------------------------------------------ 1238 TBD3 Preference sub-TLV This document 1239 TBD4 Binding SID sub-TLV This document 1240 TBD5 Segment List sub-TLV This document 1242 8.4. New Registry: SR Policy List Sub-TLVs 1244 This document defines a new registry called "SR Policy List Sub- 1245 TLVs". The allocation policy of this registry is "First Come First 1246 Served (FCFS)" according to [RFC5226]. 1248 Following Sub-TLV codepoints are defined: 1250 Value Description Reference 1251 ------------------------------------------------------------------ 1252 1 MPLS SID sub-TLV This document 1253 2 IPv6 SID sub-TLV This document 1254 3 IPv4 Node and SID sub-TLV This document 1255 4 IPv6 Node and SID sub-TLV This document 1256 5 IPv4 Node, index and SID sub-TLV This document 1257 6 IPv4 Local/Remote addresses and SID sub-TLV This document 1258 7 IPv6 Node, index and SID sub-TLV This document 1259 8 IPv6 Local/Remote addresses and SID sub-TLV This document 1260 9 Weight sub-TLV This document 1262 9. Security Considerations 1264 TBD. 1266 10. References 1268 10.1. Normative References 1270 [I-D.ietf-idr-tunnel-encaps] 1271 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 1272 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-06 1273 (work in progress), June 2017. 1275 [I-D.ietf-pce-segment-routing] 1276 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1277 and J. Hardwick, "PCEP Extensions for Segment Routing", 1278 draft-ietf-pce-segment-routing-09 (work in progress), 1279 April 2017. 1281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1282 Requirement Levels", BCP 14, RFC 2119, 1283 DOI 10.17487/RFC2119, March 1997, 1284 . 1286 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1287 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1288 DOI 10.17487/RFC4271, January 2006, 1289 . 1291 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1292 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1293 February 2006, . 1295 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1296 "Multiprotocol Extensions for BGP-4", RFC 4760, 1297 DOI 10.17487/RFC4760, January 2007, 1298 . 1300 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1301 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1302 DOI 10.17487/RFC5226, May 2008, 1303 . 1305 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1306 and D. McPherson, "Dissemination of Flow Specification 1307 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1308 . 1310 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1311 Patel, "Revised Error Handling for BGP UPDATE Messages", 1312 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1313 . 1315 10.2. Informational References 1317 [I-D.filsfils-spring-segment-routing-policy] 1318 Filsfils, C., Sivabalan, S., Yoyer, D., Nanduri, M., Lin, 1319 S., bogdanov@google.com, b., Horneffer, M., Clad, F., 1320 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 1321 Routing Policy for Traffic Engineering", draft-filsfils- 1322 spring-segment-routing-policy-00 (work in progress), 1323 February 2017. 1325 [I-D.ietf-6man-segment-routing-header] 1326 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 1327 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 1328 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 1329 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 1330 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1331 segment-routing-header-06 (work in progress), March 2017. 1333 [I-D.ietf-idr-flowspec-redirect-ip] 1334 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 1335 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 1336 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 1337 in progress), February 2015. 1339 [I-D.ietf-spring-segment-routing] 1340 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1341 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1342 spring-segment-routing-11 (work in progress), February 1343 2017. 1345 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1346 Reflection: An Alternative to Full Mesh Internal BGP 1347 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1348 . 1350 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1351 Code: The Implementation Status Section", BCP 205, 1352 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1353 . 1355 Authors' Addresses 1357 Stefano Previdi (editor) 1358 Cisco Systems, Inc. 1359 IT 1361 Email: stefano@previdi.net 1362 Clarence Filsfils 1363 Cisco Systems, Inc. 1364 Brussels 1365 BE 1367 Email: cfilsfil@cisco.com 1369 Paul Mattes 1370 Microsoft 1371 One Microsoft Way 1372 Redmond, WA 98052 1373 USA 1375 Email: pamattes@microsoft.com 1377 Eric Rosen 1378 Juniper Networks 1379 10 Technology Park Drive 1380 Westford, MA 01886 1381 US 1383 Email: erosen@juniper.net 1385 Steven Lin 1386 Google 1388 Email: stevenlin@google.com