idnits 2.17.1 draft-ietf-idr-segment-routing-te-policy-07.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 -- The document date (July 5, 2019) is 1757 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-12 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-09) exists of draft-filsfils-spring-sr-policy-considerations-03 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi 3 Internet-Draft Individual 4 Intended status: Standards Track C. Filsfils 5 Expires: January 6, 2020 Cisco Systems, Inc. 6 P. Mattes 7 Microsoft 8 E. Rosen 9 Juniper Networks 10 D. Jain 11 S. Lin 12 Google 13 July 5, 2019 15 Advertising Segment Routing Policies in BGP 16 draft-ietf-idr-segment-routing-te-policy-07 18 Abstract 20 This document defines a new BGP SAFI with a new NLRI in order to 21 advertise a candidate path of a Segment Routing Policy (SR Policy). 22 An SR Policy is a set of candidate paths, each consisting of one or 23 more segment lists. The headend of an SR Policy may learn multiple 24 candidate paths for an SR Policy. Candidate paths may be learned via 25 a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. 26 This document specifies the way in which BGP may be used to 27 distribute candidate paths. New sub-TLVs for the Tunnel 28 Encapsulation Attribute are defined. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 6, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 66 2. SR Policy Encoding . . . . . . . . . . . . . . . . . . . . . 5 67 2.1. SR Policy SAFI and NLRI . . . . . . . . . . . . . . . . . 5 68 2.2. SR Policy and Tunnel Encapsulation Attribute . . . . . . 7 69 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 70 2.4. SR Policy Sub-TLVs . . . . . . . . . . . . . . . . . . . 9 71 2.4.1. Preference Sub-TLV . . . . . . . . . . . . . . . . . 9 72 2.4.2. Binding SID Sub-TLV . . . . . . . . . . . . . . . . . 10 73 2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 11 74 2.4.4. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 27 75 2.4.5. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 29 76 2.4.6. Policy Name Sub-TLV . . . . . . . . . . . . . . . . . 29 77 3. Extended Color Community . . . . . . . . . . . . . . . . . . 30 78 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 31 79 4.1. Configuration and Advertisement of SR Policies . . . . . 31 80 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 31 81 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 31 82 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 32 83 4.2.3. Passing a usable SR Policy NLRI to the SRPM . . . . . 32 84 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 33 85 4.3. Flowspec and SR Policies . . . . . . . . . . . . . . . . 33 86 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 87 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 88 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 34 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 90 8.1. Existing Registry: Subsequent Address Family Identifiers 91 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 36 92 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute 93 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 36 94 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute 95 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 36 96 8.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 36 97 8.5. New Registry: SR Policy Binding SID Flags . . . . . . . . 37 98 8.6. New Registry: SR Policy Segment Flags . . . . . . . . . . 37 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 100 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 101 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 102 10.2. Informational References . . . . . . . . . . . . . . . . 39 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 105 1. Introduction 107 Segment Routing (SR) allows a headend node to steer a packet flow 108 along any path. Intermediate per-flow states are eliminated thanks 109 to source routing [I-D.ietf-spring-segment-routing]. 111 The headend node is said to steer a flow into a Segment Routing 112 Policy (SR Policy). 114 The header of a packet steered in an SR Policy is augmented with the 115 ordered list of segments associated with that SR Policy. 117 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 118 Policy and steering into an SR Policy. These apply equally to the 119 MPLS and SRv6 instantiations of segment routing. 121 [I-D.filsfils-spring-sr-policy-considerations] describes some of the 122 implementation aspects of the SR Policy Headend Architecture and 123 introduces the notion of an SR Policy Module (SRPM) that performs the 124 functionality as highlighted in section 2 of 125 [I-D.ietf-spring-segment-routing-policy]: 127 o The SRPM may learn multiple candidate paths for an SR Policy via 128 various mechanisms (CLI, NetConf, PCEP or BGP). 130 o The SRPM selects the best candidate path for the SR Policy. 132 o The SRPM binds a BSID to the selected candidate path of the SR 133 Policy. 135 o The SRPM installs the selected candidate path and its BSID in the 136 forwarding plane. 138 This document specifies the way to use BGP to distribute one or more 139 of the candidate paths of an SR Policy to the headend of that policy. 140 The document identifies the functionality that resides in the BGP 141 process and for the functionality which is outside the scope of BGP 142 and lies within SRPM on the headend node, it refers to such, as 143 appropriate. 145 This document specifies a way of representing SR Policies and their 146 candidate paths in BGP UPDATE messages. BGP can then be used to 147 propagate the SR Policies and candidate paths. The usual BGP rules 148 for BGP propagation and "bestpath selection" are used. At the 149 headend of a specific policy, this will result in one or more 150 candidate paths being installed into the "BGP table". These paths 151 are then passed to the SRPM. The SRPM may compare them to candidate 152 paths learned via other mechanisms, and will choose one or more paths 153 to be installed in the data plane. BGP itself does not install SR 154 Policy candidate paths into the data plane. 156 This document defines a new BGP address family (SAFI). In UPDATE 157 messages of that address family, the NLRI identifies an SR Policy, 158 and the attributes encode the segment lists and other details of that 159 SR Policy. 161 While for simplicity we may write that BGP advertises an SR Policy, 162 it has to be understood that BGP advertises a candidate path of an SR 163 policy and that this SR Policy might have several other candidate 164 paths provided via BGP (via an NLRI with a different distinguisher as 165 defined in this document), PCEP, NETCONF or local policy 166 configuration. 168 Typically, a controller defines the set of policies and advertise 169 them to policy head-end routers (typically ingress routers). The 170 policy advertisement uses BGP extensions defined in this document. 171 The policy advertisement is, in most but not all of the cases, 172 tailored for a specific policy head-end. In this case the 173 advertisement may sent on a BGP session to that head-end and not 174 propagated any further. 176 Alternatively, a router (i.e., a BGP egress router) advertises SR 177 Policies representing paths to itself. In this case, it is possible 178 to send the policy to each head-end over a BGP session to that head- 179 end, without requiring any further propagation of the policy. 181 An SR Policy intended only for the receiver will, in most cases, not 182 traverse any Route Reflector (RR, [RFC4456]). 184 In some situations, it is undesirable for a controller or BGP egress 185 router to have a BGP session to each policy head-end. In these 186 situations, BGP Route Reflectors may be used to propagate the 187 advertisements, or it may be necessary for the advertisement to 188 propagate through a sequence of one or more ASes. To make this 189 possible, an attribute needs to be attached to the advertisement that 190 enables a BGP speaker to determine whether it is intended to be a 191 head-end for the advertised policy. This is done by attaching one or 192 more Route Target Extended Communities to the advertisement 193 ([RFC4360]). 195 The BGP extensions for the advertisement of SR Policies include 196 following components: 198 o A new Subsequent Address Family Identifier (SAFI) whose NLRI 199 identifies an SR Policy. 201 o A new Tunnel Type identifier for SR Policy, and a set of sub-TLVs 202 to be inserted into the Tunnel Encapsulation Attribute (as defined 203 in [I-D.ietf-idr-tunnel-encaps]) specifying segment lists of the 204 SR Policy, as well as other information about the SR Policy. 206 o One or more IPv4 address format route-target extended community 207 ([RFC4360]) attached to the SR Policy advertisement and that 208 indicates the intended head-end of such SR Policy advertisement. 210 o The Color Extended Community (as defined in 211 [I-D.ietf-idr-tunnel-encaps]) and used in order to steer traffic 212 into an SR Policy, as described in section 8.4 in 213 [I-D.ietf-spring-segment-routing-policy]. This document 214 (Section 3) modifies the format of the Color Extended Community by 215 using the two leftmost bits of the RESERVED field. 217 1.1. Requirements Language 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in RFC 2119 [RFC2119]. 223 2. SR Policy Encoding 225 2.1. SR Policy SAFI and NLRI 227 A new SAFI is defined: the SR Policy SAFI, (codepoint 73 assigned by 228 IANA (see Section 8) from the "Subsequent Address Family Identifiers 229 (SAFI) Parameters" registry). 231 The SR Policy SAFI uses a new NLRI defined as follows: 233 +------------------+ 234 | NLRI Length | 1 octet 235 +------------------+ 236 | Distinguisher | 4 octets 237 +------------------+ 238 | Policy Color | 4 octets 239 +------------------+ 240 | Endpoint | 4 or 16 octets 241 +------------------+ 243 where: 245 o NLRI Length: 1 octet of length expressed in bits as defined in 246 [RFC4760]. 248 o Distinguisher: 4-octet value uniquely identifying the policy in 249 the context of tuple. The distinguisher has no 250 semantic value and is solely used by the SR Policy originator to 251 make unique (from an NLRI perspective) multiple occurrences of the 252 same SR Policy. 254 o Policy Color: 4-octet value identifying (with the endpoint) the 255 policy. The color is used to match the color of the destination 256 prefixes to steer traffic into the SR Policy 257 [I-D.ietf-spring-segment-routing-policy]. 259 o Endpoint: identifies the endpoint of a policy. The Endpoint may 260 represent a single node or a set of nodes (e.g., an anycast 261 address). The Endpoint is an IPv4 (4-octet) address or an IPv6 262 (16-octet) address according to the AFI of the NLRI. 264 The color and endpoint are used to automate the steering of BGP 265 Payload prefixes on SR Policy as described in 266 [I-D.ietf-spring-segment-routing-policy]. 268 The NLRI containing the SR Policy is carried in a BGP UPDATE message 269 [RFC4271] using BGP multiprotocol extensions [RFC4760] with an AFI of 270 1 or 2 (IPv4 or IPv6) and with a SAFI of 73 (assigned by IANA from 271 the "Subsequent Address Family Identifiers (SAFI) Parameters" 272 registry). 274 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 275 attribute with the SR Policy SAFI MUST also carry the BGP mandatory 276 attributes. In addition, the BGP update message MAY also contain any 277 of the BGP optional attributes. 279 The next-hop network address field in SR Policy SAFI (73) updates may 280 be either a 4 octet IPv4 address or a 16 octet IPv6 address, 281 independent of the SR Policy AFI. The length field of the next-hop 282 address specifies the next-hop address family. If the next-hop 283 length is 4, then the next-hop is an IPv4 address; if the next-hop 284 length is 16, then it is a global IPv6 address; and if the next-hop 285 length is 32, then it has a global IPv6 address followed by a link- 286 local IPv6 address. The setting of the next-hop field and its 287 attendant processing is governed by standard BGP procedures as 288 described in section 3 in [RFC4760]. 290 It is important to note that any BGP speaker receiving a BGP message 291 with an SR Policy NLRI, will process it only if the NLRI is among the 292 best paths as per the BGP best path selection algorithm. In other 293 words, this document does not modify the BGP propagation or bestpath 294 selection rules. 296 It has to be noted that if several candidate paths of the same SR 297 Policy (endpoint, color) are signaled via BGP to a head-end, it is 298 recommended that each NLRI use a different distinguisher. If BGP has 299 installed into the BGP table two advertisements whose respective 300 NLRIs have the same color and endpoint, but different distinguishers, 301 both advertisements are passed to the SRPM as different candidate 302 paths. In addition, the originator information corresponding to the 303 each candidate path, as described in section 2.4 in 304 [I-D.ietf-spring-segment-routing-policy], is passed to the SRPM. 306 2.2. SR Policy and Tunnel Encapsulation Attribute 308 The content of the SR Policy is encoded in the Tunnel Encapsulation 309 Attribute originally defined in [I-D.ietf-idr-tunnel-encaps] using a 310 new Tunnel-Type TLV (codepoint is 15, assigned by IANA (see 311 Section 8) from the "BGP Tunnel Encapsulation Attribute Tunnel Types" 312 registry). 314 The SR Policy Encoding structure is as follows: 316 SR Policy SAFI NLRI: 317 Attributes: 318 Tunnel Encaps Attribute (23) 319 Tunnel Type: SR Policy 320 Binding SID 321 Preference 322 Priority 323 Policy Name 324 Explicit NULL Label Policy (ENLP) 325 Segment List 326 Weight 327 Segment 328 Segment 329 ... 330 ... 331 where: 333 o SR Policy SAFI NLRI is defined in Section 2.1. 335 o Tunnel Encapsulation Attribute is defined in 336 [I-D.ietf-idr-tunnel-encaps]. 338 o Tunnel-Type is set to 15 (assigned by IANA from the "BGP Tunnel 339 Encapsulation Attribute Tunnel Types" registry). 341 o Preference, Binding SID, Priority, Policy Name, ENLP, Segment- 342 List, Weight and Segment sub-TLVs are defined in this document. 344 o Additional sub-TLVs may be defined in the future. 346 A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV 347 of type "SR Policy". If more than one TLV of type "SR Policy" 348 appears, the update is considered malformed and the "treat-as- 349 withdraw" strategy of [RFC7606] is applied. 351 Multiple occurrences of "Segment List" MAY be encoded within the same 352 SR Policy. 354 Multiple occurrences of "Segment" MAY be encoded within the same 355 Segment List. 357 2.3. Remote Endpoint and Color 359 The Remote Endpoint and Color sub-TLVs, as defined in 360 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy 361 encodings. 363 The Remote Endpoint and Color Sub-TLVs are not used for SR Policy 364 encodings and therefore their value is irrelevant in the context of 365 the SR Policy SAFI NLRI. If present, the Remote Endpoint sub-TLV and 366 the Color sub-TLV MUST be ignored by the BGP speaker. 368 2.4. SR Policy Sub-TLVs 370 This section defines the SR Policy sub-TLVs. 372 Preference, Binding SID, Segment-List, Priority, Policy Name and 373 Explicit NULL Label Policy sub-TLVs are assigned from the "BGP Tunnel 374 Encapsulation Attribute Sub-TLVs" registry. 376 Weight and Segment sub-TLVs are assigned from a new registry defined 377 in this document and called: "SR Policy List Sub-TLVs". See 378 Section 8 for the details of the registry. 380 2.4.1. Preference Sub-TLV 382 The Preference sub-TLV does not have any effect on the BGP bestpath 383 selection or propagation procedures. The contents of this sub-TLV 384 are used by the SRPM as described in section 2.7 in 385 [I-D.ietf-spring-segment-routing-policy]. 387 The Preference sub-TLV is optional and it MUST NOT appear more than 388 once in the SR Policy. If the Preference sub-TLV appears more than 389 once, the update is considered malformed and the "treat-as-withdraw" 390 strategy of [RFC7606] is applied. 392 The Preference sub-TLV has following format: 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Type | Length | Flags | RESERVED | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Preference (4 octets) | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 where: 404 o Type: 12 406 o Length: 6. 408 o Flags: 1 octet of flags. None are defined at this stage. Flags 409 SHOULD be set to zero on transmission and MUST be ignored on 410 receipt. 412 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 413 transmission and MUST be ignored on receipt. 415 o Preference: a 4-octet value. 417 2.4.2. Binding SID Sub-TLV 419 The Binding SID sub-TLV is not used by BGP. The contents of this 420 sub-TLV are used by the SRPM as described in section 6 in 421 [I-D.ietf-spring-segment-routing-policy]. 423 The Binding SID sub-TLV is optional and it MUST NOT appear more than 424 once in the SR Policy. If the Binding SID sub-TLV appears more than 425 once, the update is considered malformed and the "treat-as-withdraw" 426 strategy of [RFC7606] is applied. 428 The Binding SID sub-TLV has the following format: 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Type | Length | Flags | RESERVED | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Binding SID (variable, optional) | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 where: 440 o Type: 13 442 o Length: specifies the length of the value field not including Type 443 and Length fields. Can be 2 or 6 or 18. 445 o Flags: 1 octet of flags. Following flags are defined (to be 446 assigned by IANA from the registry "SR Policy Binding SID Flags" 447 defined in this document Section 8.5): 449 0 1 2 3 4 5 6 7 450 +-+-+-+-+-+-+-+-+ 451 |S|I| | 452 +-+-+-+-+-+-+-+-+ 454 where: 456 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 457 It is used by SRPM as described in section 6.2.3 in 458 [I-D.ietf-spring-segment-routing-policy]. 460 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 461 is used by SRPM as described in section 8.2 in 462 [I-D.ietf-spring-segment-routing-policy]. 464 * Unused bits in the Flag octet SHOULD be set to zero upon 465 transmission and MUST be ignored upon receipt. 467 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 468 transmission and MUST be ignored on receipt. 470 o Binding SID: if length is 2, then no Binding SID is present. 472 o If length is 6 then the Binding SID contains a 4-octet SID. Below 473 format is used to encode the SID. TC, S, TTL(Total of 12bits) are 474 RESERVED and SHOULD be set to Zero and MUST be ignored. 476 0 1 2 3 477 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Label | TC |S| TTL | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 If length is 18 then the Binding SID contains a 16-octet IPv6 SID. 484 2.4.3. Segment List Sub-TLV 486 The Segment List sub-TLV encodes a single explicit path towards the 487 endpoint as described in section 5.1 in 488 [I-D.ietf-spring-segment-routing-policy]. The Segment List sub-TLV 489 includes the elements of the paths (i.e., segments) as well as an 490 optional Weight sub-TLV. 492 The Segment List sub-TLV may exceed 255 bytes length due to large 493 number of segments. Therefore a 2-octet length is required. 494 According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- 495 TLV codepoint defines the size of the length field. Therefore, for 496 the Segment List sub-TLV a code point of 128 (or higher) is used. 497 See Section 8 for details of codepoints allocation. 499 The Segment List sub-TLV is optional and MAY appear multiple times in 500 the SR Policy. The ordering of Segment List sub-TLVs, each sub-TLV 501 encoding a Segment List, does not matter. 503 The Segment List sub-TLV contains zero or more Segment sub-TLVs and 504 MAY contain a Weight sub-TLV. 506 The Segment List sub-TLV has the following format: 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Type | Length | RESERVED | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 // sub-TLVs // 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 where: 518 o Type: 128. 520 o Length: the total length (not including the Type and Length 521 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 523 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 524 transmission and MUST be ignored on receipt. 526 o sub-TLVs: 528 * An optional single Weight sub-TLV. 530 * Zero or more Segment sub-TLVs. 532 Validation of an explicit path encoded by the Segment List sub-TLV is 533 completely within the scope of SRPM as described in section 5 in 534 [I-D.ietf-spring-segment-routing-policy]. 536 2.4.3.1. Weight Sub-TLV 538 The Weight sub-TLV specifies the weight associated to a given segment 539 list. The contents of this sub-TLV are used only by the SRPM as 540 described in section 2.11 in 541 [I-D.ietf-spring-segment-routing-policy]. 543 The Weight sub-TLV is optional and it MUST NOT appear more than once 544 inside the Segment List sub-TLV. If the Weight sub-TLV appears more 545 than once, the update is considered malformed and the "treat-as- 546 withdraw" strategy of [RFC7606] is applied. 548 The Weight sub-TLV has the following format: 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Type | Length | Flags | RESERVED | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Weight | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 where: 560 Type: 9 (to be assigned by IANA from the registry "SR Policy List 561 Sub-TLVs" defined in this document). 563 Length: 6. 565 Flags: 1 octet of flags. None are defined at this stage. Flags 566 SHOULD be set to zero on transmission and MUST be ignored on receipt. 568 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 569 and MUST be ignored on receipt. 571 2.4.3.2. Segment Sub-TLV 573 The Segment sub-TLV describes a single segment in a segment list 574 (i.e., a single element of the explicit path). Multiple Segment sub- 575 TLVs constitute an explicit path of the SR Policy. 577 The Segment sub-TLV is optional and MAY appear multiple times in the 578 Segment List sub-TLV. 580 The Segment sub-TLV does not have any effect on the BGP bestpath 581 selection or propagation procedures. The contents of this sub-TLV 582 are used only by the SRPM as described in section 4 in 583 [I-D.ietf-spring-segment-routing-policy]. 585 [I-D.ietf-spring-segment-routing-policy] defines several types of 586 Segments: 588 Type 1: SID only, in the form of MPLS Label 589 Type 2: SID only, in the form of IPv6 address 590 Type 3: IPv4 Node Address with optional SID 591 Type 4: IPv6 Node Address with optional SID for SR MPLS 592 Type 5: IPv4 Address + index with optional SID 593 Type 6: IPv4 Local and Remote addresses with optional SID 594 Type 7: IPv6 Address + index for local and remote pair with optional SID for SR MPLS 595 Type 8: IPv6 Local and Remote addresses with optional SID for SR MPLS 596 Type 9: IPv6 Node Address with optional SID for SRv6 597 Type 10: IPv6 Address + index for local and remote pair with optional SID for SRv6 598 Type 11: IPv6 Local and Remote addresses for SRv6 600 2.4.3.2.1. Type 1: SID only, in the form of MPLS Label 602 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 603 MPLS label. The format is as follows: 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Type | Length | Flags | RESERVED | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Label | TC |S| TTL | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 where: 615 o Type: 1 (to be assigned by IANA from the registry "SR Policy List 616 Sub-TLVs" defined in this document). 618 o Length is 6. 620 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 622 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 623 transmission and MUST be ignored on receipt. 625 o Label: 20 bits of label value. 627 o TC: 3 bits of traffic class. 629 o S: 1 bit of bottom-of-stack. 631 o TTL: 1 octet of TTL. 633 The following applies to the Type-1 Segment sub-TLV: 635 o The S bit SHOULD be zero upon transmission, and MUST be ignored 636 upon reception. 638 o If the originator wants the receiver to choose the TC value, it 639 sets the TC field to zero. 641 o If the originator wants the receiver to choose the TTL value, it 642 sets the TTL field to 255. 644 o If the originator wants to recommend a value for these fields, it 645 puts those values in the TC and/or TTL fields. 647 o The receiver MAY override the originator's values for these 648 fields. This would be determined by local policy at the receiver. 649 One possible policy would be to override the fields only if the 650 fields have the default values specified above. 652 2.4.3.2.2. Type 2: SID only, in the form of IPv6 address 654 The Type-2 Segment Sub-TLV encodes a single SRv6 SID in the form of 655 an IPv6 address. The format is as follows: 657 0 1 2 3 658 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 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Type | Length | Flags | RESERVED | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 // SRv6 SID (16 octets) // 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 where: 667 o Type: 2 (to be assigned by IANA from the registry "SR Policy List 668 Sub-TLVs" defined in this document). 670 o Length is 18. 672 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 674 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 675 transmission and MUST be ignored on receipt. 677 o SRv6 SID: 16 octets of IPv6 address. 679 The IPv6 Segment Identifier (SRv6 SID) is defined in 680 [I-D.ietf-6man-segment-routing-header]. 682 2.4.3.2.3. Type 3: IPv4 Node Address with optional SID 684 The Type-3 Segment Sub-TLV encodes an IPv4 node address, SR Algorithm 685 and an optional SID in the form of an MPLS label. The format is as 686 follows: 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Type | Length | Flags | SR Algorithm | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | IPv4 Node Address (4 octets) | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | SID (optional, 4 octets) | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 where: 700 o Type: 3 (to be assigned by IANA from the registry "SR Policy List 701 Sub-TLVs" defined in this document). 703 o Length is 6 or 10. 705 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 707 o SR Algorithm: 1 octet specifying SR Algorithm as described in 708 section 3.1.1 in [I-D.ietf-spring-segment-routing], when A-Flag as 709 defined in Section 2.4.3.2.12 is present. SR Algorithm is used by 710 SRPM as described in section 4 in 711 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 712 encoded, this field SHOULD be unset on transmission and MUST be 713 ignored on receipt. 715 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 717 o SID: 4 octet MPLS label. 719 The following applies to the Type-3 Segment sub-TLV: 721 o The IPv4 Node Address MUST be present. 723 o The SID is optional and specifies a 4 octet MPLS SID containing 724 label, TC, S and TTL as defined in Section 2.4.3.2.1. 726 o If length is 6, then only the IPv4 Node Address is present. 728 o If length is 10, then the IPv4 Node Address and the MPLS SID are 729 present. 731 2.4.3.2.4. Type 4: IPv6 Node Address with optional SID for SR MPLS 733 The Type-4 Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 734 and an optional SID in the form of an MPLS label. The format is as 735 follows: 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Type | Length | Flags | SR Algorithm | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 // IPv6 Node Address (16 octets) // 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | SID (optional, 4 octets) | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 where: 749 o Type: 4 (to be assigned by IANA from the registry "SR Policy List 750 Sub-TLVs" defined in this document). 752 o Length is 18 or 22. 754 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 756 o SR Algorithm: 1 octet specifying SR Algorithm as described in 757 section 3.1.1 in [I-D.ietf-spring-segment-routing], when A-Flag as 758 defined in Section 2.4.3.2.12 is present. SR Algorithm is used by 759 SRPM as described in section 4 in 760 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 761 encoded, this field SHOULD be unset on transmission and MUST be 762 ignored on receipt. 764 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 766 o SID: 4 octet MPLS label. 768 The following applies to the Type-4 Segment sub-TLV: 770 o The IPv6 Node Address MUST be present. 772 o The SID is optional and specifies a 4 octet MPLS SID containing 773 label, TC, S and TTL as defined in Section 2.4.3.2.1. 775 o If length is 18, then only the IPv6 Node Address is present. 777 o If length is 22, then the IPv6 Node Address and the MPLS SID are 778 present. 780 2.4.3.2.5. Type 5: IPv4 Address + Local Interface ID with optional SID 782 The Type-5 Segment Sub-TLV encodes an IPv4 node address, a local 783 interface Identifier (Local Interface ID) and an optional SID in the 784 form of an MPLS label. The format is as follows: 786 0 1 2 3 787 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 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Type | Length | Flags | RESERVED | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Local Interface ID (4 octets) | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | IPv4 Node Address (4 octets) | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | SID (optional, 4 octets) | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 where: 800 o Type: 5 (to be assigned by IANA from the registry "SR Policy List 801 Sub-TLVs" defined in this document). 803 o Length is 10 or 14. 805 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 807 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 808 transmission and MUST be ignored on receipt. 810 o Local Interface ID: 4 octets of interface index as defined in 811 [I-D.ietf-pce-segment-routing]. 813 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 815 o SID: 4 octet MPLS label. 817 The following applies to the Type-5 Segment sub-TLV: 819 o The IPv4 Node Address MUST be present. 821 o The Local Interface ID MUST be present. 823 o The SID is optional and specifies a 4 octet MPLS SID containing 824 label, TC, S and TTL as defined in Section 2.4.3.2.1. 826 o If length is 10, then the IPv4 Node Address and Local Interface ID 827 are present. 829 o If length is 14, then the IPv4 Node Address, the Local Interface 830 ID and the MPLS SID are present. 832 2.4.3.2.6. Type 6: IPv4 Local and Remote addresses with optional SID 834 The Type-6 Segment Sub-TLV encodes an adjacency local address, an 835 adjacency remote address and an optional SID in the form of an MPLS 836 label. The format is as follows: 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Type | Length | Flags | RESERVED | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Local IPv4 Address (4 octets) | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Remote IPv4 Address (4 octets) | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | SID (optional, 4 octets) | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 where: 852 o Type: 6 (to be assigned by IANA from the registry "SR Policy List 853 Sub-TLVs" defined in this document). 855 o Length is 10 or 14. 857 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 859 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 860 transmission and MUST be ignored on receipt. 862 o Local IPv4 Address: a 4 octet IPv4 address. 864 o Remote IPv4 Address: a 4 octet IPv4 address. 866 o SID: 4 octet MPLS label. 868 The following applies to the Type-6 Segment sub-TLV: 870 o The Local IPv4 Address MUST be present and represents an adjacency 871 local address. 873 o The Remote IPv4 Address MUST be present and represents the remote 874 end of the adjacency. 876 o The SID is optional and specifies a 4 octet MPLS SID containing 877 label, TC, S and TTL as defined in Section 2.4.3.2.1. 879 o If length is 10, then only the IPv4 Local and Remote addresses are 880 present. 882 o If length is 14, then the IPv4 Local address, IPv4 Remote address 883 and the MPLS SID are present. 885 2.4.3.2.7. Type 7: IPv6 Address + Interface ID for local and remote 886 pair with optional SID for SR MPLS 888 The Type-7 Segment Sub-TLV encodes an IPv6 Link Local adjacency with 889 IPv6 local node address, a local interface identifier (Local 890 Interface ID), IPv6 remote node address , a remote interface 891 identifier (Remote Interface ID) and an optional SID in the form of 892 an MPLS label. The format is as follows: 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Type | Length | Flags | RESERVED | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Local Interface ID (4 octets) | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 // IPv6 Local Node Address (16 octets) // 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Remote Interface ID (4 octets) | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 // IPv6 Remote Node Address (16 octets) // 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | SID (optional, 4 octets) | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 where: 912 o Type: 7 (to be assigned by IANA from the registry "SR Policy List 913 Sub-TLVs" defined in this document). 915 o Length is 22, 26, 42 or 46. 917 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 919 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 920 transmission and MUST be ignored on receipt. 922 o Local Interface ID: 4 octets of interface index as defined in 923 [I-D.ietf-pce-segment-routing]. 925 o IPv6 Local Node Address: a 16 octet IPv6 address. 927 o Remote Interface ID: 4 octets of interface index as defined in 928 [I-D.ietf-pce-segment-routing]. 930 o IPv6 Remote Node Address: a 16 octet IPv6 address. 932 o SID: 4 octet MPLS label. 934 The following applies to the Type-7 Segment sub-TLV: 936 o The Local Interface ID and IPv6 Local Node Address MUST be 937 present. 939 o The Remote Interface ID and Remote Node Address pair is optional. 940 If Remote Interface ID is present, the Remote Node Address MUST be 941 present as well. Similarly, if Remote Node Address is present, 942 the Remote Interface ID MUST be present as well. 944 o The SID is optional and specifies a 4 octet MPLS SID containing 945 label, TC, S and TTL as defined in Section 2.4.3.2.1. 947 o If length is 22, then the Local Interface ID and the Local IPv6 948 Address are present. 950 o If length is 26, then the Local Interface ID, Local IPv6 Address 951 and the MPLS SID are present. 953 o If length is 42, then the Local Interface ID, Local IPv6 Node 954 Address, Remote Interface ID, and the Remote IPv6 Node Address are 955 present. 957 o If length is 46, then the Local Interface ID, Local IPv6 Node 958 Address, Remote Interface ID, Remote IPv6 Node Address and the 959 MPLS SID are present. 961 2.4.3.2.8. Type 8: IPv6 Local and Remote addresses with optional SID 962 for SR MPLS 964 The Type-8 Segment Sub-TLV encodes an adjacency local address, an 965 adjacency remote address and an optional SID in the form of an MPLS 966 label. The format is as follows: 968 0 1 2 3 969 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 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Type | Length | Flags | RESERVED | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 // Local IPv6 Address (16 octets) // 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 // Remote IPv6 Address (16 octets) // 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | SID (optional, 4 octets) | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 where: 982 o Type: 8 (to be assigned by IANA from the registry "SR Policy List 983 Sub-TLVs" defined in this document). 985 o Length is 34 or 38. 987 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 989 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 990 transmission and MUST be ignored on receipt. 992 o Local IPv6 Address: a 16 octet IPv6 address. 994 o Remote IPv6 Address: a 16 octet IPv6 address. 996 o SID: 4 octet MPLS label. 998 The following applies to the Type-8 Segment sub-TLV: 1000 o The Local IPv6 Address MUST be present and represents an adjacency 1001 local address. 1003 o The Remote IPv6 Address MUST be present and represents the remote 1004 end of the adjacency. 1006 o The SID is optional and specifies a 4 octet MPLS SID containing 1007 label, TC, S and TTL as defined in Section 2.4.3.2.1. 1009 o If length is 34, then only the IPv6 Local and Remote addresses are 1010 present. 1012 o If length is 38, then IPv6 Local and Remote addresses and the MPLS 1013 SID are present. 1015 2.4.3.2.9. Type 9: IPv6 Node Address with optional SRv6 SID 1017 The Type-9 Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 1018 and an optional SID in the form of an IPv6 address. The format is as 1019 follows: 1021 0 1 2 3 1022 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 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Type | Length | Flags | SR Algorithm | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 // IPv6 Node Address (16 octets) // 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 // SID (optional, 16 octets) // 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 where: 1033 o Type: 10 (to be assigned by IANA from the registry "SR Policy List 1034 Sub-TLVs" defined in this document). 1036 o Length is 18 or 34. 1038 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 1040 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1041 section 3.1.1 in [I-D.ietf-spring-segment-routing], when A-Flag as 1042 defined in Section 2.4.3.2.12 is present. SR Algorithm is used by 1043 SRPM as described in section 4 in 1044 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1045 encoded, this field SHOULD be unset on transmission and MUST be 1046 ignored on receipt. 1048 o IPv6 Node Address: a 16 octet IPv6 address. 1050 o SID: 16 octet IPv6 address. 1052 The following applies to the Type-9 Segment sub-TLV: 1054 o The IPv6 Node Address MUST be present. 1056 o The SID is optional and specifies an SRv6 SID in the form of 16 1057 octet IPv6 address. 1059 o If length is 18, then only the IPv6 Node Address is present. 1061 o If length is 34, then the IPv6 Node Address and the SRv6 SID are 1062 present. 1064 2.4.3.2.10. Type 10: IPv6 Address + Interface ID for local and remote 1065 pair for SRv6 with optional SID 1067 The Type-10 Segment Sub-TLV encodes an IPv6 Link Local adjacency with 1068 local node address, a local interface identifier (Local Interface 1069 ID), remote IPv6 node address , a remote interface identifier (Remote 1070 Interface ID) and an optional SID in the form of an IPv6 address. 1071 The format is as follows: 1073 0 1 2 3 1074 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 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Type | Length | Flags | RESERVED | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Local Interface ID (4 octets) | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 // IPv6 Local Node Address (16 octets) // 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Remote Interface ID (4 octets) | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 // IPv6 Remote Node Address (16 octets) // 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 // SID (optional, 16 octets) // 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 where: 1091 o Type: 11 (to be assigned by IANA from the registry "SR Policy List 1092 Sub-TLVs" defined in this document). 1094 o Length is 22, 38, 42 or 58. 1096 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 1098 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 1099 transmission and MUST be ignored on receipt. 1101 o Local Interface ID: 4 octets of interface index as defined in 1102 [I-D.ietf-pce-segment-routing]. 1104 o IPv6 Local Node Address: a 16 octet IPv6 address. 1106 o Remote Interface ID: 4 octets of interface index as defined in 1107 [I-D.ietf-pce-segment-routing]. 1109 o IPv6 Remote Node Address: a 16 octet IPv6 address. 1111 o SID: 16 octet IPv6 address. 1113 The following applies to the Type-10 Segment sub-TLV: 1115 o The Local Interface ID and the Local IPv6 Node Addresses MUST be 1116 present. 1118 o The Remote Interface ID and Remote Node Address pair is optional. 1119 If Remote Interface ID is present, the Remote Node Address MUST be 1120 present as well. Similarly, if Remote Node Address is present, 1121 the Remote Interface ID MUST be present as well. 1123 o The SID is optional and specifies an SRv6 SID in the form of 16 1124 octet IPv6 address. 1126 o If length is 22, then the Local Interface ID, Local IPv6 Node 1127 Address, are present. 1129 o If length is 38, then the Local Interface ID, Local IPv6 Node 1130 Address and the SRv6 SID are present. 1132 o If length is 42, then the Local Interface ID, Local IPv6 Node 1133 Address, Remote Interface ID, and the Remote IPv6 Node Address are 1134 present. 1136 o If length is 58, then the Local Interface ID, Local IPv6 Node 1137 Address, Remote Interface ID, Remote IPv6 Node Address and the 1138 SRv6 SID are present. 1140 2.4.3.2.11. Type 11: IPv6 Local and Remote addresses for SRv6 with 1141 optional SID 1143 The Type-11 Segment Sub-TLV encodes an adjacency local address, an 1144 adjacency remote address and an optional SID in the form of IPv6 1145 address. The format is as follows: 1147 0 1 2 3 1148 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 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Type | Length | Flags | RESERVED | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 // Local IPv6 Address (16 octets) // 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 // Remote IPv6 Address (16 octets) // 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 // SID (optional, 16 octets) // 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 where: 1160 o Type: 12 (to be assigned by IANA from the registry "SR Policy List 1161 Sub-TLVs" defined in this document). 1163 o Length is 34 or 50. 1165 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 1167 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 1168 transmission and MUST be ignored on receipt. 1170 o Local IPv6 Address: a 16 octet IPv6 address. 1172 o Remote IPv6 Address: a 16 octet IPv6 address. 1174 o SID: 16 octet IPv6 address. 1176 The following applies to the Type-11 Segment sub-TLV: 1178 o The Local IPv6 Node Address MUST be present. 1180 o The Remote IPv6 Node Address MUST be present. 1182 o The SID is optional and specifies an SRv6 SID in the form of 16 1183 octet IPv6 address. 1185 o If length is 34, then the Local IPv6 Node Address and the Remote 1186 IPv6 Node Address are present. 1188 o If length is 50, then the Local IPv6 Node Address, the Remote IPv6 1189 Node Address and the SRv6 SID are present. 1191 2.4.3.2.12. Segment Flags 1193 The Segment Types described above MAY contain following flags in the 1194 "Flags" field (codes to be assigned by IANA from the registry "SR 1195 Policy Segment Flags" defined in this document Section 8.6): 1197 0 1 2 3 4 5 6 7 1198 +-+-+-+-+-+-+-+-+ 1199 |V|A| | 1200 +-+-+-+-+-+-+-+-+ 1202 where: 1204 V-Flag: This flag is used by SRPM for the purpose of "SID 1205 verification" as described in Section 5.1 in 1206 [I-D.ietf-spring-segment-routing-policy]. 1208 A-Flag: This flag indicates the presence of SR Algorithm id in the 1209 "SR Algorithm" field applicable to various Segment Types. SR 1210 Algorithm is used by SRPM as described in section 4 in 1211 [I-D.ietf-spring-segment-routing-policy]. 1213 Unused bits in the Flag octet SHOULD be set to zero upon 1214 transmission and MUST be ignored upon receipt. 1216 The following applies to the Segment Flags: 1218 o V-Flag is applicable to all Segment Types. 1220 o A-Flag is applicable to Segment Types 3, 4 and 9. If A-Flag 1221 appears with any other Segment Type, it MUST be ignored. 1223 2.4.4. Explicit NULL Label Policy Sub-TLV 1225 In order to steer an unlabeled IP packet into an SR policy, it is 1226 necessary to create a label stack for that packet, and to push one or 1227 more labels onto that stack. 1229 The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate 1230 whether an Explicit NULL Label [RFC3032] must be pushed on an 1231 unlabeled IP packet before any other labels. 1233 If an ENLP Sub-TLV is not present, the decision of whether to push an 1234 Explicit NULL label on a given packet is a matter of local 1235 configuration. 1237 The ENLP sub-TLV is optional and it MUST NOT appear more than once in 1238 the SR Policy. If the ENLP sub-TLV appears more than once, the 1239 update is considered malformed and the "treat-as-withdraw" strategy 1240 of [RFC7606] is applied. 1242 The contents of this sub-TLV are used by the SRPM as described in 1243 section 4.1 in [I-D.ietf-spring-segment-routing-policy]. 1245 0 1 2 3 1246 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 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Type | Length | Flags | RESERVED | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | ENLP | 1251 +-+-+-+-+-+-+-+-+ 1253 Where: 1255 Type: TBD1 (to be assigned by IANA from the registry "BGP Tunnel 1256 Encapsulation Attribute sub-TLVs" defined in this document 1257 Section 8.3). 1259 Length: 3. 1261 Flags: 1 octet of flags. None are defined at this stage. Flags 1262 SHOULD be set to zero on transmission and MUST be ignored on 1263 receipt. 1265 RESERVED: 1 octet of reserved bits. SHOULD be unset on 1266 transmission and MUST be ignored on receipt. 1268 ENLP(Explicit NULL Label Policy): Indicates whether Explicit NULL 1269 labels are to be pushed on unlabeled IP packets that are being 1270 steered into a given SR policy. This field has one of the 1271 following 4 values: 1273 0: Reserved. 1275 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1276 packet, but do not push an IPv6 Explicit NULL label on an 1277 unlabeled IPv6 packet. 1279 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 1280 packet, but do not push an IPv4 Explicit NULL label on an 1281 unlabeled IPv4 packet. 1283 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1284 packet, and push an IPv6 Explicit NULL label on an unlabeled 1285 IPv6 packet. 1287 4: Do not push an Explicit NULL label. 1289 5 - 255: Reserved. 1291 The ENLP reserved values may be used for future extensions and 1292 implementations SHOULD ignore the ENLP Sub-TLV with these values. 1294 The policy signaled in this Sub-TLV MAY be overridden by local 1295 configuration. The section 4.1 of 1296 [I-D.ietf-spring-segment-routing-policy] draft describes the 1297 behavior on the headend for handling of explicit null label. 1299 2.4.5. Policy Priority Sub-TLV 1301 An operator MAY set the Policy Priority sub-TLV to indicate the order 1302 in which the SR policies are re-computed upon topological change. 1304 The Priority sub-TLV does not have any effect on the BGP bestpath 1305 selection or propagation procedures. The contents of this sub-TLV 1306 are used by the SRPM as described in section 2.11 in 1307 [I-D.ietf-spring-segment-routing-policy]. 1309 The Priority sub-TLV is optional and it MUST NOT appear more than 1310 once in the SR Policy TLV. If the Priority sub-TLV appears more than 1311 once, the update is considered malformed and the "treat-as-withdraw" 1312 strategy of [RFC7606] is applied. 1314 The Priority sub-TLV has following format: 1316 0 1 2 3 1317 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 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | Type | Length | Priority | RESERVED | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 Where: 1324 Type: TBD2 (to be assigned by IANA from the registry "BGP Tunnel 1325 Encapsulation Attribute sub-TLVs" defined in this document 1326 Section 8.3). 1328 Length: 2. 1330 Priority: a 1-octet value. 1332 RESERVED: 1 octet of reserved bits. SHOULD be unset on 1333 transmission and MUST be ignored on receipt. 1335 2.4.6. Policy Name Sub-TLV 1337 An operator MAY set the Policy Name sub-TLV to attach a symbolic name 1338 to the SR Policy candidate path. 1340 Usage of Policy Name sub-TLV is described in section 2 in 1341 [I-D.ietf-spring-segment-routing-policy]. 1343 The Policy Name sub-TLV may exceed 255 bytes length due to long 1344 policy name. Therefore a 2-octet length is required. According to 1345 [I-D.ietf-idr-tunnel-encaps], the first bit of the sub-TLV codepoint 1346 defines the size of the length field. Therefore, for the Policy Name 1347 sub-TLV a code point of 128 (or higher) is used. See Section 8 for 1348 details of codepoints allocation. 1350 The Policy Name sub-TLV is optional and it MUST NOT appear more than 1351 once in the SR Policy TLV. If the Policy Name sub-TLV appears more 1352 than once, the update is considered malformed and the "treat-as- 1353 withdraw" strategy of [RFC7606] is applied. 1355 The Policy Name sub-TLV has following format: 1357 0 1 2 3 1358 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 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | Type | Length | RESERVED | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 // Policy Name // 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 Where: 1367 Type: TBD3 (to be assigned by IANA from the registry "BGP Tunnel 1368 Encapsulation Attribute sub-TLVs" defined in this document 1369 Section 8.3). 1371 Length: Variable. 1373 RESERVED: 1 octet of reserved bits. SHOULD be unset on 1374 transmission and MUST be ignored on receipt. 1376 Policy Name: Symbolic name for the policy. It SHOULD be a string 1377 of printable ASCII characters, without a NULL terminator. 1379 3. Extended Color Community 1381 The Color Extended Community as defined in 1382 [I-D.ietf-idr-tunnel-encaps] is used to steer traffic into a policy. 1384 When the Color Extended Community is used for the purpose of steering 1385 the traffic into an SR Policy, the RESERVED field (as defined in 1386 [I-D.ietf-idr-tunnel-encaps] is changed as follows: 1388 1 1389 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 |C O| RESERVED | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 where CO bits are defined as the "Color-Only" bits. 1394 [I-D.ietf-spring-segment-routing-policy] defines the influence of 1395 these bits on the automated steering of BGP Payload traffic onto SR 1396 Policies. 1398 4. SR Policy Operations 1400 As described in this document, the consumer of an SR Policy NLRI is 1401 not the BGP process. The BGP process is in charge of the origination 1402 and propagation of the SR Policy NLRI but its installation and use is 1403 outside the scope of BGP. The details of SR Policy installation and 1404 use can be referred from [I-D.ietf-spring-segment-routing-policy]. 1406 4.1. Configuration and Advertisement of SR Policies 1408 Typically, but not limited to, an SR Policy is configured into a 1409 controller. 1411 Multiple SR Policy NLRIs may be present with the same tuple but with different content when these SR policies are 1413 intended to different head-ends. 1415 The distinguisher of each SR Policy NLRI prevents undesired BGP route 1416 selection among these SR Policy NLRIs and allow their propagation 1417 across route reflectors [RFC4456]. 1419 Moreover, one or more route-target SHOULD be attached to the 1420 advertisement, where each route-target identifies one or more 1421 intended head-ends for the advertised SR policy. 1423 If no route-target is attached to the SR Policy NLRI, then it is 1424 assumed that the originator sends the SR Policy update directly 1425 (e.g., through a BGP session) to the intended receiver. In such 1426 case, the NO_ADVERTISE community MUST be attached to the SR Policy 1427 update. 1429 4.2. Reception of an SR Policy NLRI 1431 On reception of an SR Policy NLRI, a BGP speaker MUST determine if 1432 it's first acceptable, then it determines if it is usable. 1434 4.2.1. Acceptance of an SR Policy NLRI 1436 When a BGP speaker receives an SR Policy NLRI from a neighbor it has 1437 to determine if it's acceptable. The following applies: 1439 o The SR Policy NLRI MUST include a distinguisher, color and 1440 endpoint field which implies that the length of the NLRI MUST be 1441 either 12 or 24 octets (depending on the address family of the 1442 endpoint). 1444 o The SR Policy update MUST have either the NO_ADVERTISE community 1445 or at least one route-target extended community in IPv4-address 1446 format. If a router supporting this document receives an SR 1447 policy update with no route-target extended communities and no 1448 NO_ADVERTISE community, the update MUST NOT be sent to the SRPM. 1449 Furthermore, it SHOULD be considered to be malformed, and the 1450 "treat-as-withdraw" strategy of [RFC7606] is applied. 1452 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1453 Update and MUST have a Tunnel Type TLV set to SR Policy ( 1454 codepoint is 15, assigned by IANA (see Section 8) from the "BGP 1455 Tunnel Encapsulation Attribute Tunnel Types" registry). 1457 A router that receives an SR Policy update that is not valid 1458 according to these criteria MUST treat the update as malformed. The 1459 route MUST NOT be passed to the SRPM, and the "treat-as-withdraw" 1460 strategy of [RFC7606] is applied. 1462 A unacceptable SR Policy update that has a valid NLRI portion with 1463 invalid attribute portion MUST be considered as a withdraw of the SR 1464 Policy. 1466 4.2.2. Usable SR Policy NLRI 1468 If one or more route-targets are present, then at least one route- 1469 target MUST match one of the BGP Identifiers of the receiver in order 1470 for the update to be considered usable. The BGP Identifier is 1471 defined in [RFC4271] as a 4 octet IPv4 address. Therefore the route- 1472 target extended community MUST be of the same format. 1474 If one or more route-targets are present and no one matches any of 1475 the local BGP Identifiers, then, while the SR Policy NLRI is 1476 acceptable, it is not usable on the receiver node. It has to be 1477 noted that if the receiver has been explicitly configured to do so, 1478 it MAY propagate the SR Policy NLRI to its neighbors as defined in 1479 Section 4.2.4. 1481 The SR Policy candidate paths encoded by the usable SR Policy NLRIs 1482 are sent to the SRPM. 1484 4.2.3. Passing a usable SR Policy NLRI to the SRPM 1486 Once BGP has determined that the SR Policy NLRI is usable, BGP passes 1487 the SR Policy candidate path to the SRPM. Note that, along with the 1488 candidate path details, BGP also passes the originator information 1489 for breaking ties in the path-selection process as described in 1490 section 2.4 in [I-D.ietf-spring-segment-routing-policy]. 1492 The SRPM applies the rules defined in section 2 in 1493 [I-D.ietf-spring-segment-routing-policy] to determine whether the SR 1494 Policy candidate path is valid and to select the best candidate path 1495 among the valid SR Policy candidate paths. 1497 4.2.4. Propagation of an SR Policy 1499 By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate 1500 it to any EBGP neighbor. 1502 However, a node MAY be explicitly configured to advertise a received 1503 SR Policy NLRI to neighbors according to normal BGP rules (i.e., EBGP 1504 propagation by an ASBR or iBGP propagation by a Route-Reflector). 1506 SR Policy NLRIs that have been determined acceptable and valid can be 1507 propagated, even the ones that are not usable. 1509 Only SR Policy NLRIs that do not have the NO_ADVERTISE community 1510 attached to them can be propagated. 1512 4.3. Flowspec and SR Policies 1514 The SR Policy can be carried in context of a Flowspec NLRI 1515 ([RFC5575]). In this case, when the redirect to IP next-hop is 1516 specified as in [I-D.ietf-idr-flowspec-redirect-ip], the tunnel to 1517 the next-hop is specified by the segment list in the Segment List 1518 sub-TLVs. The Segment List (e.g., label stack or IPv6 segment list) 1519 is imposed to flows matching the criteria in the Flowspec route to 1520 steer them towards the next-hop as specified in the SR Policy SAFI 1521 NLRI. 1523 5. Contributors 1525 Kausik Majumdar 1526 Cisco Systems 1527 US 1529 Email: kmajumda@cisco.com 1531 Zafar Ali 1532 Cisco Systems 1533 US 1535 Email: zali@cisco.com 1536 Arjun Sreekantiah 1537 Cisco Systems 1538 US 1540 Email: asreekan@cisco.com 1542 Acee Lindem 1543 Cisco Systems 1544 US 1546 Email: acee@cisco.com 1548 Siva Sivabalan 1549 Cisco Systems 1550 US 1552 Email: msiva@cisco.com 1554 Imtiyaz Mohammad 1555 Arista Networks 1556 India 1558 Email: imtiyaz@arista.com 1560 Gaurav Dawra 1561 Cisco Systems 1562 US 1564 Email: gdawra.ietf@gmail.com 1566 6. Acknowledgments 1568 The authors of this document would like to thank Shyam Sethuram, John 1569 Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha and Ketan 1570 Talaulikar for their comments and review of this document. 1572 7. Implementation Status 1574 Note to RFC Editor: Please remove this section prior to publication, 1575 as well as the reference to RFC 7942. 1577 This section records the status of known implementations of the 1578 protocol defined by this specification at the time of posting of this 1579 Internet-Draft, and is based on a proposal described in [RFC7942]. 1580 The description of implementations in this section is intended to 1581 assist the IETF in its decision processes in progressing drafts to 1582 RFCs. Please note that the listing of any individual implementation 1583 here does not imply endorsement by the IETF. Furthermore, no effort 1584 has been spent to verify the information presented here that was 1585 supplied by IETF contributors. This is not intended as, and must not 1586 be construed to be, a catalog of available implementations or their 1587 features. Readers are advised to note that other implementations may 1588 exist. 1590 According to [RFC7942], "this will allow reviewers and working groups 1591 to assign due consideration to documents that have the benefit of 1592 running code, which may serve as evidence of valuable experimentation 1593 and feedback that have made the implemented protocols more mature. 1594 It is up to the individual working groups to use this information as 1595 they see fit". 1597 Several early implementations exist and will be reported in detail in 1598 a forthcoming version of this document. For purposes of early 1599 interoperability testing, when no FCFS code point was available, 1600 implementations have made use of the following values: 1602 o Preference sub-TLV: 12 1604 o Binding SID sub-TLV: 13 1606 o Segment List sub-TLV: 128 1608 When IANA-assigned values are available, implementations will be 1609 updated to use them. 1611 8. IANA Considerations 1613 This document defines new Sub-TLVs in following existing registries: 1615 o Subsequent Address Family Identifiers (SAFI) Parameters 1617 o BGP Tunnel Encapsulation Attribute Tunnel Types 1619 o BGP Tunnel Encapsulation Attribute sub-TLVs 1621 This document also defines following new registries: 1623 o SR Policy List Sub-TLVs 1625 o SR Policy Binding SID Flags 1627 o SR Policy Segment Flags 1629 8.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1630 Parameters 1632 This document defines a new SAFI in the registry "Subsequent Address 1633 Family Identifiers (SAFI) Parameters" that has been assigned by IANA: 1635 Codepoint Description Reference 1636 ----------------------------------------------- 1637 73 SR Policy SAFI This document 1639 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1641 This document defines a new Tunnel-Type in the registry "BGP Tunnel 1642 Encapsulation Attribute Tunnel Types" that has been assigned by IANA: 1644 Codepoint Description Reference 1645 -------------------------------------------------- 1646 15 SR Policy Type This document 1648 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1650 This document defines new sub-TLVs in the registry "BGP Tunnel 1651 Encapsulation Attribute sub-TLVs" to be assigned by IANA: 1653 Codepoint Description Reference 1654 ------------------------------------------------------ 1655 12 Preference sub-TLV This document 1656 13 Binding SID sub-TLV This document 1657 128 Segment List sub-TLV This document 1658 TBD1 ENLP sub-TLV This document 1659 TBD2 Priority sub-TLV This document 1660 TBD3 Policy Name sub-TLV This document 1662 8.4. New Registry: SR Policy List Sub-TLVs 1664 This document defines a new registry called "SR Policy List Sub- 1665 TLVs". The allocation policy of this registry is "First Come First 1666 Served (FCFS)" according to [RFC8126]. 1668 Following Sub-TLV codepoints are defined: 1670 Value Description Reference 1671 --------------------------------------------------------------------------------- 1672 1 MPLS SID sub-TLV This document 1673 2 SRv6 SID sub-TLV This document 1674 3 IPv4 Node and SID sub-TLV This document 1675 4 IPv6 Node and SID for SR-MPLS sub-TLV This document 1676 5 IPv4 Node, index and SID sub-TLV This document 1677 6 IPv4 Local/Remote addresses and SID sub-TLV This document 1678 7 IPv6 Node, index for remote and local pair This document 1679 and SID for SR-MPLS sub-TLV 1680 8 IPv6 Local/Remote addresses and SID sub-TLV This document 1681 9 Weight sub-TLV This document 1682 10 IPv6 Node and SID for SRv6 sub-TLV This document 1683 11 IPv6 Node, index for remote and local pair This document 1684 and SID for SRv6 sub-TLV 1685 12 IPv6 Local/Remote addresses and SID for This document 1686 SRv6 sub-TLV 1688 8.5. New Registry: SR Policy Binding SID Flags 1690 This document defines a new registry called "SR Policy Binding SID 1691 Flags". The allocation policy of this registry is "First Come First 1692 Served (FCFS)" according to [RFC8126]. 1694 Following Flags are defined: 1696 Bit Description Reference 1697 --------------------------------------------------------------------------------- 1698 0 Specified-BSID-Only Flag (S-Flag) This document 1699 1 Drop Upon Invalid Flag (I-Flag) This document 1700 2-7 Unassigned 1702 8.6. New Registry: SR Policy Segment Flags 1704 This document defines a new registry called "SR Policy Segment 1705 Flags". The allocation policy of this registry is "First Come First 1706 Served (FCFS)" according to [RFC8126]. 1708 Following Flags are defined: 1710 Bit Description Reference 1711 --------------------------------------------------------------------------------- 1712 0 Segment Verification Flag (V-Flag) This document 1713 1 SR Algorithm Flag (A-Flag) This document 1714 2-7 Unassigned 1716 9. Security Considerations 1718 TBD. 1720 10. References 1722 10.1. Normative References 1724 [I-D.ietf-idr-tunnel-encaps] 1725 Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The 1726 BGP Tunnel Encapsulation Attribute", draft-ietf-idr- 1727 tunnel-encaps-12 (work in progress), May 2019. 1729 [I-D.ietf-pce-segment-routing] 1730 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1731 and J. Hardwick, "PCEP Extensions for Segment Routing", 1732 draft-ietf-pce-segment-routing-16 (work in progress), 1733 March 2019. 1735 [I-D.ietf-spring-segment-routing] 1736 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1737 Litkowski, S., and R. Shakir, "Segment Routing 1738 Architecture", draft-ietf-spring-segment-routing-15 (work 1739 in progress), January 2018. 1741 [I-D.ietf-spring-segment-routing-policy] 1742 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1743 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1744 Policy Architecture", draft-ietf-spring-segment-routing- 1745 policy-03 (work in progress), May 2019. 1747 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1748 Requirement Levels", BCP 14, RFC 2119, 1749 DOI 10.17487/RFC2119, March 1997, 1750 . 1752 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1753 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1754 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1755 . 1757 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1758 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1759 DOI 10.17487/RFC4271, January 2006, 1760 . 1762 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1763 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1764 February 2006, . 1766 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1767 "Multiprotocol Extensions for BGP-4", RFC 4760, 1768 DOI 10.17487/RFC4760, January 2007, 1769 . 1771 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1772 and D. McPherson, "Dissemination of Flow Specification 1773 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1774 . 1776 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1777 Patel, "Revised Error Handling for BGP UPDATE Messages", 1778 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1779 . 1781 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1782 Writing an IANA Considerations Section in RFCs", BCP 26, 1783 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1784 . 1786 10.2. Informational References 1788 [I-D.filsfils-spring-sr-policy-considerations] 1789 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1790 P. Mattes, "SR Policy Implementation and Deployment 1791 Considerations", draft-filsfils-spring-sr-policy- 1792 considerations-03 (work in progress), April 2019. 1794 [I-D.ietf-6man-segment-routing-header] 1795 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 1796 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 1797 Routing Header (SRH)", draft-ietf-6man-segment-routing- 1798 header-21 (work in progress), June 2019. 1800 [I-D.ietf-idr-flowspec-redirect-ip] 1801 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 1802 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 1803 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 1804 in progress), February 2015. 1806 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1807 Reflection: An Alternative to Full Mesh Internal BGP 1808 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1809 . 1811 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1812 Code: The Implementation Status Section", BCP 205, 1813 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1814 . 1816 Authors' Addresses 1818 Stefano Previdi 1819 Individual 1820 IT 1822 Email: stefano@previdi.net 1824 Clarence Filsfils 1825 Cisco Systems, Inc. 1826 Brussels 1827 BE 1829 Email: cfilsfil@cisco.com 1831 Paul Mattes 1832 Microsoft 1833 One Microsoft Way 1834 Redmond, WA 98052 1835 USA 1837 Email: pamattes@microsoft.com 1839 Eric Rosen 1840 Juniper Networks 1841 10 Technology Park Drive 1842 Westford, MA 01886 1843 US 1845 Email: erosen@juniper.net 1847 Dhanendra Jain 1848 Google 1850 Email: dhanendra.ietf@gmail.com 1851 Steven Lin 1852 Google 1854 Email: stevenlin@google.com