idnits 2.17.1 draft-ietf-idr-segment-routing-te-policy-14.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 (November 10, 2021) is 896 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-spring-segment-routing-policy-14 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track C. Filsfils 5 Expires: May 14, 2022 K. Talaulikar, Ed. 6 Cisco Systems 7 P. Mattes 8 Microsoft 9 D. Jain 10 S. Lin 11 Google 12 November 10, 2021 14 Advertising Segment Routing Policies in BGP 15 draft-ietf-idr-segment-routing-te-policy-14 17 Abstract 19 This document defines a new BGP SAFI with a new NLRI to advertise a 20 candidate path of a Segment Routing (SR) Policy. An SR Policy is a 21 set of candidate paths, each consisting of one or more segment lists. 22 The headend of an SR Policy may learn multiple candidate paths for an 23 SR Policy. Candidate paths may be learned via several different 24 mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document 25 specifies how BGP may be used to distribute SR Policy candidate 26 paths. New sub-TLVs for the Tunnel Encapsulation Attribute are 27 defined for signaling information about these candidate paths. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 14, 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 65 2. SR Policy Encoding . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. SR Policy SAFI and NLRI . . . . . . . . . . . . . . . . . 5 67 2.2. SR Policy and Tunnel Encapsulation Attribute . . . . . . 7 68 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 69 2.4. SR Policy Sub-TLVs . . . . . . . . . . . . . . . . . . . 9 70 2.4.1. Preference Sub-TLV . . . . . . . . . . . . . . . . . 9 71 2.4.2. Binding SID Sub-TLV . . . . . . . . . . . . . . . . . 10 72 2.4.3. SRv6 Binding SID Sub-TLV . . . . . . . . . . . . . . 11 73 2.4.4. Segment List Sub-TLV . . . . . . . . . . . . . . . . 13 74 2.4.5. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 27 75 2.4.6. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 29 76 2.4.7. Policy Candidate Path Name Sub-TLV . . . . . . . . . 30 77 2.4.8. Policy Name Sub-TLV . . . . . . . . . . . . . . . . . 31 78 3. Color Extended Community . . . . . . . . . . . . . . . . . . 32 79 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 32 80 4.1. Advertisement of SR Policies . . . . . . . . . . . . . . 32 81 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 33 82 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 33 83 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 33 84 4.2.3. Passing a usable SR Policy NLRI to the SRPM . . . . . 34 85 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 34 86 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 35 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 88 6.1. Existing Registry: Subsequent Address Family Identifiers 89 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 36 90 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute 91 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 36 92 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute 93 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 37 95 6.4. Existing Registry: Color Extended Community Flags . . . . 37 96 6.5. New Registry: SR Policy Segment List Sub-TLVs . . . . . . 37 97 6.6. New Registry: SR Policy Binding SID Flags . . . . . . . . 38 98 6.7. New Registry: SR Policy SRv6 Binding SID Flags . . . . . 38 99 6.8. New Registry: SR Policy Segment Flags . . . . . . . . . . 39 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 101 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 102 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 104 10.1. Normative References . . . . . . . . . . . . . . . . . . 41 105 10.2. Informational References . . . . . . . . . . . . . . . . 43 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 108 1. Introduction 110 Segment Routing (SR) [RFC8402] allows a headend node to steer a 111 packet flow along any path. Intermediate per-path states are 112 eliminated thanks to source routing. 114 The headend node is said to steer a flow into an SR Policy [RFC8402]. 116 The packets steered into an SR Policy carry an ordered list of 117 segments associated with that SR Policy. 119 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 120 Policy and steering into an SR Policy. These apply equally to the 121 SR-MPLS and Segment Routing for IPv6 (SRv6) data-plane instantiations 122 of Segment Routing using SR-MPLS and SRv6 Segment Identifiers (SIDs) 123 as described in [RFC8402]. [RFC8660] describes the representation 124 and processing of this ordered list of segments as MPLS label stack 125 for SR-MPLS. While [RFC8754] and [RFC8986] describe the same for 126 SRv6 with the use of the Segment Routing Header (SRH). 128 The SR Policy related functionality described in 129 [I-D.ietf-spring-segment-routing-policy] can be conceptually viewed 130 as being incorporated in an SR Policy Module (SRPM). Following is a 131 reminder of the high-level functionality of SRPM: 133 o Learning multiple candidate paths for an SR Policy via various 134 mechanisms (CLI, NetConf, PCEP or BGP). 136 o Selection of the best candidate path for an SR Policy. 138 o Binding BSID to the selected candidate path of an SR Policy. 140 o Installation of the selected candidate path and its BSID in the 141 forwarding plane. 143 This document specifies the way to use BGP to distribute one or more 144 of the candidate paths of an SR Policy to the headend of that policy. 145 The document describes the functionality provided by BGP and, as 146 appropriate, provides references for the functionality which is 147 outside the scope of BGP (i.e. resides within SRPM on the headend 148 node). 150 This document specifies a way of representing SR Policy candidate 151 paths in BGP UPDATE messages. BGP can then be used to propagate the 152 SR Policy candidate paths to the headend nodes in the network. The 153 usual BGP rules for BGP propagation and best-path selection are used. 154 At the headend of a specific policy, this will result in one or more 155 candidate paths being installed into the "BGP table". These paths 156 are then passed to the SRPM. The SRPM may compare them to candidate 157 paths learned via other mechanisms and will choose one or more paths 158 to be installed in the data plane. BGP itself does not install SR 159 Policy candidate paths into the data plane. 161 This document defines a new BGP address family (SAFI). In UPDATE 162 messages of that address family, the NLRI identifies an SR Policy 163 Candidate Path while the attributes encode the segment lists and 164 other details of that SR Policy Candidate Path. 166 While for simplicity we may write that BGP advertises an SR Policy, 167 it has to be understood that BGP advertises a candidate path of an SR 168 policy and that this SR Policy might have several other candidate 169 paths provided via BGP (via an NLRI with a different distinguisher as 170 defined in this document), PCEP, NETCONF, or local policy 171 configuration. 173 Typically, a controller defines the set of policies and advertise 174 them to policy head-end routers (typically ingress routers). The 175 policy advertisement uses BGP extensions defined in this document. 176 The policy advertisement is, in most but not all of the cases, 177 tailored for a specific policy head-end. In this case, the 178 advertisement may be sent on a BGP session to that head-end and not 179 propagated any further. 181 Alternatively, a router (i.e., a BGP egress router) advertises SR 182 Policies representing paths to itself. In this case, it is possible 183 to send the policy to each head-end over a BGP session to that head- 184 end, without requiring any further propagation of the policy. 186 An SR Policy intended only for the receiver will, in most cases, not 187 traverse any Route Reflector (RR, [RFC4456]). 189 In some situations, it is undesirable for a controller or BGP egress 190 router to have a BGP session to each policy head-end. In these 191 situations, BGP Route Reflectors may be used to propagate the 192 advertisements, or it may be necessary for the advertisement to 193 propagate through a sequence of one or more AS. To make this 194 possible, an attribute needs to be attached to the advertisement that 195 enables a BGP speaker to determine whether it is intended to be a 196 head-end for the advertised policy. This is done by attaching one or 197 more Route Target Extended Communities to the advertisement 198 ([RFC4360]). 200 The BGP extensions for the advertisement of SR Policies include 201 following components: 203 o A new Subsequent Address Family Identifier (SAFI) whose NLRI 204 identifies an SR Policy candidate path. 206 o A new Tunnel Type identifier for SR Policy, and a set of sub-TLVs 207 to be inserted into the Tunnel Encapsulation Attribute (as defined 208 in [RFC9012]) specifying segment lists of the SR Policy candidate 209 path, as well as other information about the SR Policy. 211 o One or more IPv4 address format route target extended community 212 ([RFC4360]) attached to the SR Policy advertisement and that 213 indicates the intended head-end of such SR Policy advertisement. 215 o The Color Extended Community (as defined in [RFC9012]) and used in 216 order to steer traffic into an SR Policy, as described in section 217 8.4 in [I-D.ietf-spring-segment-routing-policy]. This document 218 (Section 3) modifies the format of the Color Extended Community by 219 using the two leftmost bits of the RESERVED field. 221 1.1. Requirements Language 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 225 "OPTIONAL" in this document are to be interpreted as described in BCP 226 14 [RFC2119] [RFC8174] when, and only when, they appear in all 227 capitals, as shown here. 229 2. SR Policy Encoding 231 2.1. SR Policy SAFI and NLRI 233 A new SAFI is defined: the SR Policy SAFI with codepoint 73. The AFI 234 used MUST be IPv4(1) or IPv6(2). 236 The SR Policy SAFI uses a new NLRI defined as follows: 238 +------------------+ 239 | NLRI Length | 1 octet 240 +------------------+ 241 | Distinguisher | 4 octets 242 +------------------+ 243 | Policy Color | 4 octets 244 +------------------+ 245 | Endpoint | 4 or 16 octets 246 +------------------+ 248 where: 250 o NLRI Length: 1 octet of length expressed in bits as defined in 251 [RFC4760]. When AFI = 1 value MUST be 96 and when AFI = 2 value 252 MUST be 192. 254 o Distinguisher: 4-octet value uniquely identifying the policy in 255 the context of tuple. The distinguisher has no 256 semantic value and is solely used by the SR Policy originator to 257 make unique (from an NLRI perspective) both for multiple candidate 258 paths of the same SR Policy as well as candidate paths of 259 different SR Policies (i.e. with different segment list) with the 260 same Color and Endpoint but meant for different head-ends. 262 o Policy Color: 4-octet value identifying (with the endpoint) the 263 policy. The color is used to match the color of the destination 264 prefixes to steer traffic into the SR Policy as specified in 265 [I-D.ietf-spring-segment-routing-policy]. 267 o Endpoint: identifies the endpoint of a policy. The Endpoint may 268 represent a single node or a set of nodes (e.g., an anycast 269 address). The Endpoint is an IPv4 (4-octet) address or an IPv6 270 (16-octet) address according to the AFI of the NLRI. 272 The color and endpoint are used to automate the steering of BGP 273 Payload prefixes on SR Policy as described in 274 [I-D.ietf-spring-segment-routing-policy]. 276 The NLRI containing the SR Policy candidate path is carried in a BGP 277 UPDATE message [RFC4271] using BGP multi-protocol extensions 278 [RFC4760] with an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of 73. 280 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 281 attribute with the SR Policy SAFI MUST also carry the BGP mandatory 282 attributes. In addition, the BGP update message MAY also contain any 283 of the BGP optional attributes. 285 The next-hop network address field in SR Policy SAFI (73) updates may 286 be either a 4 octet IPv4 address or a 16 octet IPv6 address, 287 independent of the SR Policy AFI. The length field of the next-hop 288 address specifies the next-hop address family. If the next-hop 289 length is 4, then the next-hop is an IPv4 address; if the next-hop 290 length is 16, then it is a global IPv6 address; if the next-hop 291 length is 32, then it has a global IPv6 address followed by a link- 292 local IPv6 address. The setting of the next-hop field and its 293 attendant processing is governed by standard BGP procedures as 294 described in section 3 in [RFC4760]. 296 It is important to note that any BGP speaker receiving a BGP message 297 with an SR Policy NLRI, will process it only if the NLRI is among the 298 best-paths as per the BGP best-path selection algorithm. In other 299 words, this document leverages the existing BGP propagation and best- 300 path selection rules. Details of the procedures are described in 301 Section 4. 303 It has to be noted that if several candidate paths of the same SR 304 Policy (endpoint, color) are signaled via BGP to a head-end, it is 305 RECOMMENDED that each NLRI uses a different distinguisher. If BGP 306 has installed into the BGP table two advertisements whose respective 307 NLRIs have the same color and endpoint, but different distinguishers, 308 both advertisements are passed to the SRPM as different candidate 309 paths along with their respective originator information (i.e. ASN 310 and BGP Router-ID) as described in section 2.4 of 311 [I-D.ietf-spring-segment-routing-policy]. The ASN would be the ASN 312 of origin and the BGP Router-ID is determined in the following order: 314 o From the Route Origin Community [RFC4360] if present and carrying 315 an IP Address 317 o As the BGP Originator ID [RFC4456] if present 319 o As the BGP Router-ID of the peer from which the update was 320 received as a last resort. 322 2.2. SR Policy and Tunnel Encapsulation Attribute 324 The content of the SR Policy Candidate Path is encoded in the Tunnel 325 Encapsulation Attribute defined in [RFC9012] using a new Tunnel-Type 326 called SR Policy Type with codepoint 15. 328 The SR Policy Encoding structure is as follows: 330 SR Policy SAFI NLRI: 331 Attributes: 332 Tunnel Encaps Attribute (23) 333 Tunnel Type: SR Policy 334 Binding SID 335 SRv6 Binding SID 336 Preference 337 Priority 338 Policy Name 339 Policy Candidate Path Name 340 Explicit NULL Label Policy (ENLP) 341 Segment List 342 Weight 343 Segment 344 Segment 345 ... 346 ... 347 where: 349 o SR Policy SAFI NLRI is defined in Section 2.1. 351 o Tunnel Encapsulation Attribute is defined in [RFC9012]. 353 o Tunnel-Type is set to 15. 355 o Preference, Binding SID, SRv6 Binding SID, Priority, Policy Name, 356 Policy Candidate Path Name, ENLP, Segment-List, Weight, and 357 Segment sub-TLVs are defined in this document. 359 o Additional sub-TLVs may be defined in the future. 361 A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV 362 of type "SR Policy". 364 2.3. Remote Endpoint and Color 366 The Remote Endpoint and Color sub-TLVs, as defined in [RFC9012], MAY 367 also be present in the SR Policy encodings. 369 The Remote Endpoint and Color Sub-TLVs of the Tunnel Encapsulation 370 Attribute are not used for SR Policy encodings and therefore their 371 value is irrelevant in the context of the SR Policy SAFI NLRI. If 372 present, the Remote Endpoint sub-TLV and the Color sub-TLV MUST be 373 ignored by the BGP speaker. 375 2.4. SR Policy Sub-TLVs 377 This section specifies the sub-TLVs defined for encoding the 378 information about the SR Policy Candidate Path. 380 Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority, 381 Policy Name, Policy Candidate Path Name, and Explicit NULL Label 382 Policy are the new sub-TLVs of the BGP Tunnel Encapsulation Attribute 383 [RFC9012] being defined in this section. 385 Weight and Segment are sub-TLVs of the new Segment-List sub-TLV 386 mentioned above. 388 None of the sub-TLVs defined in the following sub-sections have any 389 effect on the BGP best-path selection or propagation procedures. 390 These sub-TLVs are not used by BGP and are instead passed on to SRPM 391 as SR Policy Candidate Path information for further processing 392 described in [I-D.ietf-spring-segment-routing-policy] . 394 2.4.1. Preference Sub-TLV 396 The Preference sub-TLV is used to carry the preference of the SR 397 Policy candidate path. The contents of this sub-TLV are used by the 398 SRPM as described in section 2.7 in 399 [I-D.ietf-spring-segment-routing-policy]. 401 The Preference sub-TLV is optional and it MUST NOT appear more than 402 once in the SR Policy encoding. 404 The Preference sub-TLV has following format: 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Type | Length | Flags | RESERVED | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Preference (4 octets) | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 where: 416 o Type: 12 418 o Length: 6. 420 o Flags: 1 octet of flags. None are defined at this stage. Flags 421 SHOULD be set to zero on transmission and MUST be ignored on 422 receipt. 424 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 425 transmission and MUST be ignored on receipt. 427 o Preference: a 4-octet value. 429 2.4.2. Binding SID Sub-TLV 431 The Binding SID sub-TLV is used to signal the binding SID related 432 information of the SR Policy candidate path. The contents of this 433 sub-TLV are used by the SRPM as described in section 6 in 434 [I-D.ietf-spring-segment-routing-policy]. 436 The Binding SID sub-TLV is optional and it MUST NOT appear more than 437 once in the SR Policy encoding. 439 When the Binding SID sub-TLV is used to signal an SRv6 SID, the 440 choice of its SRv6 Endpoint Behavior [RFC8986] to be instantiated is 441 left to the headend node. It is RECOMMENDED that the SRv6 Binding 442 SID sub-TLV defined in Section 2.4.3, that enables the specification 443 of the SRv6 Endpoint Behavior, be used for signaling of an SRv6 444 Binding SID for an SR Policy candidate path. 446 The Binding SID sub-TLV has the following format: 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type | Length | Flags | RESERVED | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Binding SID (variable, optional) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 where: 458 o Type: 13 460 o Length: specifies the length of the value field not including Type 461 and Length fields. Can be 2 or 6 or 18. 463 o Flags: 1 octet of flags. Following flags are defined in the new 464 registry "SR Policy Binding SID Flags" as described in 465 Section 6.6: 467 0 1 2 3 4 5 6 7 468 +-+-+-+-+-+-+-+-+ 469 |S|I| | 470 +-+-+-+-+-+-+-+-+ 471 where: 473 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 474 It is used by SRPM as described in section 6.2.3 in 475 [I-D.ietf-spring-segment-routing-policy]. 477 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 478 is used by SRPM as described in section 8.2 in 479 [I-D.ietf-spring-segment-routing-policy]. 481 * Unused bits in the Flag octet SHOULD be set to zero upon 482 transmission and MUST be ignored upon receipt. 484 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 485 transmission and MUST be ignored on receipt. 487 o Binding SID: if the length is 2, then no Binding SID is present. 488 If the length is 6 then the Binding SID is encoded in 4 octets 489 using the format below. TC, S, TTL (Total of 12 bits) are 490 RESERVED and SHOULD be set to zero and MUST be ignored. 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Label | TC |S| TTL | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 If the length is 18 then the Binding SID contains a 16-octet SRv6 499 SID. 501 2.4.3. SRv6 Binding SID Sub-TLV 503 The SRv6 Binding SID sub-TLV is used to signal the SRv6 Binding SID 504 related information of the SR Policy candidate path. It enables the 505 specification of the SRv6 Endpoint Behavior [RFC8986] to be 506 instantiated on the headend node. The contents of this sub-TLV are 507 used by the SRPM as described in section 6 in 508 [I-D.ietf-spring-segment-routing-policy]. 510 The SRv6 Binding SID sub-TLV is optional. More than one SRv6 Binding 511 SIDs MAY be signaled in the same SR Policy encoding to indicate one 512 or more SRv6 SIDs, each with potentially different SRv6 Endpoint 513 Behaviors to be instantiated. 515 The SRv6 Binding SID sub-TLV has the following format: 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Type | Length | Flags | RESERVED | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | SRv6 Binding SID (16 octets) | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 // SRv6 Endpoint Behavior and SID Structure (optional) // 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 where: 529 o Type: TBD 531 o Length is variable 533 o Flags: 1 octet of flags. Following flags are defined in the new 534 registry "SR Policy Binding SID Flags" as described in 535 Section 6.7: 537 0 1 2 3 4 5 6 7 538 +-+-+-+-+-+-+-+-+ 539 |S|I|B| | 540 +-+-+-+-+-+-+-+-+ 542 where: 544 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 545 It is used by SRPM as described in section 6.2.3 in 546 [I-D.ietf-spring-segment-routing-policy]. 548 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 549 is used by SRPM as described in section 8.2 in 550 [I-D.ietf-spring-segment-routing-policy]. 552 * B-Flag: This flag, when set, indicates the presence of the SRv6 553 Endpoint Behavior and SID Structure encoding specified in 554 Section 2.4.4.2.13. 556 * Unused bits in the Flag octet SHOULD be set to zero upon 557 transmission and MUST be ignored upon receipt. 559 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 560 transmission and MUST be ignored on receipt. 562 o SRv6 Binding SID: Contains a 16-octet SRv6 SID. 564 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 565 Section 2.4.4.2.13. 567 2.4.4. Segment List Sub-TLV 569 The Segment List sub-TLV encodes a single explicit path towards the 570 endpoint as described in section 5.1 in 571 [I-D.ietf-spring-segment-routing-policy]. The Segment List sub-TLV 572 includes the elements of the paths (i.e., segments) as well as an 573 optional Weight sub-TLV. 575 The Segment List sub-TLV may exceed 255 bytes length due to large 576 number of segments. Therefore a 2-octet length is required. 577 According to [RFC9012], the first bit of the sub-TLV codepoint 578 defines the size of the length field. Therefore, for the Segment 579 List sub-TLV a code point of 128 or higher is used. 581 The Segment List sub-TLV is optional and MAY appear multiple times in 582 the SR Policy encoding. The ordering of Segment List sub-TLVs, each 583 sub-TLV encoding a Segment List, does not matter. 585 The Segment List sub-TLV contains zero or more Segment sub-TLVs and 586 MAY contain a Weight sub-TLV. 588 The Segment List sub-TLV has the following format: 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type | Length | RESERVED | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 // sub-TLVs // 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 where: 600 o Type: 128. 602 o Length: the total length (not including the Type and Length 603 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 605 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 606 transmission and MUST be ignored on receipt. 608 o sub-TLVs currently defined: 610 * An optional single Weight sub-TLV. 612 * Zero or more Segment sub-TLVs. 614 Validation of an explicit path encoded by the Segment List sub-TLV is 615 beyond the scope of BGP and performed by the SRPM as described in 616 section 5 in [I-D.ietf-spring-segment-routing-policy]. 618 2.4.4.1. Weight Sub-TLV 620 The Weight sub-TLV specifies the weight associated with a given 621 segment list. The contents of this sub-TLV are used only by the SRPM 622 as described in section 2.11 in 623 [I-D.ietf-spring-segment-routing-policy]. 625 The Weight sub-TLV is optional and it MUST NOT appear more than once 626 inside the Segment List sub-TLV. 628 The Weight sub-TLV has the following format: 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Type | Length | Flags | RESERVED | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Weight | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 where: 640 o Type: 9. 642 o Length: 6 644 o Flags: 1 octet of flags. None are defined at this stage. Flags 645 SHOULD be set to zero on transmission and MUST be ignored on 646 receipt. 648 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 649 transmission and MUST be ignored on receipt. 651 2.4.4.2. Segment Sub-TLVs 653 A Segment sub-TLV describes a single segment in a segment list (i.e., 654 a single element of the explicit path). One or more Segment sub-TLVs 655 constitute an explicit path of the SR Policy candidate path. The 656 contents of these sub-TLVs are used only by the SRPM as described in 657 section 4 in [I-D.ietf-spring-segment-routing-policy]. 659 The Segment sub-TLVs are optional and MAY appear multiple times in 660 the Segment List sub-TLV. 662 [I-D.ietf-spring-segment-routing-policy] defines several Segment 663 Types: 665 Type A: SR-MPLS Label 666 Type B: SRv6 SID 667 Type C: IPv4 Prefix with optional SR Algorithm 668 Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS 669 Type E: IPv4 Prefix with Local Interface ID 670 Type F: IPv4 Addresses for link endpoints as Local, Remote pair 671 Type G: IPv6 Prefix and Interface ID for link endpoints as Local, 672 Remote pair for SR-MPLS 673 Type H: IPv6 Addresses for link endpoints as Local, Remote pair 674 for SR-MPLS 675 Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6 676 Type J: IPv6 Prefix and Interface ID for link endpoints as Local, 677 Remote pair for SRv6 678 Type K: IPv6 Addresses for link endpoints as Local, Remote pair 679 for SRv6 681 The following sub-sections specify the sub-TLV used for encoding each 682 of these Segment Types. 684 2.4.4.2.1. Segment Type A 686 The Type A Segment Sub-TLV encodes a single SR-MPLS SID. The format 687 is as 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 | RESERVED | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Label | TC |S| TTL | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 where: 699 o Type: 1. 701 o Length is 6. 703 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 705 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 706 transmission and MUST be ignored on receipt. 708 o Label: 20 bits of label value. 710 o TC: 3 bits of traffic class. 712 o S: 1 bit of bottom-of-stack. 714 o TTL: 1 octet of TTL. 716 The following applies to the Type-1 Segment sub-TLV: 718 o The S bit SHOULD be zero upon transmission and MUST be ignored 719 upon reception. 721 o If the originator wants the receiver to choose the TC value, it 722 sets the TC field to zero. 724 o If the originator wants the receiver to choose the TTL value, it 725 sets the TTL field to 255. 727 o If the originator wants to recommend a value for these fields, it 728 puts those values in the TC and/or TTL fields. 730 o The receiver MAY override the originator's values for these 731 fields. This would be determined by local policy at the receiver. 732 One possible policy would be to override the fields only if the 733 fields have the default values specified above. 735 2.4.4.2.2. Segment Type B 737 The Type B Segment Sub-TLV encodes a single SRv6 SID. The format is 738 as follows: 740 0 1 2 3 741 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 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Type | Length | Flags | RESERVED | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 // SRv6 SID (16 octets) // 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 // SRv6 Endpoint Behavior and SID Structure (optional) // 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 where: 752 o Type: 13. 754 o Length is variable. 756 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 758 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 759 transmission and MUST be ignored on receipt. 761 o SRv6 SID: 16 octets of IPv6 address. 763 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 764 Section 2.4.4.2.13. 766 The TLV 2 defined for the advertisement of Segment Type B in the 767 earlier versions of this document has been deprecated to avoid 768 backward compatibility issues. 770 2.4.4.2.3. Segment Type C 772 The Type C Segment Sub-TLV encodes an IPv4 node address, SR Algorithm 773 and an optional SR-MPLS SID. The format is as follows: 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Type | Length | Flags | SR Algorithm | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | IPv4 Node Address (4 octets) | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | SR-MPLS SID (optional, 4 octets) | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 where: 787 o Type: 3. 789 o Length is 10 when the SR-MPLS SID is present else is 6. 791 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 793 o SR Algorithm: 1 octet specifying SR Algorithm as described in 794 section 3.1.1 in [RFC8402] when A-Flag as defined in 795 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 796 described in section 4 in 797 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 798 encoded, this field SHOULD be set to zero on transmission and MUST 799 be ignored on receipt. 801 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 803 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 804 TTL as defined in Section 2.4.4.2.1. 806 2.4.4.2.4. Segment Type D 808 The Type D Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 809 and an optional SR-MPLS SID. The format is as follows: 811 0 1 2 3 812 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 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Type | Length | Flags | SR Algorithm | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 // IPv6 Node Address (16 octets) // 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | SR-MPLS SID (optional, 4 octets) | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 where: 823 o Type: 4 825 o Length is 22 when the SR-MPLS SID is present else is 18. 827 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 829 o SR Algorithm: 1 octet specifying SR Algorithm as described in 830 section 3.1.1 in [RFC8402] when A-Flag as defined in 831 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 832 described in section 4 in 833 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 834 encoded, this field SHOULD be set to zero on transmission and MUST 835 be ignored on receipt. 837 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 839 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 840 TTL as defined in Section 2.4.4.2.1. 842 2.4.4.2.5. Segment Type E 844 The Type E Segment Sub-TLV encodes an IPv4 node address, a local 845 interface Identifier (Local Interface ID), and an optional SR-MPLS 846 SID. The format is as follows: 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Type | Length | Flags | RESERVED | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Local Interface ID (4 octets) | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | IPv4 Node Address (4 octets) | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | SR-MPLS SID (optional, 4 octets) | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 where: 862 o Type: 5. 864 o Length is 14 when the SR-MPLS SID is present else is 10. 866 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 868 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 869 transmission and MUST be ignored on receipt. 871 o Local Interface ID: 4 octets of interface index as defined in 872 [RFC8664]. 874 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 876 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 877 TTL as defined in Section 2.4.4.2.1. 879 2.4.4.2.6. Segment Type F 881 The Type F Segment Sub-TLV encodes an adjacency local address, an 882 adjacency remote address, and an optional SR-MPLS SID. The format is 883 as follows: 885 0 1 2 3 886 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 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Type | Length | Flags | RESERVED | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Local IPv4 Address (4 octets) | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Remote IPv4 Address (4 octets) | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | SR-MPLS SID (optional, 4 octets) | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 where: 899 o Type: 6. 901 o Length is 14 when the SR-MPLS SID is present else is 10. 903 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 905 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 906 transmission and MUST be ignored on receipt. 908 o Local IPv4 Address: a 4 octet IPv4 address. 910 o Remote IPv4 Address: a 4 octet IPv4 address. 912 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 913 TTL as defined in Section 2.4.4.2.1. 915 2.4.4.2.7. Segment Type G 917 The Type G Segment Sub-TLV encodes an IPv6 link-local adjacency with 918 IPv6 local node address, a local interface identifier (Local 919 Interface ID), IPv6 remote node address, a remote interface 920 identifier (Remote Interface ID), and an optional SR-MPLS SID. The 921 format is as follows: 923 0 1 2 3 924 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 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Type | Length | Flags | RESERVED | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Local Interface ID (4 octets) | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 // IPv6 Local Node Address (16 octets) // 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Remote Interface ID (4 octets) | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 // IPv6 Remote Node Address (16 octets) // 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | SR-MPLS SID (optional, 4 octets) | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 where: 941 o Type: 7 943 o Length is 46 when the SR-MPLS SID is present else is 42. 945 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 947 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 948 transmission and MUST be ignored on receipt. 950 o Local Interface ID: 4 octets of interface index as defined in 951 [RFC8664]. 953 o IPv6 Local Node Address: a 16 octet IPv6 address. 955 o Remote Interface ID: 4 octets of interface index as defined in 956 [RFC8664]. The value MAY be set to zero when the local node 957 address and interface identifiers are sufficient to describe the 958 link. 960 o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY 961 be set to zero when the local node address and interface 962 identifiers are sufficient to describe the link. 964 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 965 TTL as defined in Section 2.4.4.2.1. 967 2.4.4.2.8. Segment Type H 969 The Type H Segment Sub-TLV encodes an adjacency local address, an 970 adjacency remote address, and an optional SR-MPLS SID. The format is 971 as follows: 973 0 1 2 3 974 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 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Type | Length | Flags | RESERVED | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 // Local IPv6 Address (16 octets) // 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 // Remote IPv6 Address (16 octets) // 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | SR-MPLS SID (optional, 4 octets) | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 where: 987 o Type: 8 989 o Length is 38 when the SR-MPLS SID is present else is 34. 991 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 993 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 994 transmission and MUST be ignored on receipt. 996 o Local IPv6 Address: a 16 octet IPv6 address. 998 o Remote IPv6 Address: a 16 octet IPv6 address. 1000 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 1001 TTL as defined in Section 2.4.4.2.1. 1003 2.4.4.2.9. Segment Type I 1005 The Type I Segment Sub-TLV encodes an IPv6 node address, SR 1006 Algorithm, and an optional SRv6 SID. The format is as follows: 1008 0 1 2 3 1009 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 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Type | Length | Flags | SR Algorithm | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 // IPv6 Node Address (16 octets) // 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 // SRv6 SID (optional, 16 octets) // 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 // SRv6 Endpoint Behavior and SID Structure (optional) // 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 where: 1022 o Type: 14 1024 o Length is variable. 1026 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1028 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1029 section 3.1.1 in [RFC8402] when A-Flag as defined in 1030 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1031 described in section 4 in 1032 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1033 encoded, this field SHOULD be set to zero on transmission and MUST 1034 be ignored on receipt. 1036 o IPv6 Node Address: a 16 octet IPv6 address. 1038 o SRv6 SID: optional, a 16 octet IPv6 address. 1040 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1041 Section 2.4.4.2.13. 1043 The TLV 10 defined for the advertisement of Segment Type I in the 1044 earlier versions of this document has been deprecated to avoid 1045 backward compatibility issues. 1047 2.4.4.2.10. Segment Type J 1049 The Type J Segment Sub-TLV encodes an IPv6 link-local adjacency with 1050 local node address, a local interface identifier (Local Interface 1051 ID), remote IPv6 node address, a remote interface identifier (Remote 1052 Interface ID), and an optional SRv6 SID. The format is as follows: 1054 0 1 2 3 1055 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 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Type | Length | Flags | SR Algorithm | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Local Interface ID (4 octets) | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 // IPv6 Local Node Address (16 octets) // 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Remote Interface ID (4 octets) | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 // IPv6 Remote Node Address (16 octets) // 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 // SRv6 SID (optional, 16 octets) // 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 // SRv6 Endpoint Behavior and SID Structure (optional) // 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 where: 1074 o Type: 15 1076 o Length is variable. 1078 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1080 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1081 section 3.1.1 in [RFC8402] when A-Flag as defined in 1082 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1083 described in section 4 in 1084 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1085 encoded, this field SHOULD be set to zero on transmission and MUST 1086 be ignored on receipt. 1088 o Local Interface ID: 4 octets of interface index as defined in 1089 [RFC8664]. 1091 o IPv6 Local Node Address: a 16 octet IPv6 address. 1093 o Remote Interface ID: 4 octets of interface index as defined in 1094 [RFC8664]. The value MAY be set to zero when the local node 1095 address and interface identifiers are sufficient to describe the 1096 link. 1098 o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY 1099 be set to zero when the local node address and interface 1100 identifiers are sufficient to describe the link. 1102 o SRv6 SID: optional, a 16 octet IPv6 address. 1104 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1105 Section 2.4.4.2.13. 1107 The TLV 11 defined for the advertisement of Segment Type J in the 1108 earlier versions of this document has been deprecated to avoid 1109 backward compatibility issues. 1111 2.4.4.2.11. Segment Type K 1113 The Type K Segment Sub-TLV encodes an adjacency local address, an 1114 adjacency remote address, and an optional SRv6 SID. The format is as 1115 follows: 1117 0 1 2 3 1118 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 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Type | Length | Flags | SR Algorithm | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 // Local IPv6 Address (16 octets) // 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 // Remote IPv6 Address (16 octets) // 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 // SRv6 SID (optional, 16 octets) // 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 // SRv6 Endpoint Behavior and SID Structure (optional) // 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 where: 1133 o Type: 16 1135 o Length is variable. 1137 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1139 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1140 section 3.1.1 in [RFC8402] when A-Flag as defined in 1141 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1142 described in section 4 in 1143 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1144 encoded, this field SHOULD be set to zero on transmission and MUST 1145 be ignored on receipt. 1147 o Local IPv6 Address: a 16 octet IPv6 address. 1149 o Remote IPv6 Address: a 16 octet IPv6 address. 1151 o SRv6 SID: optional, a 16 octet IPv6 address. 1153 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1154 Section 2.4.4.2.13. 1156 The TLV 12 defined for the advertisement of Segment Type K in the 1157 earlier versions of this document has been deprecated to avoid 1158 backward compatibility issues. 1160 2.4.4.2.12. Segment Flags 1162 The Segment Types sub-TLVs described above MAY contain the following 1163 flags in the "Flags" field defined in Section 6.8: 1165 0 1 2 3 4 5 6 7 1166 +-+-+-+-+-+-+-+-+ 1167 |V|A|S|B| | 1168 +-+-+-+-+-+-+-+-+ 1170 where: 1172 V-Flag: This flag, when set, is used by SRPM for "SID 1173 verification" as described in Section 5.1 in 1174 [I-D.ietf-spring-segment-routing-policy]. 1176 A-Flag: This flag, when set, indicates the presence of SR 1177 Algorithm id in the "SR Algorithm" field applicable to various 1178 Segment Types. SR Algorithm is used by SRPM as described in 1179 section 4 in [I-D.ietf-spring-segment-routing-policy]. 1181 S-Flag: This flag, when set, indicates the presence of the SR-MPLS 1182 or SRv6 SID depending on the segment type. 1184 B-Flag: This flag, when set, indicates the presence of the SRv6 1185 Endpoint Behavior and SID Structure encoding specified in 1186 Section 2.4.4.2.13. 1188 Unused bits in the Flag octet SHOULD be set to zero upon 1189 transmission and MUST be ignored upon receipt. 1191 The following applies to the Segment Flags: 1193 o V-Flag applies to all Segment Types. 1195 o A-Flag applies to Segment Types C, D, I, J, and K. If A-Flag 1196 appears with Segment Types A, B, E, F, G, and H, it MUST be 1197 ignored. 1199 o S-Flag applies to Segment Types C, D, E, F, G, H, I, J, and K. If 1200 S-Flag appears with Segment Types A or B, it MUST be ignored. 1202 o B-Flag applies to Segment Types B, I, J, and K. If B-Flag appears 1203 with Segment Types A, C, D, E, F, G, and H, it MUST be ignored. 1205 2.4.4.2.13. SRv6 SID Endpoint Behavior and Structure 1207 The Segment Types sub-TLVs described above MAY contain the SRv6 1208 Endpoint Behavior and SID Structure [RFC8986] encoding as described 1209 below: 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Endpoint Behavior | Reserved | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | LB Length | LN Length | Fun. Length | Arg. Length | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 where: 1219 Endpoint Behavior: 2 octets. It carries the SRv6 Endpoint 1220 Behavior code point for this SRv6 SID as defined in section 9.2 of 1221 [RFC8986]. When set with the value 0, the choice of SRv6 Endpoint 1222 Behavior is left to the headend. 1224 Reserved: 2 octets of reserved bits. SHOULD be set to zero on 1225 transmission and MUST be ignored on receipt. 1227 Locator Block Length: 1 octet. SRv6 SID Locator Block length in 1228 bits. 1230 Locator Node Length: 1 octet. SRv6 SID Locator Node length in 1231 bits. 1233 Function Length: 1 octet. SRv6 SID Function length in bits. 1235 Argument Length: 1 octet. SRv6 SID Arguments length in bits. 1237 The total of the locator block, locator node, function, and argument 1238 lengths MUST be less than or equal to 128. 1240 2.4.5. Explicit NULL Label Policy Sub-TLV 1242 To steer an unlabeled IP packet into an SR policy, it is necessary to 1243 create a label stack for that packet, and push one or more labels 1244 onto that stack. 1246 The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate 1247 whether an Explicit NULL Label [RFC3032] must be pushed on an 1248 unlabeled IP packet before any other labels. 1250 If an ENLP Sub-TLV is not present, the decision of whether to push an 1251 Explicit NULL label on a given packet is a matter of local 1252 configuration. 1254 The ENLP sub-TLV is optional and it MUST NOT appear more than once in 1255 the SR Policy encoding. 1257 The contents of this sub-TLV are used by the SRPM as described in 1258 section 4.1 in [I-D.ietf-spring-segment-routing-policy]. 1260 0 1 2 3 1261 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 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Type | Length | Flags | RESERVED | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | ENLP | 1266 +-+-+-+-+-+-+-+-+ 1268 Where: 1270 Type: 14. 1272 Length: 3. 1274 Flags: 1 octet of flags. None are defined at this stage. Flags 1275 SHOULD be set to zero on transmission and MUST be ignored on 1276 receipt. 1278 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1279 transmission and MUST be ignored on receipt. 1281 ENLP (Explicit NULL Label Policy): Indicates whether Explicit NULL 1282 labels are to be pushed on unlabeled IP packets that are being 1283 steered into a given SR policy. This field has one of the 1284 following values: 1286 0: Reserved. 1288 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1289 packet, but do not push an IPv6 Explicit NULL label on an 1290 unlabeled IPv6 packet. 1292 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 1293 packet, but do not push an IPv4 Explicit NULL label on an 1294 unlabeled IPv4 packet. 1296 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1297 packet, and push an IPv6 Explicit NULL label on an unlabeled 1298 IPv6 packet. 1300 4: Do not push an Explicit NULL label. 1302 5 - 255: Reserved. 1304 The ENLP reserved values may be used for future extensions and 1305 implementations SHOULD ignore the ENLP Sub-TLV with these values. 1306 The behavior signaled in this Sub-TLV MAY be overridden by local 1307 configuration. The section 4.1 of 1308 [I-D.ietf-spring-segment-routing-policy] describes the behavior on 1309 the headend for the handling of the explicit null label. 1311 2.4.6. Policy Priority Sub-TLV 1313 An operator MAY set the Policy Priority sub-TLV to indicate the order 1314 in which the SR policies are re-computed upon topological change. 1315 The contents of this sub-TLV are used by the SRPM as described in 1316 section 2.11 in [I-D.ietf-spring-segment-routing-policy]. 1318 The Priority sub-TLV is optional and it MUST NOT appear more than 1319 once in the SR Policy encoding. 1321 The Priority sub-TLV has following format: 1323 0 1 2 3 1324 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 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Type | Length | Priority | RESERVED | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 Where: 1331 Type: 15 1333 Length: 2. 1335 Priority: a 1-octet value. 1337 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1338 transmission and MUST be ignored on receipt. 1340 2.4.7. Policy Candidate Path Name Sub-TLV 1342 An operator MAY set the Policy Candidate Path Name sub-TLV to attach 1343 a symbolic name to the SR Policy candidate path. 1345 Usage of Policy Candidate Path Name sub-TLV is described in section 1346 2.6 in [I-D.ietf-spring-segment-routing-policy]. 1348 The Policy Candidate Path Name sub-TLV may exceed 255 bytes length 1349 due to a long name. Therefore a 2-octet length is required. 1350 According to [RFC9012], the first bit of the sub-TLV codepoint 1351 defines the size of the length field. Therefore, for the Policy 1352 Candidate Path Name sub-TLV, a code point of 128 or higher is used. 1354 It is RECOMMENDED that the size of the symbolic name for the 1355 candidate path be limited to 255 bytes. Implementations MAY choose 1356 to truncate long names to 255 bytes when signaling via BGP. 1358 The Policy Candidate Path Name sub-TLV is optional and it MUST NOT 1359 appear more than once in the SR Policy encoding. 1361 The Policy Candidate Path Name sub-TLV has following format: 1363 0 1 2 3 1364 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 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | Type | Length | RESERVED | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 // Policy Candidate Path Name // 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 Where: 1373 Type: 129. 1375 Length: Variable. 1377 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1378 transmission and MUST be ignored on receipt. 1380 Policy Candidate Path Name: Symbolic name for the SR Policy 1381 candidate path without a NULL terminator as specified in section 1382 2.6 of [I-D.ietf-spring-segment-routing-policy]. 1384 2.4.8. Policy Name Sub-TLV 1386 An operator MAY set the Policy Name sub-TLV to associate a symbolic 1387 name with the SR Policy for which the candidate path is being 1388 advertised via the SR Policy NLRI. 1390 Usage of Policy Name sub-TLV is described in section 2.1 of 1391 [I-D.ietf-spring-segment-routing-policy]. 1393 The Policy Name sub-TLV may exceed 255 bytes length due to a long 1394 policy name. Therefore a 2-octet length is required. According to 1395 [RFC9012], the first bit of the sub-TLV codepoint defines the size of 1396 the length field. Therefore, for the Policy Name sub-TLV, a code 1397 point of 128 or higher is used. 1399 It is RECOMMENDED that the size of the symbolic name for the SR 1400 Policy be limited to 255 bytes. Implementations MAY choose to 1401 truncate long names to 255 bytes when signaling via BGP. 1403 The Policy Name sub-TLV is optional and it MUST NOT appear more than 1404 once in the SR Policy encoding. 1406 The Policy Name sub-TLV has following format: 1408 0 1 2 3 1409 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 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | Type | Length | RESERVED | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 // Policy Name // 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 Where: 1418 Type: TBD 1420 Length: Variable. 1422 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1423 transmission and MUST be ignored on receipt. 1425 Policy Name: Symbolic name for the policy. It SHOULD be a string 1426 of printable ASCII characters, without a NULL terminator. 1428 3. Color Extended Community 1430 The Color Extended Community as defined in [RFC9012] is used to steer 1431 traffic into a policy. 1433 When the Color Extended Community is used for steering the traffic 1434 into an SR Policy, two bits from the Flags field (as defined in 1435 [RFC9012]) are used as follows: 1437 1 1438 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 |C O| RESERVED | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 where CO bits are defined as the "Color-Only" bits. 1444 [I-D.ietf-spring-segment-routing-policy] defines the influence of 1445 these bits on the automated steering of BGP Payload traffic onto SR 1446 Policies. 1448 4. SR Policy Operations 1450 As described in this document, BGP is not the actual consumer of an 1451 SR Policy NLRI. BGP is in charge of the origination and propagation 1452 of the SR Policy NLRI but its installation and use are outside the 1453 scope of BGP. The details of SR Policy installation and use are 1454 specified in [I-D.ietf-spring-segment-routing-policy]. 1456 4.1. Advertisement of SR Policies 1458 Typically, but not limited to, an SR Policy is computed by a 1459 controller or a path computation engine (PCE) and originated by a BGP 1460 speaker on its behalf. 1462 Multiple SR Policy NLRIs may be present with the same tuple but with different content when these SR policies are 1464 intended for different head-ends. 1466 The distinguisher of each SR Policy NLRI prevents undesired BGP route 1467 selection among these SR Policy NLRIs and allows their propagation 1468 across route reflectors [RFC4456]. 1470 Moreover, one or more route target SHOULD be attached to the 1471 advertisement, where each route target identifies one or more 1472 intended head-ends for the advertised SR Policy update. 1474 If no route target is attached to the SR Policy NLRI, then it is 1475 assumed that the originator sends the SR Policy update directly 1476 (e.g., through a BGP session) to the intended receiver. In such 1477 case, the NO_ADVERTISE community MUST be attached to the SR Policy 1478 update. 1480 4.2. Reception of an SR Policy NLRI 1482 On reception of an SR Policy NLRI, a BGP speaker first determines if 1483 it is acceptable and then if it is usable. 1485 4.2.1. Acceptance of an SR Policy NLRI 1487 When a BGP speaker receives an SR Policy NLRI from a neighbor it MUST 1488 first, determine if it's acceptable. The following rules apply in 1489 addition to the validation described in Section 5: 1491 o The SR Policy NLRI MUST include a distinguisher, color and 1492 endpoint field which implies that the length of the NLRI MUST be 1493 either 12 or 24 octets (depending on the address family of the 1494 endpoint). 1496 o The SR Policy update MUST have either the NO_ADVERTISE community 1497 or at least one route target extended community in IPv4-address 1498 format or both. If a router supporting this specification 1499 receives an SR Policy update with no route target extended 1500 communities and no NO_ADVERTISE community, the update MUST be 1501 considered as malformed. 1503 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1504 Update and MUST have a Tunnel Type TLV set to SR Policy (codepoint 1505 is 15). 1507 A router that receives an SR Policy update that is not valid 1508 according to these criteria MUST treat the update as malformed and 1509 the SR Policy candidate path MUST NOT be passed to the SRPM. 1511 4.2.2. Usable SR Policy NLRI 1513 An SR Policy update that has been determined to be acceptable is 1514 further evaluated for its usability by the receiving node. 1516 An SR Policy NLRI update without any route target extended community 1517 but having the NO_ADVERTISE community is considered usable. 1519 If one or more route targets are present, then at least one route 1520 target MUST match the BGP Identifier of the receiver for the update 1521 to be considered usable. The BGP Identifier is defined in [RFC4271] 1522 as a 4 octet IPv4 address. Therefore, the route target extended 1523 community MUST be of the same format. 1525 If one or more route targets are present and none matches the local 1526 BGP Identifier, then, while the SR Policy NLRI is acceptable, it is 1527 not usable on the receiver node. 1529 When the SR Policy tunnel type includes any sub-TLV that is 1530 unrecognized or unsupported, the update SHOULD NOT be considered 1531 usable. An implementation MAY provide an option for ignoring 1532 unsupported sub-TLVs. 1534 4.2.3. Passing a usable SR Policy NLRI to the SRPM 1536 Once BGP on the receiving node has determined that the SR Policy NLRI 1537 is usable, it passes the SR Policy candidate path to the SRPM. Note 1538 that, along with the candidate path details, BGP also passes the 1539 originator information for breaking ties in the candidate path 1540 selection process as described in section 2.4 in 1541 [I-D.ietf-spring-segment-routing-policy]. 1543 When an update for an SR Policy NLRI results in its becoming 1544 unusable, BGP MUST delete its corresponding SR Policy candidate path 1545 from the SRPM. 1547 The SRPM applies the rules defined in section 2 in 1548 [I-D.ietf-spring-segment-routing-policy] to determine whether the SR 1549 Policy candidate path is valid and to select the best candidate path 1550 among the valid ones for a given SR Policy. 1552 4.2.4. Propagation of an SR Policy 1554 SR Policy NLRIs that have been determined acceptable and valid can be 1555 evaluated for propagation, even the ones that are not usable. 1557 SR Policy NLRIs that have the NO_ADVERTISE community attached to them 1558 MUST NOT be propagated. 1560 By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate 1561 it to any EBGP neighbor. An implementation MAY provide an explicit 1562 configuration to override this and enable propagation of acceptable 1563 SR Policy NLRIs to specific EBGP neighbors. 1565 A BGP node advertises a received SR Policy NLRI to its IBGP neighbors 1566 according to normal IBGP propagation rules. 1568 By default, a BGP node receiving an SR Policy NLRI SHOULD NOT remove 1569 route target extended community before propagation. An 1570 implementation MAY provide support for configuration to filter and/or 1571 remove route target extended community before propagation. 1573 5. Error Handling 1575 This section describes the error handling actions, as described in 1576 [RFC7606], that are to be performed for the handling of BGP update 1577 messages for BGP SR Policy SAFI. 1579 A BGP Speaker MUST perform the following syntactic validation of the 1580 SR Policy NLRI to determine if it is malformed. This includes the 1581 validation of the length of each NLRI and the total length of the 1582 MP_REACH_NLRI and MP_UNREACH_NLRI attributes. 1584 When the error determined allows for the router to skip the malformed 1585 NLRI(s) and continue the processing of the rest of the update 1586 message, then it MUST handle such malformed NLRIs as 'Treat-as- 1587 withdraw'. In other cases, where the error in the NLRI encoding 1588 results in the inability to process the BGP update message (e.g. 1589 length related encoding errors), then the router SHOULD handle such 1590 malformed NLRIs as 'AFI/SAFI disable' when other AFI/SAFI besides SR 1591 Policy are being advertised over the same session. Alternately, the 1592 router MUST perform 'session reset' when the session is only being 1593 used for SR Policy or when it 'AFI/SAFI disable' action is not 1594 possible. 1596 The validation of the TLVs/sub-TLVs introduced in this document and 1597 defined in their respective sub-sections of Section 2.4 MUST be 1598 performed to determine if they are malformed or invalid. The 1599 validation of the Tunnel Encapsulation Attribute itself and the other 1600 TLVs/sub-TLVs specified in [RFC9012] MUST be done as described in 1601 that document. In case of any error detected, either at the 1602 attribute or its TLV/sub-TLV level, the "treat-as-withdraw" strategy 1603 MUST be applied. This is because an SR Policy update without a valid 1604 Tunnel Encapsulation Attribute (comprising of all valid TLVs/sub- 1605 TLVs) is not usable. 1607 An SR Policy update that is determined to be not acceptable, and 1608 therefore malformed, based on rules described in Section 4.2.1 MUST 1609 be handled by the "treat-as-withdraw" strategy. 1611 The validation of the individual fields of the TLVs/sub-TLVs defined 1612 in Section 2.4 are beyond the scope of BGP as they are handled by the 1613 SRPM as described in the individual TLV/sub-TLV sub-sections. A BGP 1614 implementation MUST NOT perform semantic verification of such fields 1615 nor consider the SR Policy update to be invalid or not acceptable/ 1616 usable based on such validation. 1618 An implementation SHOULD log an error for any errors found during the 1619 above validation for further analysis. 1621 6. IANA Considerations 1623 This document requests codepoint allocations in the following 1624 existing registries: 1626 o Subsequent Address Family Identifiers (SAFI) Parameters registry 1628 o BGP Tunnel Encapsulation Attribute Tunnel Types registry under the 1629 BGP Tunnel Encapsulation registry 1631 o BGP Tunnel Encapsulation Attribute sub-TLVs registry under the BGP 1632 Tunnel Encapsulation registry 1634 o Color Extended Community Flags registry under the BGP Tunnel 1635 Encapsulation registry 1637 This document also requests the creation of the following new 1638 registries: 1640 o SR Policy Segment List Sub-TLVs under the BGP Tunnel Encapsulation 1641 registry 1643 o SR Policy Binding SID Flags under the BGP Tunnel Encapsulation 1644 registry 1646 o SR Policy Segment Flags under the BGP Tunnel Encapsulation 1647 registry 1649 6.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1650 Parameters 1652 This document defines a new SAFI in the registry "Subsequent Address 1653 Family Identifiers (SAFI) Parameters" that has been assigned a 1654 codepoint by IANA as follows: 1656 Codepoint Description Reference 1657 ----------------------------------------------- 1658 73 SR Policy SAFI This document 1660 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1662 This document defines a new Tunnel-Type in the registry "BGP Tunnel 1663 Encapsulation Attribute Tunnel Types" that has been assigned a 1664 codepoint by IANA as follows: 1666 Codepoint Description Reference 1667 -------------------------------------------------- 1668 15 SR Policy This document 1670 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1672 This document defines new sub-TLVs in the registry "BGP Tunnel 1673 Encapsulation Attribute sub-TLVs" that has been assigned codepoints 1674 by IANA as follows via the early allocation process: 1676 Codepoint Description Reference 1677 ------------------------------------------------------------ 1678 12 Preference sub-TLV This document 1679 13 Binding SID sub-TLV This document 1680 14 ENLP sub-TLV This document 1681 15 Priority sub-TLV This document 1682 20 SRv6 Binding SID sub-TLV This document 1683 128 Segment List sub-TLV This document 1684 129 Policy Candidate Path Name sub-TLV This document 1685 130 Policy Name sub-TLV This document 1687 6.4. Existing Registry: Color Extended Community Flags 1689 This document requests allocations in the registry called "Color 1690 Extended Community Flags" under the "BGP Tunnel Encapsulation" 1691 registry. 1693 The following bits have been assigned by IANA via the early 1694 allocation process: 1696 Bit 1697 Position Description Reference 1698 ------------------------------------------------------------------ 1699 0-1 Color-only bits This document 1701 6.5. New Registry: SR Policy Segment List Sub-TLVs 1703 This document requests the creation of a new registry called "SR 1704 Policy Segment List Sub-TLVs" under the "BGP Tunnel Encapsulation" 1705 registry. The allocation policy of this registry is "Standards 1706 Action" according to [RFC8126]. 1708 Following initial Sub-TLV codepoints are assigned by this document: 1710 Value Description Reference 1711 ----------------------------------------------------- 1712 0 Reserved This document 1713 1 Segment Type A sub-TLV This document 1714 2 Deprecated This document 1715 3 Segment Type C sub-TLV This document 1716 4 Segment Type D sub-TLV This document 1717 5 Segment Type E sub-TLV This document 1718 6 Segment Type F sub-TLV This document 1719 7 Segment Type G sub-TLV This document 1720 8 Segment Type H sub-TLV This document 1721 9 Weight sub-TLV This document 1722 10 Deprecated This document 1723 11 Deprecated This document 1724 12 Deprecated This document 1725 13 Segment Type B sub-TLV This document 1726 14 Segment Type I sub-TLV This document 1727 15 Segment Type J sub-TLV This document 1728 16 Segment Type K sub-TLV This document 1729 17-255 Unassigned 1731 6.6. New Registry: SR Policy Binding SID Flags 1733 This document requests the creation of a new registry called "SR 1734 Policy Binding SID Flags" under the "BGP Tunnel Encapsulation" 1735 registry. The allocation policy of this registry is "Standards 1736 Action" according to [RFC8126]. 1738 The following flags are defined: 1740 Bit Description Reference 1741 ----------------------------------------------------------------- 1742 0 Specified-BSID-Only Flag (S-Flag) This document 1743 1 Drop Upon Invalid Flag (I-Flag) This document 1744 2-7 Unassigned 1746 6.7. New Registry: SR Policy SRv6 Binding SID Flags 1748 This document requests the creation of a new registry called "SR 1749 Policy SRv6 Binding SID Flags" under the "BGP Tunnel Encapsulation" 1750 registry. The allocation policy of this registry is "Standards 1751 Action" according to [RFC8126]. 1753 The following flags are defined: 1755 Bit Description Reference 1756 ----------------------------------------------------------------- 1757 0 Specified-BSID-Only Flag (S-Flag) This document 1758 1 Drop Upon Invalid Flag (I-Flag) This document 1759 2 SRv6 Endpoint Behavior & 1760 SID Structure Flag (B-Flag) This document 1761 3-7 Unassigned 1763 6.8. New Registry: SR Policy Segment Flags 1765 This document requests the creation of a new registry called "SR 1766 Policy Segment Flags" under the "BGP Tunnel Encapsulation" registry. 1767 The allocation policy of this registry is "Standards Action" 1768 according to [RFC8126]. 1770 The following Flags are defined: 1772 Bit Description Reference 1773 ------------------------------------------------------------------ 1774 0 Segment Verification Flag (V-Flag) This document 1775 1 SR Algorithm Flag (A-Flag) This document 1776 2 SID Specified Flag (S-Flag) This document 1777 3 SRv6 Endpoint Behavior & 1778 SID Structure Flag (B-Flag) This document 1779 4-7 Unassigned 1781 7. Security Considerations 1783 The security mechanisms of the base BGP security model apply to the 1784 extensions described in this document as well. See the Security 1785 Considerations section of [RFC4271] for a discussion of BGP security. 1786 Also, refer to [RFC4272] and [RFC6952] for analysis of security 1787 issues for BGP. 1789 The BGP SR Policy extensions specified in this document enable 1790 traffic engineering and service programming use-cases within the SR 1791 domain as described in [I-D.ietf-spring-segment-routing-policy]. SR 1792 operates within a trusted SR domain [RFC8402] and its security 1793 considerations also apply to BGP sessions when carrying SR Policy 1794 information. The SR Policies distributed by BGP are expected to be 1795 used entirely within this trusted SR domain i.e. within a single AS 1796 or between multiple AS/domains within a single provider network. 1797 Therefore, precaution is necessary to ensure that the SR Policy 1798 information advertised via BGP sessions is limited to nodes in a 1799 secure manner within this trusted SR domain. BGP peering sessions 1800 for address-families other than SR Policy SAFI may be set up to 1801 routers outside the SR domain. The isolation of BGP SR Policy SAFI 1802 peering sessions may be used to ensure that the SR Policy information 1803 is not advertised by accident or error to an EBGP peering session 1804 outside the SR domain. 1806 Additionally, it may be considered that the export of SR Policy 1807 information, as described in this document, constitutes a risk to 1808 confidentiality of mission-critical or commercially sensitive 1809 information about the network (more specifically endpoint/node 1810 addresses, SR SIDs, and the SR Policies deployed). BGP peerings are 1811 not automatic and require configuration; thus, it is the 1812 responsibility of the network operator to ensure that only trusted 1813 nodes (that include both routers and controller applications) within 1814 the SR domain are configured to receive such information. 1816 8. Acknowledgments 1818 The authors of this document would like to thank Shyam Sethuram, John 1819 Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha, Bruno Decraene, 1820 Gurusiddesh Nidasesi, Kausik Majumdar, Zafar Ali, Swadesh Agarwal, 1821 Jakob Heitz, Viral Patel, Peng Shaofu, Cheng Li, and Martin Vigoureux 1822 for their comments and review of this document. 1824 9. Contributors 1826 Eric Rosen 1827 Juniper Networks 1828 US 1830 Email: erosen@juniper.net 1832 Arjun Sreekantiah 1833 Cisco Systems 1834 US 1836 Email: asreekan@cisco.com 1838 Acee Lindem 1839 Cisco Systems 1840 US 1842 Email: acee@cisco.com 1844 Siva Sivabalan 1845 Cisco Systems 1846 US 1848 Email: msiva@cisco.com 1849 Imtiyaz Mohammad 1850 Arista Networks 1851 India 1853 Email: imtiyaz@arista.com 1855 Gaurav Dawra 1856 Cisco Systems 1857 US 1859 Email: gdawra.ietf@gmail.com 1861 Peng Shaofu 1862 ZTE Corporation 1863 China 1865 Email: peng.shaofu@zte.com.cn 1867 10. References 1869 10.1. Normative References 1871 [I-D.ietf-spring-segment-routing-policy] 1872 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1873 P. Mattes, "Segment Routing Policy Architecture", draft- 1874 ietf-spring-segment-routing-policy-14 (work in progress), 1875 October 2021. 1877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1878 Requirement Levels", BCP 14, RFC 2119, 1879 DOI 10.17487/RFC2119, March 1997, 1880 . 1882 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1883 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1884 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1885 . 1887 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1888 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1889 DOI 10.17487/RFC4271, January 2006, 1890 . 1892 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1893 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1894 February 2006, . 1896 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1897 "Multiprotocol Extensions for BGP-4", RFC 4760, 1898 DOI 10.17487/RFC4760, January 2007, 1899 . 1901 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1902 Patel, "Revised Error Handling for BGP UPDATE Messages", 1903 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1904 . 1906 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1907 Writing an IANA Considerations Section in RFCs", BCP 26, 1908 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1909 . 1911 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1912 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1913 May 2017, . 1915 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1916 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1917 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1918 July 2018, . 1920 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1921 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1922 Routing with the MPLS Data Plane", RFC 8660, 1923 DOI 10.17487/RFC8660, December 2019, 1924 . 1926 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1927 and J. Hardwick, "Path Computation Element Communication 1928 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1929 DOI 10.17487/RFC8664, December 2019, 1930 . 1932 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1933 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1934 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1935 . 1937 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1938 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1939 (SRv6) Network Programming", RFC 8986, 1940 DOI 10.17487/RFC8986, February 2021, 1941 . 1943 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 1944 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 1945 DOI 10.17487/RFC9012, April 2021, 1946 . 1948 10.2. Informational References 1950 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1951 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1952 . 1954 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1955 Reflection: An Alternative to Full Mesh Internal BGP 1956 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1957 . 1959 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1960 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1961 and Authentication for Routing Protocols (KARP) Design 1962 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1963 . 1965 Authors' Addresses 1967 Stefano Previdi 1968 Huawei Technologies 1969 IT 1971 Email: stefano@previdi.net 1973 Clarence Filsfils 1974 Cisco Systems 1975 Brussels 1976 BE 1978 Email: cfilsfil@cisco.com 1980 Ketan Talaulikar (editor) 1981 Cisco Systems 1982 India 1984 Email: ketant.ietf@gmail.com 1985 Paul Mattes 1986 Microsoft 1987 One Microsoft Way 1988 Redmond, WA 98052 1989 USA 1991 Email: pamattes@microsoft.com 1993 Dhanendra Jain 1994 Google 1996 Email: dhanendra.ietf@gmail.com 1998 Steven Lin 1999 Google 2001 Email: stevenlin@google.com