idnits 2.17.1 draft-ietf-idr-segment-routing-te-policy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2017) is 2465 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-07 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-09 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-01 == 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-12 Summary: 1 error (**), 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: January 21, 2018 P. Mattes 6 Microsoft 7 E. Rosen 8 Juniper Networks 9 S. Lin 10 Google 11 July 20, 2017 13 Advertising Segment Routing Policies in BGP 14 draft-ietf-idr-segment-routing-te-policy-00 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 January 21, 2018. 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 | NLRI Length | 1 octet 223 +------------------+ 224 | Distinguisher | 4 octets 225 +------------------+ 226 | Policy Color | 4 octets 227 +------------------+ 228 | Endpoint | 4 or 16 octets 229 +------------------+ 231 where: 233 o NLRI Length: 1 octet of length expressed in bits as defined in 234 [RFC4760]. 236 o Distinguisher: 4-octet value uniquely identifying the policy in 237 the context of tuple. The distinguisher has no 238 semantic value and is solely used by the SR Policy originator to 239 make unique (from an NLRI perspective) multiple occurrences of the 240 same SR Policy. 242 o Policy Color: 4-octet value identifying (with the endpoint) the 243 policy. The color is used to match the color of the destination 244 prefixes to steer traffic into the SR Policy 245 [I-D.filsfils-spring-segment-routing-policy]. 247 o Endpoint: identifies the endpoint of a policy. The Endpoint may 248 represent a single node or a set of nodes (e.g., an anycast 249 address). The Endpoint is an IPv4 (4-octet) address or an IPv6 250 (16-octet) address according to the AFI of the NLRI. 252 The color and endpoint are used to automate the steering of BGP 253 Payload prefixes on SR policy 254 ([I-D.filsfils-spring-segment-routing-policy]). 256 The NLRI containing the SR Policy is carried in a BGP UPDATE message 257 [RFC4271] using BGP multiprotocol extensions [RFC4760] with an AFI of 258 1 or 2 (IPv4 or IPv6) and with a SAFI of 73 (assigned by IANA from 259 the "Subsequent Address Family Identifiers (SAFI) Parameters" 260 registry). 262 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 263 attribute with the SR Policy SAFI MUST also carry the BGP mandatory 264 attributes. In addition, the BGP update message MAY also contain any 265 of the BGP optional attributes. 267 The next-hop of the SR Policy SAFI NLRI is set based on the AFI. For 268 example, if the AFI is set to IPv4 (1), then the next-hop is encoded 269 as a 4-byte IPv4 address. If the AFI is set to IPv6 (2), then the 270 next-hop is encoded as a 16-byte IPv6 address of the router. 272 It is important to note that any BGP speaker receiving a BGP message 273 with an SR Policy NLRI, will process it only if the NLRI is among the 274 best paths as per the BGP best path selection algorithm. In other 275 words, this document does not modify the BGP propagation or bestpath 276 selection rules. 278 It has to be noted that if several candidate paths of the same SR 279 Policy (endpoint, color) are signaled via BGP to a head-end, it is 280 recommended that each NLRI use a different distinguisher. If BGP has 281 installed into the BGP table two advertisements whose respective 282 NLRIs have the same color and endpoint, but different distinguishers, 283 both advertisements are passed to the SRTE process. 285 2.2. SR TE Policy and Tunnel Encapsulation Attribute 287 The content of the SR Policy is encoded in the Tunnel Encapsulation 288 Attribute originally defined in [I-D.ietf-idr-tunnel-encaps] using a 289 new Tunnel-Type TLV (codepoint is 15, assigned by IANA (see 290 Section 8) from the "BGP Tunnel Encapsulation Attribute Tunnel Types" 291 registry). 293 The SR Policy Encoding structure is as follows: 295 SR Policy SAFI NLRI: 296 Attributes: 297 Tunnel Encaps Attribute (23) 298 Tunnel Type: SR Policy 299 Binding SID 300 Preference 301 Segment List 302 Weight 303 Segment 304 Segment 305 ... 306 ... 307 where: 309 o SR Policy SAFI NLRI is defined in Section 2.1. 311 o Tunnel Encapsulation Attribute is defined in 312 [I-D.ietf-idr-tunnel-encaps]. 314 o Tunnel-Type is set to 15 (assigned by IANA from the "BGP Tunnel 315 Encapsulation Attribute Tunnel Types" registry). 317 o Preference, Binding SID, Segment-List, Weight and Segment are 318 defined in this document. 320 o Additional sub-TLVs may be defined in the future. 322 A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV 323 of type "SR Policy". 325 Multiple occurrences of "Segment List" MAY be encoded within the same 326 SR Policy. 328 Multiple occurrences of "Segment" MAY be encoded within the same 329 Segment List. 331 2.3. Remote Endpoint and Color 333 The Remote Endpoint and Color sub-TLVs, as defined in 334 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy 335 encodings. 337 If present, the Remote Endpoint sub-TLV MUST match the Endpoint of 338 the SR Policy SAFI NLRI. 340 If present, the Color sub-TLV MUST match the Policy Color of the SR 341 Policy SAFI NLRI. 343 2.4. SR TE Policy Sub-TLVs 345 This section defines the SR Policy sub-TLVs. 347 Preference, Binding SID, Segment-List are assigned from the "BGP 348 Tunnel Encapsulation Attribute sub-TLVs" registry. 350 Weight and Segment Sub-TLVs are assigned from a new registry defined 351 in this document and called: "SR Policy List Sub-TLVs". See 352 Section 8 for the details of the registry. 354 2.4.1. Preference sub-TLV 356 The Preference sub-TLV does not have any effect on the BGP bestpath 357 selection or propagation procedures. The contents of this sub-TLV 358 are used by the SRTE process 359 ([I-D.filsfils-spring-segment-routing-policy]). 361 The Preference sub-TLV is optional, MUST NOT appear more than once in 362 the SR Policy and has following format: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type | Length | Flags | RESERVED | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Preference (4 octets) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 where: 374 o Type: TBD3 (to be assigned by IANA from the "BGP Tunnel 375 Encapsulation Attribute sub-TLVs" registry). 377 o Length: 6. 379 o Flags: 1 octet of flags. None are defined at this stage. Flags 380 SHOULD be set to zero on transmission and MUST be ignored on 381 receipt. 383 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 384 transmission and MUST be ignored on receipt. 386 o Preference: a 4-octet value. The highest value is preferred. 388 2.4.2. SR TE Binding SID Sub-TLV 390 The Binding SID sub-TLV is not used by BGP. The contents of this 391 sub-TLV are used by the SRTE process 392 ([I-D.filsfils-spring-segment-routing-policy]). 394 The Binding SID sub-TLV is optional, MUST NOT appear more than once 395 in the SR Policy and has the following format: 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type | Length | Flags | RESERVED | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Binding SID (variable, optional) | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 where: 407 o Type: TBD4 (to be assigned by IANA from the "BGP Tunnel 408 Encapsulation Attribute sub-TLVs" registry). 410 o Length: specifies the length of the value field not including Type 411 and Length fields. Can be 2 or 6 or 18. 413 o Flags: 1 octet of flags. None are defined at this stage. Flags 414 SHOULD be set to zero on transmission and MUST be ignored on 415 receipt. 417 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 418 transmission and MUST be ignored on receipt. 420 o Binding SID: if length is 2, then no Binding SID is present. If 421 length is 6 then the Binding SID contains a 4-octet SID. If 422 length is 18 then the Binding SID contains a 16-octet IPv6 SID. 424 2.4.3. Segment List Sub-TLV 426 The Segment List TLV encodes a single explicit path towards the 427 endpoint. The Segment List sub-TLV includes the elements of the 428 paths (i.e.: segments) as well as an optional Weight TLV. 430 The Segment List sub-TLV may exceed 255 bytes length due to large 431 number of segments. Therefore a 2-octet length is required. 432 According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- 433 TLV codepoint defines the size of the length field. Therefore, for 434 the Segment List sub-TLV a code point of 128 (or higher) is used. 435 See Section 8 for details of codepoints allocation. 437 The Segment List sub-TLV is mandatory and MAY appear multiple times 438 in the SR Policy. 440 The Segment-List Sub-TLV MUST contain at least one Segment Sub-TLV 441 and MAY contain a Weight Sub-TLV. 443 The Segment List sub-TLV has the following format: 445 0 1 2 3 446 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Type | Length | RESERVED | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 // sub-TLVs // 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 where: 455 o Type: TBD5 (to be assigned by IANA from the "BGP Tunnel 456 Encapsulation Attribute sub-TLVs" registry). 458 o Length: the total length (not including the Type and Length 459 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 461 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 462 transmission and MUST be ignored on receipt. 464 o sub-TLVs: 466 * An optional single Weight sub-TLV. 468 * One or more Segment sub-TLVs. 470 2.4.3.1. Weight Sub-TLV 472 The Weight sub-TLV specifies the weight associated to a given 473 candidate path (i.e.: a given segment list). The contents of this 474 sub-TLV are used only by the SRTE process 475 ([I-D.filsfils-spring-segment-routing-policy]). 477 The Weight sub-TLV is optional, MUST NOT appear more than once inside 478 the Segment List sub-TLV, and has the following format: 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Type | Length | Flags | RESERVED | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Weight | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 where: 490 Type: 9 (to be assigned by IANA from the registry "SR Policy List 491 Sub-TLVs" defined in this document). 493 Length: 6. 495 Flags: 1 octet of flags. None are defined at this stage. Flags 496 SHOULD be set to zero on transmission and MUST be ignored on receipt. 498 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 499 and MUST be ignored on receipt. 501 2.4.3.2. Segment Sub-TLV 503 The Segment sub-TLV describes a single segment in a segment list 504 (i.e., a single element of the explicit path). Multiple Segment sub- 505 TLVs constitute an explicit path of the SR Policy. 507 The Segment sub-TLV is mandatory and MAY appear multiple times in the 508 Segment List sub-TLV. 510 The Segment sub-TLV does not have any effect on the BGP bestpath 511 selection or propagation procedures. The contents of this sub-TLV 512 are used only by the SRTE process 513 ([I-D.filsfils-spring-segment-routing-policy]). 515 [I-D.filsfils-spring-segment-routing-policy] defines several types of 516 Segment Sub-TLVs: 518 Type 1: SID only, in the form of MPLS Label 519 Type 2: SID only, in the form of IPv6 address 520 Type 3: IPv4 Node Address with optional SID 521 Type 4: IPv6 Node Address with optional SID 522 Type 5: IPv4 Address + index with optional SID 523 Type 6: IPv4 Local and Remote addresses with optional SID 524 Type 7: IPv6 Address + index with optional SID 525 Type 8: IPv6 Local and Remote addresses with optional SID 527 2.4.3.2.1. Type 1: SID only, in the form of MPLS Label 529 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 530 MPLS label. The format is as follows: 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Type | Length | Flags | RESERVED | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Label | TC |S| TTL | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 where: 542 o Type: 1 (to be assigned by IANA from the registry "SR Policy List 543 Sub-TLVs" defined in this document). 545 o Length is 6. 547 o Flags: 1 octet of flags. None are defined at this stage. Flags 548 SHOULD be set to zero on transmission and MUST be ignored on 549 receipt. 551 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 552 transmission and MUST be ignored on receipt. 554 o Label: 20 bits of label value. 556 o TC: 3 bits of traffic class. 558 o S: 1 bit of bottom-of-stack. 560 o TTL: 1 octet of TTL. 562 The following applies to the Type-1 Segment sub-TLV: 564 o The S bit SHOULD be zero upon transmission, and MUST be ignored 565 upon reception. 567 o If the originator wants the receiver to choose the TC value, it 568 sets the TC field to zero. 570 o If the originator wants the receiver to choose the TTL value, it 571 sets the TTL field to 255. 573 o If the originator wants to recommend a value for these fields, it 574 puts those values in the TC and/or TTL fields. 576 o The receiver MAY override the originator's values for these 577 fields. This would be determined by local policy at the receiver. 578 One possible policy would be to override the fields only if the 579 fields have the default values specified above. 581 2.4.3.2.2. Type 2: SID only, in the form of IPv6 address 583 The Type-2 Segment Sub-TLV encodes a single SID in the form of an 584 IPv6 SID. The format is as follows: 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Type | Length | Flags | RESERVED | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 // IPv6 SID (16 octets) // 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 where: 596 o Type: 2 (to be assigned by IANA from the registry "SR Policy List 597 Sub-TLVs" defined in this document). 599 o Length is 18. 601 o Flags: 1 octet of flags. None are defined at this stage. Flags 602 SHOULD be set to zero on transmission and MUST be ignored on 603 receipt. 605 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 606 transmission and MUST be ignored on receipt. 608 o IPv6 SID: 16 octets of IPv6 address. 610 The IPv6 Segment Identifier (IPv6 SID) is defined in 611 [I-D.ietf-6man-segment-routing-header]. 613 2.4.3.2.3. Type 3: IPv4 Node Address with optional SID 615 The Type-3 Segment Sub-TLV encodes an IPv4 node address and an 616 optional SID in the form of either an MPLS label or an IPv6 address. 617 The format is as follows: 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Type | Length | Flags | RESERVED | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | IPv4 Node Address (4 octets) | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 // SID (optional, 4 or 16 octets) // 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 where: 631 o Type: 3 (to be assigned by IANA from the registry "SR Policy List 632 Sub-TLVs" defined in this document). 634 o Length is 6 or 10 or 22. 636 o Flags: 1 octet of flags. None are defined at this stage. Flags 637 SHOULD be set to zero on transmission and MUST be ignored on 638 receipt. 640 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 641 transmission and MUST be ignored on receipt. 643 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 645 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 647 The following applies to the Type-3 Segment sub-TLV: 649 o The IPv4 Node Address MUST be present. 651 o The SID is optional and MAY be of one of the following formats: 653 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 654 defined in Section 2.4.3.2.1. 656 * IPV6 SID: a 16 octet IPv6 address. 658 o If length is 6, then only the IPv4 Node Address is present. 660 o If length is 10, then the IPv4 Node Address and the MPLS SID are 661 present. 663 o If length is 22, then the IPv4 Node Address and the IPv6 SID are 664 present. 666 2.4.3.2.4. Type 4: IPv6 Node Address with optional SID 668 The Type-4 Segment Sub-TLV encodes an IPv6 node address and an 669 optional SID in the form of either an MPLS label or an IPv6 address. 670 The format is as follows: 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Type | Length | Flags | RESERVED | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 // IPv6 Node Address (16 octets) // 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 // SID (optional, 4 or 16 octets) // 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 where: 684 o Type: 4 (to be assigned by IANA from the registry "SR Policy List 685 Sub-TLVs" defined in this document). 687 o Length is 18 or 22 or 34. 689 o Flags: 1 octet of flags. None are defined at this stage. Flags 690 SHOULD be set to zero on transmission and MUST be ignored on 691 receipt. 693 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 694 transmission and MUST be ignored on receipt. 696 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 698 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 700 The following applies to the Type-4 Segment sub-TLV: 702 o The IPv6 Node Address MUST be present. 704 o The SID is optional and MAY be of one of the following formats: 706 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 707 defined in Section 2.4.3.2.1. 709 * IPV6 SID: a 16 octet IPv6 address. 711 o If length is 18, then only the IPv6 Node Address is present. 713 o If length is 22, then the IPv6 Node Address and the MPLS SID are 714 present. 716 o If length is 34, then the IPv6 Node Address and the IPv6 SID are 717 present. 719 2.4.3.2.5. Type 5: IPv4 Address + Local Interface ID with optional SID 721 The Type-5 Segment Sub-TLV encodes an IPv4 node address, a local 722 interface Identifier (Local Interface ID) and an optional SID in the 723 form of either an MPLS label or an IPv6 address. The format is as 724 follows: 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Type | Length | Flags | RESERVED | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Local Interface ID (4 octets) | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | IPv4 Node Address (4 octets) | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 // SID (optional, 4 or 16 octets) // 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 where: 740 o Type: 5 (to be assigned by IANA from the registry "SR Policy List 741 Sub-TLVs" defined in this document). 743 o Length is 10 or 14 or 26. 745 o Flags: 1 octet of flags. None are defined at this stage. Flags 746 SHOULD be set to zero on transmission and MUST be ignored on 747 receipt. 749 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 750 transmission and MUST be ignored on receipt. 752 o Local Interface ID: 4 octets as defined in 753 [I-D.ietf-pce-segment-routing]. 755 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 757 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 759 The following applies to the Type-5 Segment sub-TLV: 761 o The IPv4 Node Address MUST be present. 763 o The Local Interface ID MUST be present. 765 o The SID is optional and MAY be of one of the following formats: 767 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 768 defined in Section 2.4.3.2.1. 770 * IPV6 SID: a 16 octet IPv6 SID. 772 o If length is 10, then the IPv4 Node Address and Local Interface ID 773 are present. 775 o If length is 14, then the IPv4 Node Address, the Local Interface 776 ID and the MPLS SID are present. 778 o If length is 26, then the IPv4 Node Address, the Local Interface 779 ID and the IPv6 SID are present. 781 2.4.3.2.6. Type 6: IPv4 Local and Remote addresses with optional SID 783 The Type-6 Segment Sub-TLV encodes an adjacency local address, an 784 adjacency remote address and an optional SID in the form of either an 785 MPLS label or an IPv6 address. The format is as follows: 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Type | Length | Flags | RESERVED | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Local IPv4 Address (4 octets) | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Remote IPv4 Address (4 octets) | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 // SID (4 or 16 octets) // 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 where: 801 o Type: 6 (to be assigned by IANA from the registry "SR Policy List 802 Sub-TLVs" defined in this document). 804 o Length is 10 or 14 or 26. 806 o Flags: 1 octet of flags. None are defined at this stage. Flags 807 SHOULD be set to zero on transmission and MUST be ignored on 808 receipt. 810 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 811 transmission and MUST be ignored on receipt. 813 o Local IPv4 Address: a 4 octet IPv4 address. 815 o Remote IPv4 Address: a 4 octet IPv4 address. 817 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 819 The following applies to the Type-6 Segment sub-TLV: 821 o The Local IPv4 Address MUST be present and represents an adjacency 822 local address. 824 o The Remote IPv4 Address MUST be present and represents the remote 825 end of the adjacency. 827 o The SID is optional and MAY be of one of the following formats: 829 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 830 defined in Section 2.4.3.2.1. 832 * IPV6 SID: a 16 octet IPv6 address. 834 o If length is 10, then only the IPv4 Local and Remote addresses are 835 present. 837 o If length is 14, then the IPv4 Local address, IPv4 Remote address 838 and the MPLS SID are present. 840 o If length is 26, then the IPv4 Local address, IPv4 Remote address 841 and the IPv6 SID are present. 843 2.4.3.2.7. Type 7: IPv6 Address + Local Interface ID with optional SID 845 The Type-7 Segment Sub-TLV encodes an IPv6 node address, a local 846 interface identifier (Local Interface ID) and an optional SID in the 847 form of either an MPLS label or an IPv6 address. The format is as 848 follows: 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Type | Length | Flags | RESERVED | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Local Interface ID (4 octets) | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 // IPv6 Node Address (16 octets) // 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 // SID (optional, 4 or 16 octets) // 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 where: 864 o Type: 7 (to be assigned by IANA from the registry "SR Policy List 865 Sub-TLVs" defined in this document). 867 o Length is 22 or 26 or 38. 869 o Flags: 1 octet of flags. None are defined at this stage. Flags 870 SHOULD be set to zero on transmission and MUST be ignored on 871 receipt. 873 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 874 transmission and MUST be ignored on receipt. 876 o Local Interface ID: 4 octets of interface index. 878 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 880 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 882 The following applies to the Type-7 Segment sub-TLV: 884 o The IPv6 Node Address MUST be present. 886 o The Local Interface ID MUST be present. 888 o The SID is optional and MAY be of one of the following formats: 890 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 891 defined in Section 2.4.3.2.1. 893 * IPV6 SID: a 16 octet IPv6 address. 895 o If length is 22, then the IPv6 Node Address and Local Interface ID 896 are present. 898 o If length is 26, then the IPv6 Node Address, the Local Interface 899 ID and the MPLS SID are present. 901 o If length is 38, then the IPv6 Node Address, the Local Interface 902 ID and the IPv6 SID are present. 904 2.4.3.2.8. Type 8: IPv6 Local and Remote addresses with optional SID 906 The Type-8 Segment Sub-TLV encodes an adjacency local address, an 907 adjacency remote address and an optional SID in the form of either an 908 MPLS label or an IPv6 address. The format is as follows: 910 0 1 2 3 911 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 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Type | Length | Flags | RESERVED | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 // Local IPv6 Address (16 octets) // 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 // Remote IPv6 Address (16 octets) // 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 // SID (4 or 16 octets) // 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 where: 924 o Type: 8 (to be assigned by IANA from the registry "SR Policy List 925 Sub-TLVs" defined in this document). 927 o Length is 34 or 38 or 50. 929 o Flags: 1 octet of flags. None are defined at this stage. Flags 930 SHOULD be set to zero on transmission and MUST be ignored on 931 receipt. 933 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 934 transmission and MUST be ignored on receipt. 936 o Local IPv6 Address: a 16 octet IPv6 address. 938 o Remote IPv6 Address: a 16 octet IPv6 address. 940 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 942 The following applies to the Type-8 Segment sub-TLV: 944 o The Local IPv6 Address MUST be present and represents an adjacency 945 local address. 947 o The Remote IPv6 Address MUST be present and represents the remote 948 end of the adjacency. 950 o The SID is optional and MAY be of one of the following formats: 952 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 953 defined in Section 2.4.3.2.1. 955 * IPV6 SID: a 16 octet IPv6 address. 957 o If length is 34, then only the IPv6 Local and Remote addresses are 958 present. 960 o If length is 38, then the IPv6 Local address, IPv4 Remote address 961 and the MPLS SID are present. 963 o If length is 50, then the IPv6 Local address, IPv4 Remote address 964 and the IPv6 SID are present. 966 3. Extended Color Community 968 The Color Extended Community as defined in 969 [I-D.ietf-idr-tunnel-encaps] is used to steer traffic into a policy. 971 When the Color Extended Community is used for the purpose of steering 972 the traffic into an SRTE policy, the RESERVED field (as defined in 973 [I-D.ietf-idr-tunnel-encaps] is changed as follows: 975 1 976 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 |C O| RESERVED | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 where CO bits are defined as the "Color-Only" bits. 982 [I-D.filsfils-spring-segment-routing-policy]defines the influence of 983 these bits on the automated steering of BGP Payload traffic onto SRTE 984 policies. 986 4. SR Policy Operations 988 As described in this document, the consumer of a SR Policy NLRI is 989 not the BGP process. The BGP process is in charge of the origination 990 and propagation of the SR Policy NLRI but its installation and use is 991 outside the scope of BGP 992 ([I-D.filsfils-spring-segment-routing-policy]). 994 4.1. Configuration and Advertisement of SR TE Policies 996 Typically, but not limited to, an SR Policy is configured into a 997 controller. 999 Multiple SR Policy NLRIs may be present with the same tuple but with different content when these SR policies are 1001 intended to different head-ends. 1003 The distinguisher of each SR Policy NLRI prevents undesired BGP route 1004 selection among these SR Policy NLRIs and allow their propagation 1005 across route reflectors [RFC4456]. 1007 Moreover, one or more route-target SHOULD be attached to the 1008 advertisement, where each route-target identifies one or more 1009 intended head-ends for the advertised SR policy. 1011 If no route-target is attached to the SR Policy NLRI, then it is 1012 assumed that the originator sends the SR Policy update directly 1013 (e.g., through a BGP session) to the intended receiver. In such 1014 case, the NO_ADVERTISE community MUST be attached to the SR Policy 1015 update. 1017 4.2. Reception of an SR Policy NLRI 1019 On reception of an SR Policy NLRI, a BGP speaker MUST determine if 1020 it's first acceptable, then it determines if it is usable. 1022 4.2.1. Acceptance of an SR Policy NLRI 1024 When a BGP speaker receives an SR Policy NLRI from a neighbor it has 1025 to determine if it's acceptable. The following applies: 1027 o The SR Policy NLRI MUST include a distinguisher, color and 1028 endpoint field which implies that the length of the NLRI MUST be 1029 either 12 or 24 octets (depending on the address family of the 1030 endpoint). If the NLRI is not one of the legal lengths, a router 1031 supporting this document and that imports the route MUST consider 1032 it to be malformed and MUST apply the "treat-as-withdraw" strategy 1033 of [RFC7606]. 1035 o The SR Policy update MUST have either the NO_ADVERTISE community 1036 or at least one route-target extended community in IPv4-address 1037 format. If a router supporting this document receives an SR 1038 policy update with no route-target extended communities and no 1039 NO_ADVERTISE community, the update MUST NOT be sent to the SRTE 1040 process. Furthermore, it SHOULD be considered to be malformed, 1041 and the "treat-as-withdraw" strategy of [RFC7606] applied. 1043 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1044 Update and MUST have the Tunnel Type set to SR Policy (value to be 1045 assigned by IANA). 1047 o Within the SR Policy NLRI, at least one Segment List sub-TLV MUST 1048 be present. 1050 o Within the Segment List sub-TLV at least one Segment sub-TLV MUST 1051 be present. 1053 A router that receives an SR Policy update that is not valid 1054 according to these criteria MUST treat the update as malformed. The 1055 route MUST NOT be passed to the SRTE process, and the "treat-as- 1056 withdraw" strategy of [RFC7606]. 1058 The Remote Endpoint and Color sub-TLVs, as defined in 1059 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy 1060 NLRI encodings. If present, the Remote Endpoint sub-TLV MUST match 1061 the Endpoint of the SR Policy SAFI NLRI. If they don't match, the SR 1062 Policy advertisement MUST be considered as unacceptable. If present, 1063 the Color sub-TLV MUST match the Policy Color of the SR Policy SAFI 1064 NLRI. If they don't match, the SR Policy advertisement MUST be 1065 considered as unacceptable. 1067 A unacceptable SR Policy update that has a valid NLRI portion with 1068 invalid attribute portion MUST be considered as a withdraw of the SR 1069 Policy. 1071 A unacceptable SR Policy update that has an invalid NLRI portion MUST 1072 trigger a reset of the BGP session. 1074 4.2.2. Usable SR Policy NLRI 1076 If one or more route-targets are present, then at least one route- 1077 target MUST match one of the BGP Identifiers of the receiver in order 1078 for the update to be considered usable. The BGP Identifier is 1079 defined in [RFC4271] as a 4 octet IPv4 address. Therefore the route- 1080 target extended community MUST be of the same format. 1082 If one or more route-targets are present and no one matches any of 1083 the local BGP Identifiers, then, while the SR Policy NLRI is 1084 acceptable, it is not usable. It has to be noted that if the 1085 receiver has been explicitly configured to do so, it MAY propagate 1086 the SR Policy NLRI to its neighbors as defined in Section 4.2.4. 1088 Usable SR Policy NLRIs are sent to the Segment Routing Traffic 1089 Engineering (SRTE) process. The description of the SRTE process is 1090 outside the scope of this document and it's described in 1091 [I-D.filsfils-spring-segment-routing-policy]. 1093 4.2.3. Passing a usable SR Policy NLRI to the SRTE Process 1095 Once BGP has determined that the SR Policy NLRI is usable, BGP passes 1096 the path to the SRTE process 1097 ([I-D.filsfils-spring-segment-routing-policy]). 1099 The SRTE process applies the rules defined in 1100 [I-D.filsfils-spring-segment-routing-policy]to determine whether a 1101 path is valid and to select the best path among the valid paths. 1103 4.2.4. Propagation of an SR Policy 1105 By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate 1106 it to any EBGP neighbor. 1108 However, a node MAY be explicitly configured to advertise a received 1109 SR Policy NLRI to neighbors according to normal BGP rules (i.e., EBGP 1110 propagation by an ASBR or iBGP propagation by a Route-Reflector). 1112 SR Policy NLRIs that have been determined acceptable and valid can be 1113 propagated, even the ones that are not usable. 1115 Only SR Policy NLRIs that do not have the NO_ADVERTISE community 1116 attached to them can be propagated. 1118 4.3. Flowspec and SR Policies 1120 The SR Policy can be carried in context of a Flowspec NLRI 1121 ([RFC5575]). In this case, when the redirect to IP next-hop is 1122 specified as in [I-D.ietf-idr-flowspec-redirect-ip], the tunnel to 1123 the next-hop is specified by the segment list in the Segment List 1124 sub-TLVs. The Segment List (e.g., label stack or IPv6 segment list) 1125 is imposed to flows matching the criteria in the Flowspec route to 1126 steer them towards the next-hop as specified in the SR Policy SAFI 1127 NLRI. 1129 5. Contributors 1131 Arjun Sreekantiah 1132 Cisco Systems 1133 US 1135 Email: asreekan@cisco.com 1136 Dhanendra Jain 1137 Cisco Systems 1138 US 1140 Email: dhjain@cisco.com 1142 Acee Lindem 1143 Cisco Systems 1144 US 1146 Email: acee@cisco.com 1148 Siva Sivabalan 1149 Cisco Systems 1150 US 1152 Email: msiva@cisco.com 1154 Imtiyaz Mohammad 1155 Arista Networks 1156 India 1158 Email: imtiyaz@arista.com 1160 6. Acknowledgments 1162 The authors of this document would like to thank Shyam Sethuram and 1163 John Scudder for their comments and review of this document. 1165 7. Implementation Status 1167 Note to RFC Editor: Please remove this section prior to publication, 1168 as well as the reference to RFC 7942. 1170 This section records the status of known implementations of the 1171 protocol defined by this specification at the time of posting of this 1172 Internet-Draft, and is based on a proposal described in [RFC7942]. 1173 The description of implementations in this section is intended to 1174 assist the IETF in its decision processes in progressing drafts to 1175 RFCs. Please note that the listing of any individual implementation 1176 here does not imply endorsement by the IETF. Furthermore, no effort 1177 has been spent to verify the information presented here that was 1178 supplied by IETF contributors. This is not intended as, and must not 1179 be construed to be, a catalog of available implementations or their 1180 features. Readers are advised to note that other implementations may 1181 exist. 1183 According to [RFC7942], "this will allow reviewers and working groups 1184 to assign due consideration to documents that have the benefit of 1185 running code, which may serve as evidence of valuable experimentation 1186 and feedback that have made the implemented protocols more mature. 1187 It is up to the individual working groups to use this information as 1188 they see fit". 1190 Several early implementations exist and will be reported in detail in 1191 a forthcoming version of this document. For purposes of early 1192 interoperability testing, when no FCFS code point was available, 1193 implementations have made use of the following values: 1195 o Preference sub-TLV: 6 1197 o Binding SID sub-TLV: 7 1199 o Segment List sub-TLV: 128 1201 When IANA-assigned values are available, implementations will be 1202 updated to use them. 1204 8. IANA Considerations 1206 This document defines new Sub-TLVs in following existing registries: 1208 o Subsequent Address Family Identifiers (SAFI) Parameters 1210 o BGP Tunnel Encapsulation Attribute Tunnel Types 1212 o BGP Tunnel Encapsulation Attribute sub-TLVs 1214 This document also defines a new registry: "SR Policy List Sub-TLVs". 1216 8.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1217 Parameters 1219 This document defines a new SAFI in the registry "Subsequent Address 1220 Family Identifiers (SAFI) Parameters" that has been assigned by IANA: 1222 Codepoint Description Reference 1223 ----------------------------------------------- 1224 73 SR Policy SAFI This document 1226 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1228 This document defines a new Tunnel-Type in the registry "BGP Tunnel 1229 Encapsulation Attribute Tunnel Types" that has been assigned by IANA: 1231 Codepoint Description Reference 1232 -------------------------------------------------- 1233 15 SR Policy Type This document 1235 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1237 This document defines new sub-TLVs in the registry "BGP Tunnel 1238 Encapsulation Attribute sub-TLVs" to be assigned by IANA: 1240 Codepoint Description Reference 1241 ------------------------------------------------------ 1242 TBD3 Preference sub-TLV This document 1243 TBD4 Binding SID sub-TLV This document 1244 TBD5 Segment List sub-TLV This document 1246 8.4. New Registry: SR Policy List Sub-TLVs 1248 This document defines a new registry called "SR Policy List Sub- 1249 TLVs". The allocation policy of this registry is "First Come First 1250 Served (FCFS)" according to [RFC8126]. 1252 Following Sub-TLV codepoints are defined: 1254 Value Description Reference 1255 ------------------------------------------------------------------ 1256 1 MPLS SID sub-TLV This document 1257 2 IPv6 SID sub-TLV This document 1258 3 IPv4 Node and SID sub-TLV This document 1259 4 IPv6 Node and SID sub-TLV This document 1260 5 IPv4 Node, index and SID sub-TLV This document 1261 6 IPv4 Local/Remote addresses and SID sub-TLV This document 1262 7 IPv6 Node, index and SID sub-TLV This document 1263 8 IPv6 Local/Remote addresses and SID sub-TLV This document 1264 9 Weight sub-TLV This document 1266 9. Security Considerations 1268 TBD. 1270 10. References 1272 10.1. Normative References 1274 [I-D.ietf-idr-tunnel-encaps] 1275 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 1276 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-07 1277 (work in progress), July 2017. 1279 [I-D.ietf-pce-segment-routing] 1280 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1281 and J. Hardwick, "PCEP Extensions for Segment Routing", 1282 draft-ietf-pce-segment-routing-09 (work in progress), 1283 April 2017. 1285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1286 Requirement Levels", BCP 14, RFC 2119, 1287 DOI 10.17487/RFC2119, March 1997, 1288 . 1290 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1291 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1292 DOI 10.17487/RFC4271, January 2006, 1293 . 1295 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1296 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1297 February 2006, . 1299 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1300 "Multiprotocol Extensions for BGP-4", RFC 4760, 1301 DOI 10.17487/RFC4760, January 2007, 1302 . 1304 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1305 and D. McPherson, "Dissemination of Flow Specification 1306 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1307 . 1309 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1310 Patel, "Revised Error Handling for BGP UPDATE Messages", 1311 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1312 . 1314 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1315 Writing an IANA Considerations Section in RFCs", BCP 26, 1316 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1317 . 1319 10.2. Informational References 1321 [I-D.filsfils-spring-segment-routing-policy] 1322 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 1323 F., Lin, S., bogdanov@google.com, b., Horneffer, M., 1324 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 1325 Routing Policy for Traffic Engineering", draft-filsfils- 1326 spring-segment-routing-policy-01 (work in progress), July 1327 2017. 1329 [I-D.ietf-6man-segment-routing-header] 1330 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 1331 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 1332 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 1333 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 1334 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1335 segment-routing-header-06 (work in progress), March 2017. 1337 [I-D.ietf-idr-flowspec-redirect-ip] 1338 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 1339 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 1340 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 1341 in progress), February 2015. 1343 [I-D.ietf-spring-segment-routing] 1344 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1345 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1346 spring-segment-routing-12 (work in progress), June 2017. 1348 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1349 Reflection: An Alternative to Full Mesh Internal BGP 1350 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1351 . 1353 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1354 Code: The Implementation Status Section", BCP 205, 1355 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1356 . 1358 Authors' Addresses 1360 Stefano Previdi (editor) 1361 Cisco Systems, Inc. 1362 IT 1364 Email: stefano@previdi.net 1365 Clarence Filsfils 1366 Cisco Systems, Inc. 1367 Brussels 1368 BE 1370 Email: cfilsfil@cisco.com 1372 Paul Mattes 1373 Microsoft 1374 One Microsoft Way 1375 Redmond, WA 98052 1376 USA 1378 Email: pamattes@microsoft.com 1380 Eric Rosen 1381 Juniper Networks 1382 10 Technology Park Drive 1383 Westford, MA 01886 1384 US 1386 Email: erosen@juniper.net 1388 Steven Lin 1389 Google 1391 Email: stevenlin@google.com