idnits 2.17.1 draft-ietf-idr-segment-routing-te-policy-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2020) is 1260 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-20 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-24 Summary: 0 errors (**), 0 flaws (~~), 4 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 Individual 4 Intended status: Standards Track C. Filsfils 5 Expires: May 17, 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 November 13, 2020 16 Advertising Segment Routing Policies in BGP 17 draft-ietf-idr-segment-routing-te-policy-11 19 Abstract 21 This document defines a new BGP SAFI with a new NLRI in order to 22 advertise a candidate path of a Segment Routing (SR) Policy. An SR 23 Policy is a set of candidate paths, each consisting of one or more 24 segment lists. The headend of an SR Policy may learn multiple 25 candidate paths for an SR Policy. Candidate paths may be learned via 26 a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. 27 This document specifies the way in which BGP may be used to 28 distribute SR Policy candidate paths. New sub-TLVs for the Tunnel 29 Encapsulation Attribute are defined for signaling information about 30 these candidate paths. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 17, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 68 2. SR Policy Encoding . . . . . . . . . . . . . . . . . . . . . 6 69 2.1. SR Policy SAFI and NLRI . . . . . . . . . . . . . . . . . 6 70 2.2. SR Policy and Tunnel Encapsulation Attribute . . . . . . 7 71 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 72 2.4. SR Policy Sub-TLVs . . . . . . . . . . . . . . . . . . . 9 73 2.4.1. Preference Sub-TLV . . . . . . . . . . . . . . . . . 9 74 2.4.2. Binding SID Sub-TLV . . . . . . . . . . . . . . . . . 10 75 2.4.3. SRv6 Binding SID Sub-TLV . . . . . . . . . . . . . . 11 76 2.4.4. Segment List Sub-TLV . . . . . . . . . . . . . . . . 13 77 2.4.5. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 28 78 2.4.6. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 29 79 2.4.7. Policy Candidate Path Name Sub-TLV . . . . . . . . . 30 80 2.4.8. Policy Name Sub-TLV . . . . . . . . . . . . . . . . . 31 81 3. Color Extended Community . . . . . . . . . . . . . . . . . . 31 82 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 32 83 4.1. Advertisement of SR Policies . . . . . . . . . . . . . . 32 84 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 32 85 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 33 86 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 33 87 4.2.3. Passing a usable SR Policy NLRI to the SRPM . . . . . 34 88 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 34 89 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 34 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 91 6.1. Existing Registry: Subsequent Address Family Identifiers 92 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 36 93 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute 94 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 36 95 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute 96 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 36 98 6.4. Existing Registry: Color Extended Community Flags . . . . 37 99 6.5. New Registry: SR Policy Segment List Sub-TLVs . . . . . . 37 100 6.6. New Registry: SR Policy Binding SID Flags . . . . . . . . 38 101 6.7. New Registry: SR Policy SRv6 Binding SID Flags . . . . . 38 102 6.8. New Registry: SR Policy Segment Flags . . . . . . . . . . 39 103 6.9. Guidance for Designated Experts . . . . . . . . . . . . . 39 104 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 105 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 106 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 108 10.1. Normative References . . . . . . . . . . . . . . . . . . 41 109 10.2. Informational References . . . . . . . . . . . . . . . . 42 110 Appendix A. Deprecated Segment Sub-TLVs . . . . . . . . . . . . 43 111 A.1. Type B-Deprecated: SID only, in the form of IPv6 address 43 112 A.2. Type I-Deprecated: IPv6 Node Address with optional SRv6 113 SID . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 114 A.3. Type J-Deprecated: IPv6 Address + Interface ID for local 115 and remote pair for SRv6 with optional SID . . . . . . . 44 116 A.4. Type K-Deprecated: IPv6 Local and Remote addresses for 117 SRv6 with optional SID . . . . . . . . . . . . . . . . . 46 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 120 1. Introduction 122 Segment Routing (SR) [RFC8402] allows a headend node to steer a 123 packet flow along any path. Intermediate per-flow states are 124 eliminated thanks to source routing. 126 The headend node is said to steer a flow into a SR Policy. 128 The header of a packet steered in an SR Policy is augmented with the 129 ordered list of segments associated with that SR Policy. 131 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 132 Policy and steering into an SR Policy. These apply equally to the 133 MPLS and IPv6 (known as SRv6) data plane instantiations of Segment 134 Routing with their respective representations of segments as SR-MPLS 135 SID and SRv6 SID as described in [RFC8402]. 137 The SR Policy related functionality described in 138 [I-D.ietf-spring-segment-routing-policy] can be conceptually viewed 139 as being incorporated in an SR Policy Module (SRPM). Following is a 140 reminder of the high-level functionality of SRPM: 142 o Learning multiple candidate paths for an SR Policy via various 143 mechanisms (CLI, NetConf, PCEP or BGP). 145 o Selection of the best candidate path for an SR Policy. 147 o Binding BSID to the selected candidate path of an SR Policy. 149 o Installation of the selected candidate path and its BSID in the 150 forwarding plane. 152 This document specifies the way to use BGP to distribute one or more 153 of the candidate paths of an SR Policy to the headend of that policy. 154 The document describes the functionality that provided by BGP and, as 155 appropriate, provides references for the functionality which is 156 outside the scope of BGP (i.e. resides within SRPM on the headend 157 node). 159 This document specifies a way of representing SR Policy candidate 160 paths in BGP UPDATE messages. BGP can then be used to propagate the 161 SR Policy candidate paths to the headend nodes in the network. The 162 usual BGP rules for BGP propagation and best-path selection are used. 163 At the headend of a specific policy, this will result in one or more 164 candidate paths being installed into the "BGP table". These paths 165 are then passed to the SRPM. The SRPM may compare them to candidate 166 paths learned via other mechanisms, and will choose one or more paths 167 to be installed in the data plane. BGP itself does not install SR 168 Policy candidate paths into the data plane. 170 This document defines a new BGP address family (SAFI). In UPDATE 171 messages of that address family, the NLRI identifies an SR Policy 172 Candidate Path, and the attributes encode the segment lists and other 173 details of that SR Policy Candidate Path. 175 While for simplicity we may write that BGP advertises an SR Policy, 176 it has to be understood that BGP advertises a candidate path of an SR 177 policy and that this SR Policy might have several other candidate 178 paths provided via BGP (via an NLRI with a different distinguisher as 179 defined in this document), PCEP, NETCONF or local policy 180 configuration. 182 Typically, a controller defines the set of policies and advertise 183 them to policy head-end routers (typically ingress routers). The 184 policy advertisement uses BGP extensions defined in this document. 185 The policy advertisement is, in most but not all of the cases, 186 tailored for a specific policy head-end. In this case the 187 advertisement may be sent on a BGP session to that head-end and not 188 propagated any further. 190 Alternatively, a router (i.e., a BGP egress router) advertises SR 191 Policies representing paths to itself. In this case, it is possible 192 to send the policy to each head-end over a BGP session to that head- 193 end, without requiring any further propagation of the policy. 195 An SR Policy intended only for the receiver will, in most cases, not 196 traverse any Route Reflector (RR, [RFC4456]). 198 In some situations, it is undesirable for a controller or BGP egress 199 router to have a BGP session to each policy head-end. In these 200 situations, BGP Route Reflectors may be used to propagate the 201 advertisements, or it may be necessary for the advertisement to 202 propagate through a sequence of one or more AS. To make this 203 possible, an attribute needs to be attached to the advertisement that 204 enables a BGP speaker to determine whether it is intended to be a 205 head-end for the advertised policy. This is done by attaching one or 206 more Route Target Extended Communities to the advertisement 207 ([RFC4360]). 209 The BGP extensions for the advertisement of SR Policies include 210 following components: 212 o A new Subsequent Address Family Identifier (SAFI) whose NLRI 213 identifies an SR Policy candidate path. 215 o A new Tunnel Type identifier for SR Policy, and a set of sub-TLVs 216 to be inserted into the Tunnel Encapsulation Attribute (as defined 217 in [I-D.ietf-idr-tunnel-encaps]) specifying segment lists of the 218 SR Policy candidate path, as well as other information about the 219 SR Policy. 221 o One or more IPv4 address format route-target extended community 222 ([RFC4360]) attached to the SR Policy advertisement and that 223 indicates the intended head-end of such SR Policy advertisement. 225 o The Color Extended Community (as defined in 226 [I-D.ietf-idr-tunnel-encaps]) and used in order to steer traffic 227 into an SR Policy, as described in section 8.4 in 228 [I-D.ietf-spring-segment-routing-policy]. This document 229 (Section 3) modifies the format of the Color Extended Community by 230 using the two leftmost bits of the RESERVED field. 232 1.1. Requirements Language 234 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 235 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 236 "OPTIONAL" in this document are to be interpreted as described in BCP 237 14 [RFC2119] [RFC8174] when, and only when, they appear in all 238 capitals, as shown here. 240 2. SR Policy Encoding 242 2.1. SR Policy SAFI and NLRI 244 A new SAFI is defined: the SR Policy SAFI with codepoint 73. The AFI 245 used MUST be IPv4(1) or IPv6(2). 247 The SR Policy SAFI uses a new NLRI defined as follows: 249 +------------------+ 250 | NLRI Length | 1 octet 251 +------------------+ 252 | Distinguisher | 4 octets 253 +------------------+ 254 | Policy Color | 4 octets 255 +------------------+ 256 | Endpoint | 4 or 16 octets 257 +------------------+ 259 where: 261 o NLRI Length: 1 octet of length expressed in bits as defined in 262 [RFC4760]. When AFI = 1 value MUST be 96 and when AFI = 2 value 263 MUST be 192. 265 o Distinguisher: 4-octet value uniquely identifying the policy in 266 the context of tuple. The distinguisher has no 267 semantic value and is solely used by the SR Policy originator to 268 make unique (from an NLRI perspective) multiple candidate paths of 269 the same SR Policy. 271 o Policy Color: 4-octet value identifying (with the endpoint) the 272 policy. The color is used to match the color of the destination 273 prefixes to steer traffic into the SR Policy as specified in 274 [I-D.ietf-spring-segment-routing-policy]. 276 o Endpoint: identifies the endpoint of a policy. The Endpoint may 277 represent a single node or a set of nodes (e.g., an anycast 278 address). The Endpoint is an IPv4 (4-octet) address or an IPv6 279 (16-octet) address according to the AFI of the NLRI. 281 The color and endpoint are used to automate the steering of BGP 282 Payload prefixes on SR Policy as described in 283 [I-D.ietf-spring-segment-routing-policy]. 285 The NLRI containing the SR Policy candidate path is carried in a BGP 286 UPDATE message [RFC4271] using BGP multi-protocol extensions 287 [RFC4760] with an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of 73. 289 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 290 attribute with the SR Policy SAFI MUST also carry the BGP mandatory 291 attributes. In addition, the BGP update message MAY also contain any 292 of the BGP optional attributes. 294 The next-hop network address field in SR Policy SAFI (73) updates may 295 be either a 4 octet IPv4 address or a 16 octet IPv6 address, 296 independent of the SR Policy AFI. The length field of the next-hop 297 address specifies the next-hop address family. If the next-hop 298 length is 4, then the next-hop is an IPv4 address; if the next-hop 299 length is 16, then it is a global IPv6 address; and if the next-hop 300 length is 32, then it has a global IPv6 address followed by a link- 301 local IPv6 address. The setting of the next-hop field and its 302 attendant processing is governed by standard BGP procedures as 303 described in section 3 in [RFC4760]. 305 It is important to note that any BGP speaker receiving a BGP message 306 with an SR Policy NLRI, will process it only if the NLRI is among the 307 best-paths as per the BGP best-path selection algorithm. In other 308 words, this document leverages the existing BGP propagation and best- 309 path selection rules. Details of the procedures are described in 310 Section 4. 312 It has to be noted that if several candidate paths of the same SR 313 Policy (endpoint, color) are signaled via BGP to a head-end, it is 314 RECOMMENDED that each NLRI use a different distinguisher. If BGP has 315 installed into the BGP table two advertisements whose respective 316 NLRIs have the same color and endpoint, but different distinguishers, 317 both advertisements are passed to the SRPM as different candidate 318 paths along with their respective originator information (i.e. ASN 319 and BGP Router-ID) as described in section 2.4 of 320 [I-D.ietf-spring-segment-routing-policy]. The ASN would be the ASN 321 of origin and the BGP Router-ID is determined in the following order: 323 o From the Route Origin Community [RFC4360] if present and carrying 324 an IP Address 326 o As the BGP Originator ID [RFC4456] if present 328 o As the BGP Router-ID of the peer from which the update was 329 received as a last resort. 331 2.2. SR Policy and Tunnel Encapsulation Attribute 333 The content of the SR Policy Candidate Path is encoded in the Tunnel 334 Encapsulation Attribute defined in [I-D.ietf-idr-tunnel-encaps] using 335 a new Tunnel-Type called SR Policy Type with codepoint 15. 337 The SR Policy Encoding structure is as follows: 339 SR Policy SAFI NLRI: 340 Attributes: 341 Tunnel Encaps Attribute (23) 342 Tunnel Type: SR Policy 343 Binding SID 344 SRv6 Binding SID 345 Preference 346 Priority 347 Policy Name 348 Policy Candidate Path Name 349 Explicit NULL Label Policy (ENLP) 350 Segment List 351 Weight 352 Segment 353 Segment 354 ... 355 ... 356 where: 358 o SR Policy SAFI NLRI is defined in Section 2.1. 360 o Tunnel Encapsulation Attribute is defined in 361 [I-D.ietf-idr-tunnel-encaps]. 363 o Tunnel-Type is set to 15. 365 o Preference, Binding SID, SRv6 Binding SID, Priority, Policy Name, 366 Policy Candidate Path Name, ENLP, Segment-List, Weight and Segment 367 sub-TLVs are defined in this document. 369 o Additional sub-TLVs may be defined in the future. 371 A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV 372 of type "SR Policy". 374 2.3. Remote Endpoint and Color 376 The Remote Endpoint and Color sub-TLVs, as defined in 377 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy 378 encodings. 380 The Remote Endpoint and Color Sub-TLVs of the Tunnel Encapsulation 381 Attribute are not used for SR Policy encodings and therefore their 382 value is irrelevant in the context of the SR Policy SAFI NLRI. If 383 present, the Remote Endpoint sub-TLV and the Color sub-TLV MUST be 384 ignored by the BGP speaker. 386 2.4. SR Policy Sub-TLVs 388 This section specifies the sub-TLVs defined for encoding the 389 information about the SR Policy Candidate Path. 391 Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority, 392 Policy Name, Policy Candidate Path Name and Explicit NULL Label 393 Policy are the new sub-TLVs of the BGP Tunnel Encapsulation Attribute 394 [I-D.ietf-idr-tunnel-encaps] being defined in this section. 396 Weight and Segment are sub-TLVs of the new Segment-List sub-TLV 397 mentioned above. 399 None of the sub-TLVs defined in the following sub-sections have any 400 effect on the BGP best-path selection or propagation procedures. 401 These sub-TLVs are not used by BGP and are instead passed on to SRPM 402 as SR Policy Candidate Path information for further processing 403 described in [I-D.ietf-spring-segment-routing-policy] . 405 2.4.1. Preference Sub-TLV 407 The Preference sub-TLV is used to carry the preference of the SR 408 Policy candidate path. The contents of this sub-TLV are used by the 409 SRPM as described in section 2.7 in 410 [I-D.ietf-spring-segment-routing-policy]. 412 The Preference sub-TLV is optional and it MUST NOT appear more than 413 once in the SR Policy encoding. 415 The Preference sub-TLV has following format: 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Type | Length | Flags | RESERVED | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Preference (4 octets) | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 where: 427 o Type: 12 429 o Length: 6. 431 o Flags: 1 octet of flags. None are defined at this stage. Flags 432 SHOULD be set to zero on transmission and MUST be ignored on 433 receipt. 435 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 436 transmission and MUST be ignored on receipt. 438 o Preference: a 4-octet value. 440 2.4.2. Binding SID Sub-TLV 442 The Binding SID sub-TLV is used to signal the binding SID related 443 information of the SR Policy candidate path. The contents of this 444 sub-TLV are used by the SRPM as described in section 6 in 445 [I-D.ietf-spring-segment-routing-policy]. 447 The Binding SID sub-TLV is optional and it MUST NOT appear more than 448 once in the SR Policy encoding. 450 When the Binding SID sub-TLV is used to signal an SRv6 SID, the 451 choice of its SRv6 Endpoint Behavior 452 [I-D.ietf-spring-srv6-network-programming] to be instantiated is left 453 to the headend node. It is RECOMMENDED that the SRv6 Binding SID 454 sub-TLV defined in Section 2.4.3, that enables the specification of 455 the SRv6 Endpoint Behavior, be used for signaling of an SRv6 Binding 456 SID for an SR Policy candidate path. 458 The Binding SID sub-TLV has the following format: 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type | Length | Flags | RESERVED | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Binding SID (variable, optional) | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 where: 470 o Type: 13 472 o Length: specifies the length of the value field not including Type 473 and Length fields. Can be 2 or 6 or 18. 475 o Flags: 1 octet of flags. Following flags are defined in the new 476 registry "SR Policy Binding SID Flags" as described in 477 Section 6.6: 479 0 1 2 3 4 5 6 7 480 +-+-+-+-+-+-+-+-+ 481 |S|I| | 482 +-+-+-+-+-+-+-+-+ 483 where: 485 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 486 It is used by SRPM as described in section 6.2.3 in 487 [I-D.ietf-spring-segment-routing-policy]. 489 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 490 is used by SRPM as described in section 8.2 in 491 [I-D.ietf-spring-segment-routing-policy]. 493 * Unused bits in the Flag octet SHOULD be set to zero upon 494 transmission and MUST be ignored upon receipt. 496 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 497 transmission and MUST be ignored on receipt. 499 o Binding SID: if length is 2, then no Binding SID is present. If 500 length is 6 then the Binding SID is encoded in 4 octets using the 501 format below. TC, S, TTL (Total of 12 bits) are RESERVED and 502 SHOULD be set to zero and MUST be ignored. 504 0 1 2 3 505 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 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Label | TC |S| TTL | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 If length is 18 then the Binding SID contains a 16-octet SRv6 SID. 512 2.4.3. SRv6 Binding SID Sub-TLV 514 The SRv6 Binding SID sub-TLV is used to signal the SRv6 Binding SID 515 related information of the SR Policy candidate path. It enables the 516 specification of the SRv6 Endpoint Behavior 517 [I-D.ietf-spring-srv6-network-programming] to be instantiated on the 518 headend node. The contents of this sub-TLV are used by the SRPM as 519 described in section 6 in [I-D.ietf-spring-segment-routing-policy]. 521 The SRv6 Binding SID sub-TLV is optional. More than one SRv6 Binding 522 SIDs MAY be signalled in the same SR Policy encoding to indicate one 523 or more SRv6 SIDs, each with potentially different SRv6 Endpoint 524 Behaviors to be instantiated. 526 The SRv6 Binding SID sub-TLV has the following format: 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Type | Length | Flags | RESERVED | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | SRv6 Binding SID (16 octets) | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 // SRv6 Endpoint Behavior and SID Structure (optional) // 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 where: 540 o Type: TBD 542 o Length is variable 544 o Flags: 1 octet of flags. Following flags are defined in the new 545 registry "SR Policy Binding SID Flags" as described in 546 Section 6.7: 548 0 1 2 3 4 5 6 7 549 +-+-+-+-+-+-+-+-+ 550 |S|I|B| | 551 +-+-+-+-+-+-+-+-+ 553 where: 555 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 556 It is used by SRPM as described in section 6.2.3 in 557 [I-D.ietf-spring-segment-routing-policy]. 559 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 560 is used by SRPM as described in section 8.2 in 561 [I-D.ietf-spring-segment-routing-policy]. 563 * B-Flag: This flag, when set, indicates the presence of the SRv6 564 Endpoint Behavior and SID Structure encoding specified in 565 Section 2.4.4.2.13. 567 * Unused bits in the Flag octet SHOULD be set to zero upon 568 transmission and MUST be ignored upon receipt. 570 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 571 transmission and MUST be ignored on receipt. 573 o SRv6 Binding SID: Contains a 16-octet SRv6 SID. 575 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 576 Section 2.4.4.2.13. 578 2.4.4. Segment List Sub-TLV 580 The Segment List sub-TLV encodes a single explicit path towards the 581 endpoint as described in section 5.1 in 582 [I-D.ietf-spring-segment-routing-policy]. The Segment List sub-TLV 583 includes the elements of the paths (i.e., segments) as well as an 584 optional Weight sub-TLV. 586 The Segment List sub-TLV may exceed 255 bytes length due to large 587 number of segments. Therefore a 2-octet length is required. 588 According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- 589 TLV codepoint defines the size of the length field. Therefore, for 590 the Segment List sub-TLV a code point of 128 or higher is used. 592 The Segment List sub-TLV is optional and MAY appear multiple times in 593 the SR Policy encoding. The ordering of Segment List sub-TLVs, each 594 sub-TLV encoding a Segment List, does not matter. 596 The Segment List sub-TLV contains zero or more Segment sub-TLVs and 597 MAY contain a Weight sub-TLV. 599 The Segment List sub-TLV has the following format: 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Type | Length | RESERVED | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 // sub-TLVs // 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 where: 611 o Type: 128. 613 o Length: the total length (not including the Type and Length 614 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 616 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 617 transmission and MUST be ignored on receipt. 619 o sub-TLVs currently defined: 621 * An optional single Weight sub-TLV. 623 * Zero or more Segment sub-TLVs. 625 Validation of an explicit path encoded by the Segment List sub-TLV is 626 beyond the scope of BGP and performed by the SRPM as described in 627 section 5 in [I-D.ietf-spring-segment-routing-policy]. 629 2.4.4.1. Weight Sub-TLV 631 The Weight sub-TLV specifies the weight associated to a given segment 632 list. The contents of this sub-TLV are used only by the SRPM as 633 described in section 2.11 in 634 [I-D.ietf-spring-segment-routing-policy]. 636 The Weight sub-TLV is optional and it MUST NOT appear more than once 637 inside the Segment List sub-TLV. 639 The Weight sub-TLV has the following format: 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Type | Length | Flags | RESERVED | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Weight | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 where: 651 o Type: 9. 653 o Length: 6 655 o Flags: 1 octet of flags. None are defined at this stage. Flags 656 SHOULD be set to zero on transmission and MUST be ignored on 657 receipt. 659 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 660 transmission and MUST be ignored on receipt. 662 2.4.4.2. Segment Sub-TLVs 664 A Segment sub-TLV describes a single segment in a segment list (i.e., 665 a single element of the explicit path). One or more Segment sub-TLVs 666 constitute an explicit path of the SR Policy candidate path. The 667 contents of these sub-TLVs are used only by the SRPM as described in 668 section 4 in [I-D.ietf-spring-segment-routing-policy]. 670 The Segment sub-TLVs are optional and MAY appear multiple times in 671 the Segment List sub-TLV. 673 [I-D.ietf-spring-segment-routing-policy] defines several Segment 674 Types: 676 Type A: SID only, in the form of MPLS Label 677 Type B: SID only, in the form of IPv6 address 678 Type C: IPv4 Node Address with optional SID 679 Type D: IPv6 Node Address with optional SID for SR MPLS 680 Type E: IPv4 Address and index with optional SID 681 Type F: IPv4 Local and Remote addresses with optional SID 682 Type G: IPv6 Address and index for local and remote pair with optional 683 SID for SR MPLS 684 Type H: IPv6 Local and Remote addresses with optional SID for SR MPLS 685 Type I: IPv6 Node Address with optional SID for SRv6 686 Type J: IPv6 Address and index for local and remote pair with optional 687 SID for SRv6 688 Type K: IPv6 Local and Remote addresses for SRv6 690 The follow sub-sections specify the sub-TLV used for encoding each of 691 these Segment Types. 693 2.4.4.2.1. Type A: SID only, in the form of MPLS Label 695 The Type A Segment Sub-TLV encodes a single SR-MPLS SID. The format 696 is as follows: 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Type | Length | Flags | RESERVED | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Label | TC |S| TTL | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 where: 708 o Type: 1. 710 o Length is 6. 712 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 714 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 715 transmission and MUST be ignored on receipt. 717 o Label: 20 bits of label value. 719 o TC: 3 bits of traffic class. 721 o S: 1 bit of bottom-of-stack. 723 o TTL: 1 octet of TTL. 725 The following applies to the Type-1 Segment sub-TLV: 727 o The S bit SHOULD be zero upon transmission, and MUST be ignored 728 upon reception. 730 o If the originator wants the receiver to choose the TC value, it 731 sets the TC field to zero. 733 o If the originator wants the receiver to choose the TTL value, it 734 sets the TTL field to 255. 736 o If the originator wants to recommend a value for these fields, it 737 puts those values in the TC and/or TTL fields. 739 o The receiver MAY override the originator's values for these 740 fields. This would be determined by local policy at the receiver. 741 One possible policy would be to override the fields only if the 742 fields have the default values specified above. 744 2.4.4.2.2. Type B: SID only, in the form of IPv6 address 746 The Type B Segment Sub-TLV encodes a single SRv6 SID. The format is 747 as follows: 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Type | Length | Flags | RESERVED | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 // SRv6 SID (16 octets) // 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 // SRv6 Endpoint Behavior and SID Structure (optional) // 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 where: 761 o Type: 13. 763 o Length is variable. 765 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 767 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 768 transmission and MUST be ignored on receipt. 770 o SRv6 SID: 16 octets of IPv6 address. 772 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 773 Section 2.4.4.2.13. 775 The TLV 2 defined for advertisement of Segment Type B in the earlier 776 versions of this document has been deprecated to avoid backward 777 compatibility issues (refer Appendix A for details). 779 2.4.4.2.3. Type C: IPv4 Node Address with optional SID 781 The Type C Segment Sub-TLV encodes an IPv4 node address, SR Algorithm 782 and an optional SR-MPLS SID. The format is as follows: 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Type | Length | Flags | SR Algorithm | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | IPv4 Node Address (4 octets) | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | SR-MPLS SID (optional, 4 octets) | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 where: 796 o Type: 3. 798 o Length is 10 when the SR-MPLS SID is present else is 6. 800 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 802 o SR Algorithm: 1 octet specifying SR Algorithm as described in 803 section 3.1.1 in [RFC8402], when A-Flag as defined in 804 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 805 described in section 4 in 806 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 807 encoded, this field SHOULD be set to zero on transmission and MUST 808 be ignored on receipt. 810 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 812 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 813 TTL as defined in Section 2.4.4.2.1. 815 2.4.4.2.4. Type D: IPv6 Node Address with optional SID for SR MPLS 817 The Type D Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 818 and an optional SR-MPLS SID. The format is as follows: 820 0 1 2 3 821 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 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Type | Length | Flags | SR Algorithm | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 // IPv6 Node Address (16 octets) // 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | SR-MPLS SID (optional, 4 octets) | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 where: 832 o Type: 4 834 o Length is 22 when the SR-MPLS SID is present else is 18. 836 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 838 o SR Algorithm: 1 octet specifying SR Algorithm as described in 839 section 3.1.1 in [RFC8402], when A-Flag as defined in 840 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 841 described in section 4 in 842 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 843 encoded, this field SHOULD be set to zero on transmission and MUST 844 be ignored on receipt. 846 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 848 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 849 TTL as defined in Section 2.4.4.2.1. 851 2.4.4.2.5. Type E: IPv4 Address + Local Interface ID with optional SID 853 The Type E Segment Sub-TLV encodes an IPv4 node address, a local 854 interface Identifier (Local Interface ID) and an optional SR-MPLS 855 SID. The format is as follows: 857 0 1 2 3 858 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 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Type | Length | Flags | RESERVED | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Local Interface ID (4 octets) | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | IPv4 Node Address (4 octets) | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | SR-MPLS SID (optional, 4 octets) | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 where: 871 o Type: 5. 873 o Length is 14 when the SR-MPLS SID is present else is 10. 875 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 877 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 878 transmission and MUST be ignored on receipt. 880 o Local Interface ID: 4 octets of interface index as defined in 881 [RFC8664]. 883 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 885 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 886 TTL as defined in Section 2.4.4.2.1. 888 2.4.4.2.6. Type F: IPv4 Local and Remote addresses with optional SID 890 The Type F Segment Sub-TLV encodes an adjacency local address, an 891 adjacency remote address and an optional SR-MPLS SID. The format is 892 as follows: 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Type | Length | Flags | RESERVED | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Local IPv4 Address (4 octets) | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Remote IPv4 Address (4 octets) | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | SR-MPLS SID (optional, 4 octets) | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 where: 908 o Type: 6. 910 o Length is 14 when the SR-MPLS SID is present else is 10. 912 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 914 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 915 transmission and MUST be ignored on receipt. 917 o Local IPv4 Address: a 4 octet IPv4 address. 919 o Remote IPv4 Address: a 4 octet IPv4 address. 921 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 922 TTL as defined in Section 2.4.4.2.1. 924 2.4.4.2.7. Type G: IPv6 Address + Interface ID for local and remote 925 pair with optional SID for SR MPLS 927 The Type G Segment Sub-TLV encodes an IPv6 Link Local adjacency with 928 IPv6 local node address, a local interface identifier (Local 929 Interface ID), IPv6 remote node address , a remote interface 930 identifier (Remote Interface ID) and an optional SR-MPLS SID. The 931 format is as follows: 933 0 1 2 3 934 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 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Type | Length | Flags | RESERVED | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Local Interface ID (4 octets) | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 // IPv6 Local Node Address (16 octets) // 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Remote Interface ID (4 octets) | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 // IPv6 Remote Node Address (16 octets) // 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | SR-MPLS SID (optional, 4 octets) | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 where: 951 o Type: 7 953 o Length is 46 when the SR-MPLS SID is present else is 42. 955 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 957 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 958 transmission and MUST be ignored on receipt. 960 o Local Interface ID: 4 octets of interface index as defined in 961 [RFC8664]. 963 o IPv6 Local Node Address: a 16 octet IPv6 address. 965 o Remote Interface ID: 4 octets of interface index as defined in 966 [RFC8664]. The value MAY be set to zero when the local node 967 address and interface identifiers are sufficient to describe the 968 link. 970 o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY 971 be set to zero when the local node address and interface 972 identifiers are sufficient to describe the link. 974 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 975 TTL as defined in Section 2.4.4.2.1. 977 2.4.4.2.8. Type H: IPv6 Local and Remote addresses with optional SID 978 for SR MPLS 980 The Type H Segment Sub-TLV encodes an adjacency local address, an 981 adjacency remote address and an optional SR-MPLS SID. The format is 982 as follows: 984 0 1 2 3 985 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 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Type | Length | Flags | RESERVED | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 // Local IPv6 Address (16 octets) // 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 // Remote IPv6 Address (16 octets) // 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | SR-MPLS SID (optional, 4 octets) | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 where: 998 o Type: 8 1000 o Length is 38 when the SR-MPLS SID is present else is 34. 1002 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1004 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1005 transmission and MUST be ignored on receipt. 1007 o Local IPv6 Address: a 16 octet IPv6 address. 1009 o Remote IPv6 Address: a 16 octet IPv6 address. 1011 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 1012 TTL as defined in Section 2.4.4.2.1. 1014 2.4.4.2.9. Type I: IPv6 Node Address with optional SRv6 SID 1016 The Type I Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 1017 and an optional SRv6 SID. The format is as follows: 1019 0 1 2 3 1020 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 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Type | Length | Flags | SR Algorithm | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 // IPv6 Node Address (16 octets) // 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 // SRv6 SID (optional, 16 octets) // 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 // SRv6 Endpoint Behavior and SID Structure (optional) // 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 where: 1033 o Type: 14 1035 o Length is variable. 1037 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1039 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1040 section 3.1.1 in [RFC8402], when A-Flag as defined in 1041 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1042 described in section 4 in 1043 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1044 encoded, this field SHOULD be set to zero on transmission and MUST 1045 be ignored on receipt. 1047 o IPv6 Node Address: a 16 octet IPv6 address. 1049 o SRv6 SID: optional, 16 octet IPv6 address. 1051 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1052 Section 2.4.4.2.13. 1054 The TLV 10 defined for advertisement of Segment Type I in the earlier 1055 versions of this document has been deprecated to avoid backward 1056 compatibility issues (refer Appendix A for details). 1058 2.4.4.2.10. Type J: IPv6 Address + Interface ID for local and remote 1059 pair for SRv6 with optional SID 1061 The Type J Segment Sub-TLV encodes an IPv6 Link Local adjacency with 1062 local node address, a local interface identifier (Local Interface 1063 ID), remote IPv6 node address, a remote interface identifier (Remote 1064 Interface ID) and an optional SRv6 SID. The format is as follows: 1066 0 1 2 3 1067 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 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Type | Length | Flags | SR Algorithm | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Local Interface ID (4 octets) | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 // IPv6 Local Node Address (16 octets) // 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Remote Interface ID (4 octets) | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 // IPv6 Remote Node Address (16 octets) // 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 // SRv6 SID (optional, 16 octets) // 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 // SRv6 Endpoint Behavior and SID Structure (optional) // 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 where: 1086 o Type: 15 1088 o Length is variable. 1090 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1092 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1093 section 3.1.1 in [RFC8402], when A-Flag as defined in 1094 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1095 described in section 4 in 1096 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1097 encoded, this field SHOULD be set to zero on transmission and MUST 1098 be ignored on receipt. 1100 o Local Interface ID: 4 octets of interface index as defined in 1101 [RFC8664]. 1103 o IPv6 Local Node Address: a 16 octet IPv6 address. 1105 o Remote Interface ID: 4 octets of interface index as defined in 1106 [RFC8664]. The value MAY be set to zero when the local node 1107 address and interface identifiers are sufficient to describe the 1108 link. 1110 o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY 1111 be set to zero when the local node address and interface 1112 identifiers are sufficient to describe the link. 1114 o SRv6 SID: optional, 16 octet IPv6 address. 1116 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1117 Section 2.4.4.2.13. 1119 The TLV 11 defined for advertisement of Segment Type J in the earlier 1120 versions of this document has been deprecated to avoid backward 1121 compatibility issues (refer Appendix A for details). 1123 2.4.4.2.11. Type K: IPv6 Local and Remote addresses for SRv6 with 1124 optional SID 1126 The Type K Segment Sub-TLV encodes an adjacency local address, an 1127 adjacency remote address and an optional SRv6 SID. The format is as 1128 follows: 1130 0 1 2 3 1131 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 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Type | Length | Flags | SR Algorithm | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 // Local IPv6 Address (16 octets) // 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 // Remote IPv6 Address (16 octets) // 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 // SRv6 SID (optional, 16 octets) // 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 // SRv6 Endpoint Behavior and SID Structure (optional) // 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 where: 1146 o Type: 16 1148 o Length is variable. 1150 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1152 o SR Algorithm: 1 octet specifying SR Algorithm as described in 1153 section 3.1.1 in [RFC8402], when A-Flag as defined in 1154 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 1155 described in section 4 in 1156 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 1157 encoded, this field SHOULD be set to zero on transmission and MUST 1158 be ignored on receipt. 1160 o Local IPv6 Address: a 16 octet IPv6 address. 1162 o Remote IPv6 Address: a 16 octet IPv6 address. 1164 o SRv6 SID: optional, 16 octet IPv6 address. 1166 o SRv6 Endpoint Behavior and SID Structure: Optional, as defined in 1167 Section 2.4.4.2.13. 1169 The TLV 12 defined for advertisement of Segment Type K in the earlier 1170 versions of this document has been deprecated to avoid backward 1171 compatibility issues (refer Appendix A for details). 1173 2.4.4.2.12. Segment Flags 1175 The Segment Types sub-TLVs described above MAY contain following 1176 flags in the "Flags" field defined in Section 6.8: 1178 0 1 2 3 4 5 6 7 1179 +-+-+-+-+-+-+-+-+ 1180 |V|A|S|B| | 1181 +-+-+-+-+-+-+-+-+ 1183 where: 1185 V-Flag: This flag, when set, is used by SRPM for the purpose of 1186 "SID verification" as described in Section 5.1 in 1187 [I-D.ietf-spring-segment-routing-policy]. 1189 A-Flag: This flag, when set, indicates the presence of SR 1190 Algorithm id in the "SR Algorithm" field applicable to various 1191 Segment Types. SR Algorithm is used by SRPM as described in 1192 section 4 in [I-D.ietf-spring-segment-routing-policy]. 1194 S-Flag: This flag, when set, indicates the presence of the SR-MPLS 1195 or SRv6 SID depending on the segment type. 1197 B-Flag: This flag, when set, indicates the presence of the SRv6 1198 Endpoint Behavior and SID Structure encoding specified in 1199 Section 2.4.4.2.13. 1201 Unused bits in the Flag octet SHOULD be set to zero upon 1202 transmission and MUST be ignored upon receipt. 1204 The following applies to the Segment Flags: 1206 o V-Flag is applicable to all Segment Types. 1208 o A-Flag is applicable to Segment Types C, D, I, J and K. If A-Flag 1209 appears with Segment Types A, B, E, F, G and H, it MUST be 1210 ignored. 1212 o S-Flag is applicable to Segment Types C, D, E, F, G, H, I, J and 1213 K. If S-Flag appears with Segment Types A or B, it MUST be 1214 ignored. 1216 o B-Flag is applicable to Segment Types B, I, J and K. If B-Flag 1217 appears with Segment Types A, C, D, E, F, G and H, it MUST be 1218 ignored. 1220 2.4.4.2.13. SRv6 SID Endpoint Behavior and Structure 1222 The Segment Types sub-TLVs described above MAY contain the SRv6 1223 Endpoint Behavior and SID Structure 1224 [I-D.ietf-spring-srv6-network-programming] encoding as described 1225 below: 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | Endpoint Behavior | Reserved | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | LB Length | LN Length | Fun. Length | Arg. Length | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 where: 1235 Endpoint Behavior: 2 octets. The SRv6 Endpoint Behavior code 1236 point for this SRv6 SID as defined in section 9.2 of 1237 [I-D.ietf-spring-srv6-network-programming]. When set with the 1238 value 0, the choice of SRv6 Endpoint Behavior is left to the 1239 headend. 1241 Reserved: 2 octet of reserved bits. SHOULD be set to zero on 1242 transmission and MUST be ignored on receipt. 1244 Locator Block Length: 1 octet. SRv6 SID Locator Block length in 1245 bits. 1247 Locator Node Length: 1 octet. SRv6 SID Locator Node length in 1248 bits. 1250 Function Length: 1 octet. SRv6 SID Function length in bits. 1252 Argument Length: 1 octet. SRv6 SID Arguments length in bits. 1254 The total of the locator block, locator node, function and argument 1255 lengths MUST be less than or equal to 128. 1257 2.4.5. Explicit NULL Label Policy Sub-TLV 1259 In order to steer an unlabeled IP packet into an SR policy, it is 1260 necessary to create a label stack for that packet, and to push one or 1261 more labels onto that stack. 1263 The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate 1264 whether an Explicit NULL Label [RFC3032] must be pushed on an 1265 unlabeled IP packet before any other labels. 1267 If an ENLP Sub-TLV is not present, the decision of whether to push an 1268 Explicit NULL label on a given packet is a matter of local 1269 configuration. 1271 The ENLP sub-TLV is optional and it MUST NOT appear more than once in 1272 the SR Policy encoding. 1274 The contents of this sub-TLV are used by the SRPM as described in 1275 section 4.1 in [I-D.ietf-spring-segment-routing-policy]. 1277 0 1 2 3 1278 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 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | Type | Length | Flags | RESERVED | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | ENLP | 1283 +-+-+-+-+-+-+-+-+ 1285 Where: 1287 Type: 14. 1289 Length: 3. 1291 Flags: 1 octet of flags. None are defined at this stage. Flags 1292 SHOULD be set to zero on transmission and MUST be ignored on 1293 receipt. 1295 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1296 transmission and MUST be ignored on receipt. 1298 ENLP (Explicit NULL Label Policy): Indicates whether Explicit NULL 1299 labels are to be pushed on unlabeled IP packets that are being 1300 steered into a given SR policy. This field has one of the 1301 following values: 1303 0: Reserved. 1305 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1306 packet, but do not push an IPv6 Explicit NULL label on an 1307 unlabeled IPv6 packet. 1309 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 1310 packet, but do not push an IPv4 Explicit NULL label on an 1311 unlabeled IPv4 packet. 1313 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1314 packet, and push an IPv6 Explicit NULL label on an unlabeled 1315 IPv6 packet. 1317 4: Do not push an Explicit NULL label. 1319 5 - 255: Reserved. 1321 The ENLP reserved values may be used for future extensions and 1322 implementations SHOULD ignore the ENLP Sub-TLV with these values. 1323 The behavior signaled in this Sub-TLV MAY be overridden by local 1324 configuration. The section 4.1 of 1325 [I-D.ietf-spring-segment-routing-policy] draft describes the 1326 behavior on the headend for handling of explicit null label. 1328 2.4.6. Policy Priority Sub-TLV 1330 An operator MAY set the Policy Priority sub-TLV to indicate the order 1331 in which the SR policies are re-computed upon topological change. 1332 The contents of this sub-TLV are used by the SRPM as described in 1333 section 2.11 in [I-D.ietf-spring-segment-routing-policy]. 1335 The Priority sub-TLV is optional and it MUST NOT appear more than 1336 once in the SR Policy encoding. 1338 The Priority sub-TLV has following format: 1340 0 1 2 3 1341 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 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Type | Length | Priority | RESERVED | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 Where: 1348 Type: 15 1350 Length: 2. 1352 Priority: a 1-octet value. 1354 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1355 transmission and MUST be ignored on receipt. 1357 2.4.7. Policy Candidate Path Name Sub-TLV 1359 An operator MAY set the Policy Candidate Path Name sub-TLV to attach 1360 a symbolic name to the SR Policy candidate path. 1362 Usage of Policy Candidate Path Name sub-TLV is described in section 1363 2.6 in [I-D.ietf-spring-segment-routing-policy]. 1365 The Policy Candidate Path Name sub-TLV may exceed 255 bytes length 1366 due to long name. Therefore a 2-octet length is required. According 1367 to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub-TLV 1368 codepoint defines the size of the length field. Therefore, for the 1369 Policy Candidate Path Name sub-TLV a code point of 128 or higher is 1370 used. 1372 It is RECOMMENDED that the size of the symbolic name be limited to 1373 255 bytes. Implementations MAY choose to truncate long names to 255 1374 bytes when signaling via BGP. 1376 The Policy Candidate Path Name sub-TLV is optional and it MUST NOT 1377 appear more than once in the SR Policy encoding. 1379 The Policy Candidate Path Name sub-TLV has following format: 1381 0 1 2 3 1382 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | Type | Length | RESERVED | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 // Policy Candidate Path Name // 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 Where: 1391 Type: 129. 1393 Length: Variable. 1395 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1396 transmission and MUST be ignored on receipt. 1398 Policy Candidate Path Name: Symbolic name for the SR Policy 1399 candidate path without a NULL terminator as specified in section 1400 2.6 of [I-D.ietf-spring-segment-routing-policy]. 1402 2.4.8. Policy Name Sub-TLV 1404 An operator MAY set the Policy Name sub-TLV to associate a symbolic 1405 name with the SR Policy for which the candidate path is being 1406 advertised via the SR Policy NLRI. 1408 Usage of Policy Name sub-TLV is described in section 2.1 of 1409 [I-D.ietf-spring-segment-routing-policy]. 1411 The Policy Name sub-TLV may exceed 255 bytes length due to long 1412 policy name. Therefore a 2-octet length is required. According to 1413 [I-D.ietf-idr-tunnel-encaps], the first bit of the sub-TLV codepoint 1414 defines the size of the length field. Therefore, for the Policy Name 1415 sub-TLV a code point of 128 or higher is used. 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 as defined in 1445 [I-D.ietf-idr-tunnel-encaps] is used to steer traffic into a policy. 1447 When the Color Extended Community is used for the purpose of steering 1448 the traffic into an SR Policy, two bits from the Flags field (as 1449 defined in [I-D.ietf-idr-tunnel-encaps]) are used as follows: 1451 1 1452 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 |C O| RESERVED | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 where CO bits are defined as the "Color-Only" bits. 1458 [I-D.ietf-spring-segment-routing-policy] defines the influence of 1459 these bits on the automated steering of BGP Payload traffic onto SR 1460 Policies. 1462 4. SR Policy Operations 1464 As described in this document, BGP is not the actual consumer of an 1465 SR Policy NLRI. BGP is in charge of the origination and propagation 1466 of the SR Policy NLRI but its installation and use is outside the 1467 scope of BGP. The details of SR Policy installation and use are 1468 specified in [I-D.ietf-spring-segment-routing-policy]. 1470 4.1. Advertisement of SR Policies 1472 Typically, but not limited to, an SR Policy is computed by a 1473 controller or a path computation engine (PCE) and originated by a BGP 1474 speaker on its behalf. 1476 Multiple SR Policy NLRIs may be present with the same tuple but with different content when these SR policies are 1478 intended for different head-ends. 1480 The distinguisher of each SR Policy NLRI prevents undesired BGP route 1481 selection among these SR Policy NLRIs and allows their propagation 1482 across route reflectors [RFC4456]. 1484 Moreover, one or more route-target SHOULD be attached to the 1485 advertisement, where each route-target identifies one or more 1486 intended head-ends for the advertised SR Policy update. 1488 If no route-target is attached to the SR Policy NLRI, then it is 1489 assumed that the originator sends the SR Policy update directly 1490 (e.g., through a BGP session) to the intended receiver. In such 1491 case, the NO_ADVERTISE community MUST be attached to the SR Policy 1492 update. 1494 4.2. Reception of an SR Policy NLRI 1496 On reception of an SR Policy NLRI, a BGP speaker first determines if 1497 it is acceptable and then if it is usable. 1499 4.2.1. Acceptance of an SR Policy NLRI 1501 When a BGP speaker receives an SR Policy NLRI from a neighbor it MUST 1502 first determine if it's acceptable. The following rules apply in 1503 addition to the validation described in Section 5: 1505 o The SR Policy NLRI MUST include a distinguisher, color and 1506 endpoint field which implies that the length of the NLRI MUST be 1507 either 12 or 24 octets (depending on the address family of the 1508 endpoint). 1510 o The SR Policy update MUST have either the NO_ADVERTISE community 1511 or at least one route-target extended community in IPv4-address 1512 format or both. If a router supporting this specification 1513 receives an SR Policy update with no route-target extended 1514 communities and no NO_ADVERTISE community, the update MUST be 1515 considered as malformed. 1517 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1518 Update and MUST have a Tunnel Type TLV set to SR Policy (codepoint 1519 is 15). 1521 A router that receives an SR Policy update that is not valid 1522 according to these criteria MUST treat the update as malformed and 1523 the SR Policy candidate path MUST NOT be passed to the SRPM. 1525 4.2.2. Usable SR Policy NLRI 1527 A SR Policy update that has been determined to be acceptable is 1528 further evaluated for its usability by the receiving node. 1530 An SR Policy NLRI update without any route-target extended community 1531 but having the NO_ADVERTISE community is considered usable. 1533 If one or more route-targets are present, then at least one route- 1534 target MUST match the BGP Identifier of the receiver for the update 1535 to be considered usable. The BGP Identifier is defined in [RFC4271] 1536 as a 4 octet IPv4 address. Therefore, the route-target extended 1537 community MUST be of the same format. 1539 If one or more route-targets are present and none matches the local 1540 BGP Identifier, then, while the SR Policy NLRI is acceptable, it is 1541 not usable on the receiver node. 1543 When the SR Policy tunnel type includes any sub-TLV that is 1544 unrecognized or unsupported, the update SHOULD NOT be considered 1545 usable. An implementation MAY provide an option for ignoring 1546 unsupported sub-TLVs. 1548 4.2.3. Passing a usable SR Policy NLRI to the SRPM 1550 Once BGP on the receiving node has determined that the SR Policy NLRI 1551 is usable, it passes the SR Policy candidate path to the SRPM. Note 1552 that, along with the candidate path details, BGP also passes the 1553 originator information for breaking ties in the candidate path 1554 selection process as described in section 2.4 in 1555 [I-D.ietf-spring-segment-routing-policy]. 1557 When an update for an SR Policy NLRI results in it's becoming 1558 unusable, BGP MUST delete it's corresponding SR Policy candidate path 1559 from the SRPM. 1561 The SRPM applies the rules defined in section 2 in 1562 [I-D.ietf-spring-segment-routing-policy] to determine whether the SR 1563 Policy candidate path is valid and to select the best candidate path 1564 among the valid ones for a given SR Policy. 1566 4.2.4. Propagation of an SR Policy 1568 SR Policy NLRIs that have been determined acceptable and valid can be 1569 evaluated for propagation, even the ones that are not usable. 1571 SR Policy NLRIs that have the NO_ADVERTISE community attached to them 1572 MUST NOT be propagated. 1574 By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate 1575 it to any EBGP neighbor. An implementation MAY provide an explicit 1576 configuration to override this and enable propagation of acceptable 1577 SR Policy NLRIs to specific EBGP neighbors. 1579 A BGP node advertises a received SR Policy NLRI to its IBGP neighbors 1580 according to normal IBGP propagation rules. 1582 By default, a BGP node receiving an SR Policy NLRI SHOULD NOT remove 1583 route-target extended community before propagation. An 1584 implementation MAY provide support for configuration to filter and/or 1585 remove route-target extended community before propagation. 1587 5. Error Handling 1589 This section describes the error handling actions, as described in 1590 [RFC7606], that are to be performed for handling of BGP update 1591 messages for BGP SR Policy SAFI. 1593 A BGP Speaker MUST perform the following syntactic validation of the 1594 SR Policy NLRI to determine if it is malformed. This includes the 1595 validation of length of each NLRI and the total length of the 1596 MP_REACH_NLRI and MP_UNREACH_NLRI attributes. 1598 When the error determined allows for the router to skip the malformed 1599 NLRI(s) and continue processing of the rest of the update message, 1600 then it MUST handle such malformed NLRIs as 'Treat-as-withdraw'. In 1601 other cases, where the error in the NLRI encoding results in the 1602 inability to process the BGP update message (e.g. length related 1603 encoding errors), then the router SHOULD handle such malformed NLRIs 1604 as 'AFI/SAFI disable' when other AFI/SAFI besides SR Policy are being 1605 advertised over the same session. Alternately, the router MUST 1606 perform 'session reset' when the session is only being used for SR 1607 Policy or when it 'AFI/SAFI disable' action is not possible. 1609 The validation of the TLVs/sub-TLVs introduced in this document and 1610 defined in their respective sub-sections of Section 2.4 MUST be 1611 performed to determine if they are malformed or invalid. The 1612 validation of the Tunnel Encapsulation Attribute itself and the other 1613 TLVs/sub-TLVs specified in [I-D.ietf-idr-tunnel-encaps] MUST be done 1614 as described in that document. In case of any error detected, either 1615 at the attribute or its TLV/sub-TLV level, the "treat-as-withdraw" 1616 strategy MUST be applied. This is because an SR Policy update 1617 without a valid Tunnel Encapsulation Attribute (comprising of all 1618 valid TLVs/sub-TLVs) is not usable. 1620 An SR Policy update that is determined to be not acceptable, and 1621 therefore malformed, based on rules described in Section 4.2.1 MUST 1622 be handled by the "treat-as-withdraw" strategy. 1624 The validation of the individual fields of the TLVs/sub-TLVs defined 1625 in Section 2.4 are beyond the scope of BGP as they are handled by the 1626 SRPM as described in the individual TLV/sub-TLV sub-sections. A BGP 1627 implementation MUST NOT perform semantic verification of such fields 1628 nor consider the SR Policy update to be invalid or not acceptable/ 1629 usable on the basis of such a validation. 1631 An implementation SHOULD log an error for any errors found during the 1632 above validation for further analysis. 1634 6. IANA Considerations 1636 This document requests codepoint allocations for new TLVs/sub-TLVs in 1637 following existing registries: 1639 o Subsequent Address Family Identifiers (SAFI) Parameters registry 1641 o BGP Tunnel Encapsulation Attribute Tunnel Types registry under the 1642 BGP Parameters registry 1644 o BGP Tunnel Encapsulation Attribute sub-TLVs registry under the BGP 1645 Parameters registry 1647 o Color Extended Community Flags registry under the BGP Extended 1648 Communities registry 1650 This document also requests creation of the following new registries: 1652 o SR Policy Segment List Sub-TLVs under the BGP Parameters registry 1654 o SR Policy Binding SID Flags under the BGP Parameters registry 1656 o SR Policy Segment Flags under the BGP Parameters registry 1658 6.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1659 Parameters 1661 This document defines a new SAFI in the registry "Subsequent Address 1662 Family Identifiers (SAFI) Parameters" that has been assigned a 1663 codepoint by IANA as follows: 1665 Codepoint Description Reference 1666 ----------------------------------------------- 1667 73 SR Policy SAFI This document 1669 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1671 This document defines a new Tunnel-Type in the registry "BGP Tunnel 1672 Encapsulation Attribute Tunnel Types" that has been assigned a 1673 codepoint by IANA as follows: 1675 Codepoint Description Reference 1676 -------------------------------------------------- 1677 15 SR Policy Type This document 1679 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1681 This document defines new sub-TLVs in the registry "BGP Tunnel 1682 Encapsulation Attribute sub-TLVs" that has been assigned codepoints 1683 by IANA as follows: 1685 Codepoint Description Reference 1686 ------------------------------------------------------ 1687 12 Preference sub-TLV This document 1688 13 Binding SID sub-TLV This document 1689 14 ENLP sub-TLV This document 1690 15 Priority sub-TLV This document 1691 TBD SRv6 Binding SID sub-TLV This document 1692 128 Segment List sub-TLV This document 1693 129 Policy CP Name sub-TLV This document 1694 TBD Policy Name sub-TLV This document 1696 6.4. Existing Registry: Color Extended Community Flags 1698 This document requests allocations in the registry called "Color 1699 Extended Community Flags" under the "BGP Tunnel Encapsulation 1700 Parameters" grouping. 1702 Following bits are to be allocated: 1704 Bit 1705 Position Description Reference 1706 ------------------------------------------------------------------ 1707 0-1 Color-only bits This document 1709 6.5. New Registry: SR Policy Segment List Sub-TLVs 1711 This document requests creation of a new registry called "SR Policy 1712 Segment List Sub-TLVs". The allocation policy of this registry is 1713 "Specification Required" according to [RFC8126]. 1715 Following initial Sub-TLV codepoints are assigned by this document: 1717 Value Description Reference 1718 ------------------------------------------------------------------------ 1719 1 Type A MPLS SID sub-TLV This document 1720 2 Deprecated This document 1721 3 Type C IPv4 Node and SID sub-TLV This document 1722 4 Type D IPv6 Node and SID for SR-MPLS sub-TLV This document 1723 5 Type E IPv4 Node, index and SID sub-TLV This document 1724 6 Type F IPv4 Local/Remote addresses and SID sub-TLV This document 1725 7 Type G IPv6 Node, index for remote and local pair This document 1726 and SID for SR-MPLS sub-TLV 1727 8 Type H IPv6 Local/Remote addresses and SID sub-TLV This document 1728 9 Weight sub-TLV This document 1729 10 Deprecated This document 1730 11 Deprecated This document 1731 12 Deprecated This document 1732 13 Type B SRv6 SID sub-TLV This document 1733 14 Type I IPv6 Node and SID for SRv6 sub-TLV This document 1734 15 Type J IPv6 Node, index for remote and local pair This document 1735 and SID for SRv6 sub-TLV 1736 16 Type K IPv6 Local/Remote addresses and SID for This document 1737 SRv6 sub-TLV 1739 6.6. New Registry: SR Policy Binding SID Flags 1741 This document requests creation of a new registry called "SR Policy 1742 Binding SID Flags". The allocation policy of this registry is 1743 "Specification Required" according to [RFC8126]. 1745 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 creation of a new registry called "SR Policy 1756 SRv6 Binding SID Flags". The allocation policy of this registry is 1757 "Specification Required" according to [RFC8126]. 1759 Following flags are defined: 1761 Bit Description Reference 1762 ----------------------------------------------------------------- 1763 0 Specified-BSID-Only Flag (S-Flag) This document 1764 1 Drop Upon Invalid Flag (I-Flag) This document 1765 2 SRv6 Endpoint Behavior & 1766 SID Structure Flag (B-Flag) This document 1767 3-7 Unassigned 1769 6.8. New Registry: SR Policy Segment Flags 1771 This document requests creation of a new registry called "SR Policy 1772 Segment Flags". The allocation policy of this registry is 1773 "Specification Required" according to [RFC8126]. 1775 Following Flags are defined: 1777 Bit Description Reference 1778 ------------------------------------------------------------------ 1779 0 Segment Verification Flag (V-Flag) This document 1780 1 SR Algorithm Flag (A-Flag) This document 1781 2 SID Specified Flag (S-Flag) This document 1782 3 SRv6 Endpoint Behavior & 1783 SID Structure Flag (B-Flag) This document 1784 4-7 Unassigned 1786 6.9. Guidance for Designated Experts 1788 In all cases of review by the Designated Expert (DE) described here, 1789 the DE is expected to ascertain the existence of suitable 1790 documentation (a specification) as described in [RFC8126]. The DE is 1791 also expected to check the clarity of purpose and use of the 1792 requested code points. Additionally, the DE must verify that any 1793 request for one of these code points has been made available for 1794 review and comment within the IETF: the DE will post the request to 1795 the IDR Working Group mailing list (or a successor mailing list 1796 designated by the IESG). If the request comes from within the IETF, 1797 it should be documented in an Internet-Draft. Lastly, the DE must 1798 ensure that any other request for a code point does not conflict with 1799 work that is active or already published within the IETF. 1801 7. Security Considerations 1803 The security mechanisms of the base BGP security model apply to the 1804 extensions described in this document as well. See the Security 1805 Considerations section of [RFC4271] for a discussion of BGP security. 1806 Also refer to [RFC4272] and [RFC6952] for analysis of security issues 1807 for BGP. 1809 The BGP SR Policy extensions specified in this document enable 1810 traffic engineering and service programming use-cases within the SR 1811 domain as described in [I-D.ietf-spring-segment-routing-policy] . SR 1812 operates within a trusted SR domain [RFC8402] and its security 1813 considerations also apply to BGP sessions when carrying SR Policy 1814 information. The SR Policies distributed by BGP are expected to be 1815 used entirely within this trusted SR domain i.e. within a single AS 1816 or between multiple AS/domains within a single provider network. 1817 Therefore, precaution is necessary to ensure that the SR Policy 1818 information advertised via BGP sessions is limited to nodes in a 1819 secure manner within this trusted SR domain. BGP peering sessions 1820 for address-families other than SR Policy SAFI may be setup to 1821 routers outside the SR domain. The isolation of BGP SR Policy SAFI 1822 peering sessions may be used to ensure that the SR Policy information 1823 is not advertised by accident or error to an EBGP peering session 1824 outside the SR domain. 1826 Additionally, it may be considered that the export of SR Policy 1827 information as described in this document constitutes a risk to 1828 confidentiality of mission-critical or commercially sensitive 1829 information about the network (more specifically endpoint/node 1830 addresses, SR SIDs and the SR Policies deployed). BGP peerings are 1831 not automatic and require configuration; thus, it is the 1832 responsibility of the network operator to ensure that only trusted 1833 nodes (that include both routers and controller applications) within 1834 the SR domain are configured to receive such information. 1836 8. Acknowledgments 1838 The authors of this document would like to thank Shyam Sethuram, John 1839 Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha, Bruno Decraene, 1840 Gurusiddesh Nidasesi, Kausik Majumdar, Zafar Ali, Swadesh Agarwal, 1841 Jakob Heitz, Viral Patel, Peng Shaofu and Cheng Li for their comments 1842 and review of this document. 1844 9. Contributors 1846 Arjun Sreekantiah 1847 Cisco Systems 1848 US 1850 Email: asreekan@cisco.com 1852 Acee Lindem 1853 Cisco Systems 1854 US 1856 Email: acee@cisco.com 1857 Siva Sivabalan 1858 Cisco Systems 1859 US 1861 Email: msiva@cisco.com 1863 Imtiyaz Mohammad 1864 Arista Networks 1865 India 1867 Email: imtiyaz@arista.com 1869 Gaurav Dawra 1870 Cisco Systems 1871 US 1873 Email: gdawra.ietf@gmail.com 1875 10. References 1877 10.1. Normative References 1879 [I-D.ietf-idr-tunnel-encaps] 1880 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 1881 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 1882 encaps-20 (work in progress), November 2020. 1884 [I-D.ietf-spring-segment-routing-policy] 1885 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1886 P. Mattes, "Segment Routing Policy Architecture", draft- 1887 ietf-spring-segment-routing-policy-09 (work in progress), 1888 November 2020. 1890 [I-D.ietf-spring-srv6-network-programming] 1891 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 1892 Matsushima, S., and Z. Li, "SRv6 Network Programming", 1893 draft-ietf-spring-srv6-network-programming-24 (work in 1894 progress), October 2020. 1896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1897 Requirement Levels", BCP 14, RFC 2119, 1898 DOI 10.17487/RFC2119, March 1997, 1899 . 1901 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1902 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1903 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1904 . 1906 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1907 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1908 DOI 10.17487/RFC4271, January 2006, 1909 . 1911 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1912 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1913 February 2006, . 1915 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1916 "Multiprotocol Extensions for BGP-4", RFC 4760, 1917 DOI 10.17487/RFC4760, January 2007, 1918 . 1920 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1921 Patel, "Revised Error Handling for BGP UPDATE Messages", 1922 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1923 . 1925 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1926 Writing an IANA Considerations Section in RFCs", BCP 26, 1927 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1928 . 1930 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1931 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1932 May 2017, . 1934 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1935 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1936 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1937 July 2018, . 1939 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1940 and J. Hardwick, "Path Computation Element Communication 1941 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1942 DOI 10.17487/RFC8664, December 2019, 1943 . 1945 10.2. Informational References 1947 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1948 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1949 . 1951 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1952 Reflection: An Alternative to Full Mesh Internal BGP 1953 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1954 . 1956 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1957 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1958 and Authentication for Routing Protocols (KARP) Design 1959 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1960 . 1962 Appendix A. Deprecated Segment Sub-TLVs 1964 This section describes the encoding of Segment Sub-TLVs that were 1965 specified in a previous version of this document and subsequently 1966 deprecated. 1968 A.1. Type B-Deprecated: SID only, in the form of IPv6 address 1970 The Type B-Deprecated Segment Sub-TLV encodes a single SRv6 SID. The 1971 format is as follows: 1973 0 1 2 3 1974 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 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 | Type | Length | Flags | RESERVED | 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 // SRv6 SID (16 octets) // 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 where: 1983 o Type: 2. 1985 o Length is 18. 1987 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 1989 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1990 transmission and MUST be ignored on receipt. 1992 o SRv6 SID: 16 octets of IPv6 address. 1994 A.2. Type I-Deprecated: IPv6 Node Address with optional SRv6 SID 1996 The Type I-Deprecated Segment Sub-TLV encodes an IPv6 node address, 1997 SR Algorithm and an optional SRv6 SID. The format is as follows: 1999 0 1 2 3 2000 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 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 | Type | Length | Flags | SR Algorithm | 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 // IPv6 Node Address (16 octets) // 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 // SRv6 SID (optional, 16 octets) // 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 where: 2011 o Type: 10. 2013 o Length is 34 when the SRv6 SID is present else is 18. 2015 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 2017 o SR Algorithm: 1 octet specifying SR Algorithm as described in 2018 section 3.1.1 in [RFC8402], when A-Flag as defined in 2019 Section 2.4.4.2.12 is present. SR Algorithm is used by SRPM as 2020 described in section 4 in 2021 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 2022 encoded, this field SHOULD be set to zero on transmission and MUST 2023 be ignored on receipt. 2025 o IPv6 Node Address: a 16 octet IPv6 address. 2027 o SRv6 SID: optional, 16 octet IPv6 address. 2029 A.3. Type J-Deprecated: IPv6 Address + Interface ID for local and 2030 remote pair for SRv6 with optional SID 2032 The Type J-Deprecated Segment Sub-TLV encodes an IPv6 Link Local 2033 adjacency with local node address, a local interface identifier 2034 (Local Interface ID), remote IPv6 node address, a remote interface 2035 identifier (Remote Interface ID) and an optional SRv6 SID. The 2036 format is as follows: 2038 0 1 2 3 2039 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 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 | Type | Length | Flags | RESERVED | 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 | Local Interface ID (4 octets) | 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 // IPv6 Local Node Address (16 octets) // 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 | Remote Interface ID (4 octets) | 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 // IPv6 Remote Node Address (16 octets) // 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 // SRv6 SID (optional, 16 octets) // 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 where: 2056 o Type: 11. 2058 o Length is 58 when the SRv6 SID is present else is 42. 2060 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 2062 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 2063 transmission and MUST be ignored on receipt. 2065 o Local Interface ID: 4 octets of interface index as defined in 2066 [RFC8664]. 2068 o IPv6 Local Node Address: a 16 octet IPv6 address. 2070 o Remote Interface ID: 4 octets of interface index as defined in 2071 [RFC8664]. The value MAY be set to zero when the local node 2072 address and interface identifiers are sufficient to describe the 2073 link. 2075 o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY 2076 be set to zero when the local node address and interface 2077 identifiers are sufficient to describe the link. 2079 o SRv6 SID: optional, 16 octet IPv6 address. 2081 A.4. Type K-Deprecated: IPv6 Local and Remote addresses for SRv6 with 2082 optional SID 2084 The Type K-Deprecated Segment Sub-TLV encodes an adjacency local 2085 address, an adjacency remote address and an optional SRv6 SID. The 2086 format is as follows: 2088 0 1 2 3 2089 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 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2091 | Type | Length | Flags | RESERVED | 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2093 // Local IPv6 Address (16 octets) // 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 // Remote IPv6 Address (16 octets) // 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 // SRv6 SID (optional, 16 octets) // 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 where: 2101 o Type: 12. 2103 o Length is 50 when the SRv6 SID is present else is 34. 2105 o Flags: 1 octet of flags as defined in Section 2.4.4.2.12. 2107 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 2108 transmission and MUST be ignored on receipt. 2110 o Local IPv6 Address: a 16 octet IPv6 address. 2112 o Remote IPv6 Address: a 16 octet IPv6 address. 2114 o SRv6 SID: optional, 16 octet IPv6 address. 2116 Authors' Addresses 2118 Stefano Previdi 2119 Individual 2120 IT 2122 Email: stefano@previdi.net 2123 Clarence Filsfils 2124 Cisco Systems 2125 Brussels 2126 BE 2128 Email: cfilsfil@cisco.com 2130 Ketan Talaulikar (editor) 2131 Cisco Systems 2132 India 2134 Email: ketant@cisco.com 2136 Paul Mattes 2137 Microsoft 2138 One Microsoft Way 2139 Redmond, WA 98052 2140 USA 2142 Email: pamattes@microsoft.com 2144 Eric Rosen 2145 Juniper Networks 2146 10 Technology Park Drive 2147 Westford, MA 01886 2148 US 2150 Email: erosen@juniper.net 2152 Dhanendra Jain 2153 Google 2155 Email: dhanendra.ietf@gmail.com 2157 Steven Lin 2158 Google 2160 Email: stevenlin@google.com