idnits 2.17.1 draft-ietf-idr-segment-routing-te-policy-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2022) is 672 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 Huawei Technologies 4 Updates: 9012 (if approved) C. Filsfils 5 Intended status: Standards Track Cisco Systems 6 Expires: December 18, 2022 K. Talaulikar, Ed. 7 Arrcus Inc 8 P. Mattes 9 Microsoft 10 D. Jain 11 S. Lin 12 Google 13 June 16, 2022 15 Advertising Segment Routing Policies in BGP 16 draft-ietf-idr-segment-routing-te-policy-18 18 Abstract 20 This document introduces a BGP SAFI with two NLRIs to advertise a 21 candidate path of a Segment Routing (SR) Policy. An SR Policy is a 22 set of candidate paths, each consisting of one or more segment lists. 23 The headend of an SR Policy may learn multiple candidate paths for an 24 SR Policy. Candidate paths may be learned via several different 25 mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document 26 specifies how BGP may be used to distribute SR Policy candidate 27 paths. It defines sub-TLVs for the Tunnel Encapsulation Attribute 28 for signaling information about these candidate paths. 30 This documents updates RFC9012 with extensions to the Color Extended 31 Community to support additional steering modes over SR Policy. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 18, 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 69 2. SR Policy Encoding . . . . . . . . . . . . . . . . . . . . . 5 70 2.1. SR Policy SAFI and NLRI . . . . . . . . . . . . . . . . . 5 71 2.2. SR Policy and Tunnel Encapsulation Attribute . . . . . . 7 72 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 73 2.4. SR Policy Sub-TLVs . . . . . . . . . . . . . . . . . . . 9 74 2.4.1. Preference Sub-TLV . . . . . . . . . . . . . . . . . 9 75 2.4.2. Binding SID Sub-TLV . . . . . . . . . . . . . . . . . 10 76 2.4.3. SRv6 Binding SID Sub-TLV . . . . . . . . . . . . . . 11 77 2.4.4. Segment List Sub-TLV . . . . . . . . . . . . . . . . 13 78 2.4.5. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 27 79 2.4.6. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 29 80 2.4.7. Policy Candidate Path Name Sub-TLV . . . . . . . . . 30 81 2.4.8. Policy Name Sub-TLV . . . . . . . . . . . . . . . . . 31 82 3. Color Extended Community . . . . . . . . . . . . . . . . . . 32 83 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 33 84 4.1. Advertisement of SR Policies . . . . . . . . . . . . . . 33 85 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 33 86 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 33 87 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 34 88 4.2.3. Passing a usable SR Policy NLRI to the SRPM . . . . . 34 89 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 35 90 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 35 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 92 6.1. Existing Registry: Subsequent Address Family Identifiers 93 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 37 94 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute 95 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 37 96 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute 97 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 37 99 6.4. Existing Registry: Color Extended Community Flags . . . . 38 100 6.5. New Registry: SR Policy Segment List Sub-TLVs . . . . . . 38 101 6.6. New Registry: SR Policy Binding SID Flags . . . . . . . . 39 102 6.7. New Registry: SR Policy SRv6 Binding SID Flags . . . . . 39 103 6.8. New Registry: SR Policy Segment Flags . . . . . . . . . . 40 104 6.9. New Registry: Color Extended Community Color-Only Types . 40 105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41 106 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 107 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 108 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 109 10.1. Normative References . . . . . . . . . . . . . . . . . . 43 110 10.2. Informational References . . . . . . . . . . . . . . . . 44 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 113 1. Introduction 115 Segment Routing (SR) [RFC8402] allows a headend node to steer a 116 packet flow along any path. Intermediate per-path states are 117 eliminated thanks to source routing. 119 The headend node is said to steer a flow into an SR Policy [RFC8402]. 121 The packets steered into an SR Policy carry an ordered list of 122 segments associated with that SR Policy. 124 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 125 Policy and steering into an SR Policy. These apply equally to the 126 SR-MPLS and Segment Routing for IPv6 (SRv6) data-plane instantiations 127 of Segment Routing using SR-MPLS and SRv6 Segment Identifiers (SIDs) 128 as described in [RFC8402]. [RFC8660] describes the representation 129 and processing of this ordered list of segments as an MPLS label 130 stack for SR-MPLS. While [RFC8754] and [RFC8986] describe the same 131 for SRv6 with the use of the Segment Routing Header (SRH). 133 The SR Policy related functionality described in 134 [I-D.ietf-spring-segment-routing-policy] can be conceptually viewed 135 as being incorporated in an SR Policy Module (SRPM). Following is a 136 reminder of the high-level functionality of SRPM: 138 o Learning multiple candidate paths for an SR Policy via various 139 mechanisms (CLI, NetConf, PCEP, or BGP). 141 o Selection of the best candidate path for an SR Policy. 143 o Binding BSID to the selected candidate path of an SR Policy. 145 o Installation of the selected candidate path and its BSID in the 146 forwarding plane. 148 This document specifies the way to use BGP to distribute one or more 149 of the candidate paths of an SR Policy to the headend of that policy. 150 The document describes the functionality provided by BGP and, as 151 appropriate, provides references for the functionality which is 152 outside the scope of BGP (i.e. resides within SRPM on the headend 153 node). 155 This document specifies a way of representing SR Policy candidate 156 paths in BGP UPDATE messages. BGP can then be used to propagate the 157 SR Policy candidate paths to the headend nodes in the network. The 158 usual BGP rules for BGP propagation and best-path selection are used. 159 At the headend of a specific policy, this will result in one or more 160 candidate paths being installed into the "BGP table". These paths 161 are then passed to the SRPM. The SRPM may compare them to candidate 162 paths learned via other mechanisms and will choose one or more paths 163 to be installed in the data plane. BGP itself does not install SR 164 Policy candidate paths into the data plane. 166 This document introduces a BGP subsequent address family (SAFI) for 167 IPv4 and IPv6 address families. In UPDATE messages of those AFI/ 168 SAFIs, the NLRI identifies an SR Policy Candidate Path while the 169 attributes encode the segment lists and other details of that SR 170 Policy Candidate Path. 172 While for simplicity we may write that BGP advertises an SR Policy, 173 it has to be understood that BGP advertises a candidate path of an SR 174 policy and that this SR Policy might have several other candidate 175 paths provided via BGP (via an NLRI with a different distinguisher as 176 defined in this document), PCEP, NETCONF, or local policy 177 configuration. 179 Typically, a controller defines the set of policies and advertises 180 them to policy head-end routers (typically ingress routers). These 181 policy advertisements use the BGP extensions defined in this 182 document. The policy advertisement is, in most but not all the 183 cases, tailored for a specific policy head-end. In this case, the 184 advertisement may be sent on a BGP session to that head-end and not 185 propagated any further. 187 Alternatively, a router (i.e., a BGP egress router) advertises SR 188 Policies representing paths to itself. In this case, it is possible 189 to send the policy to each head-end over a BGP session to that head- 190 end, without requiring any further propagation of the policy. 192 An SR Policy intended only for the receiver will, in most cases, not 193 traverse any Route Reflector (RR, [RFC4456]). 195 In some situations, it is undesirable for a controller or BGP egress 196 router to have a BGP session to each policy head-end. In these 197 situations, BGP Route Reflectors may be used to propagate the 198 advertisements, or it may be necessary for the advertisement to 199 propagate through a sequence of one or more AS. To make this 200 possible, an attribute needs to be attached to the advertisement that 201 enables a BGP speaker to determine whether it is intended to be a 202 head-end for the advertised policy. This is done by attaching one or 203 more Route Target Extended Communities to the advertisement 204 ([RFC4360]). 206 The BGP extensions for the advertisement of SR Policies include 207 following components: 209 o A Subsequent Address Family Identifier (SAFI) whose NLRIs 210 identifies an SR Policy candidate path. 212 o A Tunnel Type identifier for SR Policy, and a set of sub-TLVs to 213 be inserted into the Tunnel Encapsulation Attribute (as defined in 214 [RFC9012]) specifying segment lists of the SR Policy candidate 215 path, as well as other information about the SR Policy. 217 o One or more IPv4 address format route target extended community 218 ([RFC4360]) attached to the SR Policy advertisement and that 219 indicates the intended head-end of such SR Policy advertisement. 221 The Color Extended Community (as defined in [RFC9012]) is used to 222 steer traffic into an SR Policy, as described in section 8.8 of 223 [I-D.ietf-spring-segment-routing-policy]. This document (Section 3) 224 updates [RFC9012] with modifications to the format of the Color 225 Extended Community by using the two leftmost bits of the RESERVED 226 field. 228 1.1. Requirements Language 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 232 "OPTIONAL" in this document are to be interpreted as described in BCP 233 14 [RFC2119] [RFC8174] when, and only when, they appear in all 234 capitals, as shown here. 236 2. SR Policy Encoding 238 2.1. SR Policy SAFI and NLRI 240 A SAFI is introduced by this document: the SR Policy SAFI with 241 codepoint 73. The AFI used MUST be IPv4(1) or IPv6(2). 243 The SR Policy SAFI uses the NLRI format defined as follows: 245 +------------------+ 246 | NLRI Length | 1 octet 247 +------------------+ 248 | Distinguisher | 4 octets 249 +------------------+ 250 | Policy Color | 4 octets 251 +------------------+ 252 | Endpoint | 4 or 16 octets 253 +------------------+ 255 where: 257 o NLRI Length: 1 octet of length expressed in bits as defined in 258 [RFC4760]. When AFI = 1 value MUST be 96 and when AFI = 2 value 259 MUST be 192. 261 o Distinguisher: 4-octet value uniquely identifying the policy in 262 the context of tuple. The distinguisher has no 263 semantic value and is solely used by the SR Policy originator to 264 make unique (from an NLRI perspective) both for multiple candidate 265 paths of the same SR Policy as well as candidate paths of 266 different SR Policies (i.e. with different segment lists) with the 267 same Color and Endpoint but meant for different head-ends. 269 o Policy Color: 4-octet value identifying (with the endpoint) the 270 policy. The color is used to match the color of the destination 271 prefixes to steer traffic into the SR Policy as specified in 272 [I-D.ietf-spring-segment-routing-policy]. 274 o Endpoint: identifies the endpoint of a policy. The Endpoint may 275 represent a single node or a set of nodes (e.g., an anycast 276 address). The Endpoint is an IPv4 (4-octet) address or an IPv6 277 (16-octet) address according to the AFI of the NLRI. 279 The color and endpoint are used to automate the steering of BGP 280 Payload prefixes on SR Policy as described in 281 [I-D.ietf-spring-segment-routing-policy]. 283 The NLRI containing the SR Policy candidate path is carried in a BGP 284 UPDATE message [RFC4271] using BGP multi-protocol extensions 285 [RFC4760] with an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of 73. 287 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 288 attribute with the SR Policy SAFI MUST also carry the BGP mandatory 289 attributes. In addition, the BGP update message MAY also contain any 290 of the BGP optional attributes. 292 The next-hop network address field in SR Policy SAFI (73) updates may 293 be either a 4-octet IPv4 address or a 16-octet IPv6 address, 294 independent of the SR Policy AFI. The length field of the next-hop 295 address specifies the next-hop address family. If the next-hop 296 length is 4, then the next-hop is an IPv4 address; if the next-hop 297 length is 16, then it is a global IPv6 address; if the next-hop 298 length is 32, then it has a global IPv6 address followed by a link- 299 local IPv6 address. The setting of the next-hop field and its 300 attendant processing is governed by standard BGP procedures as 301 described in section 3 in [RFC4760]. 303 It is important to note that any BGP speaker receiving a BGP message 304 with an SR Policy NLRI, will process it only if the NLRI is among the 305 best paths as per the BGP best-path selection algorithm. In other 306 words, this document leverages the existing BGP propagation and best- 307 path selection rules. Details of the procedures are described in 308 Section 4. 310 It has to be noted that if several candidate paths of the same SR 311 Policy (endpoint, color) are signaled via BGP to a head-end, it is 312 RECOMMENDED that each NLRI uses a different distinguisher. If BGP 313 has installed into the BGP table two advertisements whose respective 314 NLRIs have the same color and endpoint, but different distinguishers, 315 both advertisements are passed to the SRPM as different candidate 316 paths along with their respective originator information (i.e. ASN 317 and BGP Router-ID) as described in section 2.4 of 318 [I-D.ietf-spring-segment-routing-policy]. The ASN would be the ASN 319 of origin and the BGP Router-ID is determined in the following order: 321 o From the Route Origin Community [RFC4360] if present and carrying 322 an IP Address 324 o As the BGP Originator ID [RFC4456] if present 326 o As the BGP Router-ID of the peer from which the update was 327 received as a last resort. 329 2.2. SR Policy and Tunnel Encapsulation Attribute 331 The content of the SR Policy Candidate Path is encoded in the Tunnel 332 Encapsulation Attribute defined in [RFC9012] using a Tunnel-Type 333 called SR Policy Type with codepoint 15. The use of SR Policy 334 Tunnel-type is applicable only for the AFI/SAFI pairs of (1/73, 335 2/73). 337 The SR Policy Encoding structure is as follows: 339 SR Policy SAFI NLRI: 340 Attributes: 341 Tunnel Encaps Attribute (23) 342 Tunnel Type: SR Policy 343 Binding SID 344 SRv6 Binding SID 345 Preference 346 Priority 347 Policy Name 348 Policy Candidate Path Name 349 Explicit NULL Label Policy (ENLP) 350 Segment List 351 Weight 352 Segment 353 Segment 354 ... 355 ... 356 where: 358 o SR Policy SAFI NLRI is defined in Section 2.1. 360 o Tunnel Encapsulation Attribute is defined in [RFC9012]. 362 o Tunnel-Type is set to 15. 364 o Preference, Binding SID, SRv6 Binding SID, Priority, Policy Name, 365 Policy Candidate Path Name, ENLP, Segment-List, Weight, and 366 Segment sub-TLVs are defined in this document. 368 o Additional sub-TLVs may be defined in the future. 370 A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV 371 of type "SR Policy". 373 2.3. Remote Endpoint and Color 375 The Tunnel Egress Endpoint and Color sub-TLVs, as defined in 376 [RFC9012], may also be present in the SR Policy encodings. 378 The Tunnel Egress Endpoint and Color Sub-TLVs of the Tunnel 379 Encapsulation Attribute are not used for SR Policy encodings and 380 therefore their value is irrelevant in the context of the SR Policy 381 SAFI NLRI. If present, the Tunnel Egress Endpoint sub-TLV and the 382 Color sub-TLV MUST be ignored by the BGP speaker and not removed from 383 the Tunnel Encapsulation Attribute during propagation. 385 2.4. SR Policy Sub-TLVs 387 This section specifies the sub-TLVs defined for encoding the 388 information about the SR Policy Candidate Path. 390 Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority, 391 Policy Name, Policy Candidate Path Name, and Explicit NULL Label 392 Policy are the sub-TLVs introduced for the BGP Tunnel Encapsulation 393 Attribute [RFC9012] being defined in this section. 395 Weight and Segment are sub-TLVs of the Segment-List sub-TLV mentioned 396 above. 398 None of the sub-TLVs defined in the following sub-sections have any 399 effect on the BGP best-path selection or propagation procedures. 400 These sub-TLVs are not used by BGP and are instead passed on to SRPM 401 as SR Policy Candidate Path information for further processing 402 described in [I-D.ietf-spring-segment-routing-policy]. 404 The use of SR Policy Sub-TLVs is applicable only for the AFI/SAFI 405 pairs of (1/73, 2/73). Future documents may extend their 406 applicability to other AFI/SAFI. 408 2.4.1. Preference Sub-TLV 410 The Preference sub-TLV is used to carry the preference of the SR 411 Policy candidate path. The contents of this sub-TLV are used by the 412 SRPM as described in section 2.7 in 413 [I-D.ietf-spring-segment-routing-policy]. 415 The Preference sub-TLV is optional and it MUST NOT appear more than 416 once in the SR Policy encoding. 418 The Preference sub-TLV has following format: 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Type | Length | Flags | RESERVED | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Preference (4 octets) | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 where: 430 o Type: 12 432 o Length: 6. 434 o Flags: 1 octet of flags. None are defined at this stage. Flags 435 SHOULD be set to zero on transmission and MUST be ignored on 436 receipt. 438 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 439 transmission and MUST be ignored on receipt. 441 o Preference: a 4-octet value. 443 2.4.2. Binding SID Sub-TLV 445 The Binding SID sub-TLV is used to signal the binding SID related 446 information of the SR Policy candidate path. The contents of this 447 sub-TLV are used by the SRPM as described in section 6 in 448 [I-D.ietf-spring-segment-routing-policy]. 450 The Binding SID sub-TLV is optional and it MUST NOT appear more than 451 once in the SR Policy encoding. 453 When the Binding SID sub-TLV is used to signal an SRv6 SID, the 454 choice of its SRv6 Endpoint Behavior [RFC8986] to be instantiated is 455 left to the headend node. It is RECOMMENDED that the SRv6 Binding 456 SID sub-TLV defined in Section 2.4.3, that enables the specification 457 of the SRv6 Endpoint Behavior, be used for signaling of an SRv6 458 Binding SID for an SR Policy candidate path. 460 The Binding SID sub-TLV has the following format: 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Type | Length | Flags | RESERVED | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Binding SID (variable, optional) | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 where: 472 o Type: 13 474 o Length: specifies the length of the value field not including Type 475 and Length fields. Can be 2 or 6 or 18. 477 o Flags: 1 octet of flags. The following flags are defined in the 478 registry "SR Policy Binding SID Flags" as described in 479 Section 6.6: 481 0 1 2 3 4 5 6 7 482 +-+-+-+-+-+-+-+-+ 483 |S|I| | 484 +-+-+-+-+-+-+-+-+ 486 where: 488 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 489 It is used by SRPM as described in section 6.2.3 in 490 [I-D.ietf-spring-segment-routing-policy]. 492 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 493 is used by SRPM as described in section 8.2 in 494 [I-D.ietf-spring-segment-routing-policy]. 496 * Unused bits in the Flag octet SHOULD be set to zero upon 497 transmission and MUST be ignored upon receipt. 499 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 500 transmission and MUST be ignored on receipt. 502 o Binding SID: if the length is 2, then no Binding SID is present. 503 If the length is 6 then the Binding SID is encoded in 4 octets 504 using the format below. TC, S and TTL (Total of 12 bits) are 505 RESERVED and SHOULD be set to zero and MUST be ignored. 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Label | TC |S| TTL | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 If the length is 18 then the Binding SID contains a 16-octet SRv6 514 SID. 516 2.4.3. SRv6 Binding SID Sub-TLV 518 The SRv6 Binding SID sub-TLV is used to signal the SRv6 Binding SID 519 related information of the SR Policy candidate path. It enables the 520 specification of the SRv6 Endpoint Behavior [RFC8986] to be 521 instantiated on the headend node. The contents of this sub-TLV are 522 used by the SRPM as described in section 6 in 523 [I-D.ietf-spring-segment-routing-policy]. 525 The SRv6 Binding SID sub-TLV is optional. More than one SRv6 Binding 526 SIDs MAY be signaled in the same SR Policy encoding to indicate one 527 or more SRv6 SIDs, each with potentially different SRv6 Endpoint 528 Behaviors to be instantiated. 530 The SRv6 Binding SID sub-TLV has the following format: 532 0 1 2 3 533 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Type | Length | Flags | RESERVED | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | SRv6 Binding SID (16 octets) | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 // SRv6 Endpoint Behavior and SID Structure (optional) // 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 where: 544 o Type: TBD 546 o Length is variable 548 o Flags: 1 octet of flags. The following flags are defined in the 549 registry "SR Policy Binding SID Flags" as described in 550 Section 6.7: 552 0 1 2 3 4 5 6 7 553 +-+-+-+-+-+-+-+-+ 554 |S|I|B| | 555 +-+-+-+-+-+-+-+-+ 557 where: 559 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 560 It is used by SRPM as described in section 6.2.3 in 561 [I-D.ietf-spring-segment-routing-policy]. 563 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 564 is used by SRPM as described in section 8.2 in 565 [I-D.ietf-spring-segment-routing-policy]. 567 * B-Flag: This flag, when set, indicates the presence of the SRv6 568 Endpoint Behavior and SID Structure encoding specified in 569 Section 2.4.4.2.13. 571 * Unused bits in the Flag octet SHOULD be set to zero upon 572 transmission and MUST be ignored upon receipt. 574 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 575 transmission and MUST be ignored on receipt. 577 o SRv6 Binding SID: Contains a 16-octet SRv6 SID. 579 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 580 Section 2.4.4.2.13. 582 2.4.4. Segment List Sub-TLV 584 The Segment List sub-TLV encodes a single explicit path towards the 585 endpoint as described in section 5.1 in 586 [I-D.ietf-spring-segment-routing-policy]. The Segment List sub-TLV 587 includes the elements of the paths (i.e., segments) as well as an 588 optional Weight sub-TLV. 590 The Segment List sub-TLV may exceed 255 bytes in length due to a 591 large number of segments. Therefore a 2-octet length is required. 592 According to [RFC9012], the first bit of the sub-TLV codepoint 593 defines the size of the length field. Therefore, for the Segment 594 List sub-TLV a code point of 128 or higher is used. 596 The Segment List sub-TLV is optional and MAY appear multiple times in 597 the SR Policy encoding. The ordering of Segment List sub-TLVs, each 598 sub-TLV encoding a Segment List, does not matter. 600 The Segment List sub-TLV contains zero or more Segment sub-TLVs and 601 MAY contain a Weight sub-TLV. 603 The Segment List sub-TLV has the following format: 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 | RESERVED | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 // sub-TLVs // 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 where: 615 o Type: 128. 617 o Length: the total length (not including the Type and Length 618 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 620 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 621 transmission and MUST be ignored on receipt. 623 o sub-TLVs currently defined: 625 * An optional single Weight sub-TLV. 627 * Zero or more Segment sub-TLVs. 629 Validation of an explicit path encoded by the Segment List sub-TLV is 630 beyond the scope of BGP and performed by the SRPM as described in 631 section 5 in [I-D.ietf-spring-segment-routing-policy]. 633 2.4.4.1. Weight Sub-TLV 635 The Weight sub-TLV specifies the weight associated with a given 636 segment list. The contents of this sub-TLV are used only by the SRPM 637 as described in section 2.11 in 638 [I-D.ietf-spring-segment-routing-policy]. 640 The Weight sub-TLV is optional and it MUST NOT appear more than once 641 inside the Segment List sub-TLV. 643 The Weight sub-TLV has the following format: 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Type | Length | Flags | RESERVED | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Weight | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 where: 655 o Type: 9. 657 o Length: 6 659 o Flags: 1 octet of flags. None are defined at this stage. Flags 660 SHOULD be set to zero on transmission and MUST be ignored on 661 receipt. 663 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 664 transmission and MUST be ignored on receipt. 666 o Weight: 4 octets value. 668 2.4.4.2. Segment Sub-TLVs 670 A Segment sub-TLV describes a single segment in a segment list (i.e., 671 a single element of the explicit path). One or more Segment sub-TLVs 672 constitute an explicit path of the SR Policy candidate path. The 673 contents of these sub-TLVs are used only by the SRPM as described in 674 section 4 in [I-D.ietf-spring-segment-routing-policy]. 676 The Segment sub-TLVs are optional and MAY appear multiple times in 677 the Segment List sub-TLV. 679 [I-D.ietf-spring-segment-routing-policy] defines several Segment 680 Types: 682 Type A: SR-MPLS Label 683 Type B: SRv6 SID 684 Type C: IPv4 Prefix with optional SR Algorithm 685 Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS 686 Type E: IPv4 Prefix with Local Interface ID 687 Type F: IPv4 Addresses for link endpoints as Local, Remote pair 688 Type G: IPv6 Prefix and Interface ID for link endpoints as Local, 689 Remote pair for SR-MPLS 690 Type H: IPv6 Addresses for link endpoints as Local, Remote pair 691 for SR-MPLS 692 Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6 693 Type J: IPv6 Prefix and Interface ID for link endpoints as Local, 694 Remote pair for SRv6 695 Type K: IPv6 Addresses for link endpoints as Local, Remote pair 696 for SRv6 698 The following sub-sections specify the sub-TLV used for encoding each 699 of these Segment Types. 701 2.4.4.2.1. Segment Type A 703 The Type A Segment Sub-TLV encodes a single SR-MPLS SID. The format 704 is as follows: 706 0 1 2 3 707 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 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Type | Length | Flags | RESERVED | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Label | TC |S| TTL | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 where: 716 o Type: 1. 718 o Length is 6. 720 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 722 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 723 transmission and MUST be ignored on receipt. 725 o Label: 20 bits of label value. 727 o TC: 3 bits of traffic class. 729 o S: 1 bit of bottom-of-stack. 731 o TTL: 1 octet of TTL. 733 The following applies to the Type-1 Segment sub-TLV: 735 o The S bit SHOULD be zero upon transmission and MUST be ignored 736 upon reception. 738 o If the originator wants the receiver to choose the TC value, it 739 sets the TC field to zero. 741 o If the originator wants the receiver to choose the TTL value, it 742 sets the TTL field to 255. 744 o If the originator wants to recommend a value for these fields, it 745 puts those values in the TC and/or TTL fields. 747 o The receiver MAY override the originator's values for these 748 fields. This would be determined by local policy at the receiver. 749 One possible policy would be to override the fields only if the 750 fields have the default values specified above. 752 2.4.4.2.2. Segment Type B 754 The Type B Segment Sub-TLV encodes a single SRv6 SID. The format is 755 as follows: 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Type | Length | Flags | RESERVED | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 // SRv6 SID (16 octets) // 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 // SRv6 Endpoint Behavior and SID Structure (optional) // 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 where: 769 o Type: 13. 771 o Length is 26 when the SRv6 Endpoint Behavior and SID Structure is 772 present else it is 18. 774 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 776 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 777 transmission and MUST be ignored on receipt. 779 o SRv6 SID: 16 octets of IPv6 address. 781 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 782 Section 2.4.4.2.13. 784 The TLV 2 defined for the advertisement of Segment Type B in the 785 earlier versions of this document has been deprecated to avoid 786 backward compatibility issues. 788 2.4.4.2.3. Segment Type C 790 The Type C Segment Sub-TLV encodes an IPv4 node address, SR Algorithm 791 and an optional SR-MPLS SID. The format is as follows: 793 0 1 2 3 794 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 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Type | Length | Flags | SR Algorithm | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | IPv4 Node Address (4 octets) | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | SR-MPLS SID (optional, 4 octets) | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 where: 805 o Type: 3. 807 o Length is 10 when the SR-MPLS SID is present else it is 6. 809 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 811 o SR Algorithm: 1 octet specifying SR Algorithm as described in 812 section 3.1.1 in [RFC8402] when A-Flag as defined in 813 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 814 described in section 4 in 815 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 816 encoded, this field SHOULD be set to zero on transmission and MUST 817 be ignored on receipt. 819 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 821 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 822 TTL as defined in Section 2.4.4.2.1. 824 2.4.4.2.4. Segment Type D 826 The Type D Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 827 and an optional SR-MPLS SID. The format is as follows: 829 0 1 2 3 830 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 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Type | Length | Flags | SR Algorithm | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 // IPv6 Node Address (16 octets) // 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | SR-MPLS SID (optional, 4 octets) | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 where: 841 o Type: 4 843 o Length is 22 when the SR-MPLS SID is present else it is 18. 845 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 847 o SR Algorithm: 1 octet specifying SR Algorithm as described in 848 section 3.1.1 in [RFC8402] when A-Flag as defined in 849 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 850 described in section 4 in 851 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 852 encoded, this field SHOULD be set to zero on transmission and MUST 853 be ignored on receipt. 855 o IPv6 Node Address: a 16-octet IPv6 address representing a node. 857 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 858 TTL as defined in Section 2.4.4.2.1. 860 2.4.4.2.5. Segment Type E 862 The Type E Segment Sub-TLV encodes an IPv4 node address, a local 863 interface Identifier (Local Interface ID), and an optional SR-MPLS 864 SID. The format is as follows: 866 0 1 2 3 867 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 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Type | Length | Flags | RESERVED | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Local Interface ID (4 octets) | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | IPv4 Node Address (4 octets) | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | SR-MPLS SID (optional, 4 octets) | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 where: 880 o Type: 5. 882 o Length is 14 when the SR-MPLS SID is present else it is 10. 884 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 886 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 887 transmission and MUST be ignored on receipt. 889 o Local Interface ID: 4 octets of interface index as defined in 890 [RFC8664]. 892 o IPv4 Node Address: a 4-octet IPv4 address representing a node. 894 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 895 TTL as defined in Section 2.4.4.2.1. 897 2.4.4.2.6. Segment Type F 899 The Type F Segment Sub-TLV encodes an adjacency local address, an 900 adjacency remote address, and an optional SR-MPLS SID. The format is 901 as follows: 903 0 1 2 3 904 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 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Type | Length | Flags | RESERVED | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Local IPv4 Address (4 octets) | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Remote IPv4 Address (4 octets) | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | SR-MPLS SID (optional, 4 octets) | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 where: 917 o Type: 6. 919 o Length is 14 when the SR-MPLS SID is present else it is 10. 921 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 923 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 924 transmission and MUST be ignored on receipt. 926 o Local IPv4 Address: a 4-octet IPv4 address. 928 o Remote IPv4 Address: a 4-octet IPv4 address. 930 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 931 TTL as defined in Section 2.4.4.2.1. 933 2.4.4.2.7. Segment Type G 935 The Type G Segment Sub-TLV encodes an IPv6 link-local adjacency with 936 IPv6 local node address, a local interface identifier (Local 937 Interface ID), IPv6 remote node address, a remote interface 938 identifier (Remote Interface ID), and an optional SR-MPLS SID. The 939 format is as follows: 941 0 1 2 3 942 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 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Type | Length | Flags | RESERVED | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Local Interface ID (4 octets) | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 // IPv6 Local Node Address (16 octets) // 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Remote Interface ID (4 octets) | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 // IPv6 Remote Node Address (16 octets) // 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | SR-MPLS SID (optional, 4 octets) | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 where: 959 o Type: 7 961 o Length is 46 when the SR-MPLS SID is present else it is 42. 963 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 965 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 966 transmission and MUST be ignored on receipt. 968 o Local Interface ID: 4 octets of interface index as defined in 969 [RFC8664]. 971 o IPv6 Local Node Address: a 16-octet IPv6 address. 973 o Remote Interface ID: 4 octets of interface index as defined in 974 [RFC8664]. The value MAY be set to zero when the local node 975 address and interface identifiers are sufficient to describe the 976 link. 978 o IPv6 Remote Node Address: a 16-octet IPv6 address. The value MAY 979 be set to zero when the local node address and interface 980 identifiers are sufficient to describe the link. 982 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 983 TTL as defined in Section 2.4.4.2.1. 985 2.4.4.2.8. Segment Type H 987 The Type H Segment Sub-TLV encodes an adjacency local address, an 988 adjacency remote address, and an optional SR-MPLS SID. The format is 989 as follows: 991 0 1 2 3 992 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 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Type | Length | Flags | RESERVED | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 // Local IPv6 Address (16 octets) // 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 // Remote IPv6 Address (16 octets) // 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | SR-MPLS SID (optional, 4 octets) | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 where: 1005 o Type: 8 1007 o Length is 38 when the SR-MPLS SID is present else it is 34. 1009 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1011 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1012 transmission and MUST be ignored on receipt. 1014 o Local IPv6 Address: a 16-octet IPv6 address. 1016 o Remote IPv6 Address: a 16-octet IPv6 address. 1018 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 1019 TTL as defined in Section 2.4.4.2.1. 1021 2.4.4.2.9. Segment Type I 1023 The Type I Segment Sub-TLV encodes an IPv6 node address, SR 1024 Algorithm, and an optional SRv6 SID. The format is as follows: 1026 0 1 2 3 1027 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 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Type | Length | Flags | SR Algorithm | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 // IPv6 Node Address (16 octets) // 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 // SRv6 SID (optional, 16 octets) // 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 // SRv6 Endpoint Behavior and SID Structure (optional) // 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 where: 1040 o Type: 14 1042 o Length is variable. 1044 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1046 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1047 section 3.1.1 in [RFC8402] when A-Flag as defined in 1048 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1049 described in section 4 in 1050 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1051 encoded, this field SHOULD be set to zero on transmission and MUST 1052 be ignored on receipt. 1054 o IPv6 Node Address: a 16-octet IPv6 address. 1056 o SRv6 SID: optional, a 16-octet IPv6 address. 1058 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1059 Section 2.4.4.2.13. 1061 The TLV 10 defined for the advertisement of Segment Type I in the 1062 earlier versions of this document has been deprecated to avoid 1063 backward compatibility issues. 1065 2.4.4.2.10. Segment Type J 1067 The Type J 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 SRv6 SID. The format is as follows: 1072 0 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Type | Length | Flags | SR Algorithm | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Local Interface ID (4 octets) | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 // IPv6 Local Node Address (16 octets) // 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Remote Interface ID (4 octets) | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 // IPv6 Remote Node Address (16 octets) // 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 // SRv6 SID (optional, 16 octets) // 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 // SRv6 Endpoint Behavior and SID Structure (optional) // 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 where: 1092 o Type: 15 1094 o Length is variable. 1096 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1098 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1099 section 3.1.1 in [RFC8402] when A-Flag as defined in 1100 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1101 described in section 4 in 1102 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1103 encoded, this field SHOULD be set to zero on transmission and MUST 1104 be ignored on receipt. 1106 o Local Interface ID: 4 octets of interface index as defined in 1107 [RFC8664]. 1109 o IPv6 Local Node Address: a 16-octet IPv6 address. 1111 o Remote Interface ID: 4 octets of interface index as defined in 1112 [RFC8664]. The value MAY be set to zero when the local node 1113 address and interface identifiers are sufficient to describe the 1114 link. 1116 o IPv6 Remote Node Address: a 16-octet IPv6 address. The value MAY 1117 be set to zero when the local node address and interface 1118 identifiers are sufficient to describe the link. 1120 o SRv6 SID: optional, a 16-octet IPv6 address. 1122 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1123 Section 2.4.4.2.13. 1125 The TLV 11 defined for the advertisement of Segment Type J in the 1126 earlier versions of this document has been deprecated to avoid 1127 backward compatibility issues. 1129 2.4.4.2.11. Segment Type K 1131 The Type K Segment Sub-TLV encodes an adjacency local address, an 1132 adjacency remote address, and an optional SRv6 SID. The format is as 1133 follows: 1135 0 1 2 3 1136 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 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Type | Length | Flags | SR Algorithm | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 // Local IPv6 Address (16 octets) // 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 // Remote IPv6 Address (16 octets) // 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 // SRv6 SID (optional, 16 octets) // 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 // SRv6 Endpoint Behavior and SID Structure (optional) // 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 where: 1151 o Type: 16 1153 o Length is variable. 1155 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1157 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1158 section 3.1.1 in [RFC8402] when A-Flag as defined in 1159 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1160 described in section 4 in 1161 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1162 encoded, this field SHOULD be set to zero on transmission and MUST 1163 be ignored on receipt. 1165 o Local IPv6 Address: a 16-octet IPv6 address. 1167 o Remote IPv6 Address: a 16-octet IPv6 address. 1169 o SRv6 SID: optional, a 16-octet IPv6 address. 1171 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1172 Section 2.4.4.2.13. 1174 The TLV 12 defined for the advertisement of Segment Type K in the 1175 earlier versions of this document has been deprecated to avoid 1176 backward compatibility issues. 1178 2.4.4.2.12. Segment Flags 1180 The Segment Types sub-TLVs described above MAY contain the following 1181 flags in the "Flags" field defined in Section 6.8: 1183 0 1 2 3 4 5 6 7 1184 +-+-+-+-+-+-+-+-+ 1185 |V|A|S|B| | 1186 +-+-+-+-+-+-+-+-+ 1188 where: 1190 V-Flag: This flag, when set, is used by SRPM for "SID 1191 verification" as described in Section 5.1 in 1192 [I-D.ietf-spring-segment-routing-policy]. 1194 A-Flag: This flag, when set, indicates the presence of SR 1195 Algorithm id in the "SR Algorithm" field applicable to various 1196 Segment Types. SR Algorithm is used by SRPM as described in 1197 section 4 in [I-D.ietf-spring-segment-routing-policy]. 1199 S-Flag: This flag, when set, indicates the presence of the SR-MPLS 1200 or SRv6 SID depending on the segment type. 1202 B-Flag: This flag, when set, indicates the presence of the SRv6 1203 Endpoint Behavior and SID Structure encoding specified in 1204 Section 2.4.4.2.13. 1206 Unused bits in the Flag octet SHOULD be set to zero upon 1207 transmission and MUST be ignored upon receipt. 1209 The following applies to the Segment Flags: 1211 o V-Flag applies to all Segment Types. 1213 o A-Flag applies to Segment Types C, D, I, J, and K. If A-Flag 1214 appears with Segment Types A, B, E, F, G, and H, it MUST be 1215 ignored. 1217 o S-Flag applies to Segment Types C, D, E, F, G, H, I, J, and K. If 1218 S-Flag appears with Segment Types A or B, it MUST be ignored. 1220 o B-Flag applies to Segment Types B, I, J, and K. If B-Flag appears 1221 with Segment Types A, C, D, E, F, G, and H, it MUST be ignored. 1223 2.4.4.2.13. SRv6 SID Endpoint Behavior and Structure 1225 The Segment Types sub-TLVs described above MAY contain the SRv6 1226 Endpoint Behavior and SID Structure [RFC8986] encoding as described 1227 below: 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | Endpoint Behavior | Reserved | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | LB Length | LN Length | Fun. Length | Arg. Length | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 where: 1237 Endpoint Behavior: 2 octets. It carries the SRv6 Endpoint 1238 Behavior code point for this SRv6 SID as defined in section 9.2 of 1239 [RFC8986]. When set with the value 0, the choice of SRv6 Endpoint 1240 Behavior is left to the headend. 1242 Reserved: 2 octets of reserved bits. SHOULD be set to zero on 1243 transmission and MUST be ignored on receipt. 1245 Locator Block Length: 1 octet. SRv6 SID Locator Block length in 1246 bits. 1248 Locator Node Length: 1 octet. SRv6 SID Locator Node length in 1249 bits. 1251 Function Length: 1 octet. SRv6 SID Function length in bits. 1253 Argument Length: 1 octet. SRv6 SID Arguments length in bits. 1255 The total of the locator block, locator node, function, and argument 1256 lengths MUST be less than or equal to 128. 1258 2.4.5. Explicit NULL Label Policy Sub-TLV 1260 To steer an unlabeled IP packet into an SR policy, it is necessary to 1261 create a label stack for that packet, and push one or more labels 1262 onto that stack. 1264 The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate 1265 whether an Explicit NULL Label [RFC3032] must be pushed on an 1266 unlabeled IP packet before any other labels. 1268 If an ENLP Sub-TLV is not present, the decision of whether to push an 1269 Explicit NULL label on a given packet is a matter of local 1270 configuration. 1272 The ENLP sub-TLV is optional and it MUST NOT appear more than once in 1273 the SR Policy encoding. 1275 The contents of this sub-TLV are used by the SRPM as described in 1276 section 4.1 in [I-D.ietf-spring-segment-routing-policy]. 1278 0 1 2 3 1279 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 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Type | Length | Flags | RESERVED | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | ENLP | 1284 +-+-+-+-+-+-+-+-+ 1286 Where: 1288 Type: 14. 1290 Length: 3. 1292 Flags: 1 octet of flags. None are defined at this stage. Flags 1293 SHOULD be set to zero on transmission and MUST be ignored on 1294 receipt. 1296 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1297 transmission and MUST be ignored on receipt. 1299 ENLP (Explicit NULL Label Policy): Indicates whether Explicit NULL 1300 labels are to be pushed on unlabeled IP packets that are being 1301 steered into a given SR policy. This field has one of the 1302 following values: 1304 0: Reserved. 1306 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1307 packet, but do not push an IPv6 Explicit NULL label on an 1308 unlabeled IPv6 packet. 1310 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 1311 packet, but do not push an IPv4 Explicit NULL label on an 1312 unlabeled IPv4 packet. 1314 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1315 packet, and push an IPv6 Explicit NULL label on an unlabeled 1316 IPv6 packet. 1318 4: Do not push an Explicit NULL label. 1320 5 - 255: Reserved. 1322 The ENLP reserved values may be used for future extensions and 1323 implementations SHOULD ignore the ENLP Sub-TLV with these values. 1324 The behavior signaled in this Sub-TLV MAY be overridden by local 1325 configuration. The section 4.1 of 1326 [I-D.ietf-spring-segment-routing-policy] describes the behavior on 1327 the headend for the handling of the explicit null label. 1329 2.4.6. Policy Priority Sub-TLV 1331 An operator MAY set the Policy Priority sub-TLV to indicate the order 1332 in which the SR policies are re-computed upon topological change. 1333 The contents of this sub-TLV are used by the SRPM as described in 1334 section 2.11 in [I-D.ietf-spring-segment-routing-policy]. 1336 The Priority sub-TLV is optional and it MUST NOT appear more than 1337 once in the SR Policy encoding. 1339 The Priority sub-TLV has following format: 1341 0 1 2 3 1342 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 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | Type | Length | Priority | RESERVED | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 Where: 1349 Type: 15 1351 Length: 2. 1353 Priority: a 1-octet value. 1355 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1356 transmission and MUST be ignored on receipt. 1358 2.4.7. Policy Candidate Path Name Sub-TLV 1360 An operator MAY set the Policy Candidate Path Name sub-TLV to attach 1361 a symbolic name to the SR Policy candidate path. 1363 Usage of Policy Candidate Path Name sub-TLV is described in section 1364 2.6 in [I-D.ietf-spring-segment-routing-policy]. 1366 The Policy Candidate Path Name sub-TLV may exceed 255 bytes in length 1367 due to a long name. Therefore a 2-octet length is required. 1368 According to [RFC9012], the first bit of the sub-TLV codepoint 1369 defines the size of the length field. Therefore, for the Policy 1370 Candidate Path Name sub-TLV, a code point of 128 or higher is used. 1372 It is RECOMMENDED that the size of the symbolic name for the 1373 candidate path is limited to 255 bytes. Implementations MAY choose 1374 to truncate long names to 255 bytes when signaling via BGP. 1376 The Policy Candidate Path Name sub-TLV is optional and it MUST NOT 1377 appear more than once in the SR Policy encoding. 1379 The Policy Candidate Path Name sub-TLV has following format: 1381 0 1 2 3 1382 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 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | Type | Length | RESERVED | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 // Policy Candidate Path Name // 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 Where: 1391 Type: 129. 1393 Length: Variable. 1395 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1396 transmission and MUST be ignored on receipt. 1398 Policy Candidate Path Name: Symbolic name for the SR Policy 1399 candidate path without a NULL terminator as specified in section 1400 2.6 of [I-D.ietf-spring-segment-routing-policy]. 1402 2.4.8. Policy Name Sub-TLV 1404 An operator MAY set the Policy Name sub-TLV to associate a symbolic 1405 name with the SR Policy for which the candidate path is being 1406 advertised via the SR Policy NLRI. 1408 Usage of Policy Name sub-TLV is described in section 2.1 of 1409 [I-D.ietf-spring-segment-routing-policy]. 1411 The Policy Name sub-TLV may exceed 255 bytes in length due to a long 1412 policy name. Therefore a 2-octet length is required. According to 1413 [RFC9012], the first bit of the sub-TLV codepoint defines the size of 1414 the length field. Therefore, for the Policy Name sub-TLV, a code 1415 point of 128 or higher is used. 1417 It is RECOMMENDED that the size of the symbolic name for the SR 1418 Policy is limited to 255 bytes. Implementations MAY choose to 1419 truncate long names to 255 bytes when signaling via BGP. 1421 The Policy Name sub-TLV is optional and it MUST NOT appear more than 1422 once in the SR Policy encoding. 1424 The Policy Name sub-TLV has following format: 1426 0 1 2 3 1427 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 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | Type | Length | RESERVED | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 // Policy Name // 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 Where: 1436 Type: TBD 1438 Length: Variable. 1440 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1441 transmission and MUST be ignored on receipt. 1443 Policy Name: Symbolic name for the policy. It SHOULD be a string 1444 of printable ASCII characters, without a NULL terminator. 1446 3. Color Extended Community 1448 The Color Extended Community [RFC9012] is used to steer traffic 1449 corresponding to BGP routes into an SR Policy with matching color 1450 value. The Color Extended Community MAY be carried in any BGP UPDATE 1451 message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 Unicast), 1/4 1452 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1/128 (VPN-IPv4 1453 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), or 25/70 1454 (Ethernet VPN, usually known as EVPN). Use of the Color Extended 1455 Community in BGP UPDATE messages of other AFI/SAFIs is outside the 1456 scope of this document. 1458 Two bits from the Flags field of the Color Extended Community are 1459 used as follows to support the requirements of Color-Only steering as 1460 specified in Section 8.8 of [I-D.ietf-spring-segment-routing-policy]: 1462 1 1463 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 |C O| RESERVED | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 The CO bits together form the Color-Only Type field which indicates 1469 the various matching criteria between BGP NH and SR Policy endpoint 1470 in addition to the matching of the color value. Following types are 1471 defined: 1473 o Type 0: Specific Endpoint Match: Request match for the endpoint 1474 that is the BGP NH 1476 o Type 1: Specific or Null Endpoint Match: Request match for either 1477 the endpoint that is the BGP NH or a null endpoint (e.g., like a 1478 default gateway) 1480 o Type 2: Specific, Null, or Any Endpoint Match: Request match for 1481 either the endpoint that is the BGP NH or with a null or any 1482 endpoint 1484 o Type 3: reserved for future use and SHOULD NOT be used. Upon 1485 reception, an implementation MUST treat it like Type 0. 1487 The details of the SR Policy steering mechanisms based on these 1488 Color-Only types are specified in section 8.8 of 1489 [I-D.ietf-spring-segment-routing-policy]. 1491 One or more Color Extended Communities MAY be associated with a BGP 1492 route update. Sections 8.4.1, 8.5.1, and 8.8.2 of 1494 [I-D.ietf-spring-segment-routing-policy] specify the steering 1495 behaviors over SR Policies when multiple Color Extended Communities 1496 are associated with a BGP route. 1498 4. SR Policy Operations 1500 As described in this document, BGP is not the actual consumer of an 1501 SR Policy NLRI. BGP is in charge of the origination and propagation 1502 of the SR Policy NLRI but its installation and use are outside the 1503 scope of BGP. The details of SR Policy installation and use are 1504 specified in [I-D.ietf-spring-segment-routing-policy]. 1506 4.1. Advertisement of SR Policies 1508 Typically, but not limited to, an SR Policy is computed by a 1509 controller or a path computation engine (PCE) and originated by a BGP 1510 speaker on its behalf. 1512 Multiple SR Policy NLRIs may be present with the same tuple but with different content when these SR policies are 1514 intended for different head-ends. 1516 The distinguisher of each SR Policy NLRI prevents undesired BGP route 1517 selection among these SR Policy NLRIs and allows their propagation 1518 across route reflectors [RFC4456]. 1520 Moreover, one or more route target SHOULD be attached to the 1521 advertisement, where each route target identifies one or more 1522 intended head-ends for the advertised SR Policy update. 1524 If no route target is attached to the SR Policy NLRI, then it is 1525 assumed that the originator sends the SR Policy update directly 1526 (e.g., through a BGP session) to the intended receiver. In such 1527 case, the NO_ADVERTISE community MUST be attached to the SR Policy 1528 update. 1530 4.2. Reception of an SR Policy NLRI 1532 On reception of an SR Policy NLRI, a BGP speaker first determines if 1533 it is acceptable and then if it is usable. 1535 4.2.1. Acceptance of an SR Policy NLRI 1537 When a BGP speaker receives an SR Policy NLRI from a neighbor it MUST 1538 first, determine if it's acceptable. The following rules apply in 1539 addition to the validation described in Section 5: 1541 o The SR Policy NLRI MUST include a distinguisher, color and 1542 endpoint field which implies that the length of the NLRI MUST be 1543 either 12 or 24 octets (depending on the address family of the 1544 endpoint). 1546 o The SR Policy update MUST have either the NO_ADVERTISE community 1547 or at least one route target extended community in IPv4-address 1548 format or both. If a router supporting this specification 1549 receives an SR Policy update with no route target extended 1550 communities and no NO_ADVERTISE community, the update MUST be 1551 considered as malformed. 1553 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1554 Update and MUST have a Tunnel Type TLV set to SR Policy (codepoint 1555 is 15). 1557 A router that receives an SR Policy update that is not valid 1558 according to these criteria MUST treat the update as malformed and 1559 the SR Policy candidate path MUST NOT be passed to the SRPM. 1561 4.2.2. Usable SR Policy NLRI 1563 An SR Policy update that has been determined to be acceptable is 1564 further evaluated for its usability by the receiving node. 1566 An SR Policy NLRI update without any route target extended community 1567 but having the NO_ADVERTISE community is considered usable. 1569 If one or more route targets are present, then at least one route 1570 target MUST match the BGP Identifier of the receiver for the update 1571 to be considered usable. The BGP Identifier is defined in [RFC4271] 1572 as a 4-octet IPv4 address. Therefore, the route target extended 1573 community MUST be of the same format. 1575 If one or more route targets are present and none matches the local 1576 BGP Identifier, then, while the SR Policy NLRI is acceptable, it is 1577 not usable on the receiver node. 1579 When the SR Policy tunnel type includes any sub-TLV that is 1580 unrecognized or unsupported, the update SHOULD NOT be considered 1581 usable. An implementation MAY provide an option for ignoring 1582 unsupported sub-TLVs. 1584 4.2.3. Passing a usable SR Policy NLRI to the SRPM 1586 Once BGP on the receiving node has determined that the SR Policy NLRI 1587 is usable, it passes the SR Policy candidate path to the SRPM. Note 1588 that, along with the candidate path details, BGP also passes the 1589 originator information for breaking ties in the candidate path 1590 selection process as described in section 2.4 in 1591 [I-D.ietf-spring-segment-routing-policy]. 1593 When an update for an SR Policy NLRI results in its becoming 1594 unusable, BGP MUST delete its corresponding SR Policy candidate path 1595 from the SRPM. 1597 The SRPM applies the rules defined in section 2 in 1598 [I-D.ietf-spring-segment-routing-policy] to determine whether the SR 1599 Policy candidate path is valid and to select the best candidate path 1600 among the valid ones for a given SR Policy. 1602 4.2.4. Propagation of an SR Policy 1604 SR Policy NLRIs that have been determined acceptable and valid can be 1605 evaluated for propagation, even the ones that are not usable. 1607 SR Policy NLRIs that have the NO_ADVERTISE community attached to them 1608 MUST NOT be propagated. 1610 By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate 1611 it to any EBGP neighbor. An implementation MAY provide an explicit 1612 configuration to override this and enable the propagation of 1613 acceptable SR Policy NLRIs to specific EBGP neighbors. 1615 A BGP node advertises a received SR Policy NLRI to its IBGP neighbors 1616 according to normal IBGP propagation rules. 1618 By default, a BGP node receiving an SR Policy NLRI SHOULD NOT remove 1619 route target extended community before propagation. An 1620 implementation MAY provide support for configuration to filter and/or 1621 remove route target extended community before propagation. 1623 5. Error Handling 1625 This section describes the error handling actions, as described in 1626 [RFC7606], that are to be performed for the handling of the BGP 1627 update messages for BGP SR Policy SAFI. 1629 A BGP Speaker MUST perform the following syntactic validation of the 1630 SR Policy NLRI to determine if it is malformed. This includes the 1631 validation of the length of each NLRI and the total length of the 1632 MP_REACH_NLRI and MP_UNREACH_NLRI attributes. 1634 When the error determined allows for the router to skip the malformed 1635 NLRI(s) and continue the processing of the rest of the update 1636 message, then it MUST handle such malformed NLRIs as 'Treat-as- 1637 withdraw'. In other cases, where the error in the NLRI encoding 1638 results in the inability to process the BGP update message (e.g. 1639 length related encoding errors), then the router SHOULD handle such 1640 malformed NLRIs as 'AFI/SAFI disable' when other AFI/SAFI besides SR 1641 Policy are being advertised over the same session. Alternately, the 1642 router MUST perform 'session reset' when the session is only being 1643 used for SR Policy or when it 'AFI/SAFI disable' action is not 1644 possible. 1646 The validation of the TLVs/sub-TLVs introduced in this document and 1647 defined in their respective sub-sections of Section 2.4 MUST be 1648 performed to determine if they are malformed or invalid. The 1649 validation of the Tunnel Encapsulation Attribute itself and the other 1650 TLVs/sub-TLVs specified in [RFC9012] MUST be done as described in 1651 that document. In case of any error detected, either at the 1652 attribute or its TLV/sub-TLV level, the "treat-as-withdraw" strategy 1653 MUST be applied. This is because an SR Policy update without a valid 1654 Tunnel Encapsulation Attribute (comprising of all valid TLVs/sub- 1655 TLVs) is not usable. 1657 An SR Policy update that is determined to be not acceptable, and 1658 therefore malformed, based on rules described in Section 4.2.1 MUST 1659 be handled by the "treat-as-withdraw" strategy. 1661 The validation of the individual fields of the TLVs/sub-TLVs defined 1662 in Section 2.4 are beyond the scope of BGP as they are handled by the 1663 SRPM as described in the individual TLV/sub-TLV sub-sections. A BGP 1664 implementation MUST NOT perform semantic verification of such fields 1665 nor consider the SR Policy update to be invalid or not acceptable/ 1666 usable based on such validation. 1668 An implementation SHOULD log an error for any errors found during the 1669 above validation for further analysis. 1671 6. IANA Considerations 1673 This document requests codepoint allocations in the following 1674 existing registries: 1676 o Subsequent Address Family Identifiers (SAFI) Parameters registry 1678 o BGP Tunnel Encapsulation Attribute Tunnel Types registry under the 1679 BGP Tunnel Encapsulation registry 1681 o BGP Tunnel Encapsulation Attribute sub-TLVs registry under the BGP 1682 Tunnel Encapsulation registry 1684 o Color Extended Community Flags registry under the BGP Tunnel 1685 Encapsulation registry 1687 This document also requests the creation of the following registries: 1689 o SR Policy Segment List Sub-TLVs under the BGP Tunnel Encapsulation 1690 registry 1692 o SR Policy Binding SID Flags under the BGP Tunnel Encapsulation 1693 registry 1695 o SR Policy Segment Flags under the BGP Tunnel Encapsulation 1696 registry 1698 o Color Extended Community Color-Only Types registry under the BGP 1699 Tunnel Encapsulation registry 1701 6.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1702 Parameters 1704 This document introduces a SAFI in the registry "Subsequent Address 1705 Family Identifiers (SAFI) Parameters" that has been assigned a 1706 codepoint by IANA as follows: 1708 Codepoint Description Reference 1709 ----------------------------------------------- 1710 73 SR Policy SAFI This document 1712 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1714 This document introduces a Tunnel-Type in the registry "BGP Tunnel 1715 Encapsulation Attribute Tunnel Types" that has been assigned a 1716 codepoint by IANA as follows: 1718 Codepoint Description Reference 1719 -------------------------------------------------- 1720 15 SR Policy This document 1722 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1724 This document defines sub-TLVs in the registry "BGP Tunnel 1725 Encapsulation Attribute sub-TLVs" that has been assigned codepoints 1726 by IANA as follows via the early allocation process: 1728 Codepoint Description Reference 1729 ------------------------------------------------------------ 1730 12 Preference sub-TLV This document 1731 13 Binding SID sub-TLV This document 1732 14 ENLP sub-TLV This document 1733 15 Priority sub-TLV This document 1734 20 SRv6 Binding SID sub-TLV This document 1735 128 Segment List sub-TLV This document 1736 129 Policy Candidate Path Name sub-TLV This document 1737 130 Policy Name sub-TLV This document 1739 6.4. Existing Registry: Color Extended Community Flags 1741 This document requests allocations in the registry called "Color 1742 Extended Community Flags" under the "BGP Tunnel Encapsulation" 1743 registry. 1745 The following bits have been assigned by IANA via the early 1746 allocation process to form the Color-Only Types field: 1748 Bit 1749 Position Description Reference 1750 ------------------------------------------------------------------ 1751 0-1 Color-only Types Field This document 1753 6.5. New Registry: SR Policy Segment List Sub-TLVs 1755 This document requests the creation of a new registry called "SR 1756 Policy Segment List Sub-TLVs" under the "BGP Tunnel Encapsulation" 1757 registry. The allocation policy of this registry is "Standards 1758 Action" according to [RFC8126]. 1760 Following initial Sub-TLV codepoints are assigned by this document: 1762 Value Description Reference 1763 ----------------------------------------------------- 1764 0 Reserved This document 1765 1 Segment Type A sub-TLV This document 1766 2 Deprecated This document 1767 3 Segment Type C sub-TLV This document 1768 4 Segment Type D sub-TLV This document 1769 5 Segment Type E sub-TLV This document 1770 6 Segment Type F sub-TLV This document 1771 7 Segment Type G sub-TLV This document 1772 8 Segment Type H sub-TLV This document 1773 9 Weight sub-TLV This document 1774 10 Deprecated This document 1775 11 Deprecated This document 1776 12 Deprecated This document 1777 13 Segment Type B sub-TLV This document 1778 14 Segment Type I sub-TLV This document 1779 15 Segment Type J sub-TLV This document 1780 16 Segment Type K sub-TLV This document 1781 17-255 Unassigned 1783 6.6. New Registry: SR Policy Binding SID Flags 1785 This document requests the creation of a new registry called "SR 1786 Policy Binding SID Flags" under the "BGP Tunnel Encapsulation" 1787 registry. The allocation policy of this registry is "Standards 1788 Action" according to [RFC8126]. 1790 The following flags are defined: 1792 Bit Description Reference 1793 ----------------------------------------------------------------- 1794 0 Specified-BSID-Only Flag (S-Flag) This document 1795 1 Drop Upon Invalid Flag (I-Flag) This document 1796 2-7 Unassigned 1798 6.7. New Registry: SR Policy SRv6 Binding SID Flags 1800 This document requests the creation of a new registry called "SR 1801 Policy SRv6 Binding SID Flags" under the "BGP Tunnel Encapsulation" 1802 registry. The allocation policy of this registry is "Standards 1803 Action" according to [RFC8126]. 1805 The following flags are defined: 1807 Bit Description Reference 1808 ----------------------------------------------------------------- 1809 0 Specified-BSID-Only Flag (S-Flag) This document 1810 1 Drop Upon Invalid Flag (I-Flag) This document 1811 2 SRv6 Endpoint Behavior & 1812 SID Structure Flag (B-Flag) This document 1813 3-7 Unassigned 1815 6.8. New Registry: SR Policy Segment Flags 1817 This document requests the creation of a new registry called "SR 1818 Policy Segment Flags" under the "BGP Tunnel Encapsulation" registry. 1819 The allocation policy of this registry is "Standards Action" 1820 according to [RFC8126]. 1822 The following Flags are defined: 1824 Bit Description Reference 1825 ------------------------------------------------------------------ 1826 0 Segment Verification Flag (V-Flag) This document 1827 1 SR Algorithm Flag (A-Flag) This document 1828 2 SID Specified Flag (S-Flag) This document 1829 3 SRv6 Endpoint Behavior & 1830 SID Structure Flag (B-Flag) This document 1831 4-7 Unassigned 1833 6.9. New Registry: Color Extended Community Color-Only Types 1835 This document requests the creation of a new registry called "Color 1836 Extended Community Color-Only Types" under the "BGP Tunnel 1837 Encapsulation" registry for assignment of codepoints (values 0 1838 through 3) in the Color-Only Type field of the Color Extended 1839 Community Flags field. The allocation policy of this registry is 1840 "Standards Action" according to [RFC8126]. 1842 The following types are defined: 1844 Type Description Reference 1845 ----------------------------------------------------------- 1846 0 Specific Endpoint Match This document 1847 1 Specific or Null Endpoint Match This document 1848 2 Specific, Null, or Any Endpoint Match This document 1849 3 Unallocated & reserved for future This document 1851 7. Security Considerations 1853 The security mechanisms of the base BGP security model apply to the 1854 extensions described in this document as well. See the Security 1855 Considerations section of [RFC4271] for a discussion of BGP security. 1856 Also, refer to [RFC4272] and [RFC6952] for analysis of security 1857 issues for BGP. 1859 The BGP SR Policy extensions specified in this document enable 1860 traffic engineering and service programming use-cases within the SR 1861 domain as described in [I-D.ietf-spring-segment-routing-policy]. SR 1862 operates within a trusted SR domain [RFC8402] and its security 1863 considerations also apply to BGP sessions when carrying SR Policy 1864 information. The SR Policies distributed by BGP are expected to be 1865 used entirely within this trusted SR domain i.e. within a single AS 1866 or between multiple AS/domains within a single provider network. 1867 Therefore, precaution is necessary to ensure that the SR Policy 1868 information advertised via BGP sessions is limited to nodes in a 1869 secure manner within this trusted SR domain. BGP peering sessions 1870 for address-families other than SR Policy SAFI may be set up to 1871 routers outside the SR domain. The isolation of BGP SR Policy SAFI 1872 peering sessions may be used to ensure that the SR Policy information 1873 is not advertised by accident or error to an EBGP peering session 1874 outside the SR domain. 1876 Additionally, it may be considered that the export of SR Policy 1877 information, as described in this document, constitutes a risk to 1878 confidentiality of mission-critical or commercially sensitive 1879 information about the network (more specifically endpoint/node 1880 addresses, SR SIDs, and the SR Policies deployed). BGP peerings are 1881 not automatic and require configuration; thus, it is the 1882 responsibility of the network operator to ensure that only trusted 1883 nodes (that include both routers and controller applications) within 1884 the SR domain are configured to receive such information. 1886 8. Acknowledgments 1888 The authors of this document would like to thank Shyam Sethuram, John 1889 Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha, Bruno Decraene, 1890 Gurusiddesh Nidasesi, Kausik Majumdar, Zafar Ali, Swadesh Agarwal, 1891 Jakob Heitz, Viral Patel, Peng Shaofu, Cheng Li, Martin Vigoureux, 1892 and John Scudder for their comments and review of this document. The 1893 authors would like to thank Sue Hares for her detailed shepherd 1894 review that helped in improving the document. 1896 9. Contributors 1898 Eric Rosen 1899 Juniper Networks 1900 US 1902 Email: erosen@juniper.net 1904 Arjun Sreekantiah 1905 Cisco Systems 1906 US 1908 Email: asreekan@cisco.com 1910 Acee Lindem 1911 Cisco Systems 1912 US 1914 Email: acee@cisco.com 1916 Siva Sivabalan 1917 Cisco Systems 1918 US 1920 Email: msiva@cisco.com 1922 Imtiyaz Mohammad 1923 Arista Networks 1924 India 1926 Email: imtiyaz@arista.com 1928 Gaurav Dawra 1929 Cisco Systems 1930 US 1932 Email: gdawra.ietf@gmail.com 1934 Peng Shaofu 1935 ZTE Corporation 1936 China 1938 Email: peng.shaofu@zte.com.cn 1940 10. References 1942 10.1. Normative References 1944 [I-D.ietf-spring-segment-routing-policy] 1945 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1946 P. Mattes, "Segment Routing Policy Architecture", draft- 1947 ietf-spring-segment-routing-policy-22 (work in progress), 1948 March 2022. 1950 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1951 Requirement Levels", BCP 14, RFC 2119, 1952 DOI 10.17487/RFC2119, March 1997, 1953 . 1955 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1956 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1957 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1958 . 1960 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1961 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1962 DOI 10.17487/RFC4271, January 2006, 1963 . 1965 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1966 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1967 February 2006, . 1969 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1970 "Multiprotocol Extensions for BGP-4", RFC 4760, 1971 DOI 10.17487/RFC4760, January 2007, 1972 . 1974 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1975 Patel, "Revised Error Handling for BGP UPDATE Messages", 1976 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1977 . 1979 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1980 Writing an IANA Considerations Section in RFCs", BCP 26, 1981 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1982 . 1984 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1985 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1986 May 2017, . 1988 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1989 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1990 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1991 July 2018, . 1993 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1994 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1995 Routing with the MPLS Data Plane", RFC 8660, 1996 DOI 10.17487/RFC8660, December 2019, 1997 . 1999 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 2000 and J. Hardwick, "Path Computation Element Communication 2001 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 2002 DOI 10.17487/RFC8664, December 2019, 2003 . 2005 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 2006 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 2007 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 2008 . 2010 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 2011 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 2012 (SRv6) Network Programming", RFC 8986, 2013 DOI 10.17487/RFC8986, February 2021, 2014 . 2016 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 2017 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 2018 DOI 10.17487/RFC9012, April 2021, 2019 . 2021 10.2. Informational References 2023 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 2024 RFC 4272, DOI 10.17487/RFC4272, January 2006, 2025 . 2027 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 2028 Reflection: An Alternative to Full Mesh Internal BGP 2029 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 2030 . 2032 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 2033 BGP, LDP, PCEP, and MSDP Issues According to the Keying 2034 and Authentication for Routing Protocols (KARP) Design 2035 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 2036 . 2038 Authors' Addresses 2040 Stefano Previdi 2041 Huawei Technologies 2042 IT 2044 Email: stefano@previdi.net 2046 Clarence Filsfils 2047 Cisco Systems 2048 Brussels 2049 BE 2051 Email: cfilsfil@cisco.com 2053 Ketan Talaulikar (editor) 2054 Arrcus Inc 2055 India 2057 Email: ketant.ietf@gmail.com 2059 Paul Mattes 2060 Microsoft 2061 One Microsoft Way 2062 Redmond, WA 98052 2063 USA 2065 Email: pamattes@microsoft.com 2067 Dhanendra Jain 2068 Google 2070 Email: dhanendra.ietf@gmail.com 2071 Steven Lin 2072 Google 2074 Email: stevenlin@google.com