idnits 2.17.1 draft-ietf-idr-segment-routing-te-policy-13.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 7, 2021) is 1054 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-13 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: December 9, 2021 K. Talaulikar, Ed. 6 Cisco Systems 7 P. Mattes 8 Microsoft 9 E. Rosen 10 Juniper Networks 11 D. Jain 12 S. Lin 13 Google 14 June 7, 2021 16 Advertising Segment Routing Policies in BGP 17 draft-ietf-idr-segment-routing-te-policy-13 19 Abstract 21 This document defines a new BGP SAFI with a new NLRI to advertise a 22 candidate path of a Segment Routing (SR) Policy. An SR Policy is a 23 set of candidate paths, each consisting of one or more segment lists. 24 The headend of an SR Policy may learn multiple candidate paths for an 25 SR Policy. Candidate paths may be learned via several different 26 mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document 27 specifies how BGP may be used to distribute SR Policy candidate 28 paths. New sub-TLVs for the Tunnel Encapsulation Attribute are 29 defined for signaling information about these candidate paths. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 9, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 67 2. SR Policy Encoding . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. SR Policy SAFI and NLRI . . . . . . . . . . . . . . . . . 5 69 2.2. SR Policy and Tunnel Encapsulation Attribute . . . . . . 7 70 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 71 2.4. SR Policy Sub-TLVs . . . . . . . . . . . . . . . . . . . 9 72 2.4.1. Preference Sub-TLV . . . . . . . . . . . . . . . . . 9 73 2.4.2. Binding SID Sub-TLV . . . . . . . . . . . . . . . . . 10 74 2.4.3. SRv6 Binding SID Sub-TLV . . . . . . . . . . . . . . 11 75 2.4.4. Segment List Sub-TLV . . . . . . . . . . . . . . . . 13 76 2.4.5. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 28 77 2.4.6. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 29 78 2.4.7. Policy Candidate Path Name Sub-TLV . . . . . . . . . 30 79 2.4.8. Policy Name Sub-TLV . . . . . . . . . . . . . . . . . 31 80 3. Color Extended Community . . . . . . . . . . . . . . . . . . 32 81 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 32 82 4.1. Advertisement of SR Policies . . . . . . . . . . . . . . 32 83 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 33 84 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 33 85 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 33 86 4.2.3. Passing a usable SR Policy NLRI to the SRPM . . . . . 34 87 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 34 88 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 35 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 90 6.1. Existing Registry: Subsequent Address Family Identifiers 91 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 36 92 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute 93 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 36 94 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute 95 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 37 97 6.4. Existing Registry: Color Extended Community Flags . . . . 37 98 6.5. New Registry: SR Policy Segment List Sub-TLVs . . . . . . 37 99 6.6. New Registry: SR Policy Binding SID Flags . . . . . . . . 38 100 6.7. New Registry: SR Policy SRv6 Binding SID Flags . . . . . 38 101 6.8. New Registry: SR Policy Segment Flags . . . . . . . . . . 39 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 103 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 104 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 106 10.1. Normative References . . . . . . . . . . . . . . . . . . 41 107 10.2. Informational References . . . . . . . . . . . . . . . . 43 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 110 1. Introduction 112 Segment Routing (SR) [RFC8402] allows a headend node to steer a 113 packet flow along any path. Intermediate per-path states are 114 eliminated thanks to source routing. 116 The headend node is said to steer a flow into an SR Policy [RFC8402]. 118 The packets steered into an SR Policy carry an ordered list of 119 segments associated with that SR Policy. 121 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 122 Policy and steering into an SR Policy. These apply equally to the 123 SR-MPLS and Segment Routing for IPv6 (SRv6) data-plane instantiations 124 of Segment Routing using SR-MPLS and SRv6 Segment Identifiers (SIDs) 125 as described in [RFC8402]. [RFC8660] describes the representation 126 and processing of this ordered list of segments as MPLS label stack 127 for SR-MPLS. While [RFC8754] and [RFC8986] describe the same for 128 SRv6 with the use of the Segment Routing Header (SRH). 130 The SR Policy related functionality described in 131 [I-D.ietf-spring-segment-routing-policy] can be conceptually viewed 132 as being incorporated in an SR Policy Module (SRPM). Following is a 133 reminder of the high-level functionality of SRPM: 135 o Learning multiple candidate paths for an SR Policy via various 136 mechanisms (CLI, NetConf, PCEP or BGP). 138 o Selection of the best candidate path for an SR Policy. 140 o Binding BSID to the selected candidate path of an SR Policy. 142 o Installation of the selected candidate path and its BSID in the 143 forwarding plane. 145 This document specifies the way to use BGP to distribute one or more 146 of the candidate paths of an SR Policy to the headend of that policy. 147 The document describes the functionality provided by BGP and, as 148 appropriate, provides references for the functionality which is 149 outside the scope of BGP (i.e. resides within SRPM on the headend 150 node). 152 This document specifies a way of representing SR Policy candidate 153 paths in BGP UPDATE messages. BGP can then be used to propagate the 154 SR Policy candidate paths to the headend nodes in the network. The 155 usual BGP rules for BGP propagation and best-path selection are used. 156 At the headend of a specific policy, this will result in one or more 157 candidate paths being installed into the "BGP table". These paths 158 are then passed to the SRPM. The SRPM may compare them to candidate 159 paths learned via other mechanisms and will choose one or more paths 160 to be installed in the data plane. BGP itself does not install SR 161 Policy candidate paths into the data plane. 163 This document defines a new BGP address family (SAFI). In UPDATE 164 messages of that address family, the NLRI identifies an SR Policy 165 Candidate Path while the attributes encode the segment lists and 166 other details of that SR Policy Candidate Path. 168 While for simplicity we may write that BGP advertises an SR Policy, 169 it has to be understood that BGP advertises a candidate path of an SR 170 policy and that this SR Policy might have several other candidate 171 paths provided via BGP (via an NLRI with a different distinguisher as 172 defined in this document), PCEP, NETCONF, or local policy 173 configuration. 175 Typically, a controller defines the set of policies and advertise 176 them to policy head-end routers (typically ingress routers). The 177 policy advertisement uses BGP extensions defined in this document. 178 The policy advertisement is, in most but not all of the cases, 179 tailored for a specific policy head-end. In this case, the 180 advertisement may be sent on a BGP session to that head-end and not 181 propagated any further. 183 Alternatively, a router (i.e., a BGP egress router) advertises SR 184 Policies representing paths to itself. In this case, it is possible 185 to send the policy to each head-end over a BGP session to that head- 186 end, without requiring any further propagation of the policy. 188 An SR Policy intended only for the receiver will, in most cases, not 189 traverse any Route Reflector (RR, [RFC4456]). 191 In some situations, it is undesirable for a controller or BGP egress 192 router to have a BGP session to each policy head-end. In these 193 situations, BGP Route Reflectors may be used to propagate the 194 advertisements, or it may be necessary for the advertisement to 195 propagate through a sequence of one or more AS. To make this 196 possible, an attribute needs to be attached to the advertisement that 197 enables a BGP speaker to determine whether it is intended to be a 198 head-end for the advertised policy. This is done by attaching one or 199 more Route Target Extended Communities to the advertisement 200 ([RFC4360]). 202 The BGP extensions for the advertisement of SR Policies include 203 following components: 205 o A new Subsequent Address Family Identifier (SAFI) whose NLRI 206 identifies an SR Policy candidate path. 208 o A new Tunnel Type identifier for SR Policy, and a set of sub-TLVs 209 to be inserted into the Tunnel Encapsulation Attribute (as defined 210 in [RFC9012]) specifying segment lists of the SR Policy candidate 211 path, as well as other information about the SR Policy. 213 o One or more IPv4 address format route target extended community 214 ([RFC4360]) attached to the SR Policy advertisement and that 215 indicates the intended head-end of such SR Policy advertisement. 217 o The Color Extended Community (as defined in [RFC9012]) and used in 218 order to steer traffic into an SR Policy, as described in section 219 8.4 in [I-D.ietf-spring-segment-routing-policy]. This document 220 (Section 3) modifies the format of the Color Extended Community by 221 using the two leftmost bits of the RESERVED field. 223 1.1. Requirements Language 225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 227 "OPTIONAL" in this document are to be interpreted as described in BCP 228 14 [RFC2119] [RFC8174] when, and only when, they appear in all 229 capitals, as shown here. 231 2. SR Policy Encoding 233 2.1. SR Policy SAFI and NLRI 235 A new SAFI is defined: the SR Policy SAFI with codepoint 73. The AFI 236 used MUST be IPv4(1) or IPv6(2). 238 The SR Policy SAFI uses a new NLRI defined as follows: 240 +------------------+ 241 | NLRI Length | 1 octet 242 +------------------+ 243 | Distinguisher | 4 octets 244 +------------------+ 245 | Policy Color | 4 octets 246 +------------------+ 247 | Endpoint | 4 or 16 octets 248 +------------------+ 250 where: 252 o NLRI Length: 1 octet of length expressed in bits as defined in 253 [RFC4760]. When AFI = 1 value MUST be 96 and when AFI = 2 value 254 MUST be 192. 256 o Distinguisher: 4-octet value uniquely identifying the policy in 257 the context of tuple. The distinguisher has no 258 semantic value and is solely used by the SR Policy originator to 259 make unique (from an NLRI perspective) both for multiple candidate 260 paths of the same SR Policy as well as candidate paths of 261 different SR Policies (i.e. with different segment list) with the 262 same Color and Endpoint but meant for different head-ends. 264 o Policy Color: 4-octet value identifying (with the endpoint) the 265 policy. The color is used to match the color of the destination 266 prefixes to steer traffic into the SR Policy as specified in 267 [I-D.ietf-spring-segment-routing-policy]. 269 o Endpoint: identifies the endpoint of a policy. The Endpoint may 270 represent a single node or a set of nodes (e.g., an anycast 271 address). The Endpoint is an IPv4 (4-octet) address or an IPv6 272 (16-octet) address according to the AFI of the NLRI. 274 The color and endpoint are used to automate the steering of BGP 275 Payload prefixes on SR Policy as described in 276 [I-D.ietf-spring-segment-routing-policy]. 278 The NLRI containing the SR Policy candidate path is carried in a BGP 279 UPDATE message [RFC4271] using BGP multi-protocol extensions 280 [RFC4760] with an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of 73. 282 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 283 attribute with the SR Policy SAFI MUST also carry the BGP mandatory 284 attributes. In addition, the BGP update message MAY also contain any 285 of the BGP optional attributes. 287 The next-hop network address field in SR Policy SAFI (73) updates may 288 be either a 4 octet IPv4 address or a 16 octet IPv6 address, 289 independent of the SR Policy AFI. The length field of the next-hop 290 address specifies the next-hop address family. If the next-hop 291 length is 4, then the next-hop is an IPv4 address; if the next-hop 292 length is 16, then it is a global IPv6 address; if the next-hop 293 length is 32, then it has a global IPv6 address followed by a link- 294 local IPv6 address. The setting of the next-hop field and its 295 attendant processing is governed by standard BGP procedures as 296 described in section 3 in [RFC4760]. 298 It is important to note that any BGP speaker receiving a BGP message 299 with an SR Policy NLRI, will process it only if the NLRI is among the 300 best-paths as per the BGP best-path selection algorithm. In other 301 words, this document leverages the existing BGP propagation and best- 302 path selection rules. Details of the procedures are described in 303 Section 4. 305 It has to be noted that if several candidate paths of the same SR 306 Policy (endpoint, color) are signaled via BGP to a head-end, it is 307 RECOMMENDED that each NLRI uses a different distinguisher. If BGP 308 has installed into the BGP table two advertisements whose respective 309 NLRIs have the same color and endpoint, but different distinguishers, 310 both advertisements are passed to the SRPM as different candidate 311 paths along with their respective originator information (i.e. ASN 312 and BGP Router-ID) as described in section 2.4 of 313 [I-D.ietf-spring-segment-routing-policy]. The ASN would be the ASN 314 of origin and the BGP Router-ID is determined in the following order: 316 o From the Route Origin Community [RFC4360] if present and carrying 317 an IP Address 319 o As the BGP Originator ID [RFC4456] if present 321 o As the BGP Router-ID of the peer from which the update was 322 received as a last resort. 324 2.2. SR Policy and Tunnel Encapsulation Attribute 326 The content of the SR Policy Candidate Path is encoded in the Tunnel 327 Encapsulation Attribute defined in [RFC9012] using a new Tunnel-Type 328 called SR Policy Type with codepoint 15. 330 The SR Policy Encoding structure is as follows: 332 SR Policy SAFI NLRI: 333 Attributes: 334 Tunnel Encaps Attribute (23) 335 Tunnel Type: SR Policy 336 Binding SID 337 SRv6 Binding SID 338 Preference 339 Priority 340 Policy Name 341 Policy Candidate Path Name 342 Explicit NULL Label Policy (ENLP) 343 Segment List 344 Weight 345 Segment 346 Segment 347 ... 348 ... 349 where: 351 o SR Policy SAFI NLRI is defined in Section 2.1. 353 o Tunnel Encapsulation Attribute is defined in [RFC9012]. 355 o Tunnel-Type is set to 15. 357 o Preference, Binding SID, SRv6 Binding SID, Priority, Policy Name, 358 Policy Candidate Path Name, ENLP, Segment-List, Weight, and 359 Segment sub-TLVs are defined in this document. 361 o Additional sub-TLVs may be defined in the future. 363 A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV 364 of type "SR Policy". 366 2.3. Remote Endpoint and Color 368 The Remote Endpoint and Color sub-TLVs, as defined in [RFC9012], MAY 369 also be present in the SR Policy encodings. 371 The Remote Endpoint and Color Sub-TLVs of the Tunnel Encapsulation 372 Attribute are not used for SR Policy encodings and therefore their 373 value is irrelevant in the context of the SR Policy SAFI NLRI. If 374 present, the Remote Endpoint sub-TLV and the Color sub-TLV MUST be 375 ignored by the BGP speaker. 377 2.4. SR Policy Sub-TLVs 379 This section specifies the sub-TLVs defined for encoding the 380 information about the SR Policy Candidate Path. 382 Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority, 383 Policy Name, Policy Candidate Path Name, and Explicit NULL Label 384 Policy are the new sub-TLVs of the BGP Tunnel Encapsulation Attribute 385 [RFC9012] being defined in this section. 387 Weight and Segment are sub-TLVs of the new Segment-List sub-TLV 388 mentioned above. 390 None of the sub-TLVs defined in the following sub-sections have any 391 effect on the BGP best-path selection or propagation procedures. 392 These sub-TLVs are not used by BGP and are instead passed on to SRPM 393 as SR Policy Candidate Path information for further processing 394 described in [I-D.ietf-spring-segment-routing-policy] . 396 2.4.1. Preference Sub-TLV 398 The Preference sub-TLV is used to carry the preference of the SR 399 Policy candidate path. The contents of this sub-TLV are used by the 400 SRPM as described in section 2.7 in 401 [I-D.ietf-spring-segment-routing-policy]. 403 The Preference sub-TLV is optional and it MUST NOT appear more than 404 once in the SR Policy encoding. 406 The Preference sub-TLV has following format: 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type | Length | Flags | RESERVED | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Preference (4 octets) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 where: 418 o Type: 12 420 o Length: 6. 422 o Flags: 1 octet of flags. None are defined at this stage. Flags 423 SHOULD be set to zero on transmission and MUST be ignored on 424 receipt. 426 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 427 transmission and MUST be ignored on receipt. 429 o Preference: a 4-octet value. 431 2.4.2. Binding SID Sub-TLV 433 The Binding SID sub-TLV is used to signal the binding SID related 434 information of the SR Policy candidate path. The contents of this 435 sub-TLV are used by the SRPM as described in section 6 in 436 [I-D.ietf-spring-segment-routing-policy]. 438 The Binding SID sub-TLV is optional and it MUST NOT appear more than 439 once in the SR Policy encoding. 441 When the Binding SID sub-TLV is used to signal an SRv6 SID, the 442 choice of its SRv6 Endpoint Behavior [RFC8986] to be instantiated is 443 left to the headend node. It is RECOMMENDED that the SRv6 Binding 444 SID sub-TLV defined in Section 2.4.3, that enables the specification 445 of the SRv6 Endpoint Behavior, be used for signaling of an SRv6 446 Binding SID for an SR Policy candidate path. 448 The Binding SID sub-TLV has the following format: 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Type | Length | Flags | RESERVED | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Binding SID (variable, optional) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 where: 460 o Type: 13 462 o Length: specifies the length of the value field not including Type 463 and Length fields. Can be 2 or 6 or 18. 465 o Flags: 1 octet of flags. Following flags are defined in the new 466 registry "SR Policy Binding SID Flags" as described in 467 Section 6.6: 469 0 1 2 3 4 5 6 7 470 +-+-+-+-+-+-+-+-+ 471 |S|I| | 472 +-+-+-+-+-+-+-+-+ 473 where: 475 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 476 It is used by SRPM as described in section 6.2.3 in 477 [I-D.ietf-spring-segment-routing-policy]. 479 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 480 is used by SRPM as described in section 8.2 in 481 [I-D.ietf-spring-segment-routing-policy]. 483 * Unused bits in the Flag octet SHOULD be set to zero upon 484 transmission and MUST be ignored upon receipt. 486 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 487 transmission and MUST be ignored on receipt. 489 o Binding SID: if the length is 2, then no Binding SID is present. 490 If the length is 6 then the Binding SID is encoded in 4 octets 491 using the format below. TC, S, TTL (Total of 12 bits) are 492 RESERVED and SHOULD be set to zero and MUST be ignored. 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Label | TC |S| TTL | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 If the length is 18 then the Binding SID contains a 16-octet SRv6 501 SID. 503 2.4.3. SRv6 Binding SID Sub-TLV 505 The SRv6 Binding SID sub-TLV is used to signal the SRv6 Binding SID 506 related information of the SR Policy candidate path. It enables the 507 specification of the SRv6 Endpoint Behavior [RFC8986] to be 508 instantiated on the headend node. The contents of this sub-TLV are 509 used by the SRPM as described in section 6 in 510 [I-D.ietf-spring-segment-routing-policy]. 512 The SRv6 Binding SID sub-TLV is optional. More than one SRv6 Binding 513 SIDs MAY be signaled in the same SR Policy encoding to indicate one 514 or more SRv6 SIDs, each with potentially different SRv6 Endpoint 515 Behaviors to be instantiated. 517 The SRv6 Binding SID sub-TLV has the following format: 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Type | Length | Flags | RESERVED | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | SRv6 Binding SID (16 octets) | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 // SRv6 Endpoint Behavior and SID Structure (optional) // 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 where: 531 o Type: TBD 533 o Length is variable 535 o Flags: 1 octet of flags. Following flags are defined in the new 536 registry "SR Policy Binding SID Flags" as described in 537 Section 6.7: 539 0 1 2 3 4 5 6 7 540 +-+-+-+-+-+-+-+-+ 541 |S|I|B| | 542 +-+-+-+-+-+-+-+-+ 544 where: 546 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 547 It is used by SRPM as described in section 6.2.3 in 548 [I-D.ietf-spring-segment-routing-policy]. 550 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 551 is used by SRPM as described in section 8.2 in 552 [I-D.ietf-spring-segment-routing-policy]. 554 * B-Flag: This flag, when set, indicates the presence of the SRv6 555 Endpoint Behavior and SID Structure encoding specified in 556 Section 2.4.4.2.13. 558 * Unused bits in the Flag octet SHOULD be set to zero upon 559 transmission and MUST be ignored upon receipt. 561 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 562 transmission and MUST be ignored on receipt. 564 o SRv6 Binding SID: Contains a 16-octet SRv6 SID. 566 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 567 Section 2.4.4.2.13. 569 2.4.4. Segment List Sub-TLV 571 The Segment List sub-TLV encodes a single explicit path towards the 572 endpoint as described in section 5.1 in 573 [I-D.ietf-spring-segment-routing-policy]. The Segment List sub-TLV 574 includes the elements of the paths (i.e., segments) as well as an 575 optional Weight sub-TLV. 577 The Segment List sub-TLV may exceed 255 bytes length due to large 578 number of segments. Therefore a 2-octet length is required. 579 According to [RFC9012], the first bit of the sub-TLV codepoint 580 defines the size of the length field. Therefore, for the Segment 581 List sub-TLV a code point of 128 or higher is used. 583 The Segment List sub-TLV is optional and MAY appear multiple times in 584 the SR Policy encoding. The ordering of Segment List sub-TLVs, each 585 sub-TLV encoding a Segment List, does not matter. 587 The Segment List sub-TLV contains zero or more Segment sub-TLVs and 588 MAY contain a Weight sub-TLV. 590 The Segment List sub-TLV has the following format: 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type | Length | RESERVED | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 // sub-TLVs // 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 where: 602 o Type: 128. 604 o Length: the total length (not including the Type and Length 605 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 607 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 608 transmission and MUST be ignored on receipt. 610 o sub-TLVs currently defined: 612 * An optional single Weight sub-TLV. 614 * Zero or more Segment sub-TLVs. 616 Validation of an explicit path encoded by the Segment List sub-TLV is 617 beyond the scope of BGP and performed by the SRPM as described in 618 section 5 in [I-D.ietf-spring-segment-routing-policy]. 620 2.4.4.1. Weight Sub-TLV 622 The Weight sub-TLV specifies the weight associated with a given 623 segment list. The contents of this sub-TLV are used only by the SRPM 624 as described in section 2.11 in 625 [I-D.ietf-spring-segment-routing-policy]. 627 The Weight sub-TLV is optional and it MUST NOT appear more than once 628 inside the Segment List sub-TLV. 630 The Weight sub-TLV has the following format: 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Type | Length | Flags | RESERVED | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Weight | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 where: 642 o Type: 9. 644 o Length: 6 646 o Flags: 1 octet of flags. None are defined at this stage. Flags 647 SHOULD be set to zero on transmission and MUST be ignored on 648 receipt. 650 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 651 transmission and MUST be ignored on receipt. 653 2.4.4.2. Segment Sub-TLVs 655 A Segment sub-TLV describes a single segment in a segment list (i.e., 656 a single element of the explicit path). One or more Segment sub-TLVs 657 constitute an explicit path of the SR Policy candidate path. The 658 contents of these sub-TLVs are used only by the SRPM as described in 659 section 4 in [I-D.ietf-spring-segment-routing-policy]. 661 The Segment sub-TLVs are optional and MAY appear multiple times in 662 the Segment List sub-TLV. 664 [I-D.ietf-spring-segment-routing-policy] defines several Segment 665 Types: 667 Type A: SID only, in the form of MPLS Label 668 Type B: SID only, in the form of IPv6 address 669 Type C: IPv4 Node Address with optional SID 670 Type D: IPv6 Node Address with optional SID for SR MPLS 671 Type E: IPv4 Address and index with optional SID 672 Type F: IPv4 Local and Remote addresses with optional SID 673 Type G: IPv6 Address and index for local and remote pair with optional 674 SID for SR MPLS 675 Type H: IPv6 Local and Remote addresses with optional SID for SR MPLS 676 Type I: IPv6 Node Address with optional SID for SRv6 677 Type J: IPv6 Address and index for local and remote pair with optional 678 SID for SRv6 679 Type K: IPv6 Local and Remote addresses 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. Type A: SID only, in the form of MPLS Label 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. Type B: SID only, in the form of IPv6 address 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. Type C: IPv4 Node Address with optional SID 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. Type D: IPv6 Node Address with optional SID for SR MPLS 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. Type E: IPv4 Address + Local Interface ID with optional SID 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. Type F: IPv4 Local and Remote addresses with optional SID 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. Type G: IPv6 Address + Interface ID for local and remote 916 pair with optional SID for SR MPLS 918 The Type G Segment Sub-TLV encodes an IPv6 link-local adjacency with 919 IPv6 local node address, a local interface identifier (Local 920 Interface ID), IPv6 remote node address, a remote interface 921 identifier (Remote Interface ID), and an optional SR-MPLS SID. The 922 format is as follows: 924 0 1 2 3 925 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 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Type | Length | Flags | RESERVED | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Local Interface ID (4 octets) | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 // IPv6 Local Node Address (16 octets) // 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Remote Interface ID (4 octets) | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 // IPv6 Remote Node Address (16 octets) // 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | SR-MPLS SID (optional, 4 octets) | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 where: 942 o Type: 7 944 o Length is 46 when the SR-MPLS SID is present else is 42. 946 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 948 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 949 transmission and MUST be ignored on receipt. 951 o Local Interface ID: 4 octets of interface index as defined in 952 [RFC8664]. 954 o IPv6 Local Node Address: a 16 octet IPv6 address. 956 o Remote Interface ID: 4 octets of interface index as defined in 957 [RFC8664]. The value MAY be set to zero when the local node 958 address and interface identifiers are sufficient to describe the 959 link. 961 o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY 962 be set to zero when the local node address and interface 963 identifiers are sufficient to describe the link. 965 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 966 TTL as defined in Section 2.4.4.2.1. 968 2.4.4.2.8. Type H: IPv6 Local and Remote addresses with optional SID 969 for SR MPLS 971 The Type H Segment Sub-TLV encodes an adjacency local address, an 972 adjacency remote address, and an optional SR-MPLS SID. The format is 973 as follows: 975 0 1 2 3 976 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 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Type | Length | Flags | RESERVED | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 // Local IPv6 Address (16 octets) // 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 // Remote IPv6 Address (16 octets) // 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | SR-MPLS SID (optional, 4 octets) | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 where: 989 o Type: 8 991 o Length is 38 when the SR-MPLS SID is present else is 34. 993 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 995 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 996 transmission and MUST be ignored on receipt. 998 o Local IPv6 Address: a 16 octet IPv6 address. 1000 o Remote IPv6 Address: a 16 octet IPv6 address. 1002 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 1003 TTL as defined in Section 2.4.4.2.1. 1005 2.4.4.2.9. Type I: IPv6 Node Address with optional SRv6 SID 1007 The Type I Segment Sub-TLV encodes an IPv6 node address, SR 1008 Algorithm, and an optional SRv6 SID. The format is as follows: 1010 0 1 2 3 1011 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 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Type | Length | Flags | SR Algorithm | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 // IPv6 Node Address (16 octets) // 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 // SRv6 SID (optional, 16 octets) // 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 // SRv6 Endpoint Behavior and SID Structure (optional) // 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 where: 1024 o Type: 14 1026 o Length is variable. 1028 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1030 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1031 section 3.1.1 in [RFC8402] when A-Flag as defined in 1032 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1033 described in section 4 in 1034 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1035 encoded, this field SHOULD be set to zero on transmission and MUST 1036 be ignored on receipt. 1038 o IPv6 Node Address: a 16 octet IPv6 address. 1040 o SRv6 SID: optional, a 16 octet IPv6 address. 1042 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1043 Section 2.4.4.2.13. 1045 The TLV 10 defined for the advertisement of Segment Type I in the 1046 earlier versions of this document has been deprecated to avoid 1047 backward compatibility issues. 1049 2.4.4.2.10. Type J: IPv6 Address + Interface ID for local and remote 1050 pair for SRv6 with optional SID 1052 The Type J Segment Sub-TLV encodes an IPv6 link-local adjacency with 1053 local node address, a local interface identifier (Local Interface 1054 ID), remote IPv6 node address, a remote interface identifier (Remote 1055 Interface ID), and an optional SRv6 SID. The format is as follows: 1057 0 1 2 3 1058 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 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Type | Length | Flags | SR Algorithm | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Local Interface ID (4 octets) | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 // IPv6 Local Node Address (16 octets) // 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Remote Interface ID (4 octets) | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 // IPv6 Remote Node Address (16 octets) // 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 // SRv6 SID (optional, 16 octets) // 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 // SRv6 Endpoint Behavior and SID Structure (optional) // 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 where: 1077 o Type: 15 1079 o Length is variable. 1081 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1083 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1084 section 3.1.1 in [RFC8402] when A-Flag as defined in 1085 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1086 described in section 4 in 1087 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1088 encoded, this field SHOULD be set to zero on transmission and MUST 1089 be ignored on receipt. 1091 o Local Interface ID: 4 octets of interface index as defined in 1092 [RFC8664]. 1094 o IPv6 Local Node Address: a 16 octet IPv6 address. 1096 o Remote Interface ID: 4 octets of interface index as defined in 1097 [RFC8664]. The value MAY be set to zero when the local node 1098 address and interface identifiers are sufficient to describe the 1099 link. 1101 o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY 1102 be set to zero when the local node address and interface 1103 identifiers are sufficient to describe the link. 1105 o SRv6 SID: optional, a 16 octet IPv6 address. 1107 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1108 Section 2.4.4.2.13. 1110 The TLV 11 defined for the advertisement of Segment Type J in the 1111 earlier versions of this document has been deprecated to avoid 1112 backward compatibility issues. 1114 2.4.4.2.11. Type K: IPv6 Local and Remote addresses for SRv6 with 1115 optional SID 1117 The Type K Segment Sub-TLV encodes an adjacency local address, an 1118 adjacency remote address, and an optional SRv6 SID. The format is as 1119 follows: 1121 0 1 2 3 1122 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 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Type | Length | Flags | SR Algorithm | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 // Local IPv6 Address (16 octets) // 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 // Remote IPv6 Address (16 octets) // 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 // SRv6 SID (optional, 16 octets) // 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 // SRv6 Endpoint Behavior and SID Structure (optional) // 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 where: 1137 o Type: 16 1139 o Length is variable. 1141 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1143 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1144 section 3.1.1 in [RFC8402] when A-Flag as defined in 1145 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1146 described in section 4 in 1147 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1148 encoded, this field SHOULD be set to zero on transmission and MUST 1149 be ignored on receipt. 1151 o Local IPv6 Address: a 16 octet IPv6 address. 1153 o Remote IPv6 Address: a 16 octet IPv6 address. 1155 o SRv6 SID: optional, a 16 octet IPv6 address. 1157 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1158 Section 2.4.4.2.13. 1160 The TLV 12 defined for the advertisement of Segment Type K in the 1161 earlier versions of this document has been deprecated to avoid 1162 backward compatibility issues. 1164 2.4.4.2.12. Segment Flags 1166 The Segment Types sub-TLVs described above MAY contain the following 1167 flags in the "Flags" field defined in Section 6.8: 1169 0 1 2 3 4 5 6 7 1170 +-+-+-+-+-+-+-+-+ 1171 |V|A|S|B| | 1172 +-+-+-+-+-+-+-+-+ 1174 where: 1176 V-Flag: This flag, when set, is used by SRPM for "SID 1177 verification" as described in Section 5.1 in 1178 [I-D.ietf-spring-segment-routing-policy]. 1180 A-Flag: This flag, when set, indicates the presence of SR 1181 Algorithm id in the "SR Algorithm" field applicable to various 1182 Segment Types. SR Algorithm is used by SRPM as described in 1183 section 4 in [I-D.ietf-spring-segment-routing-policy]. 1185 S-Flag: This flag, when set, indicates the presence of the SR-MPLS 1186 or SRv6 SID depending on the segment type. 1188 B-Flag: This flag, when set, indicates the presence of the SRv6 1189 Endpoint Behavior and SID Structure encoding specified in 1190 Section 2.4.4.2.13. 1192 Unused bits in the Flag octet SHOULD be set to zero upon 1193 transmission and MUST be ignored upon receipt. 1195 The following applies to the Segment Flags: 1197 o V-Flag applies to all Segment Types. 1199 o A-Flag applies to Segment Types C, D, I, J, and K. If A-Flag 1200 appears with Segment Types A, B, E, F, G, and H, it MUST be 1201 ignored. 1203 o S-Flag applies to Segment Types C, D, E, F, G, H, I, J, and K. If 1204 S-Flag appears with Segment Types A or B, it MUST be ignored. 1206 o B-Flag applies to Segment Types B, I, J, and K. If B-Flag appears 1207 with Segment Types A, C, D, E, F, G, and H, it MUST be ignored. 1209 2.4.4.2.13. SRv6 SID Endpoint Behavior and Structure 1211 The Segment Types sub-TLVs described above MAY contain the SRv6 1212 Endpoint Behavior and SID Structure [RFC8986] encoding as described 1213 below: 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | Endpoint Behavior | Reserved | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | LB Length | LN Length | Fun. Length | Arg. Length | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 where: 1223 Endpoint Behavior: 2 octets. It carries the SRv6 Endpoint 1224 Behavior code point for this SRv6 SID as defined in section 9.2 of 1225 [RFC8986]. When set with the value 0, the choice of SRv6 Endpoint 1226 Behavior is left to the headend. 1228 Reserved: 2 octets of reserved bits. SHOULD be set to zero on 1229 transmission and MUST be ignored on receipt. 1231 Locator Block Length: 1 octet. SRv6 SID Locator Block length in 1232 bits. 1234 Locator Node Length: 1 octet. SRv6 SID Locator Node length in 1235 bits. 1237 Function Length: 1 octet. SRv6 SID Function length in bits. 1239 Argument Length: 1 octet. SRv6 SID Arguments length in bits. 1241 The total of the locator block, locator node, function, and argument 1242 lengths MUST be less than or equal to 128. 1244 2.4.5. Explicit NULL Label Policy Sub-TLV 1246 To steer an unlabeled IP packet into an SR policy, it is necessary to 1247 create a label stack for that packet, and push one or more labels 1248 onto that stack. 1250 The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate 1251 whether an Explicit NULL Label [RFC3032] must be pushed on an 1252 unlabeled IP packet before any other labels. 1254 If an ENLP Sub-TLV is not present, the decision of whether to push an 1255 Explicit NULL label on a given packet is a matter of local 1256 configuration. 1258 The ENLP sub-TLV is optional and it MUST NOT appear more than once in 1259 the SR Policy encoding. 1261 The contents of this sub-TLV are used by the SRPM as described in 1262 section 4.1 in [I-D.ietf-spring-segment-routing-policy]. 1264 0 1 2 3 1265 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 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | Type | Length | Flags | RESERVED | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | ENLP | 1270 +-+-+-+-+-+-+-+-+ 1272 Where: 1274 Type: 14. 1276 Length: 3. 1278 Flags: 1 octet of flags. None are defined at this stage. Flags 1279 SHOULD be set to zero on transmission and MUST be ignored on 1280 receipt. 1282 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1283 transmission and MUST be ignored on receipt. 1285 ENLP (Explicit NULL Label Policy): Indicates whether Explicit NULL 1286 labels are to be pushed on unlabeled IP packets that are being 1287 steered into a given SR policy. This field has one of the 1288 following values: 1290 0: Reserved. 1292 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1293 packet, but do not push an IPv6 Explicit NULL label on an 1294 unlabeled IPv6 packet. 1296 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 1297 packet, but do not push an IPv4 Explicit NULL label on an 1298 unlabeled IPv4 packet. 1300 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1301 packet, and push an IPv6 Explicit NULL label on an unlabeled 1302 IPv6 packet. 1304 4: Do not push an Explicit NULL label. 1306 5 - 255: Reserved. 1308 The ENLP reserved values may be used for future extensions and 1309 implementations SHOULD ignore the ENLP Sub-TLV with these values. 1310 The behavior signaled in this Sub-TLV MAY be overridden by local 1311 configuration. The section 4.1 of 1312 [I-D.ietf-spring-segment-routing-policy] describes the behavior on 1313 the headend for the handling of the explicit null label. 1315 2.4.6. Policy Priority Sub-TLV 1317 An operator MAY set the Policy Priority sub-TLV to indicate the order 1318 in which the SR policies are re-computed upon topological change. 1319 The contents of this sub-TLV are used by the SRPM as described in 1320 section 2.11 in [I-D.ietf-spring-segment-routing-policy]. 1322 The Priority sub-TLV is optional and it MUST NOT appear more than 1323 once in the SR Policy encoding. 1325 The Priority sub-TLV has following format: 1327 0 1 2 3 1328 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 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | Type | Length | Priority | RESERVED | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 Where: 1335 Type: 15 1337 Length: 2. 1339 Priority: a 1-octet value. 1341 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1342 transmission and MUST be ignored on receipt. 1344 2.4.7. Policy Candidate Path Name Sub-TLV 1346 An operator MAY set the Policy Candidate Path Name sub-TLV to attach 1347 a symbolic name to the SR Policy candidate path. 1349 Usage of Policy Candidate Path Name sub-TLV is described in section 1350 2.6 in [I-D.ietf-spring-segment-routing-policy]. 1352 The Policy Candidate Path Name sub-TLV may exceed 255 bytes length 1353 due to a long name. Therefore a 2-octet length is required. 1354 According to [RFC9012], the first bit of the sub-TLV codepoint 1355 defines the size of the length field. Therefore, for the Policy 1356 Candidate Path Name sub-TLV, a code point of 128 or higher is used. 1358 It is RECOMMENDED that the size of the symbolic name for the 1359 candidate path be limited to 255 bytes. Implementations MAY choose 1360 to truncate long names to 255 bytes when signaling via BGP. 1362 The Policy Candidate Path Name sub-TLV is optional and it MUST NOT 1363 appear more than once in the SR Policy encoding. 1365 The Policy Candidate Path Name sub-TLV has following format: 1367 0 1 2 3 1368 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 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Type | Length | RESERVED | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 // Policy Candidate Path Name // 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 Where: 1377 Type: 129. 1379 Length: Variable. 1381 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1382 transmission and MUST be ignored on receipt. 1384 Policy Candidate Path Name: Symbolic name for the SR Policy 1385 candidate path without a NULL terminator as specified in section 1386 2.6 of [I-D.ietf-spring-segment-routing-policy]. 1388 2.4.8. Policy Name Sub-TLV 1390 An operator MAY set the Policy Name sub-TLV to associate a symbolic 1391 name with the SR Policy for which the candidate path is being 1392 advertised via the SR Policy NLRI. 1394 Usage of Policy Name sub-TLV is described in section 2.1 of 1395 [I-D.ietf-spring-segment-routing-policy]. 1397 The Policy Name sub-TLV may exceed 255 bytes length due to a long 1398 policy name. Therefore a 2-octet length is required. According to 1399 [RFC9012], the first bit of the sub-TLV codepoint defines the size of 1400 the length field. Therefore, for the Policy Name sub-TLV, a code 1401 point of 128 or higher is used. 1403 It is RECOMMENDED that the size of the symbolic name for the SR 1404 Policy be limited to 255 bytes. Implementations MAY choose to 1405 truncate long names to 255 bytes when signaling via BGP. 1407 The Policy Name sub-TLV is optional and it MUST NOT appear more than 1408 once in the SR Policy encoding. 1410 The Policy Name sub-TLV has following format: 1412 0 1 2 3 1413 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 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | Type | Length | RESERVED | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 // Policy Name // 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 Where: 1422 Type: TBD 1424 Length: Variable. 1426 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1427 transmission and MUST be ignored on receipt. 1429 Policy Name: Symbolic name for the policy. It SHOULD be a string 1430 of printable ASCII characters, without a NULL terminator. 1432 3. Color Extended Community 1434 The Color Extended Community as defined in [RFC9012] is used to steer 1435 traffic into a policy. 1437 When the Color Extended Community is used for steering the traffic 1438 into an SR Policy, two bits from the Flags field (as defined in 1439 [RFC9012]) are used as follows: 1441 1 1442 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 |C O| RESERVED | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 where CO bits are defined as the "Color-Only" bits. 1448 [I-D.ietf-spring-segment-routing-policy] defines the influence of 1449 these bits on the automated steering of BGP Payload traffic onto SR 1450 Policies. 1452 4. SR Policy Operations 1454 As described in this document, BGP is not the actual consumer of an 1455 SR Policy NLRI. BGP is in charge of the origination and propagation 1456 of the SR Policy NLRI but its installation and use are outside the 1457 scope of BGP. The details of SR Policy installation and use are 1458 specified in [I-D.ietf-spring-segment-routing-policy]. 1460 4.1. Advertisement of SR Policies 1462 Typically, but not limited to, an SR Policy is computed by a 1463 controller or a path computation engine (PCE) and originated by a BGP 1464 speaker on its behalf. 1466 Multiple SR Policy NLRIs may be present with the same tuple but with different content when these SR policies are 1468 intended for different head-ends. 1470 The distinguisher of each SR Policy NLRI prevents undesired BGP route 1471 selection among these SR Policy NLRIs and allows their propagation 1472 across route reflectors [RFC4456]. 1474 Moreover, one or more route target SHOULD be attached to the 1475 advertisement, where each route target identifies one or more 1476 intended head-ends for the advertised SR Policy update. 1478 If no route target is attached to the SR Policy NLRI, then it is 1479 assumed that the originator sends the SR Policy update directly 1480 (e.g., through a BGP session) to the intended receiver. In such 1481 case, the NO_ADVERTISE community MUST be attached to the SR Policy 1482 update. 1484 4.2. Reception of an SR Policy NLRI 1486 On reception of an SR Policy NLRI, a BGP speaker first determines if 1487 it is acceptable and then if it is usable. 1489 4.2.1. Acceptance of an SR Policy NLRI 1491 When a BGP speaker receives an SR Policy NLRI from a neighbor it MUST 1492 first, determine if it's acceptable. The following rules apply in 1493 addition to the validation described in Section 5: 1495 o The SR Policy NLRI MUST include a distinguisher, color and 1496 endpoint field which implies that the length of the NLRI MUST be 1497 either 12 or 24 octets (depending on the address family of the 1498 endpoint). 1500 o The SR Policy update MUST have either the NO_ADVERTISE community 1501 or at least one route target extended community in IPv4-address 1502 format or both. If a router supporting this specification 1503 receives an SR Policy update with no route target extended 1504 communities and no NO_ADVERTISE community, the update MUST be 1505 considered as malformed. 1507 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1508 Update and MUST have a Tunnel Type TLV set to SR Policy (codepoint 1509 is 15). 1511 A router that receives an SR Policy update that is not valid 1512 according to these criteria MUST treat the update as malformed and 1513 the SR Policy candidate path MUST NOT be passed to the SRPM. 1515 4.2.2. Usable SR Policy NLRI 1517 An SR Policy update that has been determined to be acceptable is 1518 further evaluated for its usability by the receiving node. 1520 An SR Policy NLRI update without any route target extended community 1521 but having the NO_ADVERTISE community is considered usable. 1523 If one or more route targets are present, then at least one route 1524 target MUST match the BGP Identifier of the receiver for the update 1525 to be considered usable. The BGP Identifier is defined in [RFC4271] 1526 as a 4 octet IPv4 address. Therefore, the route target extended 1527 community MUST be of the same format. 1529 If one or more route targets are present and none matches the local 1530 BGP Identifier, then, while the SR Policy NLRI is acceptable, it is 1531 not usable on the receiver node. 1533 When the SR Policy tunnel type includes any sub-TLV that is 1534 unrecognized or unsupported, the update SHOULD NOT be considered 1535 usable. An implementation MAY provide an option for ignoring 1536 unsupported sub-TLVs. 1538 4.2.3. Passing a usable SR Policy NLRI to the SRPM 1540 Once BGP on the receiving node has determined that the SR Policy NLRI 1541 is usable, it passes the SR Policy candidate path to the SRPM. Note 1542 that, along with the candidate path details, BGP also passes the 1543 originator information for breaking ties in the candidate path 1544 selection process as described in section 2.4 in 1545 [I-D.ietf-spring-segment-routing-policy]. 1547 When an update for an SR Policy NLRI results in its becoming 1548 unusable, BGP MUST delete its corresponding SR Policy candidate path 1549 from the SRPM. 1551 The SRPM applies the rules defined in section 2 in 1552 [I-D.ietf-spring-segment-routing-policy] to determine whether the SR 1553 Policy candidate path is valid and to select the best candidate path 1554 among the valid ones for a given SR Policy. 1556 4.2.4. Propagation of an SR Policy 1558 SR Policy NLRIs that have been determined acceptable and valid can be 1559 evaluated for propagation, even the ones that are not usable. 1561 SR Policy NLRIs that have the NO_ADVERTISE community attached to them 1562 MUST NOT be propagated. 1564 By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate 1565 it to any EBGP neighbor. An implementation MAY provide an explicit 1566 configuration to override this and enable propagation of acceptable 1567 SR Policy NLRIs to specific EBGP neighbors. 1569 A BGP node advertises a received SR Policy NLRI to its IBGP neighbors 1570 according to normal IBGP propagation rules. 1572 By default, a BGP node receiving an SR Policy NLRI SHOULD NOT remove 1573 route target extended community before propagation. An 1574 implementation MAY provide support for configuration to filter and/or 1575 remove route target extended community before propagation. 1577 5. Error Handling 1579 This section describes the error handling actions, as described in 1580 [RFC7606], that are to be performed for the handling of BGP update 1581 messages for BGP SR Policy SAFI. 1583 A BGP Speaker MUST perform the following syntactic validation of the 1584 SR Policy NLRI to determine if it is malformed. This includes the 1585 validation of the length of each NLRI and the total length of the 1586 MP_REACH_NLRI and MP_UNREACH_NLRI attributes. 1588 When the error determined allows for the router to skip the malformed 1589 NLRI(s) and continue the processing of the rest of the update 1590 message, then it MUST handle such malformed NLRIs as 'Treat-as- 1591 withdraw'. In other cases, where the error in the NLRI encoding 1592 results in the inability to process the BGP update message (e.g. 1593 length related encoding errors), then the router SHOULD handle such 1594 malformed NLRIs as 'AFI/SAFI disable' when other AFI/SAFI besides SR 1595 Policy are being advertised over the same session. Alternately, the 1596 router MUST perform 'session reset' when the session is only being 1597 used for SR Policy or when it 'AFI/SAFI disable' action is not 1598 possible. 1600 The validation of the TLVs/sub-TLVs introduced in this document and 1601 defined in their respective sub-sections of Section 2.4 MUST be 1602 performed to determine if they are malformed or invalid. The 1603 validation of the Tunnel Encapsulation Attribute itself and the other 1604 TLVs/sub-TLVs specified in [RFC9012] MUST be done as described in 1605 that document. In case of any error detected, either at the 1606 attribute or its TLV/sub-TLV level, the "treat-as-withdraw" strategy 1607 MUST be applied. This is because an SR Policy update without a valid 1608 Tunnel Encapsulation Attribute (comprising of all valid TLVs/sub- 1609 TLVs) is not usable. 1611 An SR Policy update that is determined to be not acceptable, and 1612 therefore malformed, based on rules described in Section 4.2.1 MUST 1613 be handled by the "treat-as-withdraw" strategy. 1615 The validation of the individual fields of the TLVs/sub-TLVs defined 1616 in Section 2.4 are beyond the scope of BGP as they are handled by the 1617 SRPM as described in the individual TLV/sub-TLV sub-sections. A BGP 1618 implementation MUST NOT perform semantic verification of such fields 1619 nor consider the SR Policy update to be invalid or not acceptable/ 1620 usable based on such validation. 1622 An implementation SHOULD log an error for any errors found during the 1623 above validation for further analysis. 1625 6. IANA Considerations 1627 This document requests codepoint allocations in the following 1628 existing registries: 1630 o Subsequent Address Family Identifiers (SAFI) Parameters registry 1632 o BGP Tunnel Encapsulation Attribute Tunnel Types registry under the 1633 BGP Tunnel Encapsulation registry 1635 o BGP Tunnel Encapsulation Attribute sub-TLVs registry under the BGP 1636 Tunnel Encapsulation registry 1638 o Color Extended Community Flags registry under the BGP Tunnel 1639 Encapsulation registry 1641 This document also requests the creation of the following new 1642 registries: 1644 o SR Policy Segment List Sub-TLVs under the BGP Tunnel Encapsulation 1645 registry 1647 o SR Policy Binding SID Flags under the BGP Tunnel Encapsulation 1648 registry 1650 o SR Policy Segment Flags under the BGP Tunnel Encapsulation 1651 registry 1653 6.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1654 Parameters 1656 This document defines a new SAFI in the registry "Subsequent Address 1657 Family Identifiers (SAFI) Parameters" that has been assigned a 1658 codepoint by IANA as follows: 1660 Codepoint Description Reference 1661 ----------------------------------------------- 1662 73 SR Policy SAFI This document 1664 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1666 This document defines a new Tunnel-Type in the registry "BGP Tunnel 1667 Encapsulation Attribute Tunnel Types" that has been assigned a 1668 codepoint by IANA as follows: 1670 Codepoint Description Reference 1671 -------------------------------------------------- 1672 15 SR Policy This document 1674 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1676 This document defines new sub-TLVs in the registry "BGP Tunnel 1677 Encapsulation Attribute sub-TLVs" that has been assigned codepoints 1678 by IANA as follows via the early allocation process: 1680 Codepoint Description Reference 1681 ------------------------------------------------------------ 1682 12 Preference sub-TLV This document 1683 13 Binding SID sub-TLV This document 1684 14 ENLP sub-TLV This document 1685 15 Priority sub-TLV This document 1686 20 SRv6 Binding SID sub-TLV This document 1687 128 Segment List sub-TLV This document 1688 129 Policy Candidate Path Name sub-TLV This document 1689 130 Policy Name sub-TLV This document 1691 6.4. Existing Registry: Color Extended Community Flags 1693 This document requests allocations in the registry called "Color 1694 Extended Community Flags" under the "BGP Tunnel Encapsulation" 1695 registry. 1697 The following bits have been assigned by IANA via the early 1698 allocation process: 1700 Bit 1701 Position Description Reference 1702 ------------------------------------------------------------------ 1703 0-1 Color-only bits This document 1705 6.5. New Registry: SR Policy Segment List Sub-TLVs 1707 This document requests the creation of a new registry called "SR 1708 Policy Segment List Sub-TLVs" under the "BGP Tunnel Encapsulation" 1709 registry. The allocation policy of this registry is "Standards 1710 Action" according to [RFC8126]. 1712 Following initial Sub-TLV codepoints are assigned by this document: 1714 Value Description Reference 1715 ------------------------------------------------------------------------ 1716 0 Reserved This document 1717 1 Type A MPLS SID sub-TLV This document 1718 2 Deprecated This document 1719 3 Type C IPv4 Node and SID sub-TLV This document 1720 4 Type D IPv6 Node and SID for SR-MPLS sub-TLV This document 1721 5 Type E IPv4 Node, index, and SID sub-TLV This document 1722 6 Type F IPv4 Local/Remote addresses and SID sub-TLV This document 1723 7 Type G IPv6 Node, index for remote and local pair, This document 1724 and SID for SR-MPLS sub-TLV 1725 8 Type H IPv6 Local/Remote addresses and SID sub-TLV This document 1726 9 Weight sub-TLV This document 1727 10 Deprecated This document 1728 11 Deprecated This document 1729 12 Deprecated This document 1730 13 Type B SRv6 SID sub-TLV This document 1731 14 Type I IPv6 Node and SID for SRv6 sub-TLV This document 1732 15 Type J IPv6 Node, index for remote and local pair, This document 1733 and SID for SRv6 sub-TLV 1734 16 Type K IPv6 Local/Remote addresses and SID for This document 1735 SRv6 sub-TLV 1736 17-255 Unassigned 1738 6.6. New Registry: SR Policy Binding SID Flags 1740 This document requests the creation of a new registry called "SR 1741 Policy Binding SID Flags" under the "BGP Tunnel Encapsulation" 1742 registry. The allocation policy of this registry is "Standards 1743 Action" according to [RFC8126]. 1745 The following flags are defined: 1747 Bit Description Reference 1748 ----------------------------------------------------------------- 1749 0 Specified-BSID-Only Flag (S-Flag) This document 1750 1 Drop Upon Invalid Flag (I-Flag) This document 1751 2-7 Unassigned 1753 6.7. New Registry: SR Policy SRv6 Binding SID Flags 1755 This document requests the creation of a new registry called "SR 1756 Policy SRv6 Binding SID Flags" under the "BGP Tunnel Encapsulation" 1757 registry. The allocation policy of this registry is "Standards 1758 Action" according to [RFC8126]. 1760 The following flags are defined: 1762 Bit Description Reference 1763 ----------------------------------------------------------------- 1764 0 Specified-BSID-Only Flag (S-Flag) This document 1765 1 Drop Upon Invalid Flag (I-Flag) This document 1766 2 SRv6 Endpoint Behavior & 1767 SID Structure Flag (B-Flag) This document 1768 3-7 Unassigned 1770 6.8. New Registry: SR Policy Segment Flags 1772 This document requests the creation of a new registry called "SR 1773 Policy Segment Flags" under the "BGP Tunnel Encapsulation" registry. 1774 The allocation policy of this registry is "Standards Action" 1775 according to [RFC8126]. 1777 The following Flags are defined: 1779 Bit Description Reference 1780 ------------------------------------------------------------------ 1781 0 Segment Verification Flag (V-Flag) This document 1782 1 SR Algorithm Flag (A-Flag) This document 1783 2 SID Specified Flag (S-Flag) This document 1784 3 SRv6 Endpoint Behavior & 1785 SID Structure Flag (B-Flag) This document 1786 4-7 Unassigned 1788 7. Security Considerations 1790 The security mechanisms of the base BGP security model apply to the 1791 extensions described in this document as well. See the Security 1792 Considerations section of [RFC4271] for a discussion of BGP security. 1793 Also, refer to [RFC4272] and [RFC6952] for analysis of security 1794 issues for BGP. 1796 The BGP SR Policy extensions specified in this document enable 1797 traffic engineering and service programming use-cases within the SR 1798 domain as described in [I-D.ietf-spring-segment-routing-policy]. SR 1799 operates within a trusted SR domain [RFC8402] and its security 1800 considerations also apply to BGP sessions when carrying SR Policy 1801 information. The SR Policies distributed by BGP are expected to be 1802 used entirely within this trusted SR domain i.e. within a single AS 1803 or between multiple AS/domains within a single provider network. 1804 Therefore, precaution is necessary to ensure that the SR Policy 1805 information advertised via BGP sessions is limited to nodes in a 1806 secure manner within this trusted SR domain. BGP peering sessions 1807 for address-families other than SR Policy SAFI may be set up to 1808 routers outside the SR domain. The isolation of BGP SR Policy SAFI 1809 peering sessions may be used to ensure that the SR Policy information 1810 is not advertised by accident or error to an EBGP peering session 1811 outside the SR domain. 1813 Additionally, it may be considered that the export of SR Policy 1814 information, as described in this document, constitutes a risk to 1815 confidentiality of mission-critical or commercially sensitive 1816 information about the network (more specifically endpoint/node 1817 addresses, SR SIDs, and the SR Policies deployed). BGP peerings are 1818 not automatic and require configuration; thus, it is the 1819 responsibility of the network operator to ensure that only trusted 1820 nodes (that include both routers and controller applications) within 1821 the SR domain are configured to receive such information. 1823 8. Acknowledgments 1825 The authors of this document would like to thank Shyam Sethuram, John 1826 Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha, Bruno Decraene, 1827 Gurusiddesh Nidasesi, Kausik Majumdar, Zafar Ali, Swadesh Agarwal, 1828 Jakob Heitz, Viral Patel, Peng Shaofu and Cheng Li for their comments 1829 and review of this document. 1831 9. Contributors 1833 Arjun Sreekantiah 1834 Cisco Systems 1835 US 1837 Email: asreekan@cisco.com 1839 Acee Lindem 1840 Cisco Systems 1841 US 1843 Email: acee@cisco.com 1845 Siva Sivabalan 1846 Cisco Systems 1847 US 1849 Email: msiva@cisco.com 1851 Imtiyaz Mohammad 1852 Arista Networks 1853 India 1855 Email: imtiyaz@arista.com 1856 Gaurav Dawra 1857 Cisco Systems 1858 US 1860 Email: gdawra.ietf@gmail.com 1862 Peng Shaofu 1863 ZTE Corporation 1864 China 1866 Email: peng.shaofu@zte.com.cn 1868 10. References 1870 10.1. Normative References 1872 [I-D.ietf-spring-segment-routing-policy] 1873 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1874 P. Mattes, "Segment Routing Policy Architecture", draft- 1875 ietf-spring-segment-routing-policy-13 (work in progress), 1876 May 2021. 1878 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1879 Requirement Levels", BCP 14, RFC 2119, 1880 DOI 10.17487/RFC2119, March 1997, 1881 . 1883 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1884 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1885 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1886 . 1888 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1889 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1890 DOI 10.17487/RFC4271, January 2006, 1891 . 1893 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1894 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1895 February 2006, . 1897 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1898 "Multiprotocol Extensions for BGP-4", RFC 4760, 1899 DOI 10.17487/RFC4760, January 2007, 1900 . 1902 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1903 Patel, "Revised Error Handling for BGP UPDATE Messages", 1904 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1905 . 1907 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1908 Writing an IANA Considerations Section in RFCs", BCP 26, 1909 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1910 . 1912 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1913 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1914 May 2017, . 1916 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1917 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1918 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1919 July 2018, . 1921 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1922 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1923 Routing with the MPLS Data Plane", RFC 8660, 1924 DOI 10.17487/RFC8660, December 2019, 1925 . 1927 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1928 and J. Hardwick, "Path Computation Element Communication 1929 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1930 DOI 10.17487/RFC8664, December 2019, 1931 . 1933 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1934 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1935 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1936 . 1938 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1939 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1940 (SRv6) Network Programming", RFC 8986, 1941 DOI 10.17487/RFC8986, February 2021, 1942 . 1944 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 1945 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 1946 DOI 10.17487/RFC9012, April 2021, 1947 . 1949 10.2. Informational References 1951 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1952 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1953 . 1955 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1956 Reflection: An Alternative to Full Mesh Internal BGP 1957 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1958 . 1960 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1961 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1962 and Authentication for Routing Protocols (KARP) Design 1963 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1964 . 1966 Authors' Addresses 1968 Stefano Previdi 1969 Huawei Technologies 1970 IT 1972 Email: stefano@previdi.net 1974 Clarence Filsfils 1975 Cisco Systems 1976 Brussels 1977 BE 1979 Email: cfilsfil@cisco.com 1981 Ketan Talaulikar (editor) 1982 Cisco Systems 1983 India 1985 Email: ketant@cisco.com 1987 Paul Mattes 1988 Microsoft 1989 One Microsoft Way 1990 Redmond, WA 98052 1991 USA 1993 Email: pamattes@microsoft.com 1994 Eric Rosen 1995 Juniper Networks 1996 10 Technology Park Drive 1997 Westford, MA 01886 1998 US 2000 Email: erosen@juniper.net 2002 Dhanendra Jain 2003 Google 2005 Email: dhanendra.ietf@gmail.com 2007 Steven Lin 2008 Google 2010 Email: stevenlin@google.com