idnits 2.17.1 draft-ietf-idr-segment-routing-te-policy-09.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 (May 28, 2020) is 1429 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-15 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-sr-policy-considerations-05 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: November 29, 2020 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 May 28, 2020 16 Advertising Segment Routing Policies in BGP 17 draft-ietf-idr-segment-routing-te-policy-09 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 November 29, 2020. 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 . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. SR Policy SAFI and NLRI . . . . . . . . . . . . . . . . . 5 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. Segment List Sub-TLV . . . . . . . . . . . . . . . . 11 76 2.4.4. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 24 77 2.4.5. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 25 78 2.4.6. Policy Candidate Path Name Sub-TLV . . . . . . . . . 26 79 3. Color Extended Community . . . . . . . . . . . . . . . . . . 27 80 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 27 81 4.1. Advertisement of SR Policies . . . . . . . . . . . . . . 28 82 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 28 83 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 28 84 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 29 85 4.2.3. Passing a usable SR Policy NLRI to the SRPM . . . . . 29 86 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 30 87 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 30 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 89 6.1. Existing Registry: Subsequent Address Family Identifiers 90 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 32 91 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute 92 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 32 93 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute 94 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 32 95 6.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 32 96 6.5. New Registry: SR Policy Binding SID Flags . . . . . . . . 33 97 6.6. New Registry: SR Policy Segment Flags . . . . . . . . . . 33 98 6.7. New Registry: Color Extended Community Field . . . . . . 34 99 6.8. Guidance for Designated Experts . . . . . . . . . . . . . 34 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 101 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 102 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 104 10.1. Normative References . . . . . . . . . . . . . . . . . . 36 105 10.2. Informational References . . . . . . . . . . . . . . . . 37 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 108 1. Introduction 110 Segment Routing (SR) [RFC8402] allows a headend node to steer a 111 packet flow along any path. Intermediate per-flow states are 112 eliminated thanks to source routing. 114 The headend node is said to steer a flow into a SR Policy. 116 The header of a packet steered in an SR Policy is augmented with the 117 ordered list of segments associated with that SR Policy. 119 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 120 Policy and steering into an SR Policy. These apply equally to the 121 MPLS and IPv6 (known as SRv6) data plane instantiations of Segment 122 Routing with their respective representations of segments as SR-MPLS 123 SID and SRv6 SID as described in [RFC8402]. 125 [I-D.filsfils-spring-sr-policy-considerations] describes some of the 126 implementation aspects of the SR Policy Headend Architecture and 127 introduces the notion of an SR Policy Module (SRPM) that performs the 128 functionality as highlighted in section 2 of 129 [I-D.ietf-spring-segment-routing-policy]: 131 o The SRPM may learn multiple candidate paths for an SR Policy via 132 various mechanisms (CLI, NetConf, PCEP or BGP). 134 o The SRPM selects the best candidate path for the SR Policy. 136 o The SRPM binds a BSID to the selected candidate path of the SR 137 Policy. 139 o The SRPM installs the selected candidate path and its BSID in the 140 forwarding plane. 142 This document specifies the way to use BGP to distribute one or more 143 of the candidate paths of an SR Policy to the headend of that policy. 144 The document describes the functionality that resides in the BGP 145 process and, as appropriate, provides references for the 146 functionality which is outside the scope of BGP (i.e. resides within 147 SRPM on the headend node). 149 This document specifies a way of representing SR Policy candidate 150 paths in BGP UPDATE messages. BGP can then be used to propagate the 151 SR Policy candidate paths to the headend nodes in the network. The 152 usual BGP rules for BGP propagation and "bestpath selection" are 153 used. At the headend of a specific policy, this will result in one 154 or more candidate paths being installed into the "BGP table". These 155 paths are then passed to the SRPM. The SRPM may compare them to 156 candidate paths learned via other mechanisms, and will choose one or 157 more paths to be installed in the data plane. BGP itself does not 158 install SR Policy candidate paths into the data plane. 160 This document defines a new BGP address family (SAFI). In UPDATE 161 messages of that address family, the NLRI identifies an SR Policy 162 Candidate Path, and the attributes encode the segment lists and other 163 details of that SR Policy Candidate Path. 165 While for simplicity we may write that BGP advertises an SR Policy, 166 it has to be understood that BGP advertises a candidate path of an SR 167 policy and that this SR Policy might have several other candidate 168 paths provided via BGP (via an NLRI with a different distinguisher as 169 defined in this document), PCEP, NETCONF or local policy 170 configuration. 172 Typically, a controller defines the set of policies and advertise 173 them to policy head-end routers (typically ingress routers). The 174 policy advertisement uses BGP extensions defined in this document. 175 The policy advertisement is, in most but not all of the cases, 176 tailored for a specific policy head-end. In this case the 177 advertisement may be sent on a BGP session to that head-end and not 178 propagated any further. 180 Alternatively, a router (i.e., a BGP egress router) advertises SR 181 Policies representing paths to itself. In this case, it is possible 182 to send the policy to each head-end over a BGP session to that head- 183 end, without requiring any further propagation of the policy. 185 An SR Policy intended only for the receiver will, in most cases, not 186 traverse any Route Reflector (RR, [RFC4456]). 188 In some situations, it is undesirable for a controller or BGP egress 189 router to have a BGP session to each policy head-end. In these 190 situations, BGP Route Reflectors may be used to propagate the 191 advertisements, or it may be necessary for the advertisement to 192 propagate through a sequence of one or more AS. To make this 193 possible, an attribute needs to be attached to the advertisement that 194 enables a BGP speaker to determine whether it is intended to be a 195 head-end for the advertised policy. This is done by attaching one or 196 more Route Target Extended Communities to the advertisement 197 ([RFC4360]). 199 The BGP extensions for the advertisement of SR Policies include 200 following components: 202 o A new Subsequent Address Family Identifier (SAFI) whose NLRI 203 identifies an SR Policy. 205 o A new Tunnel Type identifier for SR Policy, and a set of sub-TLVs 206 to be inserted into the Tunnel Encapsulation Attribute (as defined 207 in [I-D.ietf-idr-tunnel-encaps]) specifying segment lists of the 208 SR Policy, as well as other information about the SR Policy. 210 o One or more IPv4 address format route-target extended community 211 ([RFC4360]) attached to the SR Policy advertisement and that 212 indicates the intended head-end of such SR Policy advertisement. 214 o The Color Extended Community (as defined in 215 [I-D.ietf-idr-tunnel-encaps]) and used in order to steer traffic 216 into an SR Policy, as described in section 8.4 in 217 [I-D.ietf-spring-segment-routing-policy]. This document 218 (Section 3) modifies the format of the Color Extended Community by 219 using the two leftmost bits of the RESERVED field. 221 1.1. Requirements Language 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 225 "OPTIONAL" in this document are to be interpreted as described in BCP 226 14 [RFC2119] [RFC8174] when, and only when, they appear in all 227 capitals, as shown here. 229 2. SR Policy Encoding 231 2.1. SR Policy SAFI and NLRI 233 A new SAFI is defined: the SR Policy SAFI with codepoint 73. The AFI 234 used MUST be IPv4(1) or IPv6(2). 236 The SR Policy SAFI uses a new NLRI defined as follows: 238 +------------------+ 239 | NLRI Length | 1 octet 240 +------------------+ 241 | Distinguisher | 4 octets 242 +------------------+ 243 | Policy Color | 4 octets 244 +------------------+ 245 | Endpoint | 4 or 16 octets 246 +------------------+ 248 where: 250 o NLRI Length: 1 octet of length expressed in bits as defined in 251 [RFC4760]. When AFI = 1 value MUST be 96 and when AFI = 2 value 252 MUST be 192. 254 o Distinguisher: 4-octet value uniquely identifying the policy in 255 the context of tuple. The distinguisher has no 256 semantic value and is solely used by the SR Policy originator to 257 make unique (from an NLRI perspective) multiple candidate paths of 258 the same SR Policy. 260 o Policy Color: 4-octet value identifying (with the endpoint) the 261 policy. The color is used to match the color of the destination 262 prefixes to steer traffic into the SR Policy as specified in 263 [I-D.ietf-spring-segment-routing-policy]. 265 o Endpoint: identifies the endpoint of a policy. The Endpoint may 266 represent a single node or a set of nodes (e.g., an anycast 267 address). The Endpoint is an IPv4 (4-octet) address or an IPv6 268 (16-octet) address according to the AFI of the NLRI. 270 The color and endpoint are used to automate the steering of BGP 271 Payload prefixes on SR Policy as described in 272 [I-D.ietf-spring-segment-routing-policy]. 274 The NLRI containing the SR Policy is carried in a BGP UPDATE message 275 [RFC4271] using BGP multiprotocol extensions [RFC4760] with an AFI of 276 1 or 2 (IPv4 or IPv6) and with a SAFI of 73. 278 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 279 attribute with the SR Policy SAFI MUST also carry the BGP mandatory 280 attributes. In addition, the BGP update message MAY also contain any 281 of the BGP optional attributes. 283 The next-hop network address field in SR Policy SAFI (73) updates may 284 be either a 4 octet IPv4 address or a 16 octet IPv6 address, 285 independent of the SR Policy AFI. The length field of the next-hop 286 address specifies the next-hop address family. If the next-hop 287 length is 4, then the next-hop is an IPv4 address; if the next-hop 288 length is 16, then it is a global IPv6 address; and if the next-hop 289 length is 32, then it has a global IPv6 address followed by a link- 290 local IPv6 address. The setting of the next-hop field and its 291 attendant processing is governed by standard BGP procedures as 292 described in section 3 in [RFC4760]. 294 It is important to note that any BGP speaker receiving a BGP message 295 with an SR Policy NLRI, will process it only if the NLRI is among the 296 best paths as per the BGP best path selection algorithm. In other 297 words, this document leverages the existing BGP propagation and 298 bestpath selection rules. Details of the procedures are described in 299 Section 4. 301 It has to be noted that if several candidate paths of the same SR 302 Policy (endpoint, color) are signaled via BGP to a head-end, it is 303 RECOMMENDED that each NLRI use a different distinguisher. If BGP has 304 installed into the BGP table two advertisements whose respective 305 NLRIs have the same color and endpoint, but different distinguishers, 306 both advertisements are passed to the SRPM as different candidate 307 paths along with their respective originator information (i.e. ASN 308 and BGP Router-ID) as described in section 2.4 of 309 [I-D.ietf-spring-segment-routing-policy]. The ASN would be the ASN 310 of origin and the BGP Router-ID is determined in the following order: 312 o From the Route Origin Community [RFC4360] if present and carrying 313 an IP Address 315 o As the BGP Originator ID [RFC4456] if present 317 o As the BGP Router-ID of the peer from which the update was 318 received as a last resort. 320 2.2. SR Policy and Tunnel Encapsulation Attribute 322 The content of the SR Policy is encoded in the Tunnel Encapsulation 323 Attribute defined in [I-D.ietf-idr-tunnel-encaps] using a new Tunnel- 324 Type called SR Policy Type with codepoint 15. 326 The SR Policy Encoding structure is as follows: 328 SR Policy SAFI NLRI: 329 Attributes: 330 Tunnel Encaps Attribute (23) 331 Tunnel Type: SR Policy 332 Binding SID 333 Preference 334 Priority 335 Policy Name 336 Explicit NULL Label Policy (ENLP) 337 Segment List 338 Weight 339 Segment 340 Segment 341 ... 342 ... 343 where: 345 o SR Policy SAFI NLRI is defined in Section 2.1. 347 o Tunnel Encapsulation Attribute is defined in 348 [I-D.ietf-idr-tunnel-encaps]. 350 o Tunnel-Type is set to 15. 352 o Preference, Binding SID, Priority, Policy Name, ENLP, Segment- 353 List, Weight and Segment sub-TLVs are defined in this document. 355 o Additional sub-TLVs may be defined in the future. 357 A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV 358 of type "SR Policy". 360 2.3. Remote Endpoint and Color 362 The Remote Endpoint and Color sub-TLVs, as defined in 363 [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy 364 encodings. 366 The Remote Endpoint and Color Sub-TLVs of the Tunnel Encapsulation 367 Attribute are not used for SR Policy encodings and therefore their 368 value is irrelevant in the context of the SR Policy SAFI NLRI. If 369 present, the Remote Endpoint sub-TLV and the Color sub-TLV MUST be 370 ignored by the BGP speaker. 372 2.4. SR Policy Sub-TLVs 374 This section specifies the sub-TLVs defined for encoding the 375 information about the SR Policy. 377 Preference, Binding SID, Segment-List, Priority, Policy Name and 378 Explicit NULL Label Policy are the new sub-TLVs of the BGP Tunnel 379 Encapsulation Attribute [I-D.ietf-idr-tunnel-encaps] being defined in 380 this section. 382 Weight and Segment are sub-TLVs of the new Segment-List sub-TLV 383 mentioned above. 385 None of the sub-TLVs defined in the following sub-sections have any 386 effect on the BGP bestpath selection or propagation procedures. 387 These sub-TLVs are not used by BGP and are instead passed on to SRPM 388 as SR Policy Candidate Path information for further processing 389 described in [I-D.ietf-spring-segment-routing-policy] . 391 2.4.1. Preference Sub-TLV 393 The Preference sub-TLV is used to carry the preference of the SR 394 Policy candidate path. The contents of this sub-TLV are used by the 395 SRPM as described in section 2.7 in 396 [I-D.ietf-spring-segment-routing-policy]. 398 The Preference sub-TLV is optional and it MUST NOT appear more than 399 once in the SR Policy. 401 The Preference sub-TLV has following format: 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Type | Length | Flags | RESERVED | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Preference (4 octets) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 where: 413 o Type: 12 415 o Length: 6. 417 o Flags: 1 octet of flags. None are defined at this stage. Flags 418 SHOULD be set to zero on transmission and MUST be ignored on 419 receipt. 421 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 422 transmission and MUST be ignored on receipt. 424 o Preference: a 4-octet value. 426 2.4.2. Binding SID Sub-TLV 428 The Binding SID sub-TLV is used to signal the binding SID related 429 information of the SR Policy candidate path. The contents of this 430 sub-TLV are used by the SRPM as described in section 6 in 431 [I-D.ietf-spring-segment-routing-policy]. 433 The Binding SID sub-TLV is optional and it MUST NOT appear more than 434 once in the SR Policy. 436 The Binding SID sub-TLV has the following format: 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Type | Length | Flags | RESERVED | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Binding SID (variable, optional) | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 where: 448 o Type: 13 450 o Length: specifies the length of the value field not including Type 451 and Length fields. Can be 2 or 6 or 18. 453 o Flags: 1 octet of flags. Following flags are defined in the new 454 registry "SR Policy Binding SID Flags" as described in 455 Section 6.5: 457 0 1 2 3 4 5 6 7 458 +-+-+-+-+-+-+-+-+ 459 |S|I| | 460 +-+-+-+-+-+-+-+-+ 462 where: 464 * S-Flag: This flag encodes the "Specified-BSID-only" behavior. 465 It is used by SRPM as described in section 6.2.3 in 466 [I-D.ietf-spring-segment-routing-policy]. 468 * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It 469 is used by SRPM as described in section 8.2 in 470 [I-D.ietf-spring-segment-routing-policy]. 472 * Unused bits in the Flag octet SHOULD be set to zero upon 473 transmission and MUST be ignored upon receipt. 475 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 476 transmission and MUST be ignored on receipt. 478 o Binding SID: if length is 2, then no Binding SID is present. If 479 length is 6 then the Binding SID is encoded in 4 octets using the 480 format below. TC, S, TTL (Total of 12 bits) are RESERVED and 481 SHOULD be set to zero and MUST be ignored. 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Label | TC |S| TTL | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 If length is 18 then the Binding SID contains a 16-octet SRv6 SID. 491 2.4.3. Segment List Sub-TLV 493 The Segment List sub-TLV encodes a single explicit path towards the 494 endpoint as described in section 5.1 in 495 [I-D.ietf-spring-segment-routing-policy]. The Segment List sub-TLV 496 includes the elements of the paths (i.e., segments) as well as an 497 optional Weight sub-TLV. 499 The Segment List sub-TLV may exceed 255 bytes length due to large 500 number of segments. Therefore a 2-octet length is required. 501 According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- 502 TLV codepoint defines the size of the length field. Therefore, for 503 the Segment List sub-TLV a code point of 128 or higher is used. 505 The Segment List sub-TLV is optional and MAY appear multiple times in 506 the SR Policy. The ordering of Segment List sub-TLVs, each sub-TLV 507 encoding a Segment List, does not matter. 509 The Segment List sub-TLV contains zero or more Segment sub-TLVs and 510 MAY contain a Weight sub-TLV. 512 The Segment List sub-TLV has the following format: 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Type | Length | RESERVED | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 // sub-TLVs // 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 where: 524 o Type: 128. 526 o Length: the total length (not including the Type and Length 527 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 529 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 530 transmission and MUST be ignored on receipt. 532 o sub-TLVs currently defined: 534 * An optional single Weight sub-TLV. 536 * Zero or more Segment sub-TLVs. 538 Validation of an explicit path encoded by the Segment List sub-TLV is 539 beyond the scope of BGP and performed by the SRPM as described in 540 section 5 in [I-D.ietf-spring-segment-routing-policy]. 542 2.4.3.1. Weight Sub-TLV 544 The Weight sub-TLV specifies the weight associated to a given segment 545 list. The contents of this sub-TLV are used only by the SRPM as 546 described in section 2.11 in 547 [I-D.ietf-spring-segment-routing-policy]. 549 The Weight sub-TLV is optional and it MUST NOT appear more than once 550 inside the Segment List sub-TLV. 552 The Weight sub-TLV has the following format: 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Type | Length | Flags | RESERVED | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Weight | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 where: 564 o Type: 9. 566 o Length: 6 568 o Flags: 1 octet of flags. None are defined at this stage. Flags 569 SHOULD be set to zero on transmission and MUST be ignored on 570 receipt. 572 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 573 transmission and MUST be ignored on receipt. 575 2.4.3.2. Segment Sub-TLVs 577 A Segment sub-TLV describes a single segment in a segment list (i.e., 578 a single element of the explicit path). One or more Segment sub-TLVs 579 constitute an explicit path of the SR Policy. The contents of these 580 sub-TLVs are used only by the SRPM as described in section 4 in 581 [I-D.ietf-spring-segment-routing-policy]. 583 The Segment sub-TLVs are optional and MAY appear multiple times in 584 the Segment List sub-TLV. 586 [I-D.ietf-spring-segment-routing-policy] defines several Segment 587 Types: 589 Type A: SID only, in the form of MPLS Label 590 Type B: SID only, in the form of IPv6 address 591 Type C: IPv4 Node Address with optional SID 592 Type D: IPv6 Node Address with optional SID for SR MPLS 593 Type E: IPv4 Address and index with optional SID 594 Type F: IPv4 Local and Remote addresses with optional SID 595 Type G: IPv6 Address and index for local and remote pair with optional 596 SID for SR MPLS 597 Type H: IPv6 Local and Remote addresses with optional SID for SR MPLS 598 Type I: IPv6 Node Address with optional SID for SRv6 599 Type J: IPv6 Address and index for local and remote pair with optional 600 SID for SRv6 601 Type K: IPv6 Local and Remote addresses for SRv6 602 The follow sub-sections specify the sub-TLV used for encoding each of 603 these Segment Types. 605 2.4.3.2.1. Type A: SID only, in the form of MPLS Label 607 The Type A Segment Sub-TLV encodes a single SR-MPLS SID. The format 608 is as follows: 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Type | Length | Flags | RESERVED | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Label | TC |S| TTL | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 where: 620 o Type: 1. 622 o Length is 6. 624 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 626 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 627 transmission and MUST be ignored on receipt. 629 o Label: 20 bits of label value. 631 o TC: 3 bits of traffic class. 633 o S: 1 bit of bottom-of-stack. 635 o TTL: 1 octet of TTL. 637 The following applies to the Type-1 Segment sub-TLV: 639 o The S bit SHOULD be zero upon transmission, and MUST be ignored 640 upon reception. 642 o If the originator wants the receiver to choose the TC value, it 643 sets the TC field to zero. 645 o If the originator wants the receiver to choose the TTL value, it 646 sets the TTL field to 255. 648 o If the originator wants to recommend a value for these fields, it 649 puts those values in the TC and/or TTL fields. 651 o The receiver MAY override the originator's values for these 652 fields. This would be determined by local policy at the receiver. 653 One possible policy would be to override the fields only if the 654 fields have the default values specified above. 656 2.4.3.2.2. Type B: SID only, in the form of IPv6 address 658 The Type B Segment Sub-TLV encodes a single SRv6 SID. The format is 659 as follows: 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Type | Length | Flags | RESERVED | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 // SRv6 SID (16 octets) // 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 where: 671 o Type: 2. 673 o Length is 18. 675 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 677 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 678 transmission and MUST be ignored on receipt. 680 o SRv6 SID: 16 octets of IPv6 address. 682 2.4.3.2.3. Type C: IPv4 Node Address with optional SID 684 The Type C Segment Sub-TLV encodes an IPv4 node address, SR Algorithm 685 and an optional SR-MPLS SID. The format is as follows: 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Type | Length | Flags | SR Algorithm | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | IPv4 Node Address (4 octets) | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | SR-MPLS SID (optional, 4 octets) | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 where: 699 o Type: 3. 701 o Length is 10 when the SR-MPLS SID is present else is 6. 703 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 705 o SR Algorithm: 1 octet specifying SR Algorithm as described in 706 section 3.1.1 in [RFC8402], when A-Flag as defined in 707 Section 2.4.3.2.12 is present. SR Algorithm is used by SRPM as 708 described in section 4 in 709 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 710 encoded, this field SHOULD be set to zero on transmission and MUST 711 be ignored on receipt. 713 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 715 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 716 TTL as defined in Section 2.4.3.2.1. 718 2.4.3.2.4. Type D: IPv6 Node Address with optional SID for SR MPLS 720 The Type D Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 721 and an optional SR-MPLS SID. The format is as follows: 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Type | Length | Flags | SR Algorithm | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 // IPv6 Node Address (16 octets) // 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | SR-MPLS SID (optional, 4 octets) | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 where: 735 o Type: 4 737 o Length is 22 when the SR-MPLS SID is present else is 18. 739 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 741 o SR Algorithm: 1 octet specifying SR Algorithm as described in 742 section 3.1.1 in [RFC8402], when A-Flag as defined in 743 Section 2.4.3.2.12 is present. SR Algorithm is used by SRPM as 744 described in section 4 in 745 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 746 encoded, this field SHOULD be set to zero on transmission and MUST 747 be ignored on receipt. 749 o IPv6 Node Address: a 16 octet IPv6 address representing a node. 751 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 752 TTL as defined in Section 2.4.3.2.1. 754 2.4.3.2.5. Type E: IPv4 Address + Local Interface ID with optional SID 756 The Type E Segment Sub-TLV encodes an IPv4 node address, a local 757 interface Identifier (Local Interface ID) and an optional SR-MPLS 758 SID. The format is as follows: 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Type | Length | Flags | RESERVED | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Local Interface ID (4 octets) | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | IPv4 Node Address (4 octets) | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | SR-MPLS SID (optional, 4 octets) | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 where: 774 o Type: 5. 776 o Length is 14 when the SR-MPLS SID is present else is 10. 778 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 780 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 781 transmission and MUST be ignored on receipt. 783 o Local Interface ID: 4 octets of interface index as defined in 784 [RFC8664]. 786 o IPv4 Node Address: a 4 octet IPv4 address representing a node. 788 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 789 TTL as defined in Section 2.4.3.2.1. 791 2.4.3.2.6. Type F: IPv4 Local and Remote addresses with optional SID 793 The Type F Segment Sub-TLV encodes an adjacency local address, an 794 adjacency remote address and an optional SR-MPLS SID. The format is 795 as follows: 797 0 1 2 3 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Type | Length | Flags | RESERVED | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Local IPv4 Address (4 octets) | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Remote IPv4 Address (4 octets) | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | SR-MPLS SID (optional, 4 octets) | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 where: 811 o Type: 6. 813 o Length is 14 when the SR-MPLS SID is present else is 10. 815 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 817 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 818 transmission and MUST be ignored on receipt. 820 o Local IPv4 Address: a 4 octet IPv4 address. 822 o Remote IPv4 Address: a 4 octet IPv4 address. 824 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 825 TTL as defined in Section 2.4.3.2.1. 827 2.4.3.2.7. Type G: IPv6 Address + Interface ID for local and remote 828 pair with optional SID for SR MPLS 830 The Type G Segment Sub-TLV encodes an IPv6 Link Local adjacency with 831 IPv6 local node address, a local interface identifier (Local 832 Interface ID), IPv6 remote node address , a remote interface 833 identifier (Remote Interface ID) and an optional SR-MPLS SID. The 834 format is as follows: 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Type | Length | Flags | RESERVED | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Local Interface ID (4 octets) | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 // IPv6 Local Node Address (16 octets) // 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Remote Interface ID (4 octets) | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 // IPv6 Remote Node Address (16 octets) // 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | SR-MPLS SID (optional, 4 octets) | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 where: 854 o Type: 7 856 o Length is 46 when the SR-MPLS SID is present else is 42. 858 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 860 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 861 transmission and MUST be ignored on receipt. 863 o Local Interface ID: 4 octets of interface index as defined in 864 [RFC8664]. 866 o IPv6 Local Node Address: a 16 octet IPv6 address. 868 o Remote Interface ID: 4 octets of interface index as defined in 869 [RFC8664]. The value MAY be set to zero when the local node 870 address and interface identifiers are sufficient to describe the 871 link. 873 o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY 874 be set to zero when the local node address and interface 875 identifiers are sufficient to describe the link. 877 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 878 TTL as defined in Section 2.4.3.2.1. 880 2.4.3.2.8. Type H: IPv6 Local and Remote addresses with optional SID 881 for SR MPLS 883 The Type H Segment Sub-TLV encodes an adjacency local address, an 884 adjacency remote address and an optional SR-MPLS SID. The format is 885 as follows: 887 0 1 2 3 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Type | Length | Flags | RESERVED | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 // Local IPv6 Address (16 octets) // 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 // Remote IPv6 Address (16 octets) // 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | SR-MPLS SID (optional, 4 octets) | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 where: 901 o Type: 8 903 o Length is 38 when the SR-MPLS SID is present else is 34. 905 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 907 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 908 transmission and MUST be ignored on receipt. 910 o Local IPv6 Address: a 16 octet IPv6 address. 912 o Remote IPv6 Address: a 16 octet IPv6 address. 914 o SR-MPLS SID: optional, 4 octet field containing label, TC, S and 915 TTL as defined in Section 2.4.3.2.1. 917 2.4.3.2.9. Type I: IPv6 Node Address with optional SRv6 SID 919 The Type I Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 920 and an optional SRv6 SID. The format is as follows: 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Type | Length | Flags | SR Algorithm | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 // IPv6 Node Address (16 octets) // 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 // SRv6 SID (optional, 16 octets) // 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 where: 934 o Type: 10 936 o Length is 34 when the SRv6 SID is present else is 18. 938 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 940 o SR Algorithm: 1 octet specifying SR Algorithm as described in 941 section 3.1.1 in [RFC8402], when A-Flag as defined in 942 Section 2.4.3.2.12 is present. SR Algorithm is used by SRPM as 943 described in section 4 in 944 [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 945 encoded, this field SHOULD be set to zero on transmission and MUST 946 be ignored on receipt. 948 o IPv6 Node Address: a 16 octet IPv6 address. 950 o SRv6 SID: optional, 16 octet IPv6 address. 952 2.4.3.2.10. Type J: IPv6 Address + Interface ID for local and remote 953 pair for SRv6 with optional SID 955 The Type J Segment Sub-TLV encodes an IPv6 Link Local adjacency with 956 local node address, a local interface identifier (Local Interface 957 ID), remote IPv6 node address, a remote interface identifier (Remote 958 Interface ID) and an optional SRv6 SID. The format is as follows: 960 0 1 2 3 961 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 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Type | Length | Flags | RESERVED | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Local Interface ID (4 octets) | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 // IPv6 Local Node Address (16 octets) // 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Remote Interface ID (4 octets) | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 // IPv6 Remote Node Address (16 octets) // 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 // SRv6 SID (optional, 16 octets) // 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 where: 978 o Type: 11. 980 o Length is 58 when the SRv6 SID is present else is 42. 982 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 984 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 985 transmission and MUST be ignored on receipt. 987 o Local Interface ID: 4 octets of interface index as defined in 988 [RFC8664]. 990 o IPv6 Local Node Address: a 16 octet IPv6 address. 992 o Remote Interface ID: 4 octets of interface index as defined in 993 [RFC8664]. The value MAY be set to zero when the local node 994 address and interface identifiers are sufficient to describe the 995 link. 997 o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY 998 be set to zero when the local node address and interface 999 identifiers are sufficient to describe the link. 1001 o SRv6 SID: optional, 16 octet IPv6 address. 1003 2.4.3.2.11. Type K: IPv6 Local and Remote addresses for SRv6 with 1004 optional SID 1006 The Type K Segment Sub-TLV encodes an adjacency local address, an 1007 adjacency remote address and an optional SRv6 SID. The format is as 1008 follows: 1010 0 1 2 3 1011 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Type | Length | Flags | RESERVED | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 // Local IPv6 Address (16 octets) // 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 // Remote IPv6 Address (16 octets) // 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 // SRv6 SID (optional, 16 octets) // 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 where: 1023 o Type: 12 . 1025 o Length is 50 when the SRv6 SID is present else is 34. 1027 o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. 1029 o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1030 transmission and MUST be ignored on receipt. 1032 o Local IPv6 Address: a 16 octet IPv6 address. 1034 o Remote IPv6 Address: a 16 octet IPv6 address. 1036 o SRv6 SID: optional, 16 octet IPv6 address. 1038 2.4.3.2.12. Segment Flags 1040 The Segment Types sub-TLVs described above MAY contain following 1041 flags in the "Flags" field defined in Section 6.6: 1043 0 1 2 3 4 5 6 7 1044 +-+-+-+-+-+-+-+-+ 1045 |V|A| | 1046 +-+-+-+-+-+-+-+-+ 1048 where: 1050 V-Flag: This flag is used by SRPM for the purpose of "SID 1051 verification" as described in Section 5.1 in 1052 [I-D.ietf-spring-segment-routing-policy]. 1054 A-Flag: This flag indicates the presence of SR Algorithm id in the 1055 "SR Algorithm" field applicable to various Segment Types. SR 1056 Algorithm is used by SRPM as described in section 4 in 1057 [I-D.ietf-spring-segment-routing-policy]. 1059 Unused bits in the Flag octet SHOULD be set to zero upon 1060 transmission and MUST be ignored upon receipt. 1062 The following applies to the Segment Flags: 1064 o V-Flag is applicable to all Segment Types. 1066 o A-Flag is applicable to Segment Types 3, 4 and 9. If A-Flag 1067 appears with any other Segment Type, it MUST be ignored. 1069 2.4.4. Explicit NULL Label Policy Sub-TLV 1071 In order to steer an unlabeled IP packet into an SR policy, it is 1072 necessary to create a label stack for that packet, and to push one or 1073 more labels onto that stack. 1075 The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate 1076 whether an Explicit NULL Label [RFC3032] must be pushed on an 1077 unlabeled IP packet before any other labels. 1079 If an ENLP Sub-TLV is not present, the decision of whether to push an 1080 Explicit NULL label on a given packet is a matter of local 1081 configuration. 1083 The ENLP sub-TLV is optional and it MUST NOT appear more than once in 1084 the SR Policy. 1086 The contents of this sub-TLV are used by the SRPM as described in 1087 section 4.1 in [I-D.ietf-spring-segment-routing-policy]. 1089 0 1 2 3 1090 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 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Type | Length | Flags | RESERVED | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | ENLP | 1095 +-+-+-+-+-+-+-+-+ 1097 Where: 1099 Type: 14. 1101 Length: 3. 1103 Flags: 1 octet of flags. None are defined at this stage. Flags 1104 SHOULD be set to zero on transmission and MUST be ignored on 1105 receipt. 1107 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1108 transmission and MUST be ignored on receipt. 1110 ENLP (Explicit NULL Label Policy): Indicates whether Explicit NULL 1111 labels are to be pushed on unlabeled IP packets that are being 1112 steered into a given SR policy. This field has one of the 1113 following values: 1115 0: Reserved. 1117 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1118 packet, but do not push an IPv6 Explicit NULL label on an 1119 unlabeled IPv6 packet. 1121 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 1122 packet, but do not push an IPv4 Explicit NULL label on an 1123 unlabeled IPv4 packet. 1125 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1126 packet, and push an IPv6 Explicit NULL label on an unlabeled 1127 IPv6 packet. 1129 4: Do not push an Explicit NULL label. 1131 5 - 255: Reserved. 1133 The ENLP reserved values may be used for future extensions and 1134 implementations SHOULD ignore the ENLP Sub-TLV with these values. 1135 The behavior signaled in this Sub-TLV MAY be overridden by local 1136 configuration. The section 4.1 of 1137 [I-D.ietf-spring-segment-routing-policy] draft describes the 1138 behavior on the headend for handling of explicit null label. 1140 2.4.5. Policy Priority Sub-TLV 1142 An operator MAY set the Policy Priority sub-TLV to indicate the order 1143 in which the SR policies are re-computed upon topological change. 1144 The contents of this sub-TLV are used by the SRPM as described in 1145 section 2.11 in [I-D.ietf-spring-segment-routing-policy]. 1147 The Priority sub-TLV is optional and it MUST NOT appear more than 1148 once in the SR Policy TLV. 1150 The Priority sub-TLV has following format: 1152 0 1 2 3 1153 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 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Type | Length | Priority | RESERVED | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 Where: 1160 Type: 15 1162 Length: 2. 1164 Priority: a 1-octet value. 1166 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1167 transmission and MUST be ignored on receipt. 1169 2.4.6. Policy Candidate Path Name Sub-TLV 1171 An operator MAY set the Policy Candidate Path Name sub-TLV to attach 1172 a symbolic name to the SR Policy candidate path. 1174 Usage of Policy Candidate Path Name sub-TLV is described in section 1175 2.6 in [I-D.ietf-spring-segment-routing-policy]. 1177 The Policy Candidate Path Name sub-TLV may exceed 255 bytes length 1178 due to long policy name. Therefore a 2-octet length is required. 1179 According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- 1180 TLV codepoint defines the size of the length field. Therefore, for 1181 the Policy Candidate Path Name sub-TLV a code point of 128 or higher 1182 is used. 1184 It is RECOMMENDED that the size of the symbolic name be limited to 1185 255 bytes. Implementations MAY choose to truncate long names to 255 1186 bytes when signaling via BGP. 1188 The Policy Candidate Path Name sub-TLV is optional and it MUST NOT 1189 appear more than once in the SR Policy TLV. 1191 The Policy Candidate Path Name sub-TLV has following format: 1193 0 1 2 3 1194 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 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Type | Length | RESERVED | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 // Policy Candidate Path Name // 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 Where: 1203 Type: 129. 1205 Length: Variable. 1207 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 1208 transmission and MUST be ignored on receipt. 1210 Policy Candidate Path Name: Symbolic name for the SR Policy 1211 candidate path without a NULL terminator as specified in section 1212 2.6 of [I-D.ietf-spring-segment-routing-policy]. 1214 3. Color Extended Community 1216 The Color Extended Community as defined in 1217 [I-D.ietf-idr-tunnel-encaps] is used to steer traffic into a policy. 1219 When the Color Extended Community is used for the purpose of steering 1220 the traffic into an SR Policy, two bits from the RESERVED field (as 1221 defined in [I-D.ietf-idr-tunnel-encaps]) are used as follows: 1223 1 1224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 |C O| RESERVED | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 where CO bits are defined as the "Color-Only" bits. 1230 [I-D.ietf-spring-segment-routing-policy] defines the influence of 1231 these bits on the automated steering of BGP Payload traffic onto SR 1232 Policies. 1234 4. SR Policy Operations 1236 As described in this document, the consumer of an SR Policy NLRI is 1237 not the BGP process. The BGP process is in charge of the origination 1238 and propagation of the SR Policy NLRI but its installation and use is 1239 outside the scope of BGP. The details of SR Policy installation and 1240 use are specified in [I-D.ietf-spring-segment-routing-policy]. 1242 4.1. Advertisement of SR Policies 1244 Typically, but not limited to, an SR Policy is computed by a 1245 controller or a path computation engine (PCE) and originated by a BGP 1246 speaker on its behalf. 1248 Multiple SR Policy NLRIs may be present with the same tuple but with different content when these SR policies are 1250 intended for different head-ends. 1252 The distinguisher of each SR Policy NLRI prevents undesired BGP route 1253 selection among these SR Policy NLRIs and allows their propagation 1254 across route reflectors [RFC4456]. 1256 Moreover, one or more route-target SHOULD be attached to the 1257 advertisement, where each route-target identifies one or more 1258 intended head-ends for the advertised SR policy. 1260 If no route-target is attached to the SR Policy NLRI, then it is 1261 assumed that the originator sends the SR Policy update directly 1262 (e.g., through a BGP session) to the intended receiver. In such 1263 case, the NO_ADVERTISE community MUST be attached to the SR Policy 1264 update. 1266 4.2. Reception of an SR Policy NLRI 1268 On reception of an SR Policy NLRI, a BGP speaker first determines if 1269 it is acceptable and then if it is usable. 1271 4.2.1. Acceptance of an SR Policy NLRI 1273 When a BGP speaker receives an SR Policy NLRI from a neighbor it MUST 1274 first determine if it's acceptable. The following rules apply: 1276 o The SR Policy NLRI MUST include a distinguisher, color and 1277 endpoint field which implies that the length of the NLRI MUST be 1278 either 12 or 24 octets (depending on the address family of the 1279 endpoint). 1281 o The SR Policy update MUST have either the NO_ADVERTISE community 1282 or at least one route-target extended community in IPv4-address 1283 format or both. If a router supporting this specification 1284 receives an SR Policy update with no route-target extended 1285 communities and no NO_ADVERTISE community, the update MUST be 1286 considered as malformed. 1288 o The Tunnel Encapsulation Attribute MUST be attached to the BGP 1289 Update and MUST have a Tunnel Type TLV set to SR Policy (codepoint 1290 is 15). 1292 A router that receives an SR Policy update that is not valid 1293 according to these criteria MUST treat the update as malformed and 1294 the SR Policy candidate path MUST NOT be passed to the SRPM. 1296 4.2.2. Usable SR Policy NLRI 1298 A SR Policy update that has been determined to be acceptable is 1299 further evaluated for its usability by the receiving node. 1301 An SR Policy NLRI update without any route-target extended community 1302 but having the NO_ADVERTISE community is considered usable. 1304 If one or more route-targets are present, then at least one route- 1305 target MUST match the BGP Identifier of the receiver for the update 1306 to be considered usable. The BGP Identifier is defined in [RFC4271] 1307 as a 4 octet IPv4 address. Therefore, the route-target extended 1308 community MUST be of the same format. 1310 If one or more route-targets are present and none matches the local 1311 BGP Identifier, then, while the SR Policy NLRI is acceptable, it is 1312 not usable on the receiver node. 1314 When the SR Policy tunnel type includes any sub-TLV that is 1315 unrecognized or unsupported, the update SHOULD NOT be considered 1316 usable. An implementation MAY provide an option for ignoring 1317 unsupported sub-TLVs. 1319 4.2.3. Passing a usable SR Policy NLRI to the SRPM 1321 Once BGP on the receiving node has determined that the SR Policy NLRI 1322 is usable, it passes the SR Policy candidate path to the SRPM. Note 1323 that, along with the candidate path details, BGP also passes the 1324 originator information for breaking ties in the candidate path 1325 selection process as described in section 2.4 in 1326 [I-D.ietf-spring-segment-routing-policy]. 1328 When an update for an SR Policy NLRI results in it's becoming 1329 unusable, BGP MUST delete it's corresponding SR Policy candidate path 1330 from the SRPM. 1332 The SRPM applies the rules defined in section 2 in 1333 [I-D.ietf-spring-segment-routing-policy] to determine whether the SR 1334 Policy candidate path is valid and to select the best candidate path 1335 among the valid ones for a given SR Policy. 1337 4.2.4. Propagation of an SR Policy 1339 SR Policy NLRIs that have been determined acceptable and valid can be 1340 evaluated for propagation, even the ones that are not usable. 1342 SR Policy NLRIs that have the NO_ADVERTISE community attached to them 1343 MUST NOT be propagated. 1345 By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate 1346 it to any EBGP neighbor. An implementation MAY provide an explicit 1347 configuration to override this and enable propagation of acceptable 1348 SR Policy NLRIs to specific EBGP neighbors. 1350 A BGP node advertises a received SR Policy NLRI to its IBGP neighbors 1351 according to normal IBGP propagation rules. 1353 By default, a BGP node receiving an SR Policy NLRI SHOULD NOT remove 1354 route-target extended community before propagation. An 1355 implementation MAY provide support for configuration to filter and/or 1356 remove route-target extended community before propagation. 1358 5. Error Handling 1360 This section describes the error handling actions, as described in 1361 [RFC7606], that are to be performed for handling of BGP update 1362 messages for BGP SR Policy SAFI. 1364 A BGP Speaker MUST perform the following syntactic validation of the 1365 SR Policy NLRI to determine if it is malformed. This includes the 1366 validation of length of each NLRI and the total length of the 1367 MP_REACH_NLRI and MP_UNREACH_NLRI attributes. 1369 When the error determined allows for the router to skip the malformed 1370 NLRI(s) and continue processing of the rest of the update message, 1371 then it MUST handle such malformed NLRIs as 'Treat-as-withdraw'. In 1372 other cases, where the error in the NLRI encoding results in the 1373 inability to process the BGP update message (e.g. length related 1374 encoding errors), then the router SHOULD handle such malformed NLRIs 1375 as 'AFI/SAFI disable' when other AFI/SAFI besides SR Policy are being 1376 advertised over the same session. Alternately, the router MUST 1377 perform 'session reset' when the session is only being used for SR 1378 Policy or when it 'AFI/SAFI disable' action is not possible. 1380 The validation of the TLVs/sub-TLVs introduced in this document and 1381 defined in their respective sub-sections of Section 2.4 MUST be 1382 performed to determine if they are malformed or invalid. The 1383 validation of the Tunnel Encapsulation Attribute itself and the other 1384 TLVs/sub-TLVs specified in [I-D.ietf-idr-tunnel-encaps] MUST be done 1385 as described in that document. In case of any error detected, either 1386 at the attribute or its TLV/sub-TLV level, the "treat-as-withdraw" 1387 strategy MUST be applied. This is because an SR Policy update 1388 without a valid Tunnel Encapsulation Attribute (comprising of all 1389 valid TLVs/sub-TLVs) is not usable. 1391 An SR Policy update that is determined to be not acceptable, and 1392 therefore malformed, based on rules described in Section 4.2.1 MUST 1393 be handled by the "treat-as-withdraw" strategy. 1395 The validation of the individual fields of the TLVs/sub-TLVs defined 1396 in Section 2.4 are beyond the scope of BGP as they are handled by the 1397 SRPM as described in the individual TLV/sub-TLV sub-sections. A BGP 1398 implementation MUST NOT perform semantic verification of such fields 1399 nor consider the SR Policy update to be invalid or not acceptable/ 1400 usable on the basis of such a validation. 1402 An implementation SHOULD log an error for any errors found during the 1403 above validation for further analysis. 1405 6. IANA Considerations 1407 This document requests codepoint allocations for new TLVs/sub-TLVs in 1408 following existing registries: 1410 o Subsequent Address Family Identifiers (SAFI) Parameters registry 1412 o BGP Tunnel Encapsulation Attribute Tunnel Types registry under the 1413 BGP Parameters registry 1415 o BGP Tunnel Encapsulation Attribute sub-TLVs registry under the BGP 1416 Parameters registry 1418 This document also requests creation of the following new registries: 1420 o SR Policy List Sub-TLVs under the BGP Parameters registry 1422 o SR Policy Binding SID Flags under the BGP Parameters registry 1424 o SR Policy Segment Flags under the BGP Parameters registry 1426 o Color Extended Community Field under the BGP Extended Communities 1427 registry 1429 6.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 1430 Parameters 1432 This document defines a new SAFI in the registry "Subsequent Address 1433 Family Identifiers (SAFI) Parameters" that has been assigned a 1434 codepoint by IANA as follows: 1436 Codepoint Description Reference 1437 ----------------------------------------------- 1438 73 SR Policy SAFI This document 1440 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute Tunnel Types 1442 This document defines a new Tunnel-Type in the registry "BGP Tunnel 1443 Encapsulation Attribute Tunnel Types" that has been assigned a 1444 codepoint by IANA as follows: 1446 Codepoint Description Reference 1447 -------------------------------------------------- 1448 15 SR Policy Type This document 1450 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 1452 This document defines new sub-TLVs in the registry "BGP Tunnel 1453 Encapsulation Attribute sub-TLVs" that has been assigned codepoints 1454 by IANA as follows: 1456 Codepoint Description Reference 1457 ------------------------------------------------------ 1458 12 Preference sub-TLV This document 1459 13 Binding SID sub-TLV This document 1460 128 Segment List sub-TLV This document 1461 14 ENLP sub-TLV This document 1462 15 Priority sub-TLV This document 1463 129 Policy CP Name sub-TLV This document 1465 6.4. New Registry: SR Policy List Sub-TLVs 1467 This document requests creation of a new registry called "SR Policy 1468 List Sub-TLVs". The allocation policy of this registry is 1469 "Specification Required" according to [RFC8126]. 1471 Following initial Sub-TLV codepoints are assigned by this document: 1473 Value Description Reference 1474 ------------------------------------------------------------------------ 1475 1 Type A MPLS SID sub-TLV This document 1476 2 Type B SRv6 SID sub-TLV This document 1477 3 Type C IPv4 Node and SID sub-TLV This document 1478 4 Type D IPv6 Node and SID for SR-MPLS sub-TLV This document 1479 5 Type E IPv4 Node, index and SID sub-TLV This document 1480 6 Type F IPv4 Local/Remote addresses and SID sub-TLV This document 1481 7 Type G IPv6 Node, index for remote and local pair This document 1482 and SID for SR-MPLS sub-TLV 1483 8 Type H IPv6 Local/Remote addresses and SID sub-TLV This document 1484 9 Weight sub-TLV This document 1485 10 Type I IPv6 Node and SID for SRv6 sub-TLV This document 1486 11 Type J IPv6 Node, index for remote and local pair This document 1487 and SID for SRv6 sub-TLV 1488 12 Type K IPv6 Local/Remote addresses and SID for This document 1489 SRv6 sub-TLV 1491 6.5. New Registry: SR Policy Binding SID Flags 1493 This document requests creation of a new registry called "SR Policy 1494 Binding SID Flags". The allocation policy of this registry is 1495 "Specification Required" according to [RFC8126]. 1497 Following flags are defined: 1499 Bit Description Reference 1500 ----------------------------------------------------------------- 1501 0 Specified-BSID-Only Flag (S-Flag) This document 1502 1 Drop Upon Invalid Flag (I-Flag) This document 1503 2-7 Unassigned 1505 6.6. New Registry: SR Policy Segment Flags 1507 This document requests creation of a new registry called "SR Policy 1508 Segment Flags". The allocation policy of this registry is 1509 "Specification Required" according to [RFC8126]. 1511 Following Flags are defined: 1513 Bit Description Reference 1514 ------------------------------------------------------------------ 1515 0 Segment Verification Flag (V-Flag) This document 1516 1 SR Algorithm Flag (A-Flag) This document 1517 2-7 Unassigned 1519 6.7. New Registry: Color Extended Community Field 1521 This document requests creation of a new registry called "Color 1522 Extended Community Field". The allocation policy of this registry is 1523 "Specification Required" according to [RFC8126]. 1525 Following bits are defined in this 2 octet field: 1527 Bit Description Reference 1528 ------------------------------------------------------------------ 1529 0-1 Color-only bits This document 1530 2-15 Unassigned 1532 6.8. Guidance for Designated Experts 1534 In all cases of review by the Designated Expert (DE) described here, 1535 the DE is expected to ascertain the existence of suitable 1536 documentation (a specification) as described in [RFC8126]. The DE is 1537 also expected to check the clarity of purpose and use of the 1538 requested code points. Additionally, the DE must verify that any 1539 request for one of these code points has been made available for 1540 review and comment within the IETF: the DE will post the request to 1541 the IDR Working Group mailing list (or a successor mailing list 1542 designated by the IESG). If the request comes from within the IETF, 1543 it should be documented in an Internet-Draft. Lastly, the DE must 1544 ensure that any other request for a code point does not conflict with 1545 work that is active or already published within the IETF. 1547 7. Security Considerations 1549 The security mechanisms of the base BGP security model apply to the 1550 extensions described in this document as well. See the Security 1551 Considerations section of [RFC4271] for a discussion of BGP security. 1552 Also refer to [RFC4272] and [RFC6952] for analysis of security issues 1553 for BGP. 1555 The BGP SR Policy extensions specified in this document enable 1556 traffic engineering and service programming use-cases within the SR 1557 domain as described in [I-D.ietf-spring-segment-routing-policy] . SR 1558 operates within a trusted SR domain [RFC8402] and its security 1559 considerations also apply to BGP sessions when carrying SR Policy 1560 information. The SR Policies distributed by BGP are expected to be 1561 used entirely within this trusted SR domain i.e. within a single AS 1562 or between multiple AS/domains within a single provider network. 1563 Therefore, precaution is necessary to ensure that the SR Policy 1564 information advertised via BGP sessions is limited to nodes in a 1565 secure manner within this trusted SR domain. BGP peering sessions 1566 for address-families other than SR Policy SAFI may be setup to 1567 routers outside the SR domain. The isolation of BGP SR Policy SAFI 1568 peering sessions may be used to ensure that the SR Policy information 1569 is not advertised by accident or error to an EBGP peering session 1570 outside the SR domain. 1572 Additionally, it may be considered that the export of SR Policy 1573 information as described in this document constitutes a risk to 1574 confidentiality of mission-critical or commercially sensitive 1575 information about the network (more specifically endpoint/node 1576 addresses, SR SIDs and the SR Policies deployed). BGP peerings are 1577 not automatic and require configuration; thus, it is the 1578 responsibility of the network operator to ensure that only trusted 1579 nodes (that include both routers and controller applications) within 1580 the SR domain are configured to receive such information. 1582 8. Acknowledgments 1584 The authors of this document would like to thank Shyam Sethuram, John 1585 Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha, Bruno Decraene, 1586 Gurusiddesh Nidasesi, Kausik Majumdar, Zafar Ali, Swadesh Agarwal, 1587 Jakob Heitz, Viral Patel, Peng Shaofu and Cheng Li for their comments 1588 and review of this document. 1590 9. Contributors 1592 Arjun Sreekantiah 1593 Cisco Systems 1594 US 1596 Email: asreekan@cisco.com 1598 Acee Lindem 1599 Cisco Systems 1600 US 1602 Email: acee@cisco.com 1604 Siva Sivabalan 1605 Cisco Systems 1606 US 1608 Email: msiva@cisco.com 1610 Imtiyaz Mohammad 1611 Arista Networks 1612 India 1614 Email: imtiyaz@arista.com 1615 Gaurav Dawra 1616 Cisco Systems 1617 US 1619 Email: gdawra.ietf@gmail.com 1621 10. References 1623 10.1. Normative References 1625 [I-D.ietf-idr-tunnel-encaps] 1626 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 1627 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 1628 (work in progress), December 2019. 1630 [I-D.ietf-spring-segment-routing-policy] 1631 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 1632 P. Mattes, "Segment Routing Policy Architecture", draft- 1633 ietf-spring-segment-routing-policy-07 (work in progress), 1634 May 2020. 1636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1637 Requirement Levels", BCP 14, RFC 2119, 1638 DOI 10.17487/RFC2119, March 1997, 1639 . 1641 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1642 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1643 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1644 . 1646 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1647 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1648 DOI 10.17487/RFC4271, January 2006, 1649 . 1651 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1652 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1653 February 2006, . 1655 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1656 "Multiprotocol Extensions for BGP-4", RFC 4760, 1657 DOI 10.17487/RFC4760, January 2007, 1658 . 1660 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1661 Patel, "Revised Error Handling for BGP UPDATE Messages", 1662 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1663 . 1665 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1666 Writing an IANA Considerations Section in RFCs", BCP 26, 1667 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1668 . 1670 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1671 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1672 May 2017, . 1674 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1675 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1676 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1677 July 2018, . 1679 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1680 and J. Hardwick, "Path Computation Element Communication 1681 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1682 DOI 10.17487/RFC8664, December 2019, 1683 . 1685 10.2. Informational References 1687 [I-D.filsfils-spring-sr-policy-considerations] 1688 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1689 P. Mattes, "SR Policy Implementation and Deployment 1690 Considerations", draft-filsfils-spring-sr-policy- 1691 considerations-05 (work in progress), April 2020. 1693 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1694 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1695 . 1697 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1698 Reflection: An Alternative to Full Mesh Internal BGP 1699 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1700 . 1702 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1703 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1704 and Authentication for Routing Protocols (KARP) Design 1705 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1706 . 1708 Authors' Addresses 1710 Stefano Previdi 1711 Individual 1712 IT 1714 Email: stefano@previdi.net 1716 Clarence Filsfils 1717 Cisco Systems 1718 Brussels 1719 BE 1721 Email: cfilsfil@cisco.com 1723 Ketan Talaulikar (editor) 1724 Cisco Systems 1725 India 1727 Email: ketant@cisco.com 1729 Paul Mattes 1730 Microsoft 1731 One Microsoft Way 1732 Redmond, WA 98052 1733 USA 1735 Email: pamattes@microsoft.com 1737 Eric Rosen 1738 Juniper Networks 1739 10 Technology Park Drive 1740 Westford, MA 01886 1741 US 1743 Email: erosen@juniper.net 1745 Dhanendra Jain 1746 Google 1748 Email: dhanendra.ietf@gmail.com 1749 Steven Lin 1750 Google 1752 Email: stevenlin@google.com