idnits 2.17.1 draft-ietf-idr-segment-routing-te-policy-03.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Priority sub-TLV is optional and it MUST not appear more than once in the SR Policy TLV. If the Priority sub-TLV appears more than once, the update is considered malformed and the "treat-as-withdraw" strategy of [RFC7606] is applied. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Policy Name sub-TLV is optional and it MUST not appear more than once in the SR Policy TLV. If the Policy Name sub-TLV appears more than once, the update is considered malformed and the "treat-as-withdraw" strategy of [RFC7606] is applied. -- The document date (May 18, 2018) is 2169 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 (-06) exists of draft-filsfils-spring-segment-routing-policy-05 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-09 == 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 (-26) exists of draft-ietf-6man-segment-routing-header-12 Summary: 2 errors (**), 0 flaws (~~), 7 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 D. Jain, Ed. 5 Expires: November 19, 2018 Cisco Systems, Inc. 6 P. Mattes 7 Microsoft 8 E. Rosen 9 Juniper Networks 10 S. Lin 11 Google 12 May 18, 2018 14 Advertising Segment Routing Policies in BGP 15 draft-ietf-idr-segment-routing-te-policy-03 17 Abstract 19 This document defines a new BGP SAFI with a new NLRI in order to 20 advertise a candidate path of a Segment Routing Policy (SR Policy). 21 An SR Policy is a set of candidate paths consisting of one or more 22 segment lists. The headend of an SR Policy may learn multiple 23 candidate paths for an SR Policy. Candidate paths may be learned via 24 a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. 25 This document specifies the way in which BGP may be used to 26 distribute candidate paths. New sub-TLVs for the Tunnel 27 Encapsulation Attribute are defined. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 19, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 65 2. SR TE Policy Encoding . . . . . . . . . . . . . . . . . . . . 5 66 2.1. SR TE Policy SAFI and NLRI . . . . . . . . . . . . . . . 5 67 2.2. SR TE Policy and Tunnel Encapsulation Attribute . . . . . 7 68 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 69 2.4. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . . . 9 70 2.4.1. Preference Sub-TLV . . . . . . . . . . . . . . . . . 9 71 2.4.2. SR TE Binding SID Sub-TLV . . . . . . . . . . . . . . 10 72 2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 11 73 2.4.4. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 27 74 2.4.5. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 28 75 2.4.6. Policy Name Sub-TLV . . . . . . . . . . . . . . . . . 29 76 3. Extended Color Community . . . . . . . . . . . . . . . . . . 30 77 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 30 78 4.1. Configuration and Advertisement of SR TE Policies . . . . 30 79 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 31 80 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 31 81 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 32 82 4.2.3. Passing a usable SR Policy NLRI to the SRTE Process . 32 83 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 32 84 4.3. Flowspec and SR Policies . . . . . . . . . . . . . . . . 33 85 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 86 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 87 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 34 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 89 8.1. Existing Registry: Subsequent Address Family Identifiers 90 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 35 91 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute 92 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 35 93 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute 94 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 35 95 8.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 36 96 8.5. New Registry: SR Policy Binding SID Flags . . . . . . . . 36 97 8.6. New Registry: SR Policy Segment Flags . . . . . . . . . . 37 98 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 101 10.2. Informational References . . . . . . . . . . . . . . . . 38 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 104 1. Introduction 106 Segment Routing (SR) allows a headend node to steer a packet flow 107 along any path. Intermediate per-flow states are eliminated thanks 108 to source routing [I-D.ietf-spring-segment-routing]. 110 The headend node is said to steer a flow into a Segment Routing 111 Policy (SR Policy). 113 The header of a packet steered in an SR Policy is augmented with the 114 ordered list of segments associated with that SR Policy. 116 [I-D.filsfils-spring-segment-routing-policy] details the concepts of 117 SR Policy and steering into an SR Policy. These apply equally to the 118 MPLS and SRv6 instantiations of segment routing. 120 As highlighted in section 2 of 121 [I-D.filsfils-spring-segment-routing-policy]: 123 o an SR policy may have multiple candidate paths learned via various 124 mechanisms (CLI, NetConf, PCEP or BGP); 126 o the SRTE process selects the best candidate path for a Policy; 128 o the SRTE process binds a BSID to the selected path of the Policy; 130 o the SRTE process installs the selected path and its BSID in the 131 forwarding plane. 133 This document specifies the way to use BGP to distribute one or more 134 of the candidate paths of an SR policy to the headend of that policy. 135 The SRTE process ([I-D.filsfils-spring-segment-routing-policy]) of 136 the headend receives candidate paths from BGP, and possibly other 137 sources as well, and the SRTE process then determines the selected 138 path of the policy. 140 This document specifies a way of representing SR policies and their 141 candidate paths in BGP UPDATE messages. BGP can then be used to 142 propagate the SR policies and candidate paths. The usual BGP rules 143 for BGP propagation and "bestpath selection" are used. At the 144 headend of a specific policy, this will result in one or more 145 candidate paths being installed into the "BGP table". These paths 146 are then passed to the SRTE process. The SRTE process may compare 147 them to candidate paths learned via other mechanisms, and will choose 148 one or more paths to be installed in the data plane. BGP itself does 149 not install SRTE candidate paths into the data plane. 151 This document defines a new BGP address family (SAFI). In UPDATE 152 messages of that address family, the NLRI identifies an SR policy, 153 and the attributes specify candidate paths of that policy. 155 While for simplicity we may write that BGP advertises an SR Policy, 156 it has to be understood that BGP advertises a candidate path of an SR 157 policy and that this SR Policy might have several other candidate 158 paths provided via BGP (via an NLRI with a different distinguisher as 159 defined in this document), PCEP, NETCONF or local policy 160 configuration. 162 Typically, a controller defines the set of policies and advertise 163 them to policy head-end routers (typically ingress routers). The 164 policy advertisement uses BGP extensions defined in this document. 165 The policy advertisement is, in most but not all of the cases, 166 tailored for a specific policy head-end. In this case the 167 advertisement may sent on a BGP session to that head-end and not 168 propagated any further. 170 Alternatively, a router (i.e., a BGP egress router) advertises SR 171 Policies representing paths to itself. In this case, it is possible 172 to send the policy to each head-end over a BGP session to that head- 173 end, without requiring any further propagation of the policy. 175 An SR Policy intended only for the receiver will, in most cases, not 176 traverse any Route Reflector (RR, [RFC4456]). 178 In some situations, it is undesirable for a controller or BGP egress 179 router to have a BGP session to each policy head-end. In these 180 situations, BGP Route Reflectors may be used to propagate the 181 advertisements, or it may be necessary for the advertisement to 182 propagate through a sequence of one or more ASes. To make this 183 possible, an attribute needs to be attached to the advertisement that 184 enables a BGP speaker to determine whether it is intended to be a 185 head-end for the advertised policy. This is done by attaching one or 186 more Route Target Extended Communities to the advertisement 187 ([RFC4360]). 189 The BGP extensions for the advertisement of SR Policies include 190 following components: 192 o A new Subsequent Address Family Identifier (SAFI) whose NLRI 193 identifies an SR Policy. 195 o A set of new TLVs to be inserted into the Tunnel Encapsulation 196 Attribute (as defined in [I-D.ietf-idr-tunnel-encaps]) specifying 197 candidate paths of the SR policy, as well as other information 198 about the SR policy. 200 o One or more IPv4 address format route-target extended community 201 ([RFC4360]) attached to the SR Policy advertisement and that 202 indicates the intended head-end of such SR Policy advertisement. 204 o The Color Extended Community (as defined in 205 [I-D.ietf-idr-tunnel-encaps]) and used in order to steer traffic 206 into an SR Policy, as described in section 8.4 in 207 [I-D.filsfils-spring-segment-routing-policy]. This document 208 (Section 3) modifies the format of the Color Extended Community by 209 using the two leftmost bits of the RESERVED field. 211 1.1. Requirements Language 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in RFC 2119 [RFC2119]. 217 2. SR TE Policy Encoding 219 2.1. SR TE Policy SAFI and NLRI 221 A new SAFI is defined: the SR Policy SAFI, (codepoint 73 assigned by 222 IANA (see Section 8) from the "Subsequent Address Family Identifiers 223 (SAFI) Parameters" registry). 225 The SR Policy SAFI uses a new NLRI defined as follows: 227 +------------------+ 228 | NLRI Length | 1 octet 229 +------------------+ 230 | Distinguisher | 4 octets 231 +------------------+ 232 | Policy Color | 4 octets 233 +------------------+ 234 | Endpoint | 4 or 16 octets 235 +------------------+ 237 where: 239 o NLRI Length: 1 octet of length expressed in bits as defined in 240 [RFC4760]. 242 o Distinguisher: 4-octet value uniquely identifying the policy in 243 the context of tuple. The distinguisher has no 244 semantic value and is solely used by the SR Policy originator to 245 make unique (from an NLRI perspective) multiple occurrences of the 246 same SR Policy. 248 o Policy Color: 4-octet value identifying (with the endpoint) the 249 policy. The color is used to match the color of the destination 250 prefixes to steer traffic into the SR Policy 251 [I-D.filsfils-spring-segment-routing-policy]. 253 o Endpoint: identifies the endpoint of a policy. The Endpoint may 254 represent a single node or a set of nodes (e.g., an anycast 255 address). The Endpoint is an IPv4 (4-octet) address or an IPv6 256 (16-octet) address according to the AFI of the NLRI. 258 The color and endpoint are used to automate the steering of BGP 259 Payload prefixes on SR policy 260 ([I-D.filsfils-spring-segment-routing-policy]). 262 The NLRI containing the SR Policy is carried in a BGP UPDATE message 263 [RFC4271] using BGP multiprotocol extensions [RFC4760] with an AFI of 264 1 or 2 (IPv4 or IPv6) and with a SAFI of 73 (assigned by IANA from 265 the "Subsequent Address Family Identifiers (SAFI) Parameters" 266 registry). 268 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 269 attribute with the SR Policy SAFI MUST also carry the BGP mandatory 270 attributes. In addition, the BGP update message MAY also contain any 271 of the BGP optional attributes. 273 The next-hop network address field in SR Policy SAFI (73) updates may 274 be either a 4 octet IPv4 address or a 16 octet IPv6 address, 275 independent of the SR Policy AFI. The length field of the next-hop 276 address specifies the next-hop address family. If the next-hop 277 length is 4, then the next-hop is an IPv4 address; if the next-hop 278 length is 16, then it is a global IPv6 address; and if the next-hop 279 length is 32, then it has a global IPv6 address followed by a link- 280 local IPv6 address. The setting of the next-hop field and its 281 attendant processing is governed by standard BGP procedures as 282 described in section 3 in [RFC4760]. 284 It is important to note that any BGP speaker receiving a BGP message 285 with an SR Policy NLRI, will process it only if the NLRI is among the 286 best paths as per the BGP best path selection algorithm. In other 287 words, this document does not modify the BGP propagation or bestpath 288 selection rules. 290 It has to be noted that if several candidate paths of the same SR 291 Policy (endpoint, color) are signaled via BGP to a head-end, it is 292 recommended that each NLRI use a different distinguisher. If BGP has 293 installed into the BGP table two advertisements whose respective 294 NLRIs have the same color and endpoint, but different distinguishers, 295 both advertisements are passed to the SRTE process as different 296 candidate paths. In addition, the originator information 297 corresponding to the each candidate path, as described in section 2.4 298 ([I-D.filsfils-spring-segment-routing-policy]), is passed to the SRTE 299 process. 301 2.2. SR TE Policy and Tunnel Encapsulation Attribute 303 The content of the SR Policy is encoded in the Tunnel Encapsulation 304 Attribute originally defined in [I-D.ietf-idr-tunnel-encaps] using a 305 new Tunnel-Type TLV (codepoint is 15, assigned by IANA (see 306 Section 8) from the "BGP Tunnel Encapsulation Attribute Tunnel Types" 307 registry). 309 The SR Policy Encoding structure is as follows: 311 SR Policy SAFI NLRI: 312 Attributes: 313 Tunnel Encaps Attribute (23) 314 Tunnel Type: SR Policy 315 Binding SID 316 Preference 317 Priority 318 Policy Name 319 Explicit NULL Label Policy (ENLP) 320 Segment List 321 Weight 322 Segment 323 Segment 324 ... 325 ... 326 where: 328 o SR Policy SAFI NLRI is defined in Section 2.1. 330 o Tunnel Encapsulation Attribute is defined in 331 [I-D.ietf-idr-tunnel-encaps]. 333 o Tunnel-Type is set to 15 (assigned by IANA from the "BGP Tunnel 334 Encapsulation Attribute Tunnel Types" registry). 336 o Preference, Binding SID, Priority, Policy Name, ENLP, Segment- 337 List, Weight and Segment sub-TLVs are defined in this document. 339 o Additional sub-TLVs may be defined in the future. 341 A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV 342 of type "SR Policy". If more than one TLV of type "SR Policy" 343 appears, the update is considered malformed and the "treat-as- 344 withdraw" strategy of [RFC7606] is applied. 346 Multiple occurrences of "Segment List" MAY be encoded within the same 347 SR Policy. 349 Multiple occurrences of "Segment" MAY be encoded within the same 350 Segment List. 352 2.3. Remote Endpoint and Color 354 The Remote Endpoint and Color sub-TLVs, as defined in 355 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy 356 encodings. 358 The Remote Endpoint and Color Sub-TLVs are not used for SR Policy 359 encodings and therefore their value is irrelevant in the context of 360 the SR Policy SAFI NLRI. If present, the Remote Endpoint sub-TLV and 361 the Color sub-TLV MUST be ignored by the BGP speaker. 363 2.4. SR TE Policy Sub-TLVs 365 This section defines the SR Policy sub-TLVs. 367 Preference, Binding SID, Segment-List, Priority, Policy Name and 368 Explicit NULL Label Policy sub-TLVs are assigned from the "BGP Tunnel 369 Encapsulation Attribute Sub-TLVs" registry. 371 Weight and Segment sub-TLVs are assigned from a new registry defined 372 in this document and called: "SR Policy List Sub-TLVs". See 373 Section 8 for the details of the registry. 375 2.4.1. Preference Sub-TLV 377 The Preference sub-TLV does not have any effect on the BGP bestpath 378 selection or propagation procedures. The contents of this sub-TLV 379 are used by the SRTE process as described in section 2.9 in 380 ([I-D.filsfils-spring-segment-routing-policy]). 382 The Preference sub-TLV is optional and it MUST NOT appear more than 383 once in the SR Policy. If the Preference sub-TLV appears more than 384 once, the update is considered malformed and the "treat-as-withdraw" 385 strategy of [RFC7606] is applied. 387 The Preference sub-TLV has following format: 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Type | Length | Flags | RESERVED | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Preference (4 octets) | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 where: 399 o Type: 12 401 o Length: 6. 403 o Flags: 1 octet of flags. None are defined at this stage. Flags 404 SHOULD be set to zero on transmission and MUST be ignored on 405 receipt. 407 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 408 transmission and MUST be ignored on receipt. 410 o Preference: a 4-octet value. 412 2.4.2. SR TE Binding SID Sub-TLV 414 The Binding SID sub-TLV is not used by BGP. The contents of this 415 sub-TLV are used by the SRTE process as described in section 6 in 416 ([I-D.filsfils-spring-segment-routing-policy]). 418 The Binding SID sub-TLV is optional and it MUST NOT appear more than 419 once in the SR Policy. If the Binding SID sub-TLV appears more than 420 once, the update is considered malformed and the "treat-as-withdraw" 421 strategy of [RFC7606] is applied. 423 The Binding SID sub-TLV has the following format: 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type | Length | Flags | RESERVED | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Binding SID (variable, optional) | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 where: 435 o Type: 13 437 o Length: specifies the length of the value field not including Type 438 and Length fields. Can be 2 or 6 or 18. 440 o Flags: 1 octet of flags. Following flags are defined (to be 441 assigned by IANA from the registry "SR Policy Binding SID Flags" 442 defined in this document Section 8.5): 444 0 1 2 3 4 5 6 7 445 +-+-+-+-+-+-+-+-+ 446 |S|I| | 447 +-+-+-+-+-+-+-+-+ 449 where: 451 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 452 It is used by SRTE process as described in section 6.2.3 in 453 ([I-D.filsfils-spring-segment-routing-policy]). 455 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 456 is used by SRTE process as described in section 8.2 in 457 ([I-D.filsfils-spring-segment-routing-policy]). 459 * Unused bits in the Flag octet SHOULD be set to zero upon 460 transmission and MUST be ignored upon receipt. 462 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 463 transmission and MUST be ignored on receipt. 465 o Binding SID: if length is 2, then no Binding SID is present. 467 o If length is 6 then the Binding SID contains a 4-octet SID. Below 468 format is used to encode the SID. TC, S, TTL(Total of 12bits) are 469 RESERVED and SHOULD be set to Zero and MUST be ignored. 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Label | TC |S| TTL | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 If length is 18 then the Binding SID contains a 16-octet IPv6 SID. 479 2.4.3. Segment List Sub-TLV 481 The Segment List sub-TLV encodes a single explicit path towards the 482 endpoint as described in section 5.1 in 483 ([I-D.filsfils-spring-segment-routing-policy]). The Segment List 484 sub-TLV includes the elements of the paths (i.e., segments) as well 485 as an optional Weight sub-TLV. 487 The Segment List sub-TLV may exceed 255 bytes length due to large 488 number of segments. Therefore a 2-octet length is required. 489 According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- 490 TLV codepoint defines the size of the length field. Therefore, for 491 the Segment List sub-TLV a code point of 128 (or higher) is used. 492 See Section 8 for details of codepoints allocation. 494 The Segment List sub-TLV is optional and MAY appear multiple times in 495 the SR Policy. The ordering of Segment List sub-TLVs, each sub-TLV 496 encoding a Segment List, does not matter. 498 The Segment List sub-TLV contains zero or more Segment sub-TLVs and 499 MAY contain a Weight sub-TLV. 501 The Segment List sub-TLV has the following format: 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type | Length | RESERVED | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 // sub-TLVs // 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 where: 513 o Type: 128. 515 o Length: the total length (not including the Type and Length 516 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 518 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 519 transmission and MUST be ignored on receipt. 521 o sub-TLVs: 523 * An optional single Weight sub-TLV. 525 * Zero or more Segment sub-TLVs. 527 Validation of an explicit path encoded by the Segment List sub-TLV is 528 completely within the scope of SRTE process as described in section 5 529 in ([I-D.filsfils-spring-segment-routing-policy]). 531 2.4.3.1. Weight Sub-TLV 533 The Weight sub-TLV specifies the weight associated to a given 534 candidate path (i.e., a given segment list). The contents of this 535 sub-TLV are used only by the SRTE process as described in section 536 2.11 in ([I-D.filsfils-spring-segment-routing-policy]). 538 The Weight sub-TLV is optional and it MUST NOT appear more than once 539 inside the Segment List sub-TLV. If the Weight sub-TLV appears more 540 than once, the update is considered malformed and the "treat-as- 541 withdraw" strategy of [RFC7606] is applied. 543 The Weight sub-TLV has the following format: 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Type | Length | Flags | RESERVED | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Weight | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 where: 555 Type: 9 (to be assigned by IANA from the registry "SR Policy List 556 Sub-TLVs" defined in this document). 558 Length: 6. 560 Flags: 1 octet of flags. None are defined at this stage. Flags 561 SHOULD be set to zero on transmission and MUST be ignored on receipt. 563 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 564 and MUST be ignored on receipt. 566 2.4.3.2. Segment Sub-TLV 568 The Segment sub-TLV describes a single segment in a segment list 569 (i.e., a single element of the explicit path). Multiple Segment sub- 570 TLVs constitute an explicit path of the SR Policy. 572 The Segment sub-TLV is optional and MAY appear multiple times in the 573 Segment List sub-TLV. 575 The Segment sub-TLV does not have any effect on the BGP bestpath 576 selection or propagation procedures. The contents of this sub-TLV 577 are used only by the SRTE process as described in section 4 in 578 ([I-D.filsfils-spring-segment-routing-policy]). 580 [I-D.filsfils-spring-segment-routing-policy] defines several types of 581 Segments: 583 Type 1: SID only, in the form of MPLS Label 584 Type 2: SID only, in the form of IPv6 address 585 Type 3: IPv4 Node Address with optional SID 586 Type 4: IPv6 Node Address with optional SID for SR MPLS 587 Type 5: IPv4 Address + index with optional SID 588 Type 6: IPv4 Local and Remote addresses with optional SID 589 Type 7: IPv6 Address + index for local and remote pair with optional SID for SR MPLS 590 Type 8: IPv6 Local and Remote addresses with optional SID for SR MPLS 591 Type 9: IPv6 Node Address with optional SID for SRv6 592 Type 10: IPv6 Address + index for local and remote pair with optional SID for SRv6 593 Type 11: IPv6 Local and Remote addresses for SRv6 595 2.4.3.2.1. Type 1: SID only, in the form of MPLS Label 597 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 598 MPLS label. The format is as follows: 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type | Length | Flags | RESERVED | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Label | TC |S| TTL | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 where: 610 o Type: 1 (to be assigned by IANA from the registry "SR Policy List 611 Sub-TLVs" defined in this document). 613 o Length is 6. 615 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 617 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 618 transmission and MUST be ignored on receipt. 620 o Label: 20 bits of label value. 622 o TC: 3 bits of traffic class. 624 o S: 1 bit of bottom-of-stack. 626 o TTL: 1 octet of TTL. 628 The following applies to the Type-1 Segment sub-TLV: 630 o The S bit SHOULD be zero upon transmission, and MUST be ignored 631 upon reception. 633 o If the originator wants the receiver to choose the TC value, it 634 sets the TC field to zero. 636 o If the originator wants the receiver to choose the TTL value, it 637 sets the TTL field to 255. 639 o If the originator wants to recommend a value for these fields, it 640 puts those values in the TC and/or TTL fields. 642 o The receiver MAY override the originator's values for these 643 fields. This would be determined by local policy at the receiver. 644 One possible policy would be to override the fields only if the 645 fields have the default values specified above. 647 2.4.3.2.2. Type 2: SID only, in the form of IPv6 address 649 The Type-2 Segment Sub-TLV encodes a single SRv6 SID in the form of 650 an IPv6 address. The format is as follows: 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Type | Length | Flags | RESERVED | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 // SRv6 SID (16 octets) // 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 where: 662 o Type: 2 (to be assigned by IANA from the registry "SR Policy List 663 Sub-TLVs" defined in this document). 665 o Length is 18. 667 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 669 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 670 transmission and MUST be ignored on receipt. 672 o SRv6 SID: 16 octets of IPv6 address. 674 The IPv6 Segment Identifier (SRv6 SID) is defined in 675 [I-D.ietf-6man-segment-routing-header]. 677 2.4.3.2.3. Type 3: IPv4 Node Address with optional SID 679 The Type-3 Segment Sub-TLV encodes an IPv4 node address, SR Algorithm 680 and an optional SID in the form of an MPLS label. The format is as 681 follows: 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Type | Length | Flags | SR Algorithm | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | IPv4 Node Address (4 octets) | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | SID (optional, 4 octets) | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 where: 695 o Type: 3 (to be assigned by IANA from the registry "SR Policy List 696 Sub-TLVs" defined in this document). 698 o Length is 6 or 10. 700 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 702 o SR Algorithm: 1 octet specifying SR Algorithm as described in 703 section 3.1.1 in [I-D.ietf-spring-segment-routing], when A-Flag as 704 defined in Section 2.4.3.2.12 is present. SR Algorithm is used by 705 SRTE process as described in section 4 in 706 ([I-D.filsfils-spring-segment-routing-policy]). When A-Flag is 707 not encoded, this field SHOULD be unset on transmission and MUST 708 be ignored on receipt. 710 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 712 o SID: 4 octet MPLS label. 714 The following applies to the Type-3 Segment sub-TLV: 716 o The IPv4 Node Address MUST be present. 718 o The SID is optional and specifies a 4 octet MPLS SID containing 719 label, TC, S and TTL as defined in Section 2.4.3.2.1. 721 o If length is 6, then only the IPv4 Node Address is present. 723 o If length is 10, then the IPv4 Node Address and the MPLS SID are 724 present. 726 2.4.3.2.4. Type 4: IPv6 Node Address with optional SID for SR MPLS 728 The Type-4 Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 729 and an optional SID in the form of an MPLS label. The format is as 730 follows: 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Type | Length | Flags | SR Algorithm | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 // IPv6 Node Address (16 octets) // 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | SID (optional, 4 octets) | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 where: 744 o Type: 4 (to be assigned by IANA from the registry "SR Policy List 745 Sub-TLVs" defined in this document). 747 o Length is 18 or 22. 749 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 751 o SR Algorithm: 1 octet specifying SR Algorithm as described in 752 section 3.1.1 in [I-D.ietf-spring-segment-routing], when A-Flag as 753 defined in Section 2.4.3.2.12 is present. SR Algorithm is used by 754 SRTE process as described in section 4 in 755 ([I-D.filsfils-spring-segment-routing-policy]). When A-Flag is 756 not encoded, this field SHOULD be unset on transmission and MUST 757 be ignored on receipt. 759 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 761 o SID: 4 octet MPLS label. 763 The following applies to the Type-4 Segment sub-TLV: 765 o The IPv6 Node Address MUST be present. 767 o The SID is optional and specifies a 4 octet MPLS SID containing 768 label, TC, S and TTL as defined in Section 2.4.3.2.1. 770 o If length is 18, then only the IPv6 Node Address is present. 772 o If length is 22, then the IPv6 Node Address and the MPLS SID are 773 present. 775 2.4.3.2.5. Type 5: IPv4 Address + Local Interface ID with optional SID 777 The Type-5 Segment Sub-TLV encodes an IPv4 node address, a local 778 interface Identifier (Local Interface ID) and an optional SID in the 779 form of an MPLS label. The format is as follows: 781 0 1 2 3 782 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 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Type | Length | Flags | RESERVED | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Local Interface ID (4 octets) | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | IPv4 Node Address (4 octets) | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | SID (optional, 4 octets) | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 where: 795 o Type: 5 (to be assigned by IANA from the registry "SR Policy List 796 Sub-TLVs" defined in this document). 798 o Length is 10 or 14. 800 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 802 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 803 transmission and MUST be ignored on receipt. 805 o Local Interface ID: 4 octets of interface index as defined in 806 [I-D.ietf-pce-segment-routing]. 808 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 810 o SID: 4 octet MPLS label. 812 The following applies to the Type-5 Segment sub-TLV: 814 o The IPv4 Node Address MUST be present. 816 o The Local Interface ID MUST be present. 818 o The SID is optional and specifies a 4 octet MPLS SID containing 819 label, TC, S and TTL as defined in Section 2.4.3.2.1. 821 o If length is 10, then the IPv4 Node Address and Local Interface ID 822 are present. 824 o If length is 14, then the IPv4 Node Address, the Local Interface 825 ID and the MPLS SID are present. 827 2.4.3.2.6. Type 6: IPv4 Local and Remote addresses with optional SID 829 The Type-6 Segment Sub-TLV encodes an adjacency local address, an 830 adjacency remote address and an optional SID in the form of an MPLS 831 label. The format is as follows: 833 0 1 2 3 834 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 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Type | Length | Flags | RESERVED | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Local IPv4 Address (4 octets) | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Remote IPv4 Address (4 octets) | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | SID (optional, 4 octets) | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 where: 847 o Type: 6 (to be assigned by IANA from the registry "SR Policy List 848 Sub-TLVs" defined in this document). 850 o Length is 10 or 14. 852 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 854 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 855 transmission and MUST be ignored on receipt. 857 o Local IPv4 Address: a 4 octet IPv4 address. 859 o Remote IPv4 Address: a 4 octet IPv4 address. 861 o SID: 4 octet MPLS label. 863 The following applies to the Type-6 Segment sub-TLV: 865 o The Local IPv4 Address MUST be present and represents an adjacency 866 local address. 868 o The Remote IPv4 Address MUST be present and represents the remote 869 end of the adjacency. 871 o The SID is optional and specifies a 4 octet MPLS SID containing 872 label, TC, S and TTL as defined in Section 2.4.3.2.1. 874 o If length is 10, then only the IPv4 Local and Remote addresses are 875 present. 877 o If length is 14, then the IPv4 Local address, IPv4 Remote address 878 and the MPLS SID are present. 880 2.4.3.2.7. Type 7: IPv6 Address + Interface ID for local and remote 881 pair with optional SID for SR MPLS 883 The Type-7 Segment Sub-TLV encodes an IPv6 Link Local adjacency with 884 IPv6 local node address, a local interface identifier (Local 885 Interface ID), IPv6 remote node address , a remote interface 886 identifier (Remote Interface ID) and an optional SID in the form of 887 an MPLS label. The format is as follows: 889 0 1 2 3 890 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 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Type | Length | Flags | RESERVED | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Local Interface ID (4 octets) | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 // IPv6 Local Node Address (16 octets) // 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Remote Interface ID (4 octets) | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 // IPv6 Remote Node Address (16 octets) // 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | SID (optional, 4 octets) | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 where: 907 o Type: 7 (to be assigned by IANA from the registry "SR Policy List 908 Sub-TLVs" defined in this document). 910 o Length is 22, 26, 42 or 46. 912 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 914 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 915 transmission and MUST be ignored on receipt. 917 o Local Interface ID: 4 octets of interface index as defined in 918 [I-D.ietf-pce-segment-routing]. 920 o IPv6 Local Node Address: a 16 octet IPv6 address. 922 o Remote Interface ID: 4 octets of interface index as defined in 923 [I-D.ietf-pce-segment-routing]. 925 o IPv6 Remote Node Address: a 16 octet IPv6 address. 927 o SID: 4 octet MPLS label. 929 The following applies to the Type-7 Segment sub-TLV: 931 o The Local Interface ID and IPv6 Local Node Address MUST be 932 present. 934 o The Remote Interface ID and Remote Node Address pair is optional. 935 If Remote Interface ID is present, the Remote Node Address MUST be 936 present as well. Similarly, if Remote Node Address is present, 937 the Remote Interface ID MUST be present as well. 939 o The SID is optional and specifies a 4 octet MPLS SID containing 940 label, TC, S and TTL as defined in Section 2.4.3.2.1. 942 o If length is 22, then the Local Interface ID and the Local IPv6 943 Address are present. 945 o If length is 26, then the Local Interface ID, Local IPv6 Address 946 and the MPLS SID are present. 948 o If length is 42, then the Local Interface ID, Local IPv6 Node 949 Address, Remote Interface ID, and the Remote IPv6 Node Address are 950 present. 952 o If length is 46, then the Local Interface ID, Local IPv6 Node 953 Address, Remote Interface ID, Remote IPv6 Node Address and the 954 MPLS SID are present. 956 2.4.3.2.8. Type 8: IPv6 Local and Remote addresses with optional SID 957 for SR MPLS 959 The Type-8 Segment Sub-TLV encodes an adjacency local address, an 960 adjacency remote address and an optional SID in the form of an MPLS 961 label. The format is as follows: 963 0 1 2 3 964 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 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Type | Length | Flags | RESERVED | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 // Local IPv6 Address (16 octets) // 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 // Remote IPv6 Address (16 octets) // 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | SID (optional, 4 octets) | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 where: 977 o Type: 8 (to be assigned by IANA from the registry "SR Policy List 978 Sub-TLVs" defined in this document). 980 o Length is 34 or 38. 982 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 984 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 985 transmission and MUST be ignored on receipt. 987 o Local IPv6 Address: a 16 octet IPv6 address. 989 o Remote IPv6 Address: a 16 octet IPv6 address. 991 o SID: 4 octet MPLS label. 993 The following applies to the Type-8 Segment sub-TLV: 995 o The Local IPv6 Address MUST be present and represents an adjacency 996 local address. 998 o The Remote IPv6 Address MUST be present and represents the remote 999 end of the adjacency. 1001 o The SID is optional and specifies a 4 octet MPLS SID containing 1002 label, TC, S and TTL as defined in Section 2.4.3.2.1. 1004 o If length is 34, then only the IPv6 Local and Remote addresses are 1005 present. 1007 o If length is 38, then IPv6 Local and Remote addresses and the MPLS 1008 SID are present. 1010 2.4.3.2.9. Type 9: IPv6 Node Address with optional SRv6 SID 1012 The Type-9 Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 1013 and an optional SID in the form of an IPv6 address. The format is as 1014 follows: 1016 0 1 2 3 1017 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 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Type | Length | Flags | SR Algorithm | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 // IPv6 Node Address (16 octets) // 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 // SID (optional, 16 octets) // 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 where: 1028 o Type: 10 (to be assigned by IANA from the registry "SR Policy List 1029 Sub-TLVs" defined in this document). 1031 o Length is 18 or 34. 1033 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 1035 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1036 section 3.1.1 in [I-D.ietf-spring-segment-routing], when A-Flag as 1037 defined in Section 2.4.3.2.12 is present. SR Algorithm is used by 1038 SRTE process as described in section 4 in 1039 ([I-D.filsfils-spring-segment-routing-policy]). When A-Flag is 1040 not encoded, this field SHOULD be unset on transmission and MUST 1041 be ignored on receipt. 1043 o IPv6 Node Address: a 16 octet IPv6 address. 1045 o SID: 16 octet IPv6 address. 1047 The following applies to the Type-9 Segment sub-TLV: 1049 o The IPv6 Node Address MUST be present. 1051 o The SID is optional and specifies a SRv6 SID in the form of 16 1052 octet IPv6 address. 1054 o If length is 18, then only the IPv6 Node Address is present. 1056 o If length is 34, then the IPv6 Node Address and the SRv6 SID are 1057 present. 1059 2.4.3.2.10. Type 10: IPv6 Address + Interface ID for local and remote 1060 pair for SRv6 with optional SID 1062 The Type-10 Segment Sub-TLV encodes an IPv6 Link Local adjacency with 1063 local node address, a local interface identifier (Local Interface 1064 ID), remote IPv6 node address , a remote interface identifier (Remote 1065 Interface ID) and an optional SID in the form of an IPv6 address. 1066 The format is as follows: 1068 0 1 2 3 1069 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 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Type | Length | Flags | RESERVED | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Local Interface ID (4 octets) | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 // IPv6 Local Node Address (16 octets) // 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Remote Interface ID (4 octets) | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 // IPv6 Remote Node Address (16 octets) // 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 // SID (optional, 16 octets) // 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 where: 1086 o Type: 11 (to be assigned by IANA from the registry "SR Policy List 1087 Sub-TLVs" defined in this document). 1089 o Length is 22, 38, 42 or 58. 1091 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 1093 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 1094 transmission and MUST be ignored on receipt. 1096 o Local Interface ID: 4 octets of interface index as defined in 1097 [I-D.ietf-pce-segment-routing]. 1099 o IPv6 Local Node Address: a 16 octet IPv6 address. 1101 o Remote Interface ID: 4 octets of interface index as defined in 1102 [I-D.ietf-pce-segment-routing]. 1104 o IPv6 Remote Node Address: a 16 octet IPv6 address. 1106 o SID: 16 octet IPv6 address. 1108 The following applies to the Type-10 Segment sub-TLV: 1110 o The Local Interface ID and the Local IPv6 Node Addresses MUST be 1111 present. 1113 o The Remote Interface ID and Remote Node Address pair is optional. 1114 If Remote Interface ID is present, the Remote Node Address MUST be 1115 present as well. Similarly, if Remote Node Address is present, 1116 the Remote Interface ID MUST be present as well. 1118 o The SID is optional and specifies a SRv6 SID in the form of 16 1119 octet IPv6 address. 1121 o If length is 22, then the Local Interface ID, Local IPv6 Node 1122 Address, are present. 1124 o If length is 38, then the Local Interface ID, Local IPv6 Node 1125 Address and the SRv6 SID are present. 1127 o If length is 42, then the Local Interface ID, Local IPv6 Node 1128 Address, Remote Interface ID, and the Remote IPv6 Node Address are 1129 present. 1131 o If length is 58, then the Local Interface ID, Local IPv6 Node 1132 Address, Remote Interface ID, Remote IPv6 Node Address and the 1133 SRv6 SID are present. 1135 2.4.3.2.11. Type 11: IPv6 Local and Remote addresses for SRv6 with 1136 optional SID 1138 The Type-11 Segment Sub-TLV encodes an adjacency local address, an 1139 adjacency remote address and an optional SID in the form of IPv6 1140 address. The format is as follows: 1142 0 1 2 3 1143 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 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Type | Length | Flags | RESERVED | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 // Local IPv6 Address (16 octets) // 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 // Remote IPv6 Address (16 octets) // 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 // SID (optional, 16 octets) // 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 where: 1155 o Type: 12 (to be assigned by IANA from the registry "SR Policy List 1156 Sub-TLVs" defined in this document). 1158 o Length is 34 or 50. 1160 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 1162 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 1163 transmission and MUST be ignored on receipt. 1165 o Local IPv6 Address: a 16 octet IPv6 address. 1167 o Remote IPv6 Address: a 16 octet IPv6 address. 1169 o SID: 16 octet IPv6 address. 1171 The following applies to the Type-11 Segment sub-TLV: 1173 o The Local IPv6 Node Address MUST be present. 1175 o The Remote IPv6 Node Address MUST be present. 1177 o The SID is optional and specifies a SRv6 SID in the form of 16 1178 octet IPv6 address. 1180 o If length is 34, then the Local IPv6 Node Address and the Remote 1181 IPv6 Node Address are present. 1183 o If length is 50, then the Local IPv6 Node Address, the Remote IPv6 1184 Node Address and the SRv6 SID are present. 1186 2.4.3.2.12. Segment Flags 1188 The Segment Types described above MAY contain following flags in the 1189 "Flags" field (codes to be assigned by IANA from the registry "SR 1190 Policy Segment Flags" defined in this document Section 8.6): 1192 0 1 2 3 4 5 6 7 1193 +-+-+-+-+-+-+-+-+ 1194 |V|A| | 1195 +-+-+-+-+-+-+-+-+ 1197 where: 1199 V-Flag: This flag encodes the "Segment Validation" behavior. It 1200 is used by SRTE process as described in section 5 in 1201 ([I-D.filsfils-spring-segment-routing-policy]). 1203 A-Flag: This flag indicates the presence of SR Algorithm id in the 1204 "SR Algorithm" field applicable to various Segment Types. SR 1205 Algorithm is used by SRTE process as described in section 4 in 1206 ([I-D.filsfils-spring-segment-routing-policy]). 1208 Unused bits in the Flag octet SHOULD be set to zero upon 1209 transmission and MUST be ignored upon receipt. 1211 The following applies to the Segment Flags: 1213 o V-Flag is applicable to all Segment Types. 1215 o A-Flag is applicable to Segment Types 3, 4 and 9. If A-Flag 1216 appears with any other Segment Type, it MUST be ignored. 1218 2.4.4. Explicit NULL Label Policy Sub-TLV 1220 In order to steer an unlabeled IP packet into an SR policy, it is 1221 necessary to create a label stack for that packet, and to push one or 1222 more labels onto that stack. 1224 The Explicit NULL Label Policy sub-TLV is used to indicate whether an 1225 Explicit NULL Label [RFC3032] must be pushed on an unlabeled IP 1226 packet before any other labels. 1228 If an Explicit NULL Label Policy Sub-TLV is not present, the decision 1229 of whether to push an Explicit NULL label on a given packet is a 1230 matter of local policy. 1232 The contents of this sub-TLV are used by the SRTE process as 1233 described in section 4.1 in 1234 [I-D.filsfils-spring-segment-routing-policy]. 1236 0 1 2 3 1237 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 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 | Type | Length | Flags | RESERVED | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 | ENLP | 1242 +-+-+-+-+-+-+-+-+ 1244 Where: 1246 Type: TBD1 (to be assigned by IANA from the registry "BGP Tunnel 1247 Encapsulation Attribute sub-TLVs" defined in this document 1248 Section 8.3). 1250 Length: 3. 1252 Flags: 1 octet of flags. None are defined at this stage. Flags 1253 SHOULD be set to zero on transmission and MUST be ignored on 1254 receipt. 1256 RESERVED: 1 octet of reserved bits. SHOULD be unset on 1257 transmission and MUST be ignored on receipt. 1259 ENLP(Explicit NULL Label Policy): Indicates whether Explicit NULL 1260 labels are to be pushed on unlabeled IP packets that are being 1261 steered into a given SR policy. This field has one of the 1262 following 4 values: 1264 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1265 packet, but do not push an IPv6 Explicit NULL label on an 1266 unlabeled IPv6 packet. 1268 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 1269 packet, but do not push an IPv4 Explicit NULL label on an 1270 unlabeled IPv4 packet. 1272 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1273 packet, and push an IPv6 Explicit NULL label on an unlabeled 1274 IPv6 packet. 1276 4: Do not push an Explicit NULL label. 1278 The policy signaled in this Sub-TLV MAY be overridden by local 1279 policy. 1281 2.4.5. Policy Priority Sub-TLV 1283 An operator MAY set the Policy Priority sub-TLV to indicate the order 1284 in which the SR policies are re-computed upon topological change. 1286 The Priority sub-TLV does not have any effect on the BGP bestpath 1287 selection or propagation procedures. The contents of this sub-TLV 1288 are used by the SRTE process as described in section 2.11 in 1289 ([I-D.filsfils-spring-segment-routing-policy]). 1291 The Priority sub-TLV is optional and it MUST not appear more than 1292 once in the SR Policy TLV. If the Priority sub-TLV appears more than 1293 once, the update is considered malformed and the "treat-as-withdraw" 1294 strategy of [RFC7606] is applied. 1296 The Priority sub-TLV has following format: 1298 0 1 2 3 1299 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 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | Type | Length | Priority | RESERVED | 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 Where: 1306 Type: TBD2 (to be assigned by IANA from the registry "BGP Tunnel 1307 Encapsulation Attribute sub-TLVs" defined in this document 1308 Section 8.3). 1310 Length: 2. 1312 Priority: a 1-octet value. 1314 RESERVED: 1 octet of reserved bits. SHOULD be unset on 1315 transmission and MUST be ignored on receipt. 1317 2.4.6. Policy Name Sub-TLV 1319 An operator MAY set the Policy Name sub-TLV to attach a symbolic name 1320 to the SR Policy candidate path. 1322 Usage of Policy Name sub-TLV is described in section 2 in 1323 ([I-D.filsfils-spring-segment-routing-policy]). 1325 The Policy Name sub-TLV may exceed 255 bytes length due to long 1326 policy name. Therefore a 2-octet length is required. According to 1327 [I-D.ietf-idr-tunnel-encaps], the first bit of the sub-TLV codepoint 1328 defines the size of the length field. Therefore, for the Policy Name 1329 sub-TLV a code point of 128 (or higher) is used. See Section 8 for 1330 details of codepoints allocation. 1332 The Policy Name sub-TLV is optional and it MUST not appear more than 1333 once in the SR Policy TLV. If the Policy Name sub-TLV appears more 1334 than once, the update is considered malformed and the "treat-as- 1335 withdraw" strategy of [RFC7606] is applied. 1337 The Policy Name sub-TLV has following format: 1339 0 1 2 3 1340 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 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | Type | Length | RESERVED | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 // Policy Name // 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 Where: 1348 Type: TBD3 (to be assigned by IANA from the registry "BGP Tunnel 1349 Encapsulation Attribute sub-TLVs" defined in this document 1350 Section 8.3). 1352 Length: Variable. 1354 RESERVED: 1 octet of reserved bits. SHOULD be unset on 1355 transmission and MUST be ignored on receipt. 1357 Policy Name: Symbolic name for the policy. It SHOULD be a string 1358 of printable ASCII characters, without a NULL terminator. 1360 3. Extended Color Community 1362 The Color Extended Community as defined in 1363 [I-D.ietf-idr-tunnel-encaps] is used to steer traffic into a policy. 1365 When the Color Extended Community is used for the purpose of steering 1366 the traffic into an SRTE policy, the RESERVED field (as defined in 1367 [I-D.ietf-idr-tunnel-encaps] is changed as follows: 1369 1 1370 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 |C O| RESERVED | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 where CO bits are defined as the "Color-Only" bits. 1376 [I-D.filsfils-spring-segment-routing-policy]defines the influence of 1377 these bits on the automated steering of BGP Payload traffic onto SRTE 1378 policies. 1380 4. SR Policy Operations 1382 As described in this document, the consumer of a SR Policy NLRI is 1383 not the BGP process. The BGP process is in charge of the origination 1384 and propagation of the SR Policy NLRI but its installation and use is 1385 outside the scope of BGP 1386 ([I-D.filsfils-spring-segment-routing-policy]). 1388 4.1. Configuration and Advertisement of SR TE Policies 1390 Typically, but not limited to, an SR Policy is configured into a 1391 controller. 1393 Multiple SR Policy NLRIs may be present with the same tuple but with different content when these SR policies are 1395 intended to different head-ends. 1397 The distinguisher of each SR Policy NLRI prevents undesired BGP route 1398 selection among these SR Policy NLRIs and allow their propagation 1399 across route reflectors [RFC4456]. 1401 Moreover, one or more route-target SHOULD be attached to the 1402 advertisement, where each route-target identifies one or more 1403 intended head-ends for the advertised SR policy. 1405 If no route-target is attached to the SR Policy NLRI, then it is 1406 assumed that the originator sends the SR Policy update directly 1407 (e.g., through a BGP session) to the intended receiver. In such 1408 case, the NO_ADVERTISE community MUST be attached to the SR Policy 1409 update. 1411 4.2. Reception of an SR Policy NLRI 1413 On reception of an SR Policy NLRI, a BGP speaker MUST determine if 1414 it's first acceptable, then it determines if it is usable. 1416 4.2.1. Acceptance of an SR Policy NLRI 1418 When a BGP speaker receives an SR Policy NLRI from a neighbor it has 1419 to determine if it's acceptable. The following applies: 1421 o The SR Policy NLRI MUST include a distinguisher, color and 1422 endpoint field which implies that the length of the NLRI MUST be 1423 either 12 or 24 octets (depending on the address family of the 1424 endpoint). 1426 o The SR Policy update MUST have either the NO_ADVERTISE community 1427 or at least one route-target extended community in IPv4-address 1428 format. If a router supporting this document receives an SR 1429 policy update with no route-target extended communities and no 1430 NO_ADVERTISE community, the update MUST NOT be sent to the SRTE 1431 process. Furthermore, it SHOULD be considered to be malformed, 1432 and the "treat-as-withdraw" strategy of [RFC7606] is applied. 1434 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1435 Update and MUST have a Tunnel Type TLV set to SR Policy ( 1436 codepoint is 15, assigned by IANA (see Section 8) from the "BGP 1437 Tunnel Encapsulation Attribute Tunnel Types" registry). 1439 A router that receives an SR Policy update that is not valid 1440 according to these criteria MUST treat the update as malformed. The 1441 route MUST NOT be passed to the SRTE process, and the "treat-as- 1442 withdraw" strategy of [RFC7606] is applied. 1444 A unacceptable SR Policy update that has a valid NLRI portion with 1445 invalid attribute portion MUST be considered as a withdraw of the SR 1446 Policy. 1448 4.2.2. Usable SR Policy NLRI 1450 If one or more route-targets are present, then at least one route- 1451 target MUST match one of the BGP Identifiers of the receiver in order 1452 for the update to be considered usable. The BGP Identifier is 1453 defined in [RFC4271] as a 4 octet IPv4 address. Therefore the route- 1454 target extended community MUST be of the same format. 1456 If one or more route-targets are present and no one matches any of 1457 the local BGP Identifiers, then, while the SR Policy NLRI is 1458 acceptable, it is not usable. It has to be noted that if the 1459 receiver has been explicitly configured to do so, it MAY propagate 1460 the SR Policy NLRI to its neighbors as defined in Section 4.2.4. 1462 Usable SR Policy NLRIs are sent to the Segment Routing Traffic 1463 Engineering (SRTE) process. The description of the SRTE process is 1464 outside the scope of this document and it's described in 1465 [I-D.filsfils-spring-segment-routing-policy]. 1467 4.2.3. Passing a usable SR Policy NLRI to the SRTE Process 1469 Once BGP has determined that the SR Policy NLRI is usable, BGP passes 1470 the path to the SRTE process described in 1471 ([I-D.filsfils-spring-segment-routing-policy]). Note that, along 1472 with the path details, BGP also passes the originator information for 1473 breaking ties in the path-selection process as described in section 1474 2.4 in [I-D.filsfils-spring-segment-routing-policy]. 1476 The SRTE process applies the rules defined in section 2 1477 [I-D.filsfils-spring-segment-routing-policy] to determine whether a 1478 path is valid and to select the best path among the valid paths. 1480 4.2.4. Propagation of an SR Policy 1482 By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate 1483 it to any EBGP neighbor. 1485 However, a node MAY be explicitly configured to advertise a received 1486 SR Policy NLRI to neighbors according to normal BGP rules (i.e., EBGP 1487 propagation by an ASBR or iBGP propagation by a Route-Reflector). 1489 SR Policy NLRIs that have been determined acceptable and valid can be 1490 propagated, even the ones that are not usable. 1492 Only SR Policy NLRIs that do not have the NO_ADVERTISE community 1493 attached to them can be propagated. 1495 4.3. Flowspec and SR Policies 1497 The SR Policy can be carried in context of a Flowspec NLRI 1498 ([RFC5575]). In this case, when the redirect to IP next-hop is 1499 specified as in [I-D.ietf-idr-flowspec-redirect-ip], the tunnel to 1500 the next-hop is specified by the segment list in the Segment List 1501 sub-TLVs. The Segment List (e.g., label stack or IPv6 segment list) 1502 is imposed to flows matching the criteria in the Flowspec route to 1503 steer them towards the next-hop as specified in the SR Policy SAFI 1504 NLRI. 1506 5. Contributors 1508 Arjun Sreekantiah 1509 Cisco Systems 1510 US 1512 Email: asreekan@cisco.com 1514 Acee Lindem 1515 Cisco Systems 1516 US 1518 Email: acee@cisco.com 1520 Siva Sivabalan 1521 Cisco Systems 1522 US 1524 Email: msiva@cisco.com 1526 Imtiyaz Mohammad 1527 Arista Networks 1528 India 1530 Email: imtiyaz@arista.com 1532 Gaurav Dawra 1533 Cisco Systems 1534 US 1536 Email: gdawra.ietf@gmail.com 1538 6. Acknowledgments 1540 The authors of this document would like to thank Shyam Sethuram, John 1541 Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha and Ketan 1542 Talaulikar for their comments and review of this document. 1544 7. Implementation Status 1546 Note to RFC Editor: Please remove this section prior to publication, 1547 as well as the reference to RFC 7942. 1549 This section records the status of known implementations of the 1550 protocol defined by this specification at the time of posting of this 1551 Internet-Draft, and is based on a proposal described in [RFC7942]. 1552 The description of implementations in this section is intended to 1553 assist the IETF in its decision processes in progressing drafts to 1554 RFCs. Please note that the listing of any individual implementation 1555 here does not imply endorsement by the IETF. Furthermore, no effort 1556 has been spent to verify the information presented here that was 1557 supplied by IETF contributors. This is not intended as, and must not 1558 be construed to be, a catalog of available implementations or their 1559 features. Readers are advised to note that other implementations may 1560 exist. 1562 According to [RFC7942], "this will allow reviewers and working groups 1563 to assign due consideration to documents that have the benefit of 1564 running code, which may serve as evidence of valuable experimentation 1565 and feedback that have made the implemented protocols more mature. 1566 It is up to the individual working groups to use this information as 1567 they see fit". 1569 Several early implementations exist and will be reported in detail in 1570 a forthcoming version of this document. For purposes of early 1571 interoperability testing, when no FCFS code point was available, 1572 implementations have made use of the following values: 1574 o Preference sub-TLV: 12 1576 o Binding SID sub-TLV: 13 1578 o Segment List sub-TLV: 128 1580 When IANA-assigned values are available, implementations will be 1581 updated to use them. 1583 8. IANA Considerations 1585 This document defines new Sub-TLVs in following existing registries: 1587 o Subsequent Address Family Identifiers (SAFI) Parameters 1589 o BGP Tunnel Encapsulation Attribute Tunnel Types 1591 o BGP Tunnel Encapsulation Attribute sub-TLVs 1593 This document also defines following new registries: 1595 o SR Policy List Sub-TLVs 1597 o SR Policy Binding SID Flags 1599 o SR Policy Segment Flags 1601 8.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1602 Parameters 1604 This document defines a new SAFI in the registry "Subsequent Address 1605 Family Identifiers (SAFI) Parameters" that has been assigned by IANA: 1607 Codepoint Description Reference 1608 ----------------------------------------------- 1609 73 SR Policy SAFI This document 1611 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1613 This document defines a new Tunnel-Type in the registry "BGP Tunnel 1614 Encapsulation Attribute Tunnel Types" that has been assigned by IANA: 1616 Codepoint Description Reference 1617 -------------------------------------------------- 1618 15 SR Policy Type This document 1620 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1622 This document defines new sub-TLVs in the registry "BGP Tunnel 1623 Encapsulation Attribute sub-TLVs" to be assigned by IANA: 1625 Codepoint Description Reference 1626 ------------------------------------------------------ 1627 12 Preference sub-TLV This document 1628 13 Binding SID sub-TLV This document 1629 128 Segment List sub-TLV This document 1630 TBD1 ENLP sub-TLV This document 1631 TBD2 Priority sub-TLV This document 1632 TBD3 Policy Name sub-TLV This document 1634 8.4. New Registry: SR Policy List Sub-TLVs 1636 This document defines a new registry called "SR Policy List Sub- 1637 TLVs". The allocation policy of this registry is "First Come First 1638 Served (FCFS)" according to [RFC8126]. 1640 Following Sub-TLV codepoints are defined: 1642 Value Description Reference 1643 --------------------------------------------------------------------------------- 1644 1 MPLS SID sub-TLV This document 1645 2 SRv6 SID sub-TLV This document 1646 3 IPv4 Node and SID sub-TLV This document 1647 4 IPv6 Node and SID for SR-MPLS sub-TLV This document 1648 5 IPv4 Node, index and SID sub-TLV This document 1649 6 IPv4 Local/Remote addresses and SID sub-TLV This document 1650 7 IPv6 Node, index for remote and local pair This document 1651 and SID for SR-MPLS sub-TLV 1652 8 IPv6 Local/Remote addresses and SID sub-TLV This document 1653 9 Weight sub-TLV This document 1654 10 IPv6 Node and SID for SRv6 sub-TLV This document 1655 11 IPv6 Node, index for remote and local pair This document 1656 and SID for SRv6 sub-TLV 1657 12 IPv6 Local/Remote addresses and SID for This document 1658 SRv6 sub-TLV 1660 8.5. New Registry: SR Policy Binding SID Flags 1662 This document defines a new registry called "SR Policy Binding SID 1663 Flags". The allocation policy of this registry is "First Come First 1664 Served (FCFS)" according to [RFC8126]. 1666 Following Flags are defined: 1668 Bit Description Reference 1669 --------------------------------------------------------------------------------- 1670 0 Drop Upon Invalid Flag (I-Flag) This document 1671 1 Specified-BSID-Only Flag (S-Flag) This document 1672 2-7 Unassigned 1674 8.6. New Registry: SR Policy Segment Flags 1676 This document defines a new registry called "SR Policy Segment 1677 Flags". The allocation policy of this registry is "First Come First 1678 Served (FCFS)" according to [RFC8126]. 1680 Following Flags are defined: 1682 Bit Description Reference 1683 --------------------------------------------------------------------------------- 1684 0 Segment Validation Flag (V-Flag) This document 1685 1 SR Algorithm Flag (A-Flag) This document 1686 2-7 Unassigned 1688 9. Security Considerations 1690 TBD. 1692 10. References 1694 10.1. Normative References 1696 [I-D.filsfils-spring-segment-routing-policy] 1697 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 1698 F., Talaulikar, K., Ali, Z., Hegde, S., 1699 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 1700 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 1701 Litkowski, S., and P. Mattes, "Segment Routing Policy for 1702 Traffic Engineering", draft-filsfils-spring-segment- 1703 routing-policy-05 (work in progress), February 2018. 1705 [I-D.ietf-idr-tunnel-encaps] 1706 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 1707 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-09 1708 (work in progress), February 2018. 1710 [I-D.ietf-pce-segment-routing] 1711 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1712 and J. Hardwick, "PCEP Extensions for Segment Routing", 1713 draft-ietf-pce-segment-routing-11 (work in progress), 1714 November 2017. 1716 [I-D.ietf-spring-segment-routing] 1717 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1718 Litkowski, S., and R. Shakir, "Segment Routing 1719 Architecture", draft-ietf-spring-segment-routing-15 (work 1720 in progress), January 2018. 1722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1723 Requirement Levels", BCP 14, RFC 2119, 1724 DOI 10.17487/RFC2119, March 1997, 1725 . 1727 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1728 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1729 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1730 . 1732 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1733 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1734 DOI 10.17487/RFC4271, January 2006, 1735 . 1737 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1738 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1739 February 2006, . 1741 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1742 "Multiprotocol Extensions for BGP-4", RFC 4760, 1743 DOI 10.17487/RFC4760, January 2007, 1744 . 1746 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1747 and D. McPherson, "Dissemination of Flow Specification 1748 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1749 . 1751 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1752 Patel, "Revised Error Handling for BGP UPDATE Messages", 1753 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1754 . 1756 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1757 Writing an IANA Considerations Section in RFCs", BCP 26, 1758 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1759 . 1761 10.2. Informational References 1763 [I-D.ietf-6man-segment-routing-header] 1764 Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and 1765 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 1766 (SRH)", draft-ietf-6man-segment-routing-header-12 (work in 1767 progress), April 2018. 1769 [I-D.ietf-idr-flowspec-redirect-ip] 1770 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 1771 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 1772 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 1773 in progress), February 2015. 1775 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1776 Reflection: An Alternative to Full Mesh Internal BGP 1777 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1778 . 1780 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1781 Code: The Implementation Status Section", BCP 205, 1782 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1783 . 1785 Authors' Addresses 1787 Stefano Previdi (editor) 1788 Cisco Systems, Inc. 1789 IT 1791 Email: stefano@previdi.net 1793 Clarence Filsfils 1794 Cisco Systems, Inc. 1795 Brussels 1796 BE 1798 Email: cfilsfil@cisco.com 1800 Dhanendra Jain (editor) 1801 Cisco Systems, Inc. 1802 San Jose 1803 USA 1805 Email: dhjain@cisco.com 1807 Paul Mattes 1808 Microsoft 1809 One Microsoft Way 1810 Redmond, WA 98052 1811 USA 1813 Email: pamattes@microsoft.com 1814 Eric Rosen 1815 Juniper Networks 1816 10 Technology Park Drive 1817 Westford, MA 01886 1818 US 1820 Email: erosen@juniper.net 1822 Steven Lin 1823 Google 1825 Email: stevenlin@google.com