idnits 2.17.1 draft-ietf-idr-segment-routing-te-policy-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (May 20, 2019) is 1802 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-11 == 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-18 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, Ed. 3 Internet-Draft Individual 4 Intended status: Standards Track C. Filsfils 5 Expires: November 21, 2019 Cisco Systems, Inc. 6 D. Jain, Ed. 7 Google 8 P. Mattes 9 Microsoft 10 E. Rosen 11 Juniper Networks 12 S. Lin 13 Google 14 May 20, 2019 16 Advertising Segment Routing Policies in BGP 17 draft-ietf-idr-segment-routing-te-policy-06 19 Abstract 21 This document defines a new BGP SAFI with a new NLRI in order to 22 advertise a candidate path of a Segment Routing Policy (SR Policy). 23 An SR Policy is a set of candidate paths, each consisting of one or 24 more segment lists. The headend of an SR Policy may learn multiple 25 candidate paths for an SR Policy. Candidate paths may be learned via 26 a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. 27 This document specifies the way in which BGP may be used to 28 distribute candidate paths. New sub-TLVs for the Tunnel 29 Encapsulation Attribute are defined. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 21, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 67 2. SR Policy Encoding . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. SR Policy SAFI and NLRI . . . . . . . . . . . . . . . . . 5 69 2.2. SR Policy and Tunnel Encapsulation Attribute . . . . . . 7 70 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 71 2.4. SR Policy Sub-TLVs . . . . . . . . . . . . . . . . . . . 9 72 2.4.1. Preference Sub-TLV . . . . . . . . . . . . . . . . . 9 73 2.4.2. Binding SID Sub-TLV . . . . . . . . . . . . . . . . . 10 74 2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 11 75 2.4.4. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 27 76 2.4.5. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 28 77 2.4.6. Policy Name Sub-TLV . . . . . . . . . . . . . . . . . 29 78 3. Extended Color Community . . . . . . . . . . . . . . . . . . 30 79 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 30 80 4.1. Configuration and Advertisement of SR Policies . . . . . 30 81 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 31 82 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 31 83 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 32 84 4.2.3. Passing a usable SR Policy NLRI to the SRPM . . . . . 32 85 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 32 86 4.3. Flowspec and SR Policies . . . . . . . . . . . . . . . . 33 87 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 88 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 89 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 34 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 91 8.1. Existing Registry: Subsequent Address Family Identifiers 92 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 35 93 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute 94 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 35 95 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute 96 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 35 97 8.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 36 98 8.5. New Registry: SR Policy Binding SID Flags . . . . . . . . 36 99 8.6. New Registry: SR Policy Segment Flags . . . . . . . . . . 37 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 102 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 103 10.2. Informational References . . . . . . . . . . . . . . . . 38 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 106 1. Introduction 108 Segment Routing (SR) allows a headend node to steer a packet flow 109 along any path. Intermediate per-flow states are eliminated thanks 110 to source routing [I-D.ietf-spring-segment-routing]. 112 The headend node is said to steer a flow into a Segment Routing 113 Policy (SR Policy). 115 The header of a packet steered in an SR Policy is augmented with the 116 ordered list of segments associated with that SR Policy. 118 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 119 Policy and steering into an SR Policy. These apply equally to the 120 MPLS and SRv6 instantiations of segment routing. 122 [I-D.filsfils-spring-sr-policy-considerations] describes some of the 123 implementation aspects of the SR Policy Headend Architecture and 124 introduces the notion of an SR Policy Module (SRPM) that performs the 125 functionality as highlighted in section 2 of 126 [I-D.ietf-spring-segment-routing-policy]: 128 o The SRPM may learn multiple candidate paths for an SR Policy via 129 various mechanisms (CLI, NetConf, PCEP or BGP). 131 o The SRPM selects the best candidate path for the SR Policy. 133 o The SRPM binds a BSID to the selected candidate path of the SR 134 Policy. 136 o The SRPM installs the selected candidate path and its BSID in the 137 forwarding plane. 139 This document specifies the way to use BGP to distribute one or more 140 of the candidate paths of an SR Policy to the headend of that policy. 141 The document identifies the functionality that resides in the BGP 142 process and for the functionality which is outside the scope of BGP 143 and lies within SRPM on the headend node, it refers to such, as 144 appropriate. 146 This document specifies a way of representing SR Policies and their 147 candidate paths in BGP UPDATE messages. BGP can then be used to 148 propagate the SR Policies and candidate paths. The usual BGP rules 149 for BGP propagation and "bestpath selection" are used. At the 150 headend of a specific policy, this will result in one or more 151 candidate paths being installed into the "BGP table". These paths 152 are then passed to the SRPM. The SRPM may compare them to candidate 153 paths learned via other mechanisms, and will choose one or more paths 154 to be installed in the data plane. BGP itself does not install SR 155 Policy candidate paths into the data plane. 157 This document defines a new BGP address family (SAFI). In UPDATE 158 messages of that address family, the NLRI identifies an SR Policy, 159 and the attributes encode the segment lists and other details of that 160 SR Policy. 162 While for simplicity we may write that BGP advertises an SR Policy, 163 it has to be understood that BGP advertises a candidate path of an SR 164 policy and that this SR Policy might have several other candidate 165 paths provided via BGP (via an NLRI with a different distinguisher as 166 defined in this document), PCEP, NETCONF or local policy 167 configuration. 169 Typically, a controller defines the set of policies and advertise 170 them to policy head-end routers (typically ingress routers). The 171 policy advertisement uses BGP extensions defined in this document. 172 The policy advertisement is, in most but not all of the cases, 173 tailored for a specific policy head-end. In this case the 174 advertisement may sent on a BGP session to that head-end and not 175 propagated any further. 177 Alternatively, a router (i.e., a BGP egress router) advertises SR 178 Policies representing paths to itself. In this case, it is possible 179 to send the policy to each head-end over a BGP session to that head- 180 end, without requiring any further propagation of the policy. 182 An SR Policy intended only for the receiver will, in most cases, not 183 traverse any Route Reflector (RR, [RFC4456]). 185 In some situations, it is undesirable for a controller or BGP egress 186 router to have a BGP session to each policy head-end. In these 187 situations, BGP Route Reflectors may be used to propagate the 188 advertisements, or it may be necessary for the advertisement to 189 propagate through a sequence of one or more ASes. To make this 190 possible, an attribute needs to be attached to the advertisement that 191 enables a BGP speaker to determine whether it is intended to be a 192 head-end for the advertised policy. This is done by attaching one or 193 more Route Target Extended Communities to the advertisement 194 ([RFC4360]). 196 The BGP extensions for the advertisement of SR Policies include 197 following components: 199 o A new Subsequent Address Family Identifier (SAFI) whose NLRI 200 identifies an SR Policy. 202 o A new Tunnel Type identifier for SR Policy, and a set of sub-TLVs 203 to be inserted into the Tunnel Encapsulation Attribute (as defined 204 in [I-D.ietf-idr-tunnel-encaps]) specifying segment lists of the 205 SR Policy, as well as other information about the SR Policy. 207 o One or more IPv4 address format route-target extended community 208 ([RFC4360]) attached to the SR Policy advertisement and that 209 indicates the intended head-end of such SR Policy advertisement. 211 o The Color Extended Community (as defined in 212 [I-D.ietf-idr-tunnel-encaps]) and used in order to steer traffic 213 into an SR Policy, as described in section 8.4 in 214 [I-D.ietf-spring-segment-routing-policy]. This document 215 (Section 3) modifies the format of the Color Extended Community by 216 using the two leftmost bits of the RESERVED field. 218 1.1. Requirements Language 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 222 document are to be interpreted as described in RFC 2119 [RFC2119]. 224 2. SR Policy Encoding 226 2.1. SR Policy SAFI and NLRI 228 A new SAFI is defined: the SR Policy SAFI, (codepoint 73 assigned by 229 IANA (see Section 8) from the "Subsequent Address Family Identifiers 230 (SAFI) Parameters" registry). 232 The SR Policy SAFI uses a new NLRI defined as follows: 234 +------------------+ 235 | NLRI Length | 1 octet 236 +------------------+ 237 | Distinguisher | 4 octets 238 +------------------+ 239 | Policy Color | 4 octets 240 +------------------+ 241 | Endpoint | 4 or 16 octets 242 +------------------+ 244 where: 246 o NLRI Length: 1 octet of length expressed in bits as defined in 247 [RFC4760]. 249 o Distinguisher: 4-octet value uniquely identifying the policy in 250 the context of tuple. The distinguisher has no 251 semantic value and is solely used by the SR Policy originator to 252 make unique (from an NLRI perspective) multiple occurrences of the 253 same SR Policy. 255 o Policy Color: 4-octet value identifying (with the endpoint) the 256 policy. The color is used to match the color of the destination 257 prefixes to steer traffic into the SR Policy 258 [I-D.ietf-spring-segment-routing-policy]. 260 o Endpoint: identifies the endpoint of a policy. The Endpoint may 261 represent a single node or a set of nodes (e.g., an anycast 262 address). The Endpoint is an IPv4 (4-octet) address or an IPv6 263 (16-octet) address according to the AFI of the NLRI. 265 The color and endpoint are used to automate the steering of BGP 266 Payload prefixes on SR Policy as described in 267 [I-D.ietf-spring-segment-routing-policy]. 269 The NLRI containing the SR Policy is carried in a BGP UPDATE message 270 [RFC4271] using BGP multiprotocol extensions [RFC4760] with an AFI of 271 1 or 2 (IPv4 or IPv6) and with a SAFI of 73 (assigned by IANA from 272 the "Subsequent Address Family Identifiers (SAFI) Parameters" 273 registry). 275 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 276 attribute with the SR Policy SAFI MUST also carry the BGP mandatory 277 attributes. In addition, the BGP update message MAY also contain any 278 of the BGP optional attributes. 280 The next-hop network address field in SR Policy SAFI (73) updates may 281 be either a 4 octet IPv4 address or a 16 octet IPv6 address, 282 independent of the SR Policy AFI. The length field of the next-hop 283 address specifies the next-hop address family. If the next-hop 284 length is 4, then the next-hop is an IPv4 address; if the next-hop 285 length is 16, then it is a global IPv6 address; and if the next-hop 286 length is 32, then it has a global IPv6 address followed by a link- 287 local IPv6 address. The setting of the next-hop field and its 288 attendant processing is governed by standard BGP procedures as 289 described in section 3 in [RFC4760]. 291 It is important to note that any BGP speaker receiving a BGP message 292 with an SR Policy NLRI, will process it only if the NLRI is among the 293 best paths as per the BGP best path selection algorithm. In other 294 words, this document does not modify the BGP propagation or bestpath 295 selection rules. 297 It has to be noted that if several candidate paths of the same SR 298 Policy (endpoint, color) are signaled via BGP to a head-end, it is 299 recommended that each NLRI use a different distinguisher. If BGP has 300 installed into the BGP table two advertisements whose respective 301 NLRIs have the same color and endpoint, but different distinguishers, 302 both advertisements are passed to the SRPM as different candidate 303 paths. In addition, the originator information corresponding to the 304 each candidate path, as described in section 2.4 in 305 [I-D.ietf-spring-segment-routing-policy], is passed to the SRPM. 307 2.2. SR Policy and Tunnel Encapsulation Attribute 309 The content of the SR Policy is encoded in the Tunnel Encapsulation 310 Attribute originally defined in [I-D.ietf-idr-tunnel-encaps] using a 311 new Tunnel-Type TLV (codepoint is 15, assigned by IANA (see 312 Section 8) from the "BGP Tunnel Encapsulation Attribute Tunnel Types" 313 registry). 315 The SR Policy Encoding structure is as follows: 317 SR Policy SAFI NLRI: 318 Attributes: 319 Tunnel Encaps Attribute (23) 320 Tunnel Type: SR Policy 321 Binding SID 322 Preference 323 Priority 324 Policy Name 325 Explicit NULL Label Policy (ENLP) 326 Segment List 327 Weight 328 Segment 329 Segment 330 ... 331 ... 332 where: 334 o SR Policy SAFI NLRI is defined in Section 2.1. 336 o Tunnel Encapsulation Attribute is defined in 337 [I-D.ietf-idr-tunnel-encaps]. 339 o Tunnel-Type is set to 15 (assigned by IANA from the "BGP Tunnel 340 Encapsulation Attribute Tunnel Types" registry). 342 o Preference, Binding SID, Priority, Policy Name, ENLP, Segment- 343 List, Weight and Segment sub-TLVs are defined in this document. 345 o Additional sub-TLVs may be defined in the future. 347 A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV 348 of type "SR Policy". If more than one TLV of type "SR Policy" 349 appears, the update is considered malformed and the "treat-as- 350 withdraw" strategy of [RFC7606] is applied. 352 Multiple occurrences of "Segment List" MAY be encoded within the same 353 SR Policy. 355 Multiple occurrences of "Segment" MAY be encoded within the same 356 Segment List. 358 2.3. Remote Endpoint and Color 360 The Remote Endpoint and Color sub-TLVs, as defined in 361 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy 362 encodings. 364 The Remote Endpoint and Color Sub-TLVs are not used for SR Policy 365 encodings and therefore their value is irrelevant in the context of 366 the SR Policy SAFI NLRI. If present, the Remote Endpoint sub-TLV and 367 the Color sub-TLV MUST be ignored by the BGP speaker. 369 2.4. SR Policy Sub-TLVs 371 This section defines the SR Policy sub-TLVs. 373 Preference, Binding SID, Segment-List, Priority, Policy Name and 374 Explicit NULL Label Policy sub-TLVs are assigned from the "BGP Tunnel 375 Encapsulation Attribute Sub-TLVs" registry. 377 Weight and Segment sub-TLVs are assigned from a new registry defined 378 in this document and called: "SR Policy List Sub-TLVs". See 379 Section 8 for the details of the registry. 381 2.4.1. Preference Sub-TLV 383 The Preference sub-TLV does not have any effect on the BGP bestpath 384 selection or propagation procedures. The contents of this sub-TLV 385 are used by the SRPM as described in section 2.7 in 386 [I-D.ietf-spring-segment-routing-policy]. 388 The Preference sub-TLV is optional and it MUST NOT appear more than 389 once in the SR Policy. If the Preference sub-TLV appears more than 390 once, the update is considered malformed and the "treat-as-withdraw" 391 strategy of [RFC7606] is applied. 393 The Preference sub-TLV has following format: 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type | Length | Flags | RESERVED | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Preference (4 octets) | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 where: 405 o Type: 12 407 o Length: 6. 409 o Flags: 1 octet of flags. None are defined at this stage. Flags 410 SHOULD be set to zero on transmission and MUST be ignored on 411 receipt. 413 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 414 transmission and MUST be ignored on receipt. 416 o Preference: a 4-octet value. 418 2.4.2. Binding SID Sub-TLV 420 The Binding SID sub-TLV is not used by BGP. The contents of this 421 sub-TLV are used by the SRPM as described in section 6 in 422 [I-D.ietf-spring-segment-routing-policy]. 424 The Binding SID sub-TLV is optional and it MUST NOT appear more than 425 once in the SR Policy. If the Binding SID sub-TLV appears more than 426 once, the update is considered malformed and the "treat-as-withdraw" 427 strategy of [RFC7606] is applied. 429 The Binding SID sub-TLV has the following format: 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type | Length | Flags | RESERVED | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Binding SID (variable, optional) | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 where: 441 o Type: 13 443 o Length: specifies the length of the value field not including Type 444 and Length fields. Can be 2 or 6 or 18. 446 o Flags: 1 octet of flags. Following flags are defined (to be 447 assigned by IANA from the registry "SR Policy Binding SID Flags" 448 defined in this document Section 8.5): 450 0 1 2 3 4 5 6 7 451 +-+-+-+-+-+-+-+-+ 452 |S|I| | 453 +-+-+-+-+-+-+-+-+ 455 where: 457 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 458 It is used by SRPM as described in section 6.2.3 in 459 [I-D.ietf-spring-segment-routing-policy]. 461 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 462 is used by SRPM as described in section 8.2 in 463 [I-D.ietf-spring-segment-routing-policy]. 465 * Unused bits in the Flag octet SHOULD be set to zero upon 466 transmission and MUST be ignored upon receipt. 468 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 469 transmission and MUST be ignored on receipt. 471 o Binding SID: if length is 2, then no Binding SID is present. 473 o If length is 6 then the Binding SID contains a 4-octet SID. Below 474 format is used to encode the SID. TC, S, TTL(Total of 12bits) are 475 RESERVED and SHOULD be set to Zero and MUST be ignored. 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Label | TC |S| TTL | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 If length is 18 then the Binding SID contains a 16-octet IPv6 SID. 485 2.4.3. Segment List Sub-TLV 487 The Segment List sub-TLV encodes a single explicit path towards the 488 endpoint as described in section 5.1 in 489 [I-D.ietf-spring-segment-routing-policy]. The Segment List sub-TLV 490 includes the elements of the paths (i.e., segments) as well as an 491 optional Weight sub-TLV. 493 The Segment List sub-TLV may exceed 255 bytes length due to large 494 number of segments. Therefore a 2-octet length is required. 495 According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- 496 TLV codepoint defines the size of the length field. Therefore, for 497 the Segment List sub-TLV a code point of 128 (or higher) is used. 498 See Section 8 for details of codepoints allocation. 500 The Segment List sub-TLV is optional and MAY appear multiple times in 501 the SR Policy. The ordering of Segment List sub-TLVs, each sub-TLV 502 encoding a Segment List, does not matter. 504 The Segment List sub-TLV contains zero or more Segment sub-TLVs and 505 MAY contain a Weight sub-TLV. 507 The Segment List sub-TLV has the following format: 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Type | Length | RESERVED | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 // sub-TLVs // 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 where: 519 o Type: 128. 521 o Length: the total length (not including the Type and Length 522 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 524 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 525 transmission and MUST be ignored on receipt. 527 o sub-TLVs: 529 * An optional single Weight sub-TLV. 531 * Zero or more Segment sub-TLVs. 533 Validation of an explicit path encoded by the Segment List sub-TLV is 534 completely within the scope of SRPM as described in section 5 in 535 [I-D.ietf-spring-segment-routing-policy]. 537 2.4.3.1. Weight Sub-TLV 539 The Weight sub-TLV specifies the weight associated to a given segment 540 list. The contents of this sub-TLV are used only by the SRPM as 541 described in section 2.11 in 542 [I-D.ietf-spring-segment-routing-policy]. 544 The Weight sub-TLV is optional and it MUST NOT appear more than once 545 inside the Segment List sub-TLV. If the Weight sub-TLV appears more 546 than once, the update is considered malformed and the "treat-as- 547 withdraw" strategy of [RFC7606] is applied. 549 The Weight sub-TLV has the following format: 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Type | Length | Flags | RESERVED | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Weight | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 where: 561 Type: 9 (to be assigned by IANA from the registry "SR Policy List 562 Sub-TLVs" defined in this document). 564 Length: 6. 566 Flags: 1 octet of flags. None are defined at this stage. Flags 567 SHOULD be set to zero on transmission and MUST be ignored on receipt. 569 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 570 and MUST be ignored on receipt. 572 2.4.3.2. Segment Sub-TLV 574 The Segment sub-TLV describes a single segment in a segment list 575 (i.e., a single element of the explicit path). Multiple Segment sub- 576 TLVs constitute an explicit path of the SR Policy. 578 The Segment sub-TLV is optional and MAY appear multiple times in the 579 Segment List sub-TLV. 581 The Segment sub-TLV does not have any effect on the BGP bestpath 582 selection or propagation procedures. The contents of this sub-TLV 583 are used only by the SRPM as described in section 4 in 584 [I-D.ietf-spring-segment-routing-policy]. 586 [I-D.ietf-spring-segment-routing-policy] defines several types of 587 Segments: 589 Type 1: SID only, in the form of MPLS Label 590 Type 2: SID only, in the form of IPv6 address 591 Type 3: IPv4 Node Address with optional SID 592 Type 4: IPv6 Node Address with optional SID for SR MPLS 593 Type 5: IPv4 Address + index with optional SID 594 Type 6: IPv4 Local and Remote addresses with optional SID 595 Type 7: IPv6 Address + index for local and remote pair with optional SID for SR MPLS 596 Type 8: IPv6 Local and Remote addresses with optional SID for SR MPLS 597 Type 9: IPv6 Node Address with optional SID for SRv6 598 Type 10: IPv6 Address + index for local and remote pair with optional SID for SRv6 599 Type 11: IPv6 Local and Remote addresses for SRv6 601 2.4.3.2.1. Type 1: SID only, in the form of MPLS Label 603 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 604 MPLS label. The format is as follows: 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Type | Length | Flags | RESERVED | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Label | TC |S| TTL | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 where: 616 o Type: 1 (to be assigned by IANA from the registry "SR Policy List 617 Sub-TLVs" defined in this document). 619 o Length is 6. 621 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 623 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 624 transmission and MUST be ignored on receipt. 626 o Label: 20 bits of label value. 628 o TC: 3 bits of traffic class. 630 o S: 1 bit of bottom-of-stack. 632 o TTL: 1 octet of TTL. 634 The following applies to the Type-1 Segment sub-TLV: 636 o The S bit SHOULD be zero upon transmission, and MUST be ignored 637 upon reception. 639 o If the originator wants the receiver to choose the TC value, it 640 sets the TC field to zero. 642 o If the originator wants the receiver to choose the TTL value, it 643 sets the TTL field to 255. 645 o If the originator wants to recommend a value for these fields, it 646 puts those values in the TC and/or TTL fields. 648 o The receiver MAY override the originator's values for these 649 fields. This would be determined by local policy at the receiver. 650 One possible policy would be to override the fields only if the 651 fields have the default values specified above. 653 2.4.3.2.2. Type 2: SID only, in the form of IPv6 address 655 The Type-2 Segment Sub-TLV encodes a single SRv6 SID in the form of 656 an IPv6 address. The format is as follows: 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Type | Length | Flags | RESERVED | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 // SRv6 SID (16 octets) // 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 where: 668 o Type: 2 (to be assigned by IANA from the registry "SR Policy List 669 Sub-TLVs" defined in this document). 671 o Length is 18. 673 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 675 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 676 transmission and MUST be ignored on receipt. 678 o SRv6 SID: 16 octets of IPv6 address. 680 The IPv6 Segment Identifier (SRv6 SID) is defined in 681 [I-D.ietf-6man-segment-routing-header]. 683 2.4.3.2.3. Type 3: IPv4 Node Address with optional SID 685 The Type-3 Segment Sub-TLV encodes an IPv4 node address, SR Algorithm 686 and an optional SID in the form of an MPLS label. The format is as 687 follows: 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Type | Length | Flags | SR Algorithm | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | IPv4 Node Address (4 octets) | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | SID (optional, 4 octets) | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 where: 701 o Type: 3 (to be assigned by IANA from the registry "SR Policy List 702 Sub-TLVs" defined in this document). 704 o Length is 6 or 10. 706 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 708 o SR Algorithm: 1 octet specifying SR Algorithm as described in 709 section 3.1.1 in [I-D.ietf-spring-segment-routing], when A-Flag as 710 defined in Section 2.4.3.2.12 is present. SR Algorithm is used by 711 SRPM as described in section 4 in 712 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 713 encoded, this field SHOULD be unset on transmission and MUST be 714 ignored on receipt. 716 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 718 o SID: 4 octet MPLS label. 720 The following applies to the Type-3 Segment sub-TLV: 722 o The IPv4 Node Address MUST be present. 724 o The SID is optional and specifies a 4 octet MPLS SID containing 725 label, TC, S and TTL as defined in Section 2.4.3.2.1. 727 o If length is 6, then only the IPv4 Node Address is present. 729 o If length is 10, then the IPv4 Node Address and the MPLS SID are 730 present. 732 2.4.3.2.4. Type 4: IPv6 Node Address with optional SID for SR MPLS 734 The Type-4 Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 735 and an optional SID in the form of an MPLS label. The format is as 736 follows: 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Type | Length | Flags | SR Algorithm | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 // IPv6 Node Address (16 octets) // 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | SID (optional, 4 octets) | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 where: 750 o Type: 4 (to be assigned by IANA from the registry "SR Policy List 751 Sub-TLVs" defined in this document). 753 o Length is 18 or 22. 755 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 757 o SR Algorithm: 1 octet specifying SR Algorithm as described in 758 section 3.1.1 in [I-D.ietf-spring-segment-routing], when A-Flag as 759 defined in Section 2.4.3.2.12 is present. SR Algorithm is used by 760 SRPM as described in section 4 in 761 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 762 encoded, this field SHOULD be unset on transmission and MUST be 763 ignored on receipt. 765 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 767 o SID: 4 octet MPLS label. 769 The following applies to the Type-4 Segment sub-TLV: 771 o The IPv6 Node Address MUST be present. 773 o The SID is optional and specifies a 4 octet MPLS SID containing 774 label, TC, S and TTL as defined in Section 2.4.3.2.1. 776 o If length is 18, then only the IPv6 Node Address is present. 778 o If length is 22, then the IPv6 Node Address and the MPLS SID are 779 present. 781 2.4.3.2.5. Type 5: IPv4 Address + Local Interface ID with optional SID 783 The Type-5 Segment Sub-TLV encodes an IPv4 node address, a local 784 interface Identifier (Local Interface ID) and an optional SID in the 785 form of an MPLS label. The format is as follows: 787 0 1 2 3 788 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Type | Length | Flags | RESERVED | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Local Interface ID (4 octets) | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | IPv4 Node Address (4 octets) | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | SID (optional, 4 octets) | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 where: 801 o Type: 5 (to be assigned by IANA from the registry "SR Policy List 802 Sub-TLVs" defined in this document). 804 o Length is 10 or 14. 806 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 808 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 809 transmission and MUST be ignored on receipt. 811 o Local Interface ID: 4 octets of interface index as defined in 812 [I-D.ietf-pce-segment-routing]. 814 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 816 o SID: 4 octet MPLS label. 818 The following applies to the Type-5 Segment sub-TLV: 820 o The IPv4 Node Address MUST be present. 822 o The Local Interface ID MUST be present. 824 o The SID is optional and specifies a 4 octet MPLS SID containing 825 label, TC, S and TTL as defined in Section 2.4.3.2.1. 827 o If length is 10, then the IPv4 Node Address and Local Interface ID 828 are present. 830 o If length is 14, then the IPv4 Node Address, the Local Interface 831 ID and the MPLS SID are present. 833 2.4.3.2.6. Type 6: IPv4 Local and Remote addresses with optional SID 835 The Type-6 Segment Sub-TLV encodes an adjacency local address, an 836 adjacency remote address and an optional SID in the form of an MPLS 837 label. The format is as follows: 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Type | Length | Flags | RESERVED | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Local IPv4 Address (4 octets) | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Remote IPv4 Address (4 octets) | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | SID (optional, 4 octets) | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 where: 853 o Type: 6 (to be assigned by IANA from the registry "SR Policy List 854 Sub-TLVs" defined in this document). 856 o Length is 10 or 14. 858 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 860 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 861 transmission and MUST be ignored on receipt. 863 o Local IPv4 Address: a 4 octet IPv4 address. 865 o Remote IPv4 Address: a 4 octet IPv4 address. 867 o SID: 4 octet MPLS label. 869 The following applies to the Type-6 Segment sub-TLV: 871 o The Local IPv4 Address MUST be present and represents an adjacency 872 local address. 874 o The Remote IPv4 Address MUST be present and represents the remote 875 end of the adjacency. 877 o The SID is optional and specifies a 4 octet MPLS SID containing 878 label, TC, S and TTL as defined in Section 2.4.3.2.1. 880 o If length is 10, then only the IPv4 Local and Remote addresses are 881 present. 883 o If length is 14, then the IPv4 Local address, IPv4 Remote address 884 and the MPLS SID are present. 886 2.4.3.2.7. Type 7: IPv6 Address + Interface ID for local and remote 887 pair with optional SID for SR MPLS 889 The Type-7 Segment Sub-TLV encodes an IPv6 Link Local adjacency with 890 IPv6 local node address, a local interface identifier (Local 891 Interface ID), IPv6 remote node address , a remote interface 892 identifier (Remote Interface ID) and an optional SID in the form of 893 an MPLS label. The format is as follows: 895 0 1 2 3 896 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 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Type | Length | Flags | RESERVED | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Local Interface ID (4 octets) | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 // IPv6 Local Node Address (16 octets) // 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Remote Interface ID (4 octets) | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 // IPv6 Remote Node Address (16 octets) // 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | SID (optional, 4 octets) | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 where: 913 o Type: 7 (to be assigned by IANA from the registry "SR Policy List 914 Sub-TLVs" defined in this document). 916 o Length is 22, 26, 42 or 46. 918 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 920 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 921 transmission and MUST be ignored on receipt. 923 o Local Interface ID: 4 octets of interface index as defined in 924 [I-D.ietf-pce-segment-routing]. 926 o IPv6 Local Node Address: a 16 octet IPv6 address. 928 o Remote Interface ID: 4 octets of interface index as defined in 929 [I-D.ietf-pce-segment-routing]. 931 o IPv6 Remote Node Address: a 16 octet IPv6 address. 933 o SID: 4 octet MPLS label. 935 The following applies to the Type-7 Segment sub-TLV: 937 o The Local Interface ID and IPv6 Local Node Address MUST be 938 present. 940 o The Remote Interface ID and Remote Node Address pair is optional. 941 If Remote Interface ID is present, the Remote Node Address MUST be 942 present as well. Similarly, if Remote Node Address is present, 943 the Remote Interface ID MUST be present as well. 945 o The SID is optional and specifies a 4 octet MPLS SID containing 946 label, TC, S and TTL as defined in Section 2.4.3.2.1. 948 o If length is 22, then the Local Interface ID and the Local IPv6 949 Address are present. 951 o If length is 26, then the Local Interface ID, Local IPv6 Address 952 and the MPLS SID are present. 954 o If length is 42, then the Local Interface ID, Local IPv6 Node 955 Address, Remote Interface ID, and the Remote IPv6 Node Address are 956 present. 958 o If length is 46, then the Local Interface ID, Local IPv6 Node 959 Address, Remote Interface ID, Remote IPv6 Node Address and the 960 MPLS SID are present. 962 2.4.3.2.8. Type 8: IPv6 Local and Remote addresses with optional SID 963 for SR MPLS 965 The Type-8 Segment Sub-TLV encodes an adjacency local address, an 966 adjacency remote address and an optional SID in the form of an MPLS 967 label. The format is as follows: 969 0 1 2 3 970 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 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Type | Length | Flags | RESERVED | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 // Local IPv6 Address (16 octets) // 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 // Remote IPv6 Address (16 octets) // 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | SID (optional, 4 octets) | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 where: 983 o Type: 8 (to be assigned by IANA from the registry "SR Policy List 984 Sub-TLVs" defined in this document). 986 o Length is 34 or 38. 988 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 990 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 991 transmission and MUST be ignored on receipt. 993 o Local IPv6 Address: a 16 octet IPv6 address. 995 o Remote IPv6 Address: a 16 octet IPv6 address. 997 o SID: 4 octet MPLS label. 999 The following applies to the Type-8 Segment sub-TLV: 1001 o The Local IPv6 Address MUST be present and represents an adjacency 1002 local address. 1004 o The Remote IPv6 Address MUST be present and represents the remote 1005 end of the adjacency. 1007 o The SID is optional and specifies a 4 octet MPLS SID containing 1008 label, TC, S and TTL as defined in Section 2.4.3.2.1. 1010 o If length is 34, then only the IPv6 Local and Remote addresses are 1011 present. 1013 o If length is 38, then IPv6 Local and Remote addresses and the MPLS 1014 SID are present. 1016 2.4.3.2.9. Type 9: IPv6 Node Address with optional SRv6 SID 1018 The Type-9 Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 1019 and an optional SID in the form of an IPv6 address. The format is as 1020 follows: 1022 0 1 2 3 1023 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 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | Type | Length | Flags | SR Algorithm | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 // IPv6 Node Address (16 octets) // 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 // SID (optional, 16 octets) // 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 where: 1034 o Type: 10 (to be assigned by IANA from the registry "SR Policy List 1035 Sub-TLVs" defined in this document). 1037 o Length is 18 or 34. 1039 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 1041 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1042 section 3.1.1 in [I-D.ietf-spring-segment-routing], when A-Flag as 1043 defined in Section 2.4.3.2.12 is present. SR Algorithm is used by 1044 SRPM as described in section 4 in 1045 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1046 encoded, this field SHOULD be unset on transmission and MUST be 1047 ignored on receipt. 1049 o IPv6 Node Address: a 16 octet IPv6 address. 1051 o SID: 16 octet IPv6 address. 1053 The following applies to the Type-9 Segment sub-TLV: 1055 o The IPv6 Node Address MUST be present. 1057 o The SID is optional and specifies an SRv6 SID in the form of 16 1058 octet IPv6 address. 1060 o If length is 18, then only the IPv6 Node Address is present. 1062 o If length is 34, then the IPv6 Node Address and the SRv6 SID are 1063 present. 1065 2.4.3.2.10. Type 10: IPv6 Address + Interface ID for local and remote 1066 pair for SRv6 with optional SID 1068 The Type-10 Segment Sub-TLV encodes an IPv6 Link Local adjacency with 1069 local node address, a local interface identifier (Local Interface 1070 ID), remote IPv6 node address , a remote interface identifier (Remote 1071 Interface ID) and an optional SID in the form of an IPv6 address. 1072 The format is as follows: 1074 0 1 2 3 1075 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 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Type | Length | Flags | RESERVED | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Local Interface ID (4 octets) | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 // IPv6 Local Node Address (16 octets) // 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Remote Interface ID (4 octets) | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 // IPv6 Remote Node Address (16 octets) // 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 // SID (optional, 16 octets) // 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 where: 1092 o Type: 11 (to be assigned by IANA from the registry "SR Policy List 1093 Sub-TLVs" defined in this document). 1095 o Length is 22, 38, 42 or 58. 1097 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 1099 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 1100 transmission and MUST be ignored on receipt. 1102 o Local Interface ID: 4 octets of interface index as defined in 1103 [I-D.ietf-pce-segment-routing]. 1105 o IPv6 Local Node Address: a 16 octet IPv6 address. 1107 o Remote Interface ID: 4 octets of interface index as defined in 1108 [I-D.ietf-pce-segment-routing]. 1110 o IPv6 Remote Node Address: a 16 octet IPv6 address. 1112 o SID: 16 octet IPv6 address. 1114 The following applies to the Type-10 Segment sub-TLV: 1116 o The Local Interface ID and the Local IPv6 Node Addresses MUST be 1117 present. 1119 o The Remote Interface ID and Remote Node Address pair is optional. 1120 If Remote Interface ID is present, the Remote Node Address MUST be 1121 present as well. Similarly, if Remote Node Address is present, 1122 the Remote Interface ID MUST be present as well. 1124 o The SID is optional and specifies an SRv6 SID in the form of 16 1125 octet IPv6 address. 1127 o If length is 22, then the Local Interface ID, Local IPv6 Node 1128 Address, are present. 1130 o If length is 38, then the Local Interface ID, Local IPv6 Node 1131 Address and the SRv6 SID are present. 1133 o If length is 42, then the Local Interface ID, Local IPv6 Node 1134 Address, Remote Interface ID, and the Remote IPv6 Node Address are 1135 present. 1137 o If length is 58, then the Local Interface ID, Local IPv6 Node 1138 Address, Remote Interface ID, Remote IPv6 Node Address and the 1139 SRv6 SID are present. 1141 2.4.3.2.11. Type 11: IPv6 Local and Remote addresses for SRv6 with 1142 optional SID 1144 The Type-11 Segment Sub-TLV encodes an adjacency local address, an 1145 adjacency remote address and an optional SID in the form of IPv6 1146 address. The format is as follows: 1148 0 1 2 3 1149 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 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | Type | Length | Flags | RESERVED | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 // Local IPv6 Address (16 octets) // 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 // Remote IPv6 Address (16 octets) // 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 // SID (optional, 16 octets) // 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 where: 1161 o Type: 12 (to be assigned by IANA from the registry "SR Policy List 1162 Sub-TLVs" defined in this document). 1164 o Length is 34 or 50. 1166 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 1168 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 1169 transmission and MUST be ignored on receipt. 1171 o Local IPv6 Address: a 16 octet IPv6 address. 1173 o Remote IPv6 Address: a 16 octet IPv6 address. 1175 o SID: 16 octet IPv6 address. 1177 The following applies to the Type-11 Segment sub-TLV: 1179 o The Local IPv6 Node Address MUST be present. 1181 o The Remote IPv6 Node Address MUST be present. 1183 o The SID is optional and specifies an SRv6 SID in the form of 16 1184 octet IPv6 address. 1186 o If length is 34, then the Local IPv6 Node Address and the Remote 1187 IPv6 Node Address are present. 1189 o If length is 50, then the Local IPv6 Node Address, the Remote IPv6 1190 Node Address and the SRv6 SID are present. 1192 2.4.3.2.12. Segment Flags 1194 The Segment Types described above MAY contain following flags in the 1195 "Flags" field (codes to be assigned by IANA from the registry "SR 1196 Policy Segment Flags" defined in this document Section 8.6): 1198 0 1 2 3 4 5 6 7 1199 +-+-+-+-+-+-+-+-+ 1200 |V|A| | 1201 +-+-+-+-+-+-+-+-+ 1203 where: 1205 V-Flag: This flag is used by SRPM for the purpose of "SID 1206 verification" as described in Section 5.1 in 1207 [I-D.ietf-spring-segment-routing-policy]. 1209 A-Flag: This flag indicates the presence of SR Algorithm id in the 1210 "SR Algorithm" field applicable to various Segment Types. SR 1211 Algorithm is used by SRPM as described in section 4 in 1212 [I-D.ietf-spring-segment-routing-policy]. 1214 Unused bits in the Flag octet SHOULD be set to zero upon 1215 transmission and MUST be ignored upon receipt. 1217 The following applies to the Segment Flags: 1219 o V-Flag is applicable to all Segment Types. 1221 o A-Flag is applicable to Segment Types 3, 4 and 9. If A-Flag 1222 appears with any other Segment Type, it MUST be ignored. 1224 2.4.4. Explicit NULL Label Policy Sub-TLV 1226 In order to steer an unlabeled IP packet into an SR policy, it is 1227 necessary to create a label stack for that packet, and to push one or 1228 more labels onto that stack. 1230 The Explicit NULL Label Policy sub-TLV is used to indicate whether an 1231 Explicit NULL Label [RFC3032] must be pushed on an unlabeled IP 1232 packet before any other labels. 1234 If an Explicit NULL Label Policy Sub-TLV is not present, the decision 1235 of whether to push an Explicit NULL label on a given packet is a 1236 matter of local policy. 1238 The contents of this sub-TLV are used by the SRPM as described in 1239 section 4.1 in [I-D.ietf-spring-segment-routing-policy]. 1241 0 1 2 3 1242 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 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Type | Length | Flags | RESERVED | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | ENLP | 1247 +-+-+-+-+-+-+-+-+ 1249 Where: 1251 Type: TBD1 (to be assigned by IANA from the registry "BGP Tunnel 1252 Encapsulation Attribute sub-TLVs" defined in this document 1253 Section 8.3). 1255 Length: 3. 1257 Flags: 1 octet of flags. None are defined at this stage. Flags 1258 SHOULD be set to zero on transmission and MUST be ignored on 1259 receipt. 1261 RESERVED: 1 octet of reserved bits. SHOULD be unset on 1262 transmission and MUST be ignored on receipt. 1264 ENLP(Explicit NULL Label Policy): Indicates whether Explicit NULL 1265 labels are to be pushed on unlabeled IP packets that are being 1266 steered into a given SR policy. This field has one of the 1267 following 4 values: 1269 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1270 packet, but do not push an IPv6 Explicit NULL label on an 1271 unlabeled IPv6 packet. 1273 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 1274 packet, but do not push an IPv4 Explicit NULL label on an 1275 unlabeled IPv4 packet. 1277 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1278 packet, and push an IPv6 Explicit NULL label on an unlabeled 1279 IPv6 packet. 1281 4: Do not push an Explicit NULL label. 1283 The policy signaled in this Sub-TLV MAY be overridden by local 1284 policy. 1286 2.4.5. Policy Priority Sub-TLV 1288 An operator MAY set the Policy Priority sub-TLV to indicate the order 1289 in which the SR policies are re-computed upon topological change. 1291 The Priority sub-TLV does not have any effect on the BGP bestpath 1292 selection or propagation procedures. The contents of this sub-TLV 1293 are used by the SRPM as described in section 2.11 in 1294 [I-D.ietf-spring-segment-routing-policy]. 1296 The Priority sub-TLV is optional and it MUST NOT appear more than 1297 once in the SR Policy TLV. If the Priority sub-TLV appears more than 1298 once, the update is considered malformed and the "treat-as-withdraw" 1299 strategy of [RFC7606] is applied. 1301 The Priority sub-TLV has following format: 1303 0 1 2 3 1304 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 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Type | Length | Priority | RESERVED | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 Where: 1311 Type: TBD2 (to be assigned by IANA from the registry "BGP Tunnel 1312 Encapsulation Attribute sub-TLVs" defined in this document 1313 Section 8.3). 1315 Length: 2. 1317 Priority: a 1-octet value. 1319 RESERVED: 1 octet of reserved bits. SHOULD be unset on 1320 transmission and MUST be ignored on receipt. 1322 2.4.6. Policy Name Sub-TLV 1324 An operator MAY set the Policy Name sub-TLV to attach a symbolic name 1325 to the SR Policy candidate path. 1327 Usage of Policy Name sub-TLV is described in section 2 in 1328 [I-D.ietf-spring-segment-routing-policy]. 1330 The Policy Name sub-TLV may exceed 255 bytes length due to long 1331 policy name. Therefore a 2-octet length is required. According to 1332 [I-D.ietf-idr-tunnel-encaps], the first bit of the sub-TLV codepoint 1333 defines the size of the length field. Therefore, for the Policy Name 1334 sub-TLV a code point of 128 (or higher) is used. See Section 8 for 1335 details of codepoints allocation. 1337 The Policy Name sub-TLV is optional and it MUST NOT appear more than 1338 once in the SR Policy TLV. If the Policy Name sub-TLV appears more 1339 than once, the update is considered malformed and the "treat-as- 1340 withdraw" strategy of [RFC7606] is applied. 1342 The Policy Name sub-TLV has following format: 1344 0 1 2 3 1345 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 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | Type | Length | RESERVED | 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 // Policy Name // 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 Where: 1353 Type: TBD3 (to be assigned by IANA from the registry "BGP Tunnel 1354 Encapsulation Attribute sub-TLVs" defined in this document 1355 Section 8.3). 1357 Length: Variable. 1359 RESERVED: 1 octet of reserved bits. SHOULD be unset on 1360 transmission and MUST be ignored on receipt. 1362 Policy Name: Symbolic name for the policy. It SHOULD be a string 1363 of printable ASCII characters, without a NULL terminator. 1365 3. Extended Color Community 1367 The Color Extended Community as defined in 1368 [I-D.ietf-idr-tunnel-encaps] is used to steer traffic into a policy. 1370 When the Color Extended Community is used for the purpose of steering 1371 the traffic into an SR Policy, the RESERVED field (as defined in 1372 [I-D.ietf-idr-tunnel-encaps] is changed as follows: 1374 1 1375 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 |C O| RESERVED | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 where CO bits are defined as the "Color-Only" bits. 1381 [I-D.ietf-spring-segment-routing-policy] defines the influence of 1382 these bits on the automated steering of BGP Payload traffic onto SR 1383 Policies. 1385 4. SR Policy Operations 1387 As described in this document, the consumer of an SR Policy NLRI is 1388 not the BGP process. The BGP process is in charge of the origination 1389 and propagation of the SR Policy NLRI but its installation and use is 1390 outside the scope of BGP. The details of SR Policy installation and 1391 use can be referred from [I-D.ietf-spring-segment-routing-policy]. 1393 4.1. Configuration and Advertisement of SR Policies 1395 Typically, but not limited to, an SR Policy is configured into a 1396 controller. 1398 Multiple SR Policy NLRIs may be present with the same tuple but with different content when these SR policies are 1400 intended to different head-ends. 1402 The distinguisher of each SR Policy NLRI prevents undesired BGP route 1403 selection among these SR Policy NLRIs and allow their propagation 1404 across route reflectors [RFC4456]. 1406 Moreover, one or more route-target SHOULD be attached to the 1407 advertisement, where each route-target identifies one or more 1408 intended head-ends for the advertised SR policy. 1410 If no route-target is attached to the SR Policy NLRI, then it is 1411 assumed that the originator sends the SR Policy update directly 1412 (e.g., through a BGP session) to the intended receiver. In such 1413 case, the NO_ADVERTISE community MUST be attached to the SR Policy 1414 update. 1416 4.2. Reception of an SR Policy NLRI 1418 On reception of an SR Policy NLRI, a BGP speaker MUST determine if 1419 it's first acceptable, then it determines if it is usable. 1421 4.2.1. Acceptance of an SR Policy NLRI 1423 When a BGP speaker receives an SR Policy NLRI from a neighbor it has 1424 to determine if it's acceptable. The following applies: 1426 o The SR Policy NLRI MUST include a distinguisher, color and 1427 endpoint field which implies that the length of the NLRI MUST be 1428 either 12 or 24 octets (depending on the address family of the 1429 endpoint). 1431 o The SR Policy update MUST have either the NO_ADVERTISE community 1432 or at least one route-target extended community in IPv4-address 1433 format. If a router supporting this document receives an SR 1434 policy update with no route-target extended communities and no 1435 NO_ADVERTISE community, the update MUST NOT be sent to the SRPM. 1436 Furthermore, it SHOULD be considered to be malformed, and the 1437 "treat-as-withdraw" strategy of [RFC7606] is applied. 1439 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1440 Update and MUST have a Tunnel Type TLV set to SR Policy ( 1441 codepoint is 15, assigned by IANA (see Section 8) from the "BGP 1442 Tunnel Encapsulation Attribute Tunnel Types" registry). 1444 A router that receives an SR Policy update that is not valid 1445 according to these criteria MUST treat the update as malformed. The 1446 route MUST NOT be passed to the SRPM, and the "treat-as-withdraw" 1447 strategy of [RFC7606] is applied. 1449 A unacceptable SR Policy update that has a valid NLRI portion with 1450 invalid attribute portion MUST be considered as a withdraw of the SR 1451 Policy. 1453 4.2.2. Usable SR Policy NLRI 1455 If one or more route-targets are present, then at least one route- 1456 target MUST match one of the BGP Identifiers of the receiver in order 1457 for the update to be considered usable. The BGP Identifier is 1458 defined in [RFC4271] as a 4 octet IPv4 address. Therefore the route- 1459 target extended community MUST be of the same format. 1461 If one or more route-targets are present and no one matches any of 1462 the local BGP Identifiers, then, while the SR Policy NLRI is 1463 acceptable, it is not usable on the receiver node. It has to be 1464 noted that if the receiver has been explicitly configured to do so, 1465 it MAY propagate the SR Policy NLRI to its neighbors as defined in 1466 Section 4.2.4. 1468 The SR Policy candidate paths encoded by the usable SR Policy NLRIs 1469 are sent to the SRPM. 1471 4.2.3. Passing a usable SR Policy NLRI to the SRPM 1473 Once BGP has determined that the SR Policy NLRI is usable, BGP passes 1474 the SR Policy candidate path to the SRPM. Note that, along with the 1475 candidate path details, BGP also passes the originator information 1476 for breaking ties in the path-selection process as described in 1477 section 2.4 in [I-D.ietf-spring-segment-routing-policy]. 1479 The SRPM applies the rules defined in section 2 in 1480 [I-D.ietf-spring-segment-routing-policy] to determine whether the SR 1481 Policy candidate path is valid and to select the best candidate path 1482 among the valid SR Policy candidate paths. 1484 4.2.4. Propagation of an SR Policy 1486 By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate 1487 it to any EBGP neighbor. 1489 However, a node MAY be explicitly configured to advertise a received 1490 SR Policy NLRI to neighbors according to normal BGP rules (i.e., EBGP 1491 propagation by an ASBR or iBGP propagation by a Route-Reflector). 1493 SR Policy NLRIs that have been determined acceptable and valid can be 1494 propagated, even the ones that are not usable. 1496 Only SR Policy NLRIs that do not have the NO_ADVERTISE community 1497 attached to them can be propagated. 1499 4.3. Flowspec and SR Policies 1501 The SR Policy can be carried in context of a Flowspec NLRI 1502 ([RFC5575]). In this case, when the redirect to IP next-hop is 1503 specified as in [I-D.ietf-idr-flowspec-redirect-ip], the tunnel to 1504 the next-hop is specified by the segment list in the Segment List 1505 sub-TLVs. The Segment List (e.g., label stack or IPv6 segment list) 1506 is imposed to flows matching the criteria in the Flowspec route to 1507 steer them towards the next-hop as specified in the SR Policy SAFI 1508 NLRI. 1510 5. Contributors 1512 Arjun Sreekantiah 1513 Cisco Systems 1514 US 1516 Email: asreekan@cisco.com 1518 Acee Lindem 1519 Cisco Systems 1520 US 1522 Email: acee@cisco.com 1524 Siva Sivabalan 1525 Cisco Systems 1526 US 1528 Email: msiva@cisco.com 1530 Imtiyaz Mohammad 1531 Arista Networks 1532 India 1534 Email: imtiyaz@arista.com 1536 Gaurav Dawra 1537 Cisco Systems 1538 US 1540 Email: gdawra.ietf@gmail.com 1542 6. Acknowledgments 1544 The authors of this document would like to thank Shyam Sethuram, John 1545 Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha and Ketan 1546 Talaulikar for their comments and review of this document. 1548 7. Implementation Status 1550 Note to RFC Editor: Please remove this section prior to publication, 1551 as well as the reference to RFC 7942. 1553 This section records the status of known implementations of the 1554 protocol defined by this specification at the time of posting of this 1555 Internet-Draft, and is based on a proposal described in [RFC7942]. 1556 The description of implementations in this section is intended to 1557 assist the IETF in its decision processes in progressing drafts to 1558 RFCs. Please note that the listing of any individual implementation 1559 here does not imply endorsement by the IETF. Furthermore, no effort 1560 has been spent to verify the information presented here that was 1561 supplied by IETF contributors. This is not intended as, and must not 1562 be construed to be, a catalog of available implementations or their 1563 features. Readers are advised to note that other implementations may 1564 exist. 1566 According to [RFC7942], "this will allow reviewers and working groups 1567 to assign due consideration to documents that have the benefit of 1568 running code, which may serve as evidence of valuable experimentation 1569 and feedback that have made the implemented protocols more mature. 1570 It is up to the individual working groups to use this information as 1571 they see fit". 1573 Several early implementations exist and will be reported in detail in 1574 a forthcoming version of this document. For purposes of early 1575 interoperability testing, when no FCFS code point was available, 1576 implementations have made use of the following values: 1578 o Preference sub-TLV: 12 1580 o Binding SID sub-TLV: 13 1582 o Segment List sub-TLV: 128 1584 When IANA-assigned values are available, implementations will be 1585 updated to use them. 1587 8. IANA Considerations 1589 This document defines new Sub-TLVs in following existing registries: 1591 o Subsequent Address Family Identifiers (SAFI) Parameters 1593 o BGP Tunnel Encapsulation Attribute Tunnel Types 1595 o BGP Tunnel Encapsulation Attribute sub-TLVs 1597 This document also defines following new registries: 1599 o SR Policy List Sub-TLVs 1601 o SR Policy Binding SID Flags 1603 o SR Policy Segment Flags 1605 8.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1606 Parameters 1608 This document defines a new SAFI in the registry "Subsequent Address 1609 Family Identifiers (SAFI) Parameters" that has been assigned by IANA: 1611 Codepoint Description Reference 1612 ----------------------------------------------- 1613 73 SR Policy SAFI This document 1615 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1617 This document defines a new Tunnel-Type in the registry "BGP Tunnel 1618 Encapsulation Attribute Tunnel Types" that has been assigned by IANA: 1620 Codepoint Description Reference 1621 -------------------------------------------------- 1622 15 SR Policy Type This document 1624 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1626 This document defines new sub-TLVs in the registry "BGP Tunnel 1627 Encapsulation Attribute sub-TLVs" to be assigned by IANA: 1629 Codepoint Description Reference 1630 ------------------------------------------------------ 1631 12 Preference sub-TLV This document 1632 13 Binding SID sub-TLV This document 1633 128 Segment List sub-TLV This document 1634 TBD1 ENLP sub-TLV This document 1635 TBD2 Priority sub-TLV This document 1636 TBD3 Policy Name sub-TLV This document 1638 8.4. New Registry: SR Policy List Sub-TLVs 1640 This document defines a new registry called "SR Policy List Sub- 1641 TLVs". The allocation policy of this registry is "First Come First 1642 Served (FCFS)" according to [RFC8126]. 1644 Following Sub-TLV codepoints are defined: 1646 Value Description Reference 1647 --------------------------------------------------------------------------------- 1648 1 MPLS SID sub-TLV This document 1649 2 SRv6 SID sub-TLV This document 1650 3 IPv4 Node and SID sub-TLV This document 1651 4 IPv6 Node and SID for SR-MPLS sub-TLV This document 1652 5 IPv4 Node, index and SID sub-TLV This document 1653 6 IPv4 Local/Remote addresses and SID sub-TLV This document 1654 7 IPv6 Node, index for remote and local pair This document 1655 and SID for SR-MPLS sub-TLV 1656 8 IPv6 Local/Remote addresses and SID sub-TLV This document 1657 9 Weight sub-TLV This document 1658 10 IPv6 Node and SID for SRv6 sub-TLV This document 1659 11 IPv6 Node, index for remote and local pair This document 1660 and SID for SRv6 sub-TLV 1661 12 IPv6 Local/Remote addresses and SID for This document 1662 SRv6 sub-TLV 1664 8.5. New Registry: SR Policy Binding SID Flags 1666 This document defines a new registry called "SR Policy Binding SID 1667 Flags". The allocation policy of this registry is "First Come First 1668 Served (FCFS)" according to [RFC8126]. 1670 Following Flags are defined: 1672 Bit Description Reference 1673 --------------------------------------------------------------------------------- 1674 0 Specified-BSID-Only Flag (S-Flag) This document 1675 1 Drop Upon Invalid Flag (I-Flag) This document 1676 2-7 Unassigned 1678 8.6. New Registry: SR Policy Segment Flags 1680 This document defines a new registry called "SR Policy Segment 1681 Flags". The allocation policy of this registry is "First Come First 1682 Served (FCFS)" according to [RFC8126]. 1684 Following Flags are defined: 1686 Bit Description Reference 1687 --------------------------------------------------------------------------------- 1688 0 Segment Verification Flag (V-Flag) This document 1689 1 SR Algorithm Flag (A-Flag) This document 1690 2-7 Unassigned 1692 9. Security Considerations 1694 TBD. 1696 10. References 1698 10.1. Normative References 1700 [I-D.ietf-idr-tunnel-encaps] 1701 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 1702 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-11 1703 (work in progress), February 2019. 1705 [I-D.ietf-pce-segment-routing] 1706 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1707 and J. Hardwick, "PCEP Extensions for Segment Routing", 1708 draft-ietf-pce-segment-routing-16 (work in progress), 1709 March 2019. 1711 [I-D.ietf-spring-segment-routing] 1712 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1713 Litkowski, S., and R. Shakir, "Segment Routing 1714 Architecture", draft-ietf-spring-segment-routing-15 (work 1715 in progress), January 2018. 1717 [I-D.ietf-spring-segment-routing-policy] 1718 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1719 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1720 Policy Architecture", draft-ietf-spring-segment-routing- 1721 policy-03 (work in progress), May 2019. 1723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1724 Requirement Levels", BCP 14, RFC 2119, 1725 DOI 10.17487/RFC2119, March 1997, 1726 . 1728 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1729 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1730 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1731 . 1733 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1734 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1735 DOI 10.17487/RFC4271, January 2006, 1736 . 1738 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1739 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1740 February 2006, . 1742 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1743 "Multiprotocol Extensions for BGP-4", RFC 4760, 1744 DOI 10.17487/RFC4760, January 2007, 1745 . 1747 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1748 and D. McPherson, "Dissemination of Flow Specification 1749 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1750 . 1752 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1753 Patel, "Revised Error Handling for BGP UPDATE Messages", 1754 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1755 . 1757 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1758 Writing an IANA Considerations Section in RFCs", BCP 26, 1759 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1760 . 1762 10.2. Informational References 1764 [I-D.filsfils-spring-sr-policy-considerations] 1765 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1766 P. Mattes, "SR Policy Implementation and Deployment 1767 Considerations", draft-filsfils-spring-sr-policy- 1768 considerations-03 (work in progress), April 2019. 1770 [I-D.ietf-6man-segment-routing-header] 1771 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 1772 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 1773 (SRH)", draft-ietf-6man-segment-routing-header-18 (work in 1774 progress), April 2019. 1776 [I-D.ietf-idr-flowspec-redirect-ip] 1777 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 1778 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 1779 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 1780 in progress), February 2015. 1782 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1783 Reflection: An Alternative to Full Mesh Internal BGP 1784 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1785 . 1787 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1788 Code: The Implementation Status Section", BCP 205, 1789 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1790 . 1792 Authors' Addresses 1794 Stefano Previdi (editor) 1795 Individual 1796 IT 1798 Email: stefano@previdi.net 1800 Clarence Filsfils 1801 Cisco Systems, Inc. 1802 Brussels 1803 BE 1805 Email: cfilsfil@cisco.com 1807 Dhanendra Jain (editor) 1808 Google 1810 Email: dhanendra.ietf@gmail.com 1811 Paul Mattes 1812 Microsoft 1813 One Microsoft Way 1814 Redmond, WA 98052 1815 USA 1817 Email: pamattes@microsoft.com 1819 Eric Rosen 1820 Juniper Networks 1821 10 Technology Park Drive 1822 Westford, MA 01886 1823 US 1825 Email: erosen@juniper.net 1827 Steven Lin 1828 Google 1830 Email: stevenlin@google.com