idnits 2.17.1 draft-ietf-idr-segment-routing-te-policy-17.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 (April 14, 2022) is 742 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi 3 Internet-Draft Huawei Technologies 4 Updates: 9012 (if approved) C. Filsfils 5 Intended status: Standards Track Cisco Systems 6 Expires: October 16, 2022 K. Talaulikar, Ed. 7 Arrcus Inc 8 P. Mattes 9 Microsoft 10 D. Jain 11 S. Lin 12 Google 13 April 14, 2022 15 Advertising Segment Routing Policies in BGP 16 draft-ietf-idr-segment-routing-te-policy-17 18 Abstract 20 This document defines a new BGP SAFI with a new NLRI to advertise a 21 candidate path of a Segment Routing (SR) Policy. An SR Policy is a 22 set of candidate paths, each consisting of one or more segment lists. 23 The headend of an SR Policy may learn multiple candidate paths for an 24 SR Policy. Candidate paths may be learned via several different 25 mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document 26 specifies how BGP may be used to distribute SR Policy candidate 27 paths. New sub-TLVs for the Tunnel Encapsulation Attribute are 28 defined for signaling information about these candidate paths. 30 This documents updates RFC9012 with extensions to the Color Extended 31 Community to support new steering modes over SR Policy. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 16, 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 69 2. SR Policy Encoding . . . . . . . . . . . . . . . . . . . . . 5 70 2.1. SR Policy SAFI and NLRI . . . . . . . . . . . . . . . . . 5 71 2.2. SR Policy and Tunnel Encapsulation Attribute . . . . . . 7 72 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 73 2.4. SR Policy Sub-TLVs . . . . . . . . . . . . . . . . . . . 9 74 2.4.1. Preference Sub-TLV . . . . . . . . . . . . . . . . . 9 75 2.4.2. Binding SID Sub-TLV . . . . . . . . . . . . . . . . . 10 76 2.4.3. SRv6 Binding SID Sub-TLV . . . . . . . . . . . . . . 11 77 2.4.4. Segment List Sub-TLV . . . . . . . . . . . . . . . . 13 78 2.4.5. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 27 79 2.4.6. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 29 80 2.4.7. Policy Candidate Path Name Sub-TLV . . . . . . . . . 30 81 2.4.8. Policy Name Sub-TLV . . . . . . . . . . . . . . . . . 31 82 3. Color Extended Community . . . . . . . . . . . . . . . . . . 32 83 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 33 84 4.1. Advertisement of SR Policies . . . . . . . . . . . . . . 33 85 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 33 86 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 33 87 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 34 88 4.2.3. Passing a usable SR Policy NLRI to the SRPM . . . . . 34 89 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 35 90 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 35 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 92 6.1. Existing Registry: Subsequent Address Family Identifiers 93 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 37 94 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute 95 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 37 96 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute 97 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 37 99 6.4. Existing Registry: Color Extended Community Flags . . . . 38 100 6.5. New Registry: SR Policy Segment List Sub-TLVs . . . . . . 38 101 6.6. New Registry: SR Policy Binding SID Flags . . . . . . . . 39 102 6.7. New Registry: SR Policy SRv6 Binding SID Flags . . . . . 39 103 6.8. New Registry: SR Policy Segment Flags . . . . . . . . . . 40 104 6.9. New Registry: Color Extended Community Color-Only Types . 40 105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41 106 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 107 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 108 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 109 10.1. Normative References . . . . . . . . . . . . . . . . . . 43 110 10.2. Informational References . . . . . . . . . . . . . . . . 44 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 113 1. Introduction 115 Segment Routing (SR) [RFC8402] allows a headend node to steer a 116 packet flow along any path. Intermediate per-path states are 117 eliminated thanks to source routing. 119 The headend node is said to steer a flow into an SR Policy [RFC8402]. 121 The packets steered into an SR Policy carry an ordered list of 122 segments associated with that SR Policy. 124 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 125 Policy and steering into an SR Policy. These apply equally to the 126 SR-MPLS and Segment Routing for IPv6 (SRv6) data-plane instantiations 127 of Segment Routing using SR-MPLS and SRv6 Segment Identifiers (SIDs) 128 as described in [RFC8402]. [RFC8660] describes the representation 129 and processing of this ordered list of segments as MPLS label stack 130 for SR-MPLS. While [RFC8754] and [RFC8986] describe the same for 131 SRv6 with the use of the Segment Routing Header (SRH). 133 The SR Policy related functionality described in 134 [I-D.ietf-spring-segment-routing-policy] can be conceptually viewed 135 as being incorporated in an SR Policy Module (SRPM). Following is a 136 reminder of the high-level functionality of SRPM: 138 o Learning multiple candidate paths for an SR Policy via various 139 mechanisms (CLI, NetConf, PCEP or BGP). 141 o Selection of the best candidate path for an SR Policy. 143 o Binding BSID to the selected candidate path of an SR Policy. 145 o Installation of the selected candidate path and its BSID in the 146 forwarding plane. 148 This document specifies the way to use BGP to distribute one or more 149 of the candidate paths of an SR Policy to the headend of that policy. 150 The document describes the functionality provided by BGP and, as 151 appropriate, provides references for the functionality which is 152 outside the scope of BGP (i.e. resides within SRPM on the headend 153 node). 155 This document specifies a way of representing SR Policy candidate 156 paths in BGP UPDATE messages. BGP can then be used to propagate the 157 SR Policy candidate paths to the headend nodes in the network. The 158 usual BGP rules for BGP propagation and best-path selection are used. 159 At the headend of a specific policy, this will result in one or more 160 candidate paths being installed into the "BGP table". These paths 161 are then passed to the SRPM. The SRPM may compare them to candidate 162 paths learned via other mechanisms and will choose one or more paths 163 to be installed in the data plane. BGP itself does not install SR 164 Policy candidate paths into the data plane. 166 This document defines a new BGP address family (SAFI). In UPDATE 167 messages of that address family, the NLRI identifies an SR Policy 168 Candidate Path while the attributes encode the segment lists and 169 other details of that SR Policy Candidate Path. 171 While for simplicity we may write that BGP advertises an SR Policy, 172 it has to be understood that BGP advertises a candidate path of an SR 173 policy and that this SR Policy might have several other candidate 174 paths provided via BGP (via an NLRI with a different distinguisher as 175 defined in this document), PCEP, NETCONF, or local policy 176 configuration. 178 Typically, a controller defines the set of policies and advertise 179 them to policy head-end routers (typically ingress routers). The 180 policy advertisement uses BGP extensions defined in this document. 181 The policy advertisement is, in most but not all of the cases, 182 tailored for a specific policy head-end. In this case, the 183 advertisement may be sent on a BGP session to that head-end and not 184 propagated any further. 186 Alternatively, a router (i.e., a BGP egress router) advertises SR 187 Policies representing paths to itself. In this case, it is possible 188 to send the policy to each head-end over a BGP session to that head- 189 end, without requiring any further propagation of the policy. 191 An SR Policy intended only for the receiver will, in most cases, not 192 traverse any Route Reflector (RR, [RFC4456]). 194 In some situations, it is undesirable for a controller or BGP egress 195 router to have a BGP session to each policy head-end. In these 196 situations, BGP Route Reflectors may be used to propagate the 197 advertisements, or it may be necessary for the advertisement to 198 propagate through a sequence of one or more AS. To make this 199 possible, an attribute needs to be attached to the advertisement that 200 enables a BGP speaker to determine whether it is intended to be a 201 head-end for the advertised policy. This is done by attaching one or 202 more Route Target Extended Communities to the advertisement 203 ([RFC4360]). 205 The BGP extensions for the advertisement of SR Policies include 206 following components: 208 o A new Subsequent Address Family Identifier (SAFI) whose NLRI 209 identifies an SR Policy candidate path. 211 o A new Tunnel Type identifier for SR Policy, and a set of sub-TLVs 212 to be inserted into the Tunnel Encapsulation Attribute (as defined 213 in [RFC9012]) specifying segment lists of the SR Policy candidate 214 path, as well as other information about the SR Policy. 216 o One or more IPv4 address format route target extended community 217 ([RFC4360]) attached to the SR Policy advertisement and that 218 indicates the intended head-end of such SR Policy advertisement. 220 The Color Extended Community (as defined in [RFC9012]) is used to 221 steer traffic into an SR Policy, as described in section 8.8 of 222 [I-D.ietf-spring-segment-routing-policy]. This document (Section 3) 223 updates [RFC9012] with modifications to the format of the Color 224 Extended Community by using the two leftmost bits of the RESERVED 225 field. 227 1.1. Requirements Language 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 231 "OPTIONAL" in this document are to be interpreted as described in BCP 232 14 [RFC2119] [RFC8174] when, and only when, they appear in all 233 capitals, as shown here. 235 2. SR Policy Encoding 237 2.1. SR Policy SAFI and NLRI 239 A new SAFI is defined: the SR Policy SAFI with codepoint 73. The AFI 240 used MUST be IPv4(1) or IPv6(2). 242 The SR Policy SAFI uses a new NLRI defined as follows: 244 +------------------+ 245 | NLRI Length | 1 octet 246 +------------------+ 247 | Distinguisher | 4 octets 248 +------------------+ 249 | Policy Color | 4 octets 250 +------------------+ 251 | Endpoint | 4 or 16 octets 252 +------------------+ 254 where: 256 o NLRI Length: 1 octet of length expressed in bits as defined in 257 [RFC4760]. When AFI = 1 value MUST be 96 and when AFI = 2 value 258 MUST be 192. 260 o Distinguisher: 4-octet value uniquely identifying the policy in 261 the context of tuple. The distinguisher has no 262 semantic value and is solely used by the SR Policy originator to 263 make unique (from an NLRI perspective) both for multiple candidate 264 paths of the same SR Policy as well as candidate paths of 265 different SR Policies (i.e. with different segment list) with the 266 same Color and Endpoint but meant for different head-ends. 268 o Policy Color: 4-octet value identifying (with the endpoint) the 269 policy. The color is used to match the color of the destination 270 prefixes to steer traffic into the SR Policy as specified in 271 [I-D.ietf-spring-segment-routing-policy]. 273 o Endpoint: identifies the endpoint of a policy. The Endpoint may 274 represent a single node or a set of nodes (e.g., an anycast 275 address). The Endpoint is an IPv4 (4-octet) address or an IPv6 276 (16-octet) address according to the AFI of the NLRI. 278 The color and endpoint are used to automate the steering of BGP 279 Payload prefixes on SR Policy as described in 280 [I-D.ietf-spring-segment-routing-policy]. 282 The NLRI containing the SR Policy candidate path is carried in a BGP 283 UPDATE message [RFC4271] using BGP multi-protocol extensions 284 [RFC4760] with an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of 73. 286 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 287 attribute with the SR Policy SAFI MUST also carry the BGP mandatory 288 attributes. In addition, the BGP update message MAY also contain any 289 of the BGP optional attributes. 291 The next-hop network address field in SR Policy SAFI (73) updates may 292 be either a 4 octet IPv4 address or a 16 octet IPv6 address, 293 independent of the SR Policy AFI. The length field of the next-hop 294 address specifies the next-hop address family. If the next-hop 295 length is 4, then the next-hop is an IPv4 address; if the next-hop 296 length is 16, then it is a global IPv6 address; if the next-hop 297 length is 32, then it has a global IPv6 address followed by a link- 298 local IPv6 address. The setting of the next-hop field and its 299 attendant processing is governed by standard BGP procedures as 300 described in section 3 in [RFC4760]. 302 It is important to note that any BGP speaker receiving a BGP message 303 with an SR Policy NLRI, will process it only if the NLRI is among the 304 best-paths as per the BGP best-path selection algorithm. In other 305 words, this document leverages the existing BGP propagation and best- 306 path selection rules. Details of the procedures are described in 307 Section 4. 309 It has to be noted that if several candidate paths of the same SR 310 Policy (endpoint, color) are signaled via BGP to a head-end, it is 311 RECOMMENDED that each NLRI uses a different distinguisher. If BGP 312 has installed into the BGP table two advertisements whose respective 313 NLRIs have the same color and endpoint, but different distinguishers, 314 both advertisements are passed to the SRPM as different candidate 315 paths along with their respective originator information (i.e. ASN 316 and BGP Router-ID) as described in section 2.4 of 317 [I-D.ietf-spring-segment-routing-policy]. The ASN would be the ASN 318 of origin and the BGP Router-ID is determined in the following order: 320 o From the Route Origin Community [RFC4360] if present and carrying 321 an IP Address 323 o As the BGP Originator ID [RFC4456] if present 325 o As the BGP Router-ID of the peer from which the update was 326 received as a last resort. 328 2.2. SR Policy and Tunnel Encapsulation Attribute 330 The content of the SR Policy Candidate Path is encoded in the Tunnel 331 Encapsulation Attribute defined in [RFC9012] using a new Tunnel-Type 332 called SR Policy Type with codepoint 15. The use of SR Policy 333 Tunnel-type is applicable only for the AFI/SAFI pairs of (1/73, 334 2/73). 336 The SR Policy Encoding structure is as follows: 338 SR Policy SAFI NLRI: 339 Attributes: 340 Tunnel Encaps Attribute (23) 341 Tunnel Type: SR Policy 342 Binding SID 343 SRv6 Binding SID 344 Preference 345 Priority 346 Policy Name 347 Policy Candidate Path Name 348 Explicit NULL Label Policy (ENLP) 349 Segment List 350 Weight 351 Segment 352 Segment 353 ... 354 ... 355 where: 357 o SR Policy SAFI NLRI is defined in Section 2.1. 359 o Tunnel Encapsulation Attribute is defined in [RFC9012]. 361 o Tunnel-Type is set to 15. 363 o Preference, Binding SID, SRv6 Binding SID, Priority, Policy Name, 364 Policy Candidate Path Name, ENLP, Segment-List, Weight, and 365 Segment sub-TLVs are defined in this document. 367 o Additional sub-TLVs may be defined in the future. 369 A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV 370 of type "SR Policy". 372 2.3. Remote Endpoint and Color 374 The Tunnel Egress Endpoint and Color sub-TLVs, as defined in 375 [RFC9012], may also be present in the SR Policy encodings. 377 The Tunnel Egress Endpoint and Color Sub-TLVs of the Tunnel 378 Encapsulation Attribute are not used for SR Policy encodings and 379 therefore their value is irrelevant in the context of the SR Policy 380 SAFI NLRI. If present, the Tunnel Egress Endpoint sub-TLV and the 381 Color sub-TLV MUST be ignored by the BGP speaker and not removed from 382 the Tunnel Encapsulation Attribute during propagation. 384 2.4. SR Policy Sub-TLVs 386 This section specifies the sub-TLVs defined for encoding the 387 information about the SR Policy Candidate Path. 389 Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority, 390 Policy Name, Policy Candidate Path Name, and Explicit NULL Label 391 Policy are the new sub-TLVs of the BGP Tunnel Encapsulation Attribute 392 [RFC9012] being defined in this section. 394 Weight and Segment are sub-TLVs of the new Segment-List sub-TLV 395 mentioned above. 397 None of the sub-TLVs defined in the following sub-sections have any 398 effect on the BGP best-path selection or propagation procedures. 399 These sub-TLVs are not used by BGP and are instead passed on to SRPM 400 as SR Policy Candidate Path information for further processing 401 described in [I-D.ietf-spring-segment-routing-policy]. 403 The use of SR Policy Sub-TLVs is applicable only for the AFI/SAFI 404 pairs of (1/73, 2/73). Future documents may extend their 405 applicability to other AFI/SAFI. 407 2.4.1. Preference Sub-TLV 409 The Preference sub-TLV is used to carry the preference of the SR 410 Policy candidate path. The contents of this sub-TLV are used by the 411 SRPM as described in section 2.7 in 412 [I-D.ietf-spring-segment-routing-policy]. 414 The Preference sub-TLV is optional and it MUST NOT appear more than 415 once in the SR Policy encoding. 417 The Preference sub-TLV has following format: 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type | Length | Flags | RESERVED | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Preference (4 octets) | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 where: 429 o Type: 12 431 o Length: 6. 433 o Flags: 1 octet of flags. None are defined at this stage. Flags 434 SHOULD be set to zero on transmission and MUST be ignored on 435 receipt. 437 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 438 transmission and MUST be ignored on receipt. 440 o Preference: a 4-octet value. 442 2.4.2. Binding SID Sub-TLV 444 The Binding SID sub-TLV is used to signal the binding SID related 445 information of the SR Policy candidate path. The contents of this 446 sub-TLV are used by the SRPM as described in section 6 in 447 [I-D.ietf-spring-segment-routing-policy]. 449 The Binding SID sub-TLV is optional and it MUST NOT appear more than 450 once in the SR Policy encoding. 452 When the Binding SID sub-TLV is used to signal an SRv6 SID, the 453 choice of its SRv6 Endpoint Behavior [RFC8986] to be instantiated is 454 left to the headend node. It is RECOMMENDED that the SRv6 Binding 455 SID sub-TLV defined in Section 2.4.3, that enables the specification 456 of the SRv6 Endpoint Behavior, be used for signaling of an SRv6 457 Binding SID for an SR Policy candidate path. 459 The Binding SID sub-TLV has the following format: 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type | Length | Flags | RESERVED | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Binding SID (variable, optional) | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 where: 471 o Type: 13 473 o Length: specifies the length of the value field not including Type 474 and Length fields. Can be 2 or 6 or 18. 476 o Flags: 1 octet of flags. Following flags are defined in the new 477 registry "SR Policy Binding SID Flags" as described in 478 Section 6.6: 480 0 1 2 3 4 5 6 7 481 +-+-+-+-+-+-+-+-+ 482 |S|I| | 483 +-+-+-+-+-+-+-+-+ 485 where: 487 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 488 It is used by SRPM as described in section 6.2.3 in 489 [I-D.ietf-spring-segment-routing-policy]. 491 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 492 is used by SRPM as described in section 8.2 in 493 [I-D.ietf-spring-segment-routing-policy]. 495 * Unused bits in the Flag octet SHOULD be set to zero upon 496 transmission and MUST be ignored upon receipt. 498 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 499 transmission and MUST be ignored on receipt. 501 o Binding SID: if the length is 2, then no Binding SID is present. 502 If the length is 6 then the Binding SID is encoded in 4 octets 503 using the format below. TC, S, TTL (Total of 12 bits) are 504 RESERVED and SHOULD be set to zero and MUST be ignored. 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Label | TC |S| TTL | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 If the length is 18 then the Binding SID contains a 16-octet SRv6 513 SID. 515 2.4.3. SRv6 Binding SID Sub-TLV 517 The SRv6 Binding SID sub-TLV is used to signal the SRv6 Binding SID 518 related information of the SR Policy candidate path. It enables the 519 specification of the SRv6 Endpoint Behavior [RFC8986] to be 520 instantiated on the headend node. The contents of this sub-TLV are 521 used by the SRPM as described in section 6 in 522 [I-D.ietf-spring-segment-routing-policy]. 524 The SRv6 Binding SID sub-TLV is optional. More than one SRv6 Binding 525 SIDs MAY be signaled in the same SR Policy encoding to indicate one 526 or more SRv6 SIDs, each with potentially different SRv6 Endpoint 527 Behaviors to be instantiated. 529 The SRv6 Binding SID sub-TLV has the following format: 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Type | Length | Flags | RESERVED | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | SRv6 Binding SID (16 octets) | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 // SRv6 Endpoint Behavior and SID Structure (optional) // 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 where: 543 o Type: TBD 545 o Length is variable 547 o Flags: 1 octet of flags. Following flags are defined in the new 548 registry "SR Policy Binding SID Flags" as described in 549 Section 6.7: 551 0 1 2 3 4 5 6 7 552 +-+-+-+-+-+-+-+-+ 553 |S|I|B| | 554 +-+-+-+-+-+-+-+-+ 556 where: 558 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 559 It is used by SRPM as described in section 6.2.3 in 560 [I-D.ietf-spring-segment-routing-policy]. 562 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 563 is used by SRPM as described in section 8.2 in 564 [I-D.ietf-spring-segment-routing-policy]. 566 * B-Flag: This flag, when set, indicates the presence of the SRv6 567 Endpoint Behavior and SID Structure encoding specified in 568 Section 2.4.4.2.13. 570 * Unused bits in the Flag octet SHOULD be set to zero upon 571 transmission and MUST be ignored upon receipt. 573 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 574 transmission and MUST be ignored on receipt. 576 o SRv6 Binding SID: Contains a 16-octet SRv6 SID. 578 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 579 Section 2.4.4.2.13. 581 2.4.4. Segment List Sub-TLV 583 The Segment List sub-TLV encodes a single explicit path towards the 584 endpoint as described in section 5.1 in 585 [I-D.ietf-spring-segment-routing-policy]. The Segment List sub-TLV 586 includes the elements of the paths (i.e., segments) as well as an 587 optional Weight sub-TLV. 589 The Segment List sub-TLV may exceed 255 bytes length due to large 590 number of segments. Therefore a 2-octet length is required. 591 According to [RFC9012], the first bit of the sub-TLV codepoint 592 defines the size of the length field. Therefore, for the Segment 593 List sub-TLV a code point of 128 or higher is used. 595 The Segment List sub-TLV is optional and MAY appear multiple times in 596 the SR Policy encoding. The ordering of Segment List sub-TLVs, each 597 sub-TLV encoding a Segment List, does not matter. 599 The Segment List sub-TLV contains zero or more Segment sub-TLVs and 600 MAY contain a Weight sub-TLV. 602 The Segment List sub-TLV has the following format: 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Type | Length | RESERVED | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 // sub-TLVs // 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 where: 614 o Type: 128. 616 o Length: the total length (not including the Type and Length 617 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 619 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 620 transmission and MUST be ignored on receipt. 622 o sub-TLVs currently defined: 624 * An optional single Weight sub-TLV. 626 * Zero or more Segment sub-TLVs. 628 Validation of an explicit path encoded by the Segment List sub-TLV is 629 beyond the scope of BGP and performed by the SRPM as described in 630 section 5 in [I-D.ietf-spring-segment-routing-policy]. 632 2.4.4.1. Weight Sub-TLV 634 The Weight sub-TLV specifies the weight associated with a given 635 segment list. The contents of this sub-TLV are used only by the SRPM 636 as described in section 2.11 in 637 [I-D.ietf-spring-segment-routing-policy]. 639 The Weight sub-TLV is optional and it MUST NOT appear more than once 640 inside the Segment List sub-TLV. 642 The Weight sub-TLV has the following format: 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Type | Length | Flags | RESERVED | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Weight | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 where: 654 o Type: 9. 656 o Length: 6 658 o Flags: 1 octet of flags. None are defined at this stage. Flags 659 SHOULD be set to zero on transmission and MUST be ignored on 660 receipt. 662 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 663 transmission and MUST be ignored on receipt. 665 2.4.4.2. Segment Sub-TLVs 667 A Segment sub-TLV describes a single segment in a segment list (i.e., 668 a single element of the explicit path). One or more Segment sub-TLVs 669 constitute an explicit path of the SR Policy candidate path. The 670 contents of these sub-TLVs are used only by the SRPM as described in 671 section 4 in [I-D.ietf-spring-segment-routing-policy]. 673 The Segment sub-TLVs are optional and MAY appear multiple times in 674 the Segment List sub-TLV. 676 [I-D.ietf-spring-segment-routing-policy] defines several Segment 677 Types: 679 Type A: SR-MPLS Label 680 Type B: SRv6 SID 681 Type C: IPv4 Prefix with optional SR Algorithm 682 Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS 683 Type E: IPv4 Prefix with Local Interface ID 684 Type F: IPv4 Addresses for link endpoints as Local, Remote pair 685 Type G: IPv6 Prefix and Interface ID for link endpoints as Local, 686 Remote pair for SR-MPLS 687 Type H: IPv6 Addresses for link endpoints as Local, Remote pair 688 for SR-MPLS 689 Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6 690 Type J: IPv6 Prefix and Interface ID for link endpoints as Local, 691 Remote pair for SRv6 692 Type K: IPv6 Addresses for link endpoints as Local, Remote pair 693 for SRv6 695 The following sub-sections specify the sub-TLV used for encoding each 696 of these Segment Types. 698 2.4.4.2.1. Segment Type A 700 The Type A Segment Sub-TLV encodes a single SR-MPLS SID. The format 701 is as follows: 703 0 1 2 3 704 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 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Type | Length | Flags | RESERVED | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Label | TC |S| TTL | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 where: 713 o Type: 1. 715 o Length is 6. 717 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 719 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 720 transmission and MUST be ignored on receipt. 722 o Label: 20 bits of label value. 724 o TC: 3 bits of traffic class. 726 o S: 1 bit of bottom-of-stack. 728 o TTL: 1 octet of TTL. 730 The following applies to the Type-1 Segment sub-TLV: 732 o The S bit SHOULD be zero upon transmission and MUST be ignored 733 upon reception. 735 o If the originator wants the receiver to choose the TC value, it 736 sets the TC field to zero. 738 o If the originator wants the receiver to choose the TTL value, it 739 sets the TTL field to 255. 741 o If the originator wants to recommend a value for these fields, it 742 puts those values in the TC and/or TTL fields. 744 o The receiver MAY override the originator's values for these 745 fields. This would be determined by local policy at the receiver. 746 One possible policy would be to override the fields only if the 747 fields have the default values specified above. 749 2.4.4.2.2. Segment Type B 751 The Type B Segment Sub-TLV encodes a single SRv6 SID. The format is 752 as follows: 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Type | Length | Flags | RESERVED | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 // SRv6 SID (16 octets) // 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 // SRv6 Endpoint Behavior and SID Structure (optional) // 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 where: 766 o Type: 13. 768 o Length is variable. 770 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 772 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 773 transmission and MUST be ignored on receipt. 775 o SRv6 SID: 16 octets of IPv6 address. 777 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 778 Section 2.4.4.2.13. 780 The TLV 2 defined for the advertisement of Segment Type B in the 781 earlier versions of this document has been deprecated to avoid 782 backward compatibility issues. 784 2.4.4.2.3. Segment Type C 786 The Type C Segment Sub-TLV encodes an IPv4 node address, SR Algorithm 787 and an optional SR-MPLS SID. The format is as follows: 789 0 1 2 3 790 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 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Type | Length | Flags | SR Algorithm | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | IPv4 Node Address (4 octets) | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | SR-MPLS SID (optional, 4 octets) | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 where: 801 o Type: 3. 803 o Length is 10 when the SR-MPLS SID is present else is 6. 805 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 807 o SR Algorithm: 1 octet specifying SR Algorithm as described in 808 section 3.1.1 in [RFC8402] when A-Flag as defined in 809 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 810 described in section 4 in 811 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 812 encoded, this field SHOULD be set to zero on transmission and MUST 813 be ignored on receipt. 815 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 817 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 818 TTL as defined in Section 2.4.4.2.1. 820 2.4.4.2.4. Segment Type D 822 The Type D Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 823 and an optional SR-MPLS SID. The format is as follows: 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Type | Length | Flags | SR Algorithm | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 // IPv6 Node Address (16 octets) // 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | SR-MPLS SID (optional, 4 octets) | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 where: 837 o Type: 4 839 o Length is 22 when the SR-MPLS SID is present else is 18. 841 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 843 o SR Algorithm: 1 octet specifying SR Algorithm as described in 844 section 3.1.1 in [RFC8402] when A-Flag as defined in 845 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 846 described in section 4 in 847 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 848 encoded, this field SHOULD be set to zero on transmission and MUST 849 be ignored on receipt. 851 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 853 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 854 TTL as defined in Section 2.4.4.2.1. 856 2.4.4.2.5. Segment Type E 858 The Type E Segment Sub-TLV encodes an IPv4 node address, a local 859 interface Identifier (Local Interface ID), and an optional SR-MPLS 860 SID. The format is as follows: 862 0 1 2 3 863 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 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Type | Length | Flags | RESERVED | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Local Interface ID (4 octets) | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | IPv4 Node Address (4 octets) | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | SR-MPLS SID (optional, 4 octets) | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 where: 876 o Type: 5. 878 o Length is 14 when the SR-MPLS SID is present else is 10. 880 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 882 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 883 transmission and MUST be ignored on receipt. 885 o Local Interface ID: 4 octets of interface index as defined in 886 [RFC8664]. 888 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 890 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 891 TTL as defined in Section 2.4.4.2.1. 893 2.4.4.2.6. Segment Type F 895 The Type F Segment Sub-TLV encodes an adjacency local address, an 896 adjacency remote address, and an optional SR-MPLS SID. The format is 897 as follows: 899 0 1 2 3 900 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 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Type | Length | Flags | RESERVED | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Local IPv4 Address (4 octets) | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Remote IPv4 Address (4 octets) | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | SR-MPLS SID (optional, 4 octets) | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 where: 913 o Type: 6. 915 o Length is 14 when the SR-MPLS SID is present else is 10. 917 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 919 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 920 transmission and MUST be ignored on receipt. 922 o Local IPv4 Address: a 4 octet IPv4 address. 924 o Remote IPv4 Address: a 4 octet IPv4 address. 926 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 927 TTL as defined in Section 2.4.4.2.1. 929 2.4.4.2.7. Segment Type G 931 The Type G Segment Sub-TLV encodes an IPv6 link-local adjacency with 932 IPv6 local node address, a local interface identifier (Local 933 Interface ID), IPv6 remote node address, a remote interface 934 identifier (Remote Interface ID), and an optional SR-MPLS SID. The 935 format is as follows: 937 0 1 2 3 938 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 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Type | Length | Flags | RESERVED | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Local Interface ID (4 octets) | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 // IPv6 Local Node Address (16 octets) // 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Remote Interface ID (4 octets) | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 // IPv6 Remote Node Address (16 octets) // 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | SR-MPLS SID (optional, 4 octets) | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 where: 955 o Type: 7 957 o Length is 46 when the SR-MPLS SID is present else is 42. 959 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 961 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 962 transmission and MUST be ignored on receipt. 964 o Local Interface ID: 4 octets of interface index as defined in 965 [RFC8664]. 967 o IPv6 Local Node Address: a 16 octet IPv6 address. 969 o Remote Interface ID: 4 octets of interface index as defined in 970 [RFC8664]. The value MAY be set to zero when the local node 971 address and interface identifiers are sufficient to describe the 972 link. 974 o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY 975 be set to zero when the local node address and interface 976 identifiers are sufficient to describe the link. 978 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 979 TTL as defined in Section 2.4.4.2.1. 981 2.4.4.2.8. Segment Type H 983 The Type H Segment Sub-TLV encodes an adjacency local address, an 984 adjacency remote address, and an optional SR-MPLS SID. The format is 985 as follows: 987 0 1 2 3 988 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 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Type | Length | Flags | RESERVED | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 // Local IPv6 Address (16 octets) // 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 // Remote IPv6 Address (16 octets) // 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | SR-MPLS SID (optional, 4 octets) | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 where: 1001 o Type: 8 1003 o Length is 38 when the SR-MPLS SID is present else is 34. 1005 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1007 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1008 transmission and MUST be ignored on receipt. 1010 o Local IPv6 Address: a 16 octet IPv6 address. 1012 o Remote IPv6 Address: a 16 octet IPv6 address. 1014 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 1015 TTL as defined in Section 2.4.4.2.1. 1017 2.4.4.2.9. Segment Type I 1019 The Type I Segment Sub-TLV encodes an IPv6 node address, SR 1020 Algorithm, and an optional SRv6 SID. The format is as follows: 1022 0 1 2 3 1023 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | Type | Length | Flags | SR Algorithm | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 // IPv6 Node Address (16 octets) // 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 // SRv6 SID (optional, 16 octets) // 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 // SRv6 Endpoint Behavior and SID Structure (optional) // 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 where: 1036 o Type: 14 1038 o Length is variable. 1040 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1042 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1043 section 3.1.1 in [RFC8402] when A-Flag as defined in 1044 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1045 described in section 4 in 1046 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1047 encoded, this field SHOULD be set to zero on transmission and MUST 1048 be ignored on receipt. 1050 o IPv6 Node Address: a 16 octet IPv6 address. 1052 o SRv6 SID: optional, a 16 octet IPv6 address. 1054 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1055 Section 2.4.4.2.13. 1057 The TLV 10 defined for the advertisement of Segment Type I in the 1058 earlier versions of this document has been deprecated to avoid 1059 backward compatibility issues. 1061 2.4.4.2.10. Segment Type J 1063 The Type J Segment Sub-TLV encodes an IPv6 link-local adjacency with 1064 local node address, a local interface identifier (Local Interface 1065 ID), remote IPv6 node address, a remote interface identifier (Remote 1066 Interface ID), and an optional SRv6 SID. The format is as follows: 1068 0 1 2 3 1069 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 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Type | Length | Flags | SR Algorithm | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Local Interface ID (4 octets) | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 // IPv6 Local Node Address (16 octets) // 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Remote Interface ID (4 octets) | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 // IPv6 Remote Node Address (16 octets) // 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 // SRv6 SID (optional, 16 octets) // 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 // SRv6 Endpoint Behavior and SID Structure (optional) // 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 where: 1088 o Type: 15 1090 o Length is variable. 1092 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1094 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1095 section 3.1.1 in [RFC8402] when A-Flag as defined in 1096 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1097 described in section 4 in 1098 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1099 encoded, this field SHOULD be set to zero on transmission and MUST 1100 be ignored on receipt. 1102 o Local Interface ID: 4 octets of interface index as defined in 1103 [RFC8664]. 1105 o IPv6 Local Node Address: a 16 octet IPv6 address. 1107 o Remote Interface ID: 4 octets of interface index as defined in 1108 [RFC8664]. The value MAY be set to zero when the local node 1109 address and interface identifiers are sufficient to describe the 1110 link. 1112 o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY 1113 be set to zero when the local node address and interface 1114 identifiers are sufficient to describe the link. 1116 o SRv6 SID: optional, a 16 octet IPv6 address. 1118 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1119 Section 2.4.4.2.13. 1121 The TLV 11 defined for the advertisement of Segment Type J in the 1122 earlier versions of this document has been deprecated to avoid 1123 backward compatibility issues. 1125 2.4.4.2.11. Segment Type K 1127 The Type K Segment Sub-TLV encodes an adjacency local address, an 1128 adjacency remote address, and an optional SRv6 SID. The format is as 1129 follows: 1131 0 1 2 3 1132 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 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Type | Length | Flags | SR Algorithm | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 // Local IPv6 Address (16 octets) // 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 // Remote IPv6 Address (16 octets) // 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 // SRv6 SID (optional, 16 octets) // 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 // SRv6 Endpoint Behavior and SID Structure (optional) // 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 where: 1147 o Type: 16 1149 o Length is variable. 1151 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1153 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1154 section 3.1.1 in [RFC8402] when A-Flag as defined in 1155 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1156 described in section 4 in 1157 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1158 encoded, this field SHOULD be set to zero on transmission and MUST 1159 be ignored on receipt. 1161 o Local IPv6 Address: a 16 octet IPv6 address. 1163 o Remote IPv6 Address: a 16 octet IPv6 address. 1165 o SRv6 SID: optional, a 16 octet IPv6 address. 1167 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1168 Section 2.4.4.2.13. 1170 The TLV 12 defined for the advertisement of Segment Type K in the 1171 earlier versions of this document has been deprecated to avoid 1172 backward compatibility issues. 1174 2.4.4.2.12. Segment Flags 1176 The Segment Types sub-TLVs described above MAY contain the following 1177 flags in the "Flags" field defined in Section 6.8: 1179 0 1 2 3 4 5 6 7 1180 +-+-+-+-+-+-+-+-+ 1181 |V|A|S|B| | 1182 +-+-+-+-+-+-+-+-+ 1184 where: 1186 V-Flag: This flag, when set, is used by SRPM for "SID 1187 verification" as described in Section 5.1 in 1188 [I-D.ietf-spring-segment-routing-policy]. 1190 A-Flag: This flag, when set, indicates the presence of SR 1191 Algorithm id in the "SR Algorithm" field applicable to various 1192 Segment Types. SR Algorithm is used by SRPM as described in 1193 section 4 in [I-D.ietf-spring-segment-routing-policy]. 1195 S-Flag: This flag, when set, indicates the presence of the SR-MPLS 1196 or SRv6 SID depending on the segment type. 1198 B-Flag: This flag, when set, indicates the presence of the SRv6 1199 Endpoint Behavior and SID Structure encoding specified in 1200 Section 2.4.4.2.13. 1202 Unused bits in the Flag octet SHOULD be set to zero upon 1203 transmission and MUST be ignored upon receipt. 1205 The following applies to the Segment Flags: 1207 o V-Flag applies to all Segment Types. 1209 o A-Flag applies to Segment Types C, D, I, J, and K. If A-Flag 1210 appears with Segment Types A, B, E, F, G, and H, it MUST be 1211 ignored. 1213 o S-Flag applies to Segment Types C, D, E, F, G, H, I, J, and K. If 1214 S-Flag appears with Segment Types A or B, it MUST be ignored. 1216 o B-Flag applies to Segment Types B, I, J, and K. If B-Flag appears 1217 with Segment Types A, C, D, E, F, G, and H, it MUST be ignored. 1219 2.4.4.2.13. SRv6 SID Endpoint Behavior and Structure 1221 The Segment Types sub-TLVs described above MAY contain the SRv6 1222 Endpoint Behavior and SID Structure [RFC8986] encoding as described 1223 below: 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | Endpoint Behavior | Reserved | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | LB Length | LN Length | Fun. Length | Arg. Length | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 where: 1233 Endpoint Behavior: 2 octets. It carries the SRv6 Endpoint 1234 Behavior code point for this SRv6 SID as defined in section 9.2 of 1235 [RFC8986]. When set with the value 0, the choice of SRv6 Endpoint 1236 Behavior is left to the headend. 1238 Reserved: 2 octets of reserved bits. SHOULD be set to zero on 1239 transmission and MUST be ignored on receipt. 1241 Locator Block Length: 1 octet. SRv6 SID Locator Block length in 1242 bits. 1244 Locator Node Length: 1 octet. SRv6 SID Locator Node length in 1245 bits. 1247 Function Length: 1 octet. SRv6 SID Function length in bits. 1249 Argument Length: 1 octet. SRv6 SID Arguments length in bits. 1251 The total of the locator block, locator node, function, and argument 1252 lengths MUST be less than or equal to 128. 1254 2.4.5. Explicit NULL Label Policy Sub-TLV 1256 To steer an unlabeled IP packet into an SR policy, it is necessary to 1257 create a label stack for that packet, and push one or more labels 1258 onto that stack. 1260 The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate 1261 whether an Explicit NULL Label [RFC3032] must be pushed on an 1262 unlabeled IP packet before any other labels. 1264 If an ENLP Sub-TLV is not present, the decision of whether to push an 1265 Explicit NULL label on a given packet is a matter of local 1266 configuration. 1268 The ENLP sub-TLV is optional and it MUST NOT appear more than once in 1269 the SR Policy encoding. 1271 The contents of this sub-TLV are used by the SRPM as described in 1272 section 4.1 in [I-D.ietf-spring-segment-routing-policy]. 1274 0 1 2 3 1275 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 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Type | Length | Flags | RESERVED | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | ENLP | 1280 +-+-+-+-+-+-+-+-+ 1282 Where: 1284 Type: 14. 1286 Length: 3. 1288 Flags: 1 octet of flags. None are defined at this stage. Flags 1289 SHOULD be set to zero on transmission and MUST be ignored on 1290 receipt. 1292 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1293 transmission and MUST be ignored on receipt. 1295 ENLP (Explicit NULL Label Policy): Indicates whether Explicit NULL 1296 labels are to be pushed on unlabeled IP packets that are being 1297 steered into a given SR policy. This field has one of the 1298 following values: 1300 0: Reserved. 1302 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1303 packet, but do not push an IPv6 Explicit NULL label on an 1304 unlabeled IPv6 packet. 1306 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 1307 packet, but do not push an IPv4 Explicit NULL label on an 1308 unlabeled IPv4 packet. 1310 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1311 packet, and push an IPv6 Explicit NULL label on an unlabeled 1312 IPv6 packet. 1314 4: Do not push an Explicit NULL label. 1316 5 - 255: Reserved. 1318 The ENLP reserved values may be used for future extensions and 1319 implementations SHOULD ignore the ENLP Sub-TLV with these values. 1320 The behavior signaled in this Sub-TLV MAY be overridden by local 1321 configuration. The section 4.1 of 1322 [I-D.ietf-spring-segment-routing-policy] describes the behavior on 1323 the headend for the handling of the explicit null label. 1325 2.4.6. Policy Priority Sub-TLV 1327 An operator MAY set the Policy Priority sub-TLV to indicate the order 1328 in which the SR policies are re-computed upon topological change. 1329 The contents of this sub-TLV are used by the SRPM as described in 1330 section 2.11 in [I-D.ietf-spring-segment-routing-policy]. 1332 The Priority sub-TLV is optional and it MUST NOT appear more than 1333 once in the SR Policy encoding. 1335 The Priority sub-TLV has following format: 1337 0 1 2 3 1338 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 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Type | Length | Priority | RESERVED | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 Where: 1345 Type: 15 1347 Length: 2. 1349 Priority: a 1-octet value. 1351 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1352 transmission and MUST be ignored on receipt. 1354 2.4.7. Policy Candidate Path Name Sub-TLV 1356 An operator MAY set the Policy Candidate Path Name sub-TLV to attach 1357 a symbolic name to the SR Policy candidate path. 1359 Usage of Policy Candidate Path Name sub-TLV is described in section 1360 2.6 in [I-D.ietf-spring-segment-routing-policy]. 1362 The Policy Candidate Path Name sub-TLV may exceed 255 bytes length 1363 due to a long name. Therefore a 2-octet length is required. 1364 According to [RFC9012], the first bit of the sub-TLV codepoint 1365 defines the size of the length field. Therefore, for the Policy 1366 Candidate Path Name sub-TLV, a code point of 128 or higher is used. 1368 It is RECOMMENDED that the size of the symbolic name for the 1369 candidate path be limited to 255 bytes. Implementations MAY choose 1370 to truncate long names to 255 bytes when signaling via BGP. 1372 The Policy Candidate Path Name sub-TLV is optional and it MUST NOT 1373 appear more than once in the SR Policy encoding. 1375 The Policy Candidate Path Name sub-TLV has following format: 1377 0 1 2 3 1378 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 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | Type | Length | RESERVED | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 // Policy Candidate Path Name // 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 Where: 1387 Type: 129. 1389 Length: Variable. 1391 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1392 transmission and MUST be ignored on receipt. 1394 Policy Candidate Path Name: Symbolic name for the SR Policy 1395 candidate path without a NULL terminator as specified in section 1396 2.6 of [I-D.ietf-spring-segment-routing-policy]. 1398 2.4.8. Policy Name Sub-TLV 1400 An operator MAY set the Policy Name sub-TLV to associate a symbolic 1401 name with the SR Policy for which the candidate path is being 1402 advertised via the SR Policy NLRI. 1404 Usage of Policy Name sub-TLV is described in section 2.1 of 1405 [I-D.ietf-spring-segment-routing-policy]. 1407 The Policy Name sub-TLV may exceed 255 bytes length due to a long 1408 policy name. Therefore a 2-octet length is required. According to 1409 [RFC9012], the first bit of the sub-TLV codepoint defines the size of 1410 the length field. Therefore, for the Policy Name sub-TLV, a code 1411 point of 128 or higher is used. 1413 It is RECOMMENDED that the size of the symbolic name for the SR 1414 Policy be limited to 255 bytes. Implementations MAY choose to 1415 truncate long names to 255 bytes when signaling via BGP. 1417 The Policy Name sub-TLV is optional and it MUST NOT appear more than 1418 once in the SR Policy encoding. 1420 The Policy Name sub-TLV has following format: 1422 0 1 2 3 1423 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 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | Type | Length | RESERVED | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 // Policy Name // 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 Where: 1432 Type: TBD 1434 Length: Variable. 1436 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1437 transmission and MUST be ignored on receipt. 1439 Policy Name: Symbolic name for the policy. It SHOULD be a string 1440 of printable ASCII characters, without a NULL terminator. 1442 3. Color Extended Community 1444 The Color Extended Community [RFC9012] is used to steer traffic 1445 corresponding to BGP routes (e.g., L3VPN) into an SR Policy with 1446 matching color value. 1448 Two bits from the Flags field of the Color Extended Community are 1449 used as follows to support the requirements of Color-Only steering as 1450 specified in Section 8.8 of [I-D.ietf-spring-segment-routing-policy]: 1452 1 1453 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 |C O| RESERVED | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 The CO bits together form the Color-Only Type field which indicates 1459 the various matching criteria between BGP NH and SR Policy endpoint 1460 in addition to the matching of the color value. Following types are 1461 defined: 1463 o Type 0: Specific Endpoint Match: Request match for the endpoint 1464 that is the BGP NH 1466 o Type 1: Specific or Null Endpoint Match: Request match for either 1467 the endpoint that is the BGP NH or a null endpoint (e.g., like a 1468 default gateway) 1470 o Type 2: Specific, Null or Any Endpoint Match: Request match for 1471 either the endpoint that is the BGP NH or with a null or any 1472 endpoint 1474 o Type 3: reserved for future use and SHOULD NOT be used. Upon 1475 reception, an implementation MUST treat it like Type 0. 1477 The details of the SR Policy steering mechanisms based on these 1478 Color-Only types are specified in section 8.8 of 1479 [I-D.ietf-spring-segment-routing-policy]. 1481 One or more Color Extended Communities MAY be associated with a BGP 1482 route update. Sections 8.4.1, 8.5.1, and 8.8.2 of 1483 [I-D.ietf-spring-segment-routing-policy] specify the steering 1484 behaviors over SR Policies when multiple Color Extended Communities 1485 are associated with a BGP route. 1487 4. SR Policy Operations 1489 As described in this document, BGP is not the actual consumer of an 1490 SR Policy NLRI. BGP is in charge of the origination and propagation 1491 of the SR Policy NLRI but its installation and use are outside the 1492 scope of BGP. The details of SR Policy installation and use are 1493 specified in [I-D.ietf-spring-segment-routing-policy]. 1495 4.1. Advertisement of SR Policies 1497 Typically, but not limited to, an SR Policy is computed by a 1498 controller or a path computation engine (PCE) and originated by a BGP 1499 speaker on its behalf. 1501 Multiple SR Policy NLRIs may be present with the same tuple but with different content when these SR policies are 1503 intended for different head-ends. 1505 The distinguisher of each SR Policy NLRI prevents undesired BGP route 1506 selection among these SR Policy NLRIs and allows their propagation 1507 across route reflectors [RFC4456]. 1509 Moreover, one or more route target SHOULD be attached to the 1510 advertisement, where each route target identifies one or more 1511 intended head-ends for the advertised SR Policy update. 1513 If no route target is attached to the SR Policy NLRI, then it is 1514 assumed that the originator sends the SR Policy update directly 1515 (e.g., through a BGP session) to the intended receiver. In such 1516 case, the NO_ADVERTISE community MUST be attached to the SR Policy 1517 update. 1519 4.2. Reception of an SR Policy NLRI 1521 On reception of an SR Policy NLRI, a BGP speaker first determines if 1522 it is acceptable and then if it is usable. 1524 4.2.1. Acceptance of an SR Policy NLRI 1526 When a BGP speaker receives an SR Policy NLRI from a neighbor it MUST 1527 first, determine if it's acceptable. The following rules apply in 1528 addition to the validation described in Section 5: 1530 o The SR Policy NLRI MUST include a distinguisher, color and 1531 endpoint field which implies that the length of the NLRI MUST be 1532 either 12 or 24 octets (depending on the address family of the 1533 endpoint). 1535 o The SR Policy update MUST have either the NO_ADVERTISE community 1536 or at least one route target extended community in IPv4-address 1537 format or both. If a router supporting this specification 1538 receives an SR Policy update with no route target extended 1539 communities and no NO_ADVERTISE community, the update MUST be 1540 considered as malformed. 1542 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1543 Update and MUST have a Tunnel Type TLV set to SR Policy (codepoint 1544 is 15). 1546 A router that receives an SR Policy update that is not valid 1547 according to these criteria MUST treat the update as malformed and 1548 the SR Policy candidate path MUST NOT be passed to the SRPM. 1550 4.2.2. Usable SR Policy NLRI 1552 An SR Policy update that has been determined to be acceptable is 1553 further evaluated for its usability by the receiving node. 1555 An SR Policy NLRI update without any route target extended community 1556 but having the NO_ADVERTISE community is considered usable. 1558 If one or more route targets are present, then at least one route 1559 target MUST match the BGP Identifier of the receiver for the update 1560 to be considered usable. The BGP Identifier is defined in [RFC4271] 1561 as a 4 octet IPv4 address. Therefore, the route target extended 1562 community MUST be of the same format. 1564 If one or more route targets are present and none matches the local 1565 BGP Identifier, then, while the SR Policy NLRI is acceptable, it is 1566 not usable on the receiver node. 1568 When the SR Policy tunnel type includes any sub-TLV that is 1569 unrecognized or unsupported, the update SHOULD NOT be considered 1570 usable. An implementation MAY provide an option for ignoring 1571 unsupported sub-TLVs. 1573 4.2.3. Passing a usable SR Policy NLRI to the SRPM 1575 Once BGP on the receiving node has determined that the SR Policy NLRI 1576 is usable, it passes the SR Policy candidate path to the SRPM. Note 1577 that, along with the candidate path details, BGP also passes the 1578 originator information for breaking ties in the candidate path 1579 selection process as described in section 2.4 in 1580 [I-D.ietf-spring-segment-routing-policy]. 1582 When an update for an SR Policy NLRI results in its becoming 1583 unusable, BGP MUST delete its corresponding SR Policy candidate path 1584 from the SRPM. 1586 The SRPM applies the rules defined in section 2 in 1587 [I-D.ietf-spring-segment-routing-policy] to determine whether the SR 1588 Policy candidate path is valid and to select the best candidate path 1589 among the valid ones for a given SR Policy. 1591 4.2.4. Propagation of an SR Policy 1593 SR Policy NLRIs that have been determined acceptable and valid can be 1594 evaluated for propagation, even the ones that are not usable. 1596 SR Policy NLRIs that have the NO_ADVERTISE community attached to them 1597 MUST NOT be propagated. 1599 By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate 1600 it to any EBGP neighbor. An implementation MAY provide an explicit 1601 configuration to override this and enable propagation of acceptable 1602 SR Policy NLRIs to specific EBGP neighbors. 1604 A BGP node advertises a received SR Policy NLRI to its IBGP neighbors 1605 according to normal IBGP propagation rules. 1607 By default, a BGP node receiving an SR Policy NLRI SHOULD NOT remove 1608 route target extended community before propagation. An 1609 implementation MAY provide support for configuration to filter and/or 1610 remove route target extended community before propagation. 1612 5. Error Handling 1614 This section describes the error handling actions, as described in 1615 [RFC7606], that are to be performed for the handling of BGP update 1616 messages for BGP SR Policy SAFI. 1618 A BGP Speaker MUST perform the following syntactic validation of the 1619 SR Policy NLRI to determine if it is malformed. This includes the 1620 validation of the length of each NLRI and the total length of the 1621 MP_REACH_NLRI and MP_UNREACH_NLRI attributes. 1623 When the error determined allows for the router to skip the malformed 1624 NLRI(s) and continue the processing of the rest of the update 1625 message, then it MUST handle such malformed NLRIs as 'Treat-as- 1626 withdraw'. In other cases, where the error in the NLRI encoding 1627 results in the inability to process the BGP update message (e.g. 1628 length related encoding errors), then the router SHOULD handle such 1629 malformed NLRIs as 'AFI/SAFI disable' when other AFI/SAFI besides SR 1630 Policy are being advertised over the same session. Alternately, the 1631 router MUST perform 'session reset' when the session is only being 1632 used for SR Policy or when it 'AFI/SAFI disable' action is not 1633 possible. 1635 The validation of the TLVs/sub-TLVs introduced in this document and 1636 defined in their respective sub-sections of Section 2.4 MUST be 1637 performed to determine if they are malformed or invalid. The 1638 validation of the Tunnel Encapsulation Attribute itself and the other 1639 TLVs/sub-TLVs specified in [RFC9012] MUST be done as described in 1640 that document. In case of any error detected, either at the 1641 attribute or its TLV/sub-TLV level, the "treat-as-withdraw" strategy 1642 MUST be applied. This is because an SR Policy update without a valid 1643 Tunnel Encapsulation Attribute (comprising of all valid TLVs/sub- 1644 TLVs) is not usable. 1646 An SR Policy update that is determined to be not acceptable, and 1647 therefore malformed, based on rules described in Section 4.2.1 MUST 1648 be handled by the "treat-as-withdraw" strategy. 1650 The validation of the individual fields of the TLVs/sub-TLVs defined 1651 in Section 2.4 are beyond the scope of BGP as they are handled by the 1652 SRPM as described in the individual TLV/sub-TLV sub-sections. A BGP 1653 implementation MUST NOT perform semantic verification of such fields 1654 nor consider the SR Policy update to be invalid or not acceptable/ 1655 usable based on such validation. 1657 An implementation SHOULD log an error for any errors found during the 1658 above validation for further analysis. 1660 6. IANA Considerations 1662 This document requests codepoint allocations in the following 1663 existing registries: 1665 o Subsequent Address Family Identifiers (SAFI) Parameters registry 1667 o BGP Tunnel Encapsulation Attribute Tunnel Types registry under the 1668 BGP Tunnel Encapsulation registry 1670 o BGP Tunnel Encapsulation Attribute sub-TLVs registry under the BGP 1671 Tunnel Encapsulation registry 1673 o Color Extended Community Flags registry under the BGP Tunnel 1674 Encapsulation registry 1676 This document also requests the creation of the following new 1677 registries: 1679 o SR Policy Segment List Sub-TLVs under the BGP Tunnel Encapsulation 1680 registry 1682 o SR Policy Binding SID Flags under the BGP Tunnel Encapsulation 1683 registry 1685 o SR Policy Segment Flags under the BGP Tunnel Encapsulation 1686 registry 1688 o Color Extended Community Color-Only Types registry under the BGP 1689 Tunnel Encapsulation registry 1691 6.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1692 Parameters 1694 This document defines a new SAFI in the registry "Subsequent Address 1695 Family Identifiers (SAFI) Parameters" that has been assigned a 1696 codepoint by IANA as follows: 1698 Codepoint Description Reference 1699 ----------------------------------------------- 1700 73 SR Policy SAFI This document 1702 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1704 This document defines a new Tunnel-Type in the registry "BGP Tunnel 1705 Encapsulation Attribute Tunnel Types" that has been assigned a 1706 codepoint by IANA as follows: 1708 Codepoint Description Reference 1709 -------------------------------------------------- 1710 15 SR Policy This document 1712 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1714 This document defines new sub-TLVs in the registry "BGP Tunnel 1715 Encapsulation Attribute sub-TLVs" that has been assigned codepoints 1716 by IANA as follows via the early allocation process: 1718 Codepoint Description Reference 1719 ------------------------------------------------------------ 1720 12 Preference sub-TLV This document 1721 13 Binding SID sub-TLV This document 1722 14 ENLP sub-TLV This document 1723 15 Priority sub-TLV This document 1724 20 SRv6 Binding SID sub-TLV This document 1725 128 Segment List sub-TLV This document 1726 129 Policy Candidate Path Name sub-TLV This document 1727 130 Policy Name sub-TLV This document 1729 6.4. Existing Registry: Color Extended Community Flags 1731 This document requests allocations in the registry called "Color 1732 Extended Community Flags" under the "BGP Tunnel Encapsulation" 1733 registry. 1735 The following bits have been assigned by IANA via the early 1736 allocation process to form the Color-Only Types field: 1738 Bit 1739 Position Description Reference 1740 ------------------------------------------------------------------ 1741 0-1 Color-only Types Field This document 1743 6.5. New Registry: SR Policy Segment List Sub-TLVs 1745 This document requests the creation of a new registry called "SR 1746 Policy Segment List Sub-TLVs" under the "BGP Tunnel Encapsulation" 1747 registry. The allocation policy of this registry is "Standards 1748 Action" according to [RFC8126]. 1750 Following initial Sub-TLV codepoints are assigned by this document: 1752 Value Description Reference 1753 ----------------------------------------------------- 1754 0 Reserved This document 1755 1 Segment Type A sub-TLV This document 1756 2 Deprecated This document 1757 3 Segment Type C sub-TLV This document 1758 4 Segment Type D sub-TLV This document 1759 5 Segment Type E sub-TLV This document 1760 6 Segment Type F sub-TLV This document 1761 7 Segment Type G sub-TLV This document 1762 8 Segment Type H sub-TLV This document 1763 9 Weight sub-TLV This document 1764 10 Deprecated This document 1765 11 Deprecated This document 1766 12 Deprecated This document 1767 13 Segment Type B sub-TLV This document 1768 14 Segment Type I sub-TLV This document 1769 15 Segment Type J sub-TLV This document 1770 16 Segment Type K sub-TLV This document 1771 17-255 Unassigned 1773 6.6. New Registry: SR Policy Binding SID Flags 1775 This document requests the creation of a new registry called "SR 1776 Policy Binding SID Flags" under the "BGP Tunnel Encapsulation" 1777 registry. The allocation policy of this registry is "Standards 1778 Action" according to [RFC8126]. 1780 The following flags are defined: 1782 Bit Description Reference 1783 ----------------------------------------------------------------- 1784 0 Specified-BSID-Only Flag (S-Flag) This document 1785 1 Drop Upon Invalid Flag (I-Flag) This document 1786 2-7 Unassigned 1788 6.7. New Registry: SR Policy SRv6 Binding SID Flags 1790 This document requests the creation of a new registry called "SR 1791 Policy SRv6 Binding SID Flags" under the "BGP Tunnel Encapsulation" 1792 registry. The allocation policy of this registry is "Standards 1793 Action" according to [RFC8126]. 1795 The following flags are defined: 1797 Bit Description Reference 1798 ----------------------------------------------------------------- 1799 0 Specified-BSID-Only Flag (S-Flag) This document 1800 1 Drop Upon Invalid Flag (I-Flag) This document 1801 2 SRv6 Endpoint Behavior & 1802 SID Structure Flag (B-Flag) This document 1803 3-7 Unassigned 1805 6.8. New Registry: SR Policy Segment Flags 1807 This document requests the creation of a new registry called "SR 1808 Policy Segment Flags" under the "BGP Tunnel Encapsulation" registry. 1809 The allocation policy of this registry is "Standards Action" 1810 according to [RFC8126]. 1812 The following Flags are defined: 1814 Bit Description Reference 1815 ------------------------------------------------------------------ 1816 0 Segment Verification Flag (V-Flag) This document 1817 1 SR Algorithm Flag (A-Flag) This document 1818 2 SID Specified Flag (S-Flag) This document 1819 3 SRv6 Endpoint Behavior & 1820 SID Structure Flag (B-Flag) This document 1821 4-7 Unassigned 1823 6.9. New Registry: Color Extended Community Color-Only Types 1825 This document requests the creation of a new registry called "Color 1826 Extended Community Color-Only Types" under the "BGP Tunnel 1827 Encapsulation" registry for assignment of codepoints (values 0 1828 through 3) in the Color-Only Type field of the Color Extended 1829 Community Flags field. The allocation policy of this registry is 1830 "Standards Action" according to [RFC8126]. 1832 The following types are defined: 1834 Type Description Reference 1835 ----------------------------------------------------------- 1836 0 Specific Endpoint Match This document 1837 1 Specific or Null Endpoint Match This document 1838 2 Specific, Null or Any Endpoint Match This document 1839 3 Unallocated & reserved for future This document 1841 7. Security Considerations 1843 The security mechanisms of the base BGP security model apply to the 1844 extensions described in this document as well. See the Security 1845 Considerations section of [RFC4271] for a discussion of BGP security. 1846 Also, refer to [RFC4272] and [RFC6952] for analysis of security 1847 issues for BGP. 1849 The BGP SR Policy extensions specified in this document enable 1850 traffic engineering and service programming use-cases within the SR 1851 domain as described in [I-D.ietf-spring-segment-routing-policy]. SR 1852 operates within a trusted SR domain [RFC8402] and its security 1853 considerations also apply to BGP sessions when carrying SR Policy 1854 information. The SR Policies distributed by BGP are expected to be 1855 used entirely within this trusted SR domain i.e. within a single AS 1856 or between multiple AS/domains within a single provider network. 1857 Therefore, precaution is necessary to ensure that the SR Policy 1858 information advertised via BGP sessions is limited to nodes in a 1859 secure manner within this trusted SR domain. BGP peering sessions 1860 for address-families other than SR Policy SAFI may be set up to 1861 routers outside the SR domain. The isolation of BGP SR Policy SAFI 1862 peering sessions may be used to ensure that the SR Policy information 1863 is not advertised by accident or error to an EBGP peering session 1864 outside the SR domain. 1866 Additionally, it may be considered that the export of SR Policy 1867 information, as described in this document, constitutes a risk to 1868 confidentiality of mission-critical or commercially sensitive 1869 information about the network (more specifically endpoint/node 1870 addresses, SR SIDs, and the SR Policies deployed). BGP peerings are 1871 not automatic and require configuration; thus, it is the 1872 responsibility of the network operator to ensure that only trusted 1873 nodes (that include both routers and controller applications) within 1874 the SR domain are configured to receive such information. 1876 8. Acknowledgments 1878 The authors of this document would like to thank Shyam Sethuram, John 1879 Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha, Bruno Decraene, 1880 Gurusiddesh Nidasesi, Kausik Majumdar, Zafar Ali, Swadesh Agarwal, 1881 Jakob Heitz, Viral Patel, Peng Shaofu, Cheng Li, Martin Vigoureux, 1882 and John Scudder for their comments and review of this document. The 1883 authors would like to thank Sue Hares for her detailed shepherd 1884 review that helped in improving the document. 1886 9. Contributors 1888 Eric Rosen 1889 Juniper Networks 1890 US 1892 Email: erosen@juniper.net 1894 Arjun Sreekantiah 1895 Cisco Systems 1896 US 1898 Email: asreekan@cisco.com 1900 Acee Lindem 1901 Cisco Systems 1902 US 1904 Email: acee@cisco.com 1906 Siva Sivabalan 1907 Cisco Systems 1908 US 1910 Email: msiva@cisco.com 1912 Imtiyaz Mohammad 1913 Arista Networks 1914 India 1916 Email: imtiyaz@arista.com 1918 Gaurav Dawra 1919 Cisco Systems 1920 US 1922 Email: gdawra.ietf@gmail.com 1924 Peng Shaofu 1925 ZTE Corporation 1926 China 1928 Email: peng.shaofu@zte.com.cn 1930 10. References 1932 10.1. Normative References 1934 [I-D.ietf-spring-segment-routing-policy] 1935 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1936 P. Mattes, "Segment Routing Policy Architecture", draft- 1937 ietf-spring-segment-routing-policy-22 (work in progress), 1938 March 2022. 1940 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1941 Requirement Levels", BCP 14, RFC 2119, 1942 DOI 10.17487/RFC2119, March 1997, 1943 . 1945 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1946 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1947 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1948 . 1950 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1951 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1952 DOI 10.17487/RFC4271, January 2006, 1953 . 1955 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1956 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1957 February 2006, . 1959 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1960 "Multiprotocol Extensions for BGP-4", RFC 4760, 1961 DOI 10.17487/RFC4760, January 2007, 1962 . 1964 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1965 Patel, "Revised Error Handling for BGP UPDATE Messages", 1966 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1967 . 1969 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1970 Writing an IANA Considerations Section in RFCs", BCP 26, 1971 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1972 . 1974 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1975 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1976 May 2017, . 1978 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1979 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1980 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1981 July 2018, . 1983 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1984 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1985 Routing with the MPLS Data Plane", RFC 8660, 1986 DOI 10.17487/RFC8660, December 2019, 1987 . 1989 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1990 and J. Hardwick, "Path Computation Element Communication 1991 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1992 DOI 10.17487/RFC8664, December 2019, 1993 . 1995 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1996 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1997 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1998 . 2000 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 2001 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 2002 (SRv6) Network Programming", RFC 8986, 2003 DOI 10.17487/RFC8986, February 2021, 2004 . 2006 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 2007 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 2008 DOI 10.17487/RFC9012, April 2021, 2009 . 2011 10.2. Informational References 2013 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 2014 RFC 4272, DOI 10.17487/RFC4272, January 2006, 2015 . 2017 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 2018 Reflection: An Alternative to Full Mesh Internal BGP 2019 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 2020 . 2022 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 2023 BGP, LDP, PCEP, and MSDP Issues According to the Keying 2024 and Authentication for Routing Protocols (KARP) Design 2025 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 2026 . 2028 Authors' Addresses 2030 Stefano Previdi 2031 Huawei Technologies 2032 IT 2034 Email: stefano@previdi.net 2036 Clarence Filsfils 2037 Cisco Systems 2038 Brussels 2039 BE 2041 Email: cfilsfil@cisco.com 2043 Ketan Talaulikar (editor) 2044 Arrcus Inc 2045 India 2047 Email: ketant.ietf@gmail.com 2049 Paul Mattes 2050 Microsoft 2051 One Microsoft Way 2052 Redmond, WA 98052 2053 USA 2055 Email: pamattes@microsoft.com 2057 Dhanendra Jain 2058 Google 2060 Email: dhanendra.ietf@gmail.com 2061 Steven Lin 2062 Google 2064 Email: stevenlin@google.com