idnits 2.17.1 draft-ietf-idr-segment-routing-te-policy-01.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 (December 13, 2017) is 2316 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-11 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-03 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-07 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-13 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: June 16, 2018 P. Mattes 6 Microsoft 7 E. Rosen 8 Juniper Networks 9 S. Lin 10 Google 11 December 13, 2017 13 Advertising Segment Routing Policies in BGP 14 draft-ietf-idr-segment-routing-te-policy-01 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 https://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 June 16, 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 (https://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 2.4.4. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 21 73 3. Extended Color Community . . . . . . . . . . . . . . . . . . 22 74 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 23 75 4.1. Configuration and Advertisement of SR TE Policies . . . . 23 76 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 23 77 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 23 78 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 24 79 4.2.3. Passing a usable SR Policy NLRI to the SRTE Process . 25 80 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 25 81 4.3. Flowspec and SR Policies . . . . . . . . . . . . . . . . 25 82 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 83 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 84 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 86 8.1. Existing Registry: Subsequent Address Family Identifiers 87 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 28 88 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute 89 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 28 90 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute 91 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 28 92 8.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 28 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 97 10.2. Informational References . . . . . . . . . . . . . . . . 30 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 100 1. Introduction 102 Segment Routing (SR) allows a headend node to steer a packet flow 103 along any path. Intermediate per-flow states are eliminated thanks 104 to source routing [I-D.ietf-spring-segment-routing]. 106 The headend node is said to steer a flow into an Segment Routing 107 Policy (SR Policy). 109 The header of a packet steered in an SR Policy is augmented with the 110 ordered list of segments associated with that SR Policy. 112 [I-D.filsfils-spring-segment-routing-policy] details the concepts of 113 SR Policy and steering into an SR Policy. These apply equally to the 114 MPLS and SRv6 instantiations of segment routing. 116 As highlighted in section 2 of 117 [I-D.filsfils-spring-segment-routing-policy]: 119 o an SR policy may have multiple candidate paths learned via various 120 mechanisms (CLI, NetConf, PCEP or BGP); 122 o the SRTE process selects the best candidate path for a Policy; 124 o the SRTE process binds a BSID to the selected path of the Policy; 126 o the SRTE process installs the selected path and its BSID in the 127 forwarding plane. 129 This document specifies the way to use BGP to distribute one or more 130 of the candidate paths of an SR policy to the headend of that policy. 131 The SRTE process ([I-D.filsfils-spring-segment-routing-policy]) of 132 the headend receives candidate paths from BGP, and possibly other 133 sources as well, and the SRTE process then determines the selected 134 path of the policy. 136 This document specifies a way of representing SR policies and their 137 candidate paths in BGP UPDATE messages. BGP can then be used to 138 propagate the SR policies and candidate paths. The usual BGP rules 139 for BGP propagation and "bestpath selection" are used. At the 140 headend of a specific policy, this will result in one or more 141 candidate paths being installed into the "BGP table". These paths 142 are then passed to the SRTE process. The SRTE process may compare 143 them to candidate paths learned via other mechanisms, and will choose 144 one or more paths to be installed in the data plane. BGP itself does 145 not install SRTE candidate paths into the data plane. 147 This document defines a new BGP address family (SAFI). In UPDATE 148 messages of that address family, the NLRI identifies an SR policy, 149 and the attributes specify candidate paths of that policy. 151 While for simplicity we may write that BGP advertises an SR Policy, 152 it has to be understood that BGP advertises a candidate path of an SR 153 policy and that this SR Policy might have several other candidate 154 paths provided via BGP (via an NLRI with a different distinguisher as 155 defined in this document), PCEP, NETCONF or local policy 156 configuration. 158 Typically, a controller defines the set of policies and advertise 159 them to policy head-end routers (typically ingress routers). The 160 policy advertisement uses BGP extensions defined in this document. 161 The policy advertisement is, in most but not all of the cases, 162 tailored for a specific policy head-end. In this case the 163 advertisement may sent on a BGP session to that head-end and not 164 propagated any further. 166 Alternatively, a router (i.e.: an BGP egress router) advertises SR 167 Policies representing paths to itself. In this case, it is possible 168 to send the policy to each head-end over a BGP session to that head- 169 end, without requiring any further propagation of the policy. 171 An SR Policy intended only for the receiver will, in most cases, not 172 traverse any Route Reflector (RR, [RFC4456]). 174 In some situations, it is undesirable for a controller or BGP egress 175 router to have a BGP session to each policy head-end. In these 176 situations, BGP Route Reflectors may be used to propagate the 177 advertisements, or it may be necessary for the advertisement to 178 propagate through a sequence of one or more ASes. To make this 179 possible, an attribute needs to be attached to the advertisement that 180 enables a BGP speaker to determine whether it is intended to be a 181 head-end for the advertised policy. This is done by attaching one or 182 more Route Target Extended Communities to the advertisement 183 ([RFC4360]). 185 The BGP extensions for the advertisement of SR Policies include 186 following components: 188 o A new Subsequent Address Family Identifier (SAFI) whose NLRI 189 identifies an SR Policy. 191 o A set of new TLVs to be inserted into the Tunnel Encapsulation 192 Attribute (as defined in [I-D.ietf-idr-tunnel-encaps]) specifying 193 candidate paths of the SR policy, as well as other information 194 about the SR policy. 196 o One or more IPv4 address format route-target extended community 197 ([RFC4360]) attached to the SR Policy advertisement and that 198 indicates the intended head-end of such SR Policy advertisement. 200 o The Color Extended Community (as defined in 201 [I-D.ietf-idr-tunnel-encaps]) and used in order to steer traffic 202 into an SR Policy, as described in 203 [I-D.filsfils-spring-segment-routing-policy]. This document 204 (Section 3) modifies the format of the Color Extended Community by 205 using the two leftmost bits of the RESERVED field. 207 1.1. Requirements Language 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in RFC 2119 [RFC2119]. 213 2. SR TE Policy Encoding 215 2.1. SR TE Policy SAFI and NLRI 217 A new SAFI is defined: the SR Policy SAFI, (codepoint 73 assigned by 218 IANA (see Section 8) from the "Subsequent Address Family Identifiers 219 (SAFI) Parameters" registry). 221 The SR Policy SAFI uses a new NLRI defined as follows: 223 +------------------+ 224 | NLRI Length | 1 octet 225 +------------------+ 226 | Distinguisher | 4 octets 227 +------------------+ 228 | Policy Color | 4 octets 229 +------------------+ 230 | Endpoint | 4 or 16 octets 231 +------------------+ 233 where: 235 o NLRI Length: 1 octet of length expressed in bits as defined in 236 [RFC4760]. 238 o Distinguisher: 4-octet value uniquely identifying the policy in 239 the context of tuple. The distinguisher has no 240 semantic value and is solely used by the SR Policy originator to 241 make unique (from an NLRI perspective) multiple occurrences of the 242 same SR Policy. 244 o Policy Color: 4-octet value identifying (with the endpoint) the 245 policy. The color is used to match the color of the destination 246 prefixes to steer traffic into the SR Policy 247 [I-D.filsfils-spring-segment-routing-policy]. 249 o Endpoint: identifies the endpoint of a policy. The Endpoint may 250 represent a single node or a set of nodes (e.g., an anycast 251 address). The Endpoint is an IPv4 (4-octet) address or an IPv6 252 (16-octet) address according to the AFI of the NLRI. 254 The color and endpoint are used to automate the steering of BGP 255 Payload prefixes on SR policy 256 ([I-D.filsfils-spring-segment-routing-policy]). 258 The NLRI containing the SR Policy is carried in a BGP UPDATE message 259 [RFC4271] using BGP multiprotocol extensions [RFC4760] with an AFI of 260 1 or 2 (IPv4 or IPv6) and with a SAFI of 73 (assigned by IANA from 261 the "Subsequent Address Family Identifiers (SAFI) Parameters" 262 registry). 264 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 265 attribute with the SR Policy SAFI MUST also carry the BGP mandatory 266 attributes. In addition, the BGP update message MAY also contain any 267 of the BGP optional attributes. 269 The next-hop of the SR Policy SAFI NLRI is set based on the AFI. For 270 example, if the AFI is set to IPv4 (1), then the next-hop is encoded 271 as a 4-byte IPv4 address. If the AFI is set to IPv6 (2), then the 272 next-hop is encoded as a 16-byte IPv6 address of the router. 274 It is important to note that any BGP speaker receiving a BGP message 275 with an SR Policy NLRI, will process it only if the NLRI is among the 276 best paths as per the BGP best path selection algorithm. In other 277 words, this document does not modify the BGP propagation or bestpath 278 selection rules. 280 It has to be noted that if several candidate paths of the same SR 281 Policy (endpoint, color) are signaled via BGP to a head-end, it is 282 recommended that each NLRI use a different distinguisher. If BGP has 283 installed into the BGP table two advertisements whose respective 284 NLRIs have the same color and endpoint, but different distinguishers, 285 both advertisements are passed to the SRTE process. 287 2.2. SR TE Policy and Tunnel Encapsulation Attribute 289 The content of the SR Policy is encoded in the Tunnel Encapsulation 290 Attribute originally defined in [I-D.ietf-idr-tunnel-encaps] using a 291 new Tunnel-Type TLV (codepoint is 15, assigned by IANA (see 292 Section 8) from the "BGP Tunnel Encapsulation Attribute Tunnel Types" 293 registry). 295 The SR Policy Encoding structure is as follows: 297 SR Policy SAFI NLRI: 298 Attributes: 299 Tunnel Encaps Attribute (23) 300 Tunnel Type: SR Policy 301 Binding SID 302 Preference 303 Segment List 304 Weight 305 Segment 306 Segment 307 ... 308 ... 309 where: 311 o SR Policy SAFI NLRI is defined in Section 2.1. 313 o Tunnel Encapsulation Attribute is defined in 314 [I-D.ietf-idr-tunnel-encaps]. 316 o Tunnel-Type is set to 15 (assigned by IANA from the "BGP Tunnel 317 Encapsulation Attribute Tunnel Types" registry). 319 o Preference, Binding SID, Segment-List, Weight and Segment are 320 defined in this document. 322 o Additional sub-TLVs may be defined in the future. 324 A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV 325 of type "SR Policy". 327 Multiple occurrences of "Segment List" MAY be encoded within the same 328 SR Policy. 330 Multiple occurrences of "Segment" MAY be encoded within the same 331 Segment List. 333 2.3. Remote Endpoint and Color 335 The Remote Endpoint and Color sub-TLVs, as defined in 336 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy 337 encodings. 339 If present, the Remote Endpoint sub-TLV MUST match the Endpoint of 340 the SR Policy SAFI NLRI. 342 If present, the Color sub-TLV MUST match the Policy Color of the SR 343 Policy SAFI NLRI. 345 2.4. SR TE Policy Sub-TLVs 347 This section defines the SR Policy sub-TLVs. 349 Preference, Binding SID, Segment-List are assigned from the "BGP 350 Tunnel Encapsulation Attribute sub-TLVs" registry. 352 Weight and Segment Sub-TLVs are assigned from a new registry defined 353 in this document and called: "SR Policy List Sub-TLVs". See 354 Section 8 for the details of the registry. 356 2.4.1. Preference sub-TLV 358 The Preference sub-TLV does not have any effect on the BGP bestpath 359 selection or propagation procedures. The contents of this sub-TLV 360 are used by the SRTE process 361 ([I-D.filsfils-spring-segment-routing-policy]). 363 The Preference sub-TLV is optional, MUST NOT appear more than once in 364 the SR Policy and has following format: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Type | Length | Flags | RESERVED | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Preference (4 octets) | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 where: 376 o Type: 12 378 o Length: 6. 380 o Flags: 1 octet of flags. None are defined at this stage. Flags 381 SHOULD be set to zero on transmission and MUST be ignored on 382 receipt. 384 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 385 transmission and MUST be ignored on receipt. 387 o Preference: a 4-octet value. The highest value is preferred. 389 2.4.2. SR TE Binding SID Sub-TLV 391 The Binding SID sub-TLV is not used by BGP. The contents of this 392 sub-TLV are used by the SRTE process 393 ([I-D.filsfils-spring-segment-routing-policy]). 395 The Binding SID sub-TLV is optional, MUST NOT appear more than once 396 in the SR Policy and has the following format: 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type | Length | Flags | RESERVED | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Binding SID (variable, optional) | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 where: 408 o Type: 13 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. 422 o If length is 6 then the Binding SID contains a 4-octet SID. Below 423 format is used to encode the SID. TC, S, TTL(Total of 12bits) are 424 RESERVED and SHOULD be set to Zero and MUST be ignored. 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Label | TC |S| TTL | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 If length is 18 then the Binding SID contains a 16-octet IPv6 SID. 434 2.4.3. Segment List Sub-TLV 436 The Segment List TLV encodes a single explicit path towards the 437 endpoint. The Segment List sub-TLV includes the elements of the 438 paths (i.e.: segments) as well as an optional Weight TLV. 440 The Segment List sub-TLV may exceed 255 bytes length due to large 441 number of segments. Therefore a 2-octet length is required. 442 According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- 443 TLV codepoint defines the size of the length field. Therefore, for 444 the Segment List sub-TLV a code point of 128 (or higher) is used. 445 See Section 8 for details of codepoints allocation. 447 The Segment List sub-TLV is mandatory and MAY appear multiple times 448 in the SR Policy. 450 The Segment-List Sub-TLV MUST contain at least one Segment Sub-TLV 451 and MAY contain a Weight Sub-TLV. 453 The Segment List sub-TLV has the following format: 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type | Length | RESERVED | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 // sub-TLVs // 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 where: 465 o Type: 128. 467 o Length: the total length (not including the Type and Length 468 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 470 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 471 transmission and MUST be ignored on receipt. 473 o sub-TLVs: 475 * An optional single Weight sub-TLV. 477 * One or more Segment sub-TLVs. 479 2.4.3.1. Weight Sub-TLV 481 The Weight sub-TLV specifies the weight associated to a given 482 candidate path (i.e.: a given segment list). The contents of this 483 sub-TLV are used only by the SRTE process 484 ([I-D.filsfils-spring-segment-routing-policy]). 486 The Weight sub-TLV is optional, MUST NOT appear more than once inside 487 the Segment List sub-TLV, and has the following format: 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Type | Length | Flags | RESERVED | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Weight | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 where: 499 Type: 9 (to be assigned by IANA from the registry "SR Policy List 500 Sub-TLVs" defined in this document). 502 Length: 6. 504 Flags: 1 octet of flags. None are defined at this stage. Flags 505 SHOULD be set to zero on transmission and MUST be ignored on receipt. 507 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 508 and MUST be ignored on receipt. 510 2.4.3.2. Segment Sub-TLV 512 The Segment sub-TLV describes a single segment in a segment list 513 (i.e., a single element of the explicit path). Multiple Segment sub- 514 TLVs constitute an explicit path of the SR Policy. 516 The Segment sub-TLV is mandatory and MAY appear multiple times in the 517 Segment List sub-TLV. 519 The Segment sub-TLV does not have any effect on the BGP bestpath 520 selection or propagation procedures. The contents of this sub-TLV 521 are used only by the SRTE process 522 ([I-D.filsfils-spring-segment-routing-policy]). 524 [I-D.filsfils-spring-segment-routing-policy] defines several types of 525 Segment Sub-TLVs: 527 Type 1: SID only, in the form of MPLS Label 528 Type 2: SID only, in the form of IPv6 address 529 Type 3: IPv4 Node Address with optional SID 530 Type 4: IPv6 Node Address with optional SID 531 Type 5: IPv4 Address + index with optional SID 532 Type 6: IPv4 Local and Remote addresses with optional SID 533 Type 7: IPv6 Address + index with optional SID 534 Type 8: IPv6 Local and Remote addresses with optional SID 536 2.4.3.2.1. Type 1: SID only, in the form of MPLS Label 538 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 539 MPLS label. The format is as follows: 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Type | Length | Flags | RESERVED | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Label | TC |S| TTL | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 where: 551 o Type: 1 (to be assigned by IANA from the registry "SR Policy List 552 Sub-TLVs" defined in this document). 554 o Length is 6. 556 o Flags: 1 octet of flags. None are defined at this stage. Flags 557 SHOULD be set to zero on transmission and MUST be ignored on 558 receipt. 560 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 561 transmission and MUST be ignored on receipt. 563 o Label: 20 bits of label value. 565 o TC: 3 bits of traffic class. 567 o S: 1 bit of bottom-of-stack. 569 o TTL: 1 octet of TTL. 571 The following applies to the Type-1 Segment sub-TLV: 573 o The S bit SHOULD be zero upon transmission, and MUST be ignored 574 upon reception. 576 o If the originator wants the receiver to choose the TC value, it 577 sets the TC field to zero. 579 o If the originator wants the receiver to choose the TTL value, it 580 sets the TTL field to 255. 582 o If the originator wants to recommend a value for these fields, it 583 puts those values in the TC and/or TTL fields. 585 o The receiver MAY override the originator's values for these 586 fields. This would be determined by local policy at the receiver. 587 One possible policy would be to override the fields only if the 588 fields have the default values specified above. 590 2.4.3.2.2. Type 2: SID only, in the form of IPv6 address 592 The Type-2 Segment Sub-TLV encodes a single SID in the form of an 593 IPv6 SID. The format is as follows: 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Type | Length | Flags | RESERVED | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 // IPv6 SID (16 octets) // 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 where: 605 o Type: 2 (to be assigned by IANA from the registry "SR Policy List 606 Sub-TLVs" defined in this document). 608 o Length is 18. 610 o Flags: 1 octet of flags. None are defined at this stage. Flags 611 SHOULD be set to zero on transmission and MUST be ignored on 612 receipt. 614 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 615 transmission and MUST be ignored on receipt. 617 o IPv6 SID: 16 octets of IPv6 address. 619 The IPv6 Segment Identifier (IPv6 SID) is defined in 620 [I-D.ietf-6man-segment-routing-header]. 622 2.4.3.2.3. Type 3: IPv4 Node Address with optional SID 624 The Type-3 Segment Sub-TLV encodes an IPv4 node address and an 625 optional SID in the form of either an MPLS label or an IPv6 address. 626 The format is as follows: 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Type | Length | Flags | RESERVED | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | IPv4 Node Address (4 octets) | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 // SID (optional, 4 or 16 octets) // 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 where: 640 o Type: 3 (to be assigned by IANA from the registry "SR Policy List 641 Sub-TLVs" defined in this document). 643 o Length is 6 or 10 or 22. 645 o Flags: 1 octet of flags. None are defined at this stage. Flags 646 SHOULD be set to zero on transmission and MUST be ignored on 647 receipt. 649 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 650 transmission and MUST be ignored on receipt. 652 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 654 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 656 The following applies to the Type-3 Segment sub-TLV: 658 o The IPv4 Node Address MUST be present. 660 o The SID is optional and MAY be of one of the following formats: 662 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 663 defined in Section 2.4.3.2.1. 665 * IPV6 SID: a 16 octet IPv6 address. 667 o If length is 6, then only the IPv4 Node Address is present. 669 o If length is 10, then the IPv4 Node Address and the MPLS SID are 670 present. 672 o If length is 22, then the IPv4 Node Address and the IPv6 SID are 673 present. 675 2.4.3.2.4. Type 4: IPv6 Node Address with optional SID 677 The Type-4 Segment Sub-TLV encodes an IPv6 node address and an 678 optional SID in the form of either an MPLS label or an IPv6 address. 679 The format is as follows: 681 0 1 2 3 682 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 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Type | Length | Flags | RESERVED | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 // IPv6 Node Address (16 octets) // 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 // SID (optional, 4 or 16 octets) // 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 where: 693 o Type: 4 (to be assigned by IANA from the registry "SR Policy List 694 Sub-TLVs" defined in this document). 696 o Length is 18 or 22 or 34. 698 o Flags: 1 octet of flags. None are defined at this stage. Flags 699 SHOULD be set to zero on transmission and MUST be ignored on 700 receipt. 702 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 703 transmission and MUST be ignored on receipt. 705 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 707 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 709 The following applies to the Type-4 Segment sub-TLV: 711 o The IPv6 Node Address MUST be present. 713 o The SID is optional and MAY be of one of the following formats: 715 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 716 defined in Section 2.4.3.2.1. 718 * IPV6 SID: a 16 octet IPv6 address. 720 o If length is 18, then only the IPv6 Node Address is present. 722 o If length is 22, then the IPv6 Node Address and the MPLS SID are 723 present. 725 o If length is 34, then the IPv6 Node Address and the IPv6 SID are 726 present. 728 2.4.3.2.5. Type 5: IPv4 Address + Local Interface ID with optional SID 730 The Type-5 Segment Sub-TLV encodes an IPv4 node address, a local 731 interface Identifier (Local Interface ID) and an optional SID in the 732 form of either an MPLS label or an IPv6 address. The format is as 733 follows: 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Type | Length | Flags | RESERVED | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Local Interface ID (4 octets) | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | IPv4 Node Address (4 octets) | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 // SID (optional, 4 or 16 octets) // 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 where: 749 o Type: 5 (to be assigned by IANA from the registry "SR Policy List 750 Sub-TLVs" defined in this document). 752 o Length is 10 or 14 or 26. 754 o Flags: 1 octet of flags. None are defined at this stage. Flags 755 SHOULD be set to zero on transmission and MUST be ignored on 756 receipt. 758 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 759 transmission and MUST be ignored on receipt. 761 o Local Interface ID: 4 octets as defined in 762 [I-D.ietf-pce-segment-routing]. 764 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 766 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 768 The following applies to the Type-5 Segment sub-TLV: 770 o The IPv4 Node Address MUST be present. 772 o The Local Interface ID MUST be present. 774 o The SID is optional and MAY be of one of the following formats: 776 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 777 defined in Section 2.4.3.2.1. 779 * IPV6 SID: a 16 octet IPv6 SID. 781 o If length is 10, then the IPv4 Node Address and Local Interface ID 782 are present. 784 o If length is 14, then the IPv4 Node Address, the Local Interface 785 ID and the MPLS SID are present. 787 o If length is 26, then the IPv4 Node Address, the Local Interface 788 ID and the IPv6 SID are present. 790 2.4.3.2.6. Type 6: IPv4 Local and Remote addresses with optional SID 792 The Type-6 Segment Sub-TLV encodes an adjacency local address, an 793 adjacency remote address and an optional SID in the form of either an 794 MPLS label or an IPv6 address. The format is as follows: 796 0 1 2 3 797 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 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Type | Length | Flags | RESERVED | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Local IPv4 Address (4 octets) | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Remote IPv4 Address (4 octets) | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 // SID (4 or 16 octets) // 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 where: 810 o Type: 6 (to be assigned by IANA from the registry "SR Policy List 811 Sub-TLVs" defined in this document). 813 o Length is 10 or 14 or 26. 815 o Flags: 1 octet of flags. None are defined at this stage. Flags 816 SHOULD be set to zero on transmission and MUST be ignored on 817 receipt. 819 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 820 transmission and MUST be ignored on receipt. 822 o Local IPv4 Address: a 4 octet IPv4 address. 824 o Remote IPv4 Address: a 4 octet IPv4 address. 826 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 828 The following applies to the Type-6 Segment sub-TLV: 830 o The Local IPv4 Address MUST be present and represents an adjacency 831 local address. 833 o The Remote IPv4 Address MUST be present and represents the remote 834 end of the adjacency. 836 o The SID is optional and MAY be of one of the following formats: 838 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 839 defined in Section 2.4.3.2.1. 841 * IPV6 SID: a 16 octet IPv6 address. 843 o If length is 10, then only the IPv4 Local and Remote addresses are 844 present. 846 o If length is 14, then the IPv4 Local address, IPv4 Remote address 847 and the MPLS SID are present. 849 o If length is 26, then the IPv4 Local address, IPv4 Remote address 850 and the IPv6 SID are present. 852 2.4.3.2.7. Type 7: IPv6 Address + Local Interface ID with optional SID 854 The Type-7 Segment Sub-TLV encodes an IPv6 node address, a local 855 interface identifier (Local Interface ID) and an optional SID in the 856 form of either an MPLS label or an IPv6 address. The format is as 857 follows: 859 0 1 2 3 860 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 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Type | Length | Flags | RESERVED | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Local Interface ID (4 octets) | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 // IPv6 Node Address (16 octets) // 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 // SID (optional, 4 or 16 octets) // 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 where: 873 o Type: 7 (to be assigned by IANA from the registry "SR Policy List 874 Sub-TLVs" defined in this document). 876 o Length is 22 or 26 or 38. 878 o Flags: 1 octet of flags. None are defined at this stage. Flags 879 SHOULD be set to zero on transmission and MUST be ignored on 880 receipt. 882 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 883 transmission and MUST be ignored on receipt. 885 o Local Interface ID: 4 octets of interface index. 887 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 889 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 891 The following applies to the Type-7 Segment sub-TLV: 893 o The IPv6 Node Address MUST be present. 895 o The Local Interface ID MUST be present. 897 o The SID is optional and MAY be of one of the following formats: 899 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 900 defined in Section 2.4.3.2.1. 902 * IPV6 SID: a 16 octet IPv6 address. 904 o If length is 22, then the IPv6 Node Address and Local Interface ID 905 are present. 907 o If length is 26, then the IPv6 Node Address, the Local Interface 908 ID and the MPLS SID are present. 910 o If length is 38, then the IPv6 Node Address, the Local Interface 911 ID and the IPv6 SID are present. 913 2.4.3.2.8. Type 8: IPv6 Local and Remote addresses with optional SID 915 The Type-8 Segment Sub-TLV encodes an adjacency local address, an 916 adjacency remote address and an optional SID in the form of either an 917 MPLS label or an IPv6 address. The format is as follows: 919 0 1 2 3 920 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 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Type | Length | Flags | RESERVED | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 // Local IPv6 Address (16 octets) // 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 // Remote IPv6 Address (16 octets) // 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 // SID (4 or 16 octets) // 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 where: 933 o Type: 8 (to be assigned by IANA from the registry "SR Policy List 934 Sub-TLVs" defined in this document). 936 o Length is 34 or 38 or 50. 938 o Flags: 1 octet of flags. None are defined at this stage. Flags 939 SHOULD be set to zero on transmission and MUST be ignored on 940 receipt. 942 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 943 transmission and MUST be ignored on receipt. 945 o Local IPv6 Address: a 16 octet IPv6 address. 947 o Remote IPv6 Address: a 16 octet IPv6 address. 949 o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. 951 The following applies to the Type-8 Segment sub-TLV: 953 o The Local IPv6 Address MUST be present and represents an adjacency 954 local address. 956 o The Remote IPv6 Address MUST be present and represents the remote 957 end of the adjacency. 959 o The SID is optional and MAY be of one of the following formats: 961 * MPLS SID: a 4 octet label containing label, TC, S and TTL as 962 defined in Section 2.4.3.2.1. 964 * IPV6 SID: a 16 octet IPv6 address. 966 o If length is 34, then only the IPv6 Local and Remote addresses are 967 present. 969 o If length is 38, then the IPv6 Local address, IPv4 Remote address 970 and the MPLS SID are present. 972 o If length is 50, then the IPv6 Local address, IPv4 Remote address 973 and the IPv6 SID are present. 975 2.4.4. Explicit NULL Label Policy Sub-TLV 977 In order to steer an unlabeled IP packet into an SR policy, it is 978 necessary to create a label stack for that packet, and to push one or 979 more labels onto that stack. 981 The Explicit NULL Label Policy sub-TLV is used to indicate whether an 982 Explicit NULL Label [RFC3032] must be pushed on an unlabeled IP 983 packet before any other labels. 985 If an Explicit NULL Label Policy Sub-TLV is not present, the decision 986 of whether to push an Explicit NULL label on a given packet is a 987 matter of local policy. 989 The contents of this sub-TLV are used by the SRTE 990 process[I-D.filsfils-spring-segment-routing-policy] 992 0 1 2 3 993 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 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Type | Length | Flags | RESERVED | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | ENLP | 998 +-+-+-+-+-+-+-+-+ 1000 Where: 1002 Type: TBD (to be assigned by IANA from the registry "SR Policy 1003 List Sub-TLVs" defined in this document). 1005 Length: 3. 1007 Flags: 1 octet of flags. None are defined at this stage. Flags 1008 SHOULD be set to zero on transmission and MUST be ignored on 1009 receipt. 1011 RESERVED: 1 octet of reserved bits. SHOULD be unset on 1012 transmission and MUST be ignored on receipt. 1014 ELNP(Explicit NULL Label Policy): Indicates whether Explicit NULL 1015 labels are to be pushed on unlabled IP packets that are being 1016 steered into a given SR policy. This field has one of the 1017 following 4 values: 1019 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1020 packet, but do not push an IPv6 Explicit NULL label on an 1021 unlabeled IPv6 packet. 1023 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 1024 packet, but do not push an IPv4 Explicit NULL label on an 1025 unlabeled IPv4 packet. 1027 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1028 packet, and push an IPv6 Explicit NULL label on an unlabeled 1029 IPv6 packet. 1031 4: Do not push an Explicit NULL label. 1033 The policy signaled in this Sub-TLV MAY be overridden by local 1034 policy. 1036 3. Extended Color Community 1038 The Color Extended Community as defined in 1039 [I-D.ietf-idr-tunnel-encaps] is used to steer traffic into a policy. 1041 When the Color Extended Community is used for the purpose of steering 1042 the traffic into an SRTE policy, the RESERVED field (as defined in 1043 [I-D.ietf-idr-tunnel-encaps] is changed as follows: 1045 1 1046 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 |C O| RESERVED | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 where CO bits are defined as the "Color-Only" bits. 1051 [I-D.filsfils-spring-segment-routing-policy]defines the influence of 1052 these bits on the automated steering of BGP Payload traffic onto SRTE 1053 policies. 1055 4. SR Policy Operations 1057 As described in this document, the consumer of a SR Policy NLRI is 1058 not the BGP process. The BGP process is in charge of the origination 1059 and propagation of the SR Policy NLRI but its installation and use is 1060 outside the scope of BGP 1061 ([I-D.filsfils-spring-segment-routing-policy]). 1063 4.1. Configuration and Advertisement of SR TE Policies 1065 Typically, but not limited to, an SR Policy is configured into a 1066 controller. 1068 Multiple SR Policy NLRIs may be present with the same tuple but with different content when these SR policies are 1070 intended to different head-ends. 1072 The distinguisher of each SR Policy NLRI prevents undesired BGP route 1073 selection among these SR Policy NLRIs and allow their propagation 1074 across route reflectors [RFC4456]. 1076 Moreover, one or more route-target SHOULD be attached to the 1077 advertisement, where each route-target identifies one or more 1078 intended head-ends for the advertised SR policy. 1080 If no route-target is attached to the SR Policy NLRI, then it is 1081 assumed that the originator sends the SR Policy update directly 1082 (e.g., through a BGP session) to the intended receiver. In such 1083 case, the NO_ADVERTISE community MUST be attached to the SR Policy 1084 update. 1086 4.2. Reception of an SR Policy NLRI 1088 On reception of an SR Policy NLRI, a BGP speaker MUST determine if 1089 it's first acceptable, then it determines if it is usable. 1091 4.2.1. Acceptance of an SR Policy NLRI 1093 When a BGP speaker receives an SR Policy NLRI from a neighbor it has 1094 to determine if it's acceptable. The following applies: 1096 o The SR Policy NLRI MUST include a distinguisher, color and 1097 endpoint field which implies that the length of the NLRI MUST be 1098 either 12 or 24 octets (depending on the address family of the 1099 endpoint). 1101 o The SR Policy update MUST have either the NO_ADVERTISE community 1102 or at least one route-target extended community in IPv4-address 1103 format. If a router supporting this document receives an SR 1104 policy update with no route-target extended communities and no 1105 NO_ADVERTISE community, the update MUST NOT be sent to the SRTE 1106 process. Furthermore, it SHOULD be considered to be malformed, 1107 and the "treat-as-withdraw" strategy of [RFC7606] applied. 1109 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1110 Update and MUST have the Tunnel Type set to SR Policy (value to be 1111 assigned by IANA). 1113 o Within the SR Policy NLRI, at least one Segment List sub-TLV MUST 1114 be present. 1116 o Within the Segment List sub-TLV at least one Segment sub-TLV MUST 1117 be present. 1119 A router that receives an SR Policy update that is not valid 1120 according to these criteria MUST treat the update as malformed. The 1121 route MUST NOT be passed to the SRTE process, and the "treat-as- 1122 withdraw" strategy of [RFC7606]. 1124 The Remote Endpoint and Color sub-TLVs, as defined in 1125 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy 1126 NLRI encodings. If present, the Remote Endpoint sub-TLV MUST match 1127 the Endpoint of the SR Policy SAFI NLRI. If they don't match, the SR 1128 Policy advertisement MUST be considered as unacceptable. If present, 1129 the Color sub-TLV MUST match the Policy Color of the SR Policy SAFI 1130 NLRI. If they don't match, the SR Policy advertisement MUST be 1131 considered as unacceptable. 1133 A unacceptable SR Policy update that has a valid NLRI portion with 1134 invalid attribute portion MUST be considered as a withdraw of the SR 1135 Policy. 1137 4.2.2. Usable SR Policy NLRI 1139 If one or more route-targets are present, then at least one route- 1140 target MUST match one of the BGP Identifiers of the receiver in order 1141 for the update to be considered usable. The BGP Identifier is 1142 defined in [RFC4271] as a 4 octet IPv4 address. Therefore the route- 1143 target extended community MUST be of the same format. 1145 If one or more route-targets are present and no one matches any of 1146 the local BGP Identifiers, then, while the SR Policy NLRI is 1147 acceptable, it is not usable. It has to be noted that if the 1148 receiver has been explicitly configured to do so, it MAY propagate 1149 the SR Policy NLRI to its neighbors as defined in Section 4.2.4. 1151 Usable SR Policy NLRIs are sent to the Segment Routing Traffic 1152 Engineering (SRTE) process. The description of the SRTE process is 1153 outside the scope of this document and it's described in 1154 [I-D.filsfils-spring-segment-routing-policy]. 1156 4.2.3. Passing a usable SR Policy NLRI to the SRTE Process 1158 Once BGP has determined that the SR Policy NLRI is usable, BGP passes 1159 the path to the SRTE process 1160 ([I-D.filsfils-spring-segment-routing-policy]). 1162 The SRTE process applies the rules defined in 1163 [I-D.filsfils-spring-segment-routing-policy]to determine whether a 1164 path is valid and to select the best path among the valid paths. 1166 4.2.4. Propagation of an SR Policy 1168 By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate 1169 it to any EBGP neighbor. 1171 However, a node MAY be explicitly configured to advertise a received 1172 SR Policy NLRI to neighbors according to normal BGP rules (i.e., EBGP 1173 propagation by an ASBR or iBGP propagation by a Route-Reflector). 1175 SR Policy NLRIs that have been determined acceptable and valid can be 1176 propagated, even the ones that are not usable. 1178 Only SR Policy NLRIs that do not have the NO_ADVERTISE community 1179 attached to them can be propagated. 1181 4.3. Flowspec and SR Policies 1183 The SR Policy can be carried in context of a Flowspec NLRI 1184 ([RFC5575]). In this case, when the redirect to IP next-hop is 1185 specified as in [I-D.ietf-idr-flowspec-redirect-ip], the tunnel to 1186 the next-hop is specified by the segment list in the Segment List 1187 sub-TLVs. The Segment List (e.g., label stack or IPv6 segment list) 1188 is imposed to flows matching the criteria in the Flowspec route to 1189 steer them towards the next-hop as specified in the SR Policy SAFI 1190 NLRI. 1192 5. Contributors 1194 Arjun Sreekantiah 1195 Cisco Systems 1196 US 1198 Email: asreekan@cisco.com 1200 Dhanendra Jain 1201 Cisco Systems 1202 US 1204 Email: dhjain@cisco.com 1206 Acee Lindem 1207 Cisco Systems 1208 US 1210 Email: acee@cisco.com 1212 Siva Sivabalan 1213 Cisco Systems 1214 US 1216 Email: msiva@cisco.com 1218 Imtiyaz Mohammad 1219 Arista Networks 1220 India 1222 Email: imtiyaz@arista.com 1224 Gaurav Dawra 1225 Cisco Systems 1226 US 1228 Email: gdawra@cisco.com 1230 6. Acknowledgments 1232 The authors of this document would like to thank Shyam Sethuram and 1233 John Scudder for their comments and review of this document. 1235 7. Implementation Status 1237 Note to RFC Editor: Please remove this section prior to publication, 1238 as well as the reference to RFC 7942. 1240 This section records the status of known implementations of the 1241 protocol defined by this specification at the time of posting of this 1242 Internet-Draft, and is based on a proposal described in [RFC7942]. 1243 The description of implementations in this section is intended to 1244 assist the IETF in its decision processes in progressing drafts to 1245 RFCs. Please note that the listing of any individual implementation 1246 here does not imply endorsement by the IETF. Furthermore, no effort 1247 has been spent to verify the information presented here that was 1248 supplied by IETF contributors. This is not intended as, and must not 1249 be construed to be, a catalog of available implementations or their 1250 features. Readers are advised to note that other implementations may 1251 exist. 1253 According to [RFC7942], "this will allow reviewers and working groups 1254 to assign due consideration to documents that have the benefit of 1255 running code, which may serve as evidence of valuable experimentation 1256 and feedback that have made the implemented protocols more mature. 1257 It is up to the individual working groups to use this information as 1258 they see fit". 1260 Several early implementations exist and will be reported in detail in 1261 a forthcoming version of this document. For purposes of early 1262 interoperability testing, when no FCFS code point was available, 1263 implementations have made use of the following values: 1265 o Preference sub-TLV: 6 1267 o Binding SID sub-TLV: 7 1269 o Segment List sub-TLV: 128 1271 When IANA-assigned values are available, implementations will be 1272 updated to use them. 1274 8. IANA Considerations 1276 This document defines new Sub-TLVs in following existing registries: 1278 o Subsequent Address Family Identifiers (SAFI) Parameters 1280 o BGP Tunnel Encapsulation Attribute Tunnel Types 1282 o BGP Tunnel Encapsulation Attribute sub-TLVs 1284 This document also defines a new registry: "SR Policy List Sub-TLVs". 1286 8.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1287 Parameters 1289 This document defines a new SAFI in the registry "Subsequent Address 1290 Family Identifiers (SAFI) Parameters" that has been assigned by IANA: 1292 Codepoint Description Reference 1293 ----------------------------------------------- 1294 73 SR Policy SAFI This document 1296 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1298 This document defines a new Tunnel-Type in the registry "BGP Tunnel 1299 Encapsulation Attribute Tunnel Types" that has been assigned by IANA: 1301 Codepoint Description Reference 1302 -------------------------------------------------- 1303 15 SR Policy Type This document 1305 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1307 This document defines new sub-TLVs in the registry "BGP Tunnel 1308 Encapsulation Attribute sub-TLVs" to be assigned by IANA: 1310 Codepoint Description Reference 1311 ------------------------------------------------------ 1312 12 Preference sub-TLV This document 1313 13 Binding SID sub-TLV This document 1314 128 Segment List sub-TLV This document 1316 8.4. New Registry: SR Policy List Sub-TLVs 1318 This document defines a new registry called "SR Policy List Sub- 1319 TLVs". The allocation policy of this registry is "First Come First 1320 Served (FCFS)" according to [RFC8126]. 1322 Following Sub-TLV codepoints are defined: 1324 Value Description Reference 1325 ------------------------------------------------------------------ 1326 1 MPLS SID sub-TLV This document 1327 2 IPv6 SID sub-TLV This document 1328 3 IPv4 Node and SID sub-TLV This document 1329 4 IPv6 Node and SID sub-TLV This document 1330 5 IPv4 Node, index and SID sub-TLV This document 1331 6 IPv4 Local/Remote addresses and SID sub-TLV This document 1332 7 IPv6 Node, index and SID sub-TLV This document 1333 8 IPv6 Local/Remote addresses and SID sub-TLV This document 1334 9 Weight sub-TLV This document 1336 9. Security Considerations 1338 TBD. 1340 10. References 1342 10.1. Normative References 1344 [I-D.ietf-idr-tunnel-encaps] 1345 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 1346 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-07 1347 (work in progress), July 2017. 1349 [I-D.ietf-pce-segment-routing] 1350 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1351 and J. Hardwick, "PCEP Extensions for Segment Routing", 1352 draft-ietf-pce-segment-routing-11 (work in progress), 1353 November 2017. 1355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1356 Requirement Levels", BCP 14, RFC 2119, 1357 DOI 10.17487/RFC2119, March 1997, 1358 . 1360 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1361 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1362 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1363 . 1365 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1366 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1367 DOI 10.17487/RFC4271, January 2006, 1368 . 1370 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1371 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1372 February 2006, . 1374 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1375 "Multiprotocol Extensions for BGP-4", RFC 4760, 1376 DOI 10.17487/RFC4760, January 2007, 1377 . 1379 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1380 and D. McPherson, "Dissemination of Flow Specification 1381 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1382 . 1384 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1385 Patel, "Revised Error Handling for BGP UPDATE Messages", 1386 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1387 . 1389 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1390 Writing an IANA Considerations Section in RFCs", BCP 26, 1391 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1392 . 1394 10.2. Informational References 1396 [I-D.filsfils-spring-segment-routing-policy] 1397 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 1398 F., Hegde, S., Lin, S., bogdanov@google.com, b., 1399 Horneffer, M., Steinberg, D., Decraene, B., and S. 1400 Litkowski, "Segment Routing Policy for Traffic 1401 Engineering", draft-filsfils-spring-segment-routing- 1402 policy-03 (work in progress), October 2017. 1404 [I-D.ietf-6man-segment-routing-header] 1405 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 1406 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 1407 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 1408 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 1409 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1410 segment-routing-header-07 (work in progress), July 2017. 1412 [I-D.ietf-idr-flowspec-redirect-ip] 1413 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 1414 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 1415 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 1416 in progress), February 2015. 1418 [I-D.ietf-spring-segment-routing] 1419 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1420 Litkowski, S., and R. Shakir, "Segment Routing 1421 Architecture", draft-ietf-spring-segment-routing-13 (work 1422 in progress), October 2017. 1424 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1425 Reflection: An Alternative to Full Mesh Internal BGP 1426 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1427 . 1429 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1430 Code: The Implementation Status Section", BCP 205, 1431 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1432 . 1434 Authors' Addresses 1436 Stefano Previdi (editor) 1437 Cisco Systems, Inc. 1438 IT 1440 Email: stefano@previdi.net 1442 Clarence Filsfils 1443 Cisco Systems, Inc. 1444 Brussels 1445 BE 1447 Email: cfilsfil@cisco.com 1449 Paul Mattes 1450 Microsoft 1451 One Microsoft Way 1452 Redmond, WA 98052 1453 USA 1455 Email: pamattes@microsoft.com 1456 Eric Rosen 1457 Juniper Networks 1458 10 Technology Park Drive 1459 Westford, MA 01886 1460 US 1462 Email: erosen@juniper.net 1464 Steven Lin 1465 Google 1467 Email: stevenlin@google.com