idnits 2.17.1 draft-ietf-bess-srv6-services-15.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 (March 22, 2022) is 765 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 (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-20 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-16 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-18 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-21 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-13 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group G. Dawra, Ed. 3 Internet-Draft LinkedIn 4 Intended status: Standards Track K. Talaulikar, Ed. 5 Expires: September 23, 2022 Cisco Systems 6 R. Raszuk 7 NTT Network Innovations 8 B. Decraene 9 Orange 10 S. Zhuang 11 Huawei Technologies 12 J. Rabadan 13 Nokia 14 March 22, 2022 16 SRv6 BGP based Overlay Services 17 draft-ietf-bess-srv6-services-15 19 Abstract 21 This document defines procedures and messages for SRv6-based BGP 22 services including L3VPN, EVPN, and Internet services. It builds on 23 RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432 24 "BGP MPLS-Based Ethernet VPN". 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 23, 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 2. SRv6 Services TLVs . . . . . . . . . . . . . . . . . . . . . 4 63 3. SRv6 Service Sub-TLVs . . . . . . . . . . . . . . . . . . . . 5 64 3.1. SRv6 SID Information Sub-TLV . . . . . . . . . . . . . . 6 65 3.2. SRv6 Service Data Sub-Sub-TLVs . . . . . . . . . . . . . 8 66 3.2.1. SRv6 SID Structure Sub-Sub-TLV . . . . . . . . . . . 8 67 4. Encoding SRv6 SID Information . . . . . . . . . . . . . . . . 11 68 5. BGP based L3 Service over SRv6 . . . . . . . . . . . . . . . 12 69 5.1. IPv4 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 13 70 5.2. IPv6 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 13 71 5.3. Global IPv4 over SRv6 Core . . . . . . . . . . . . . . . 14 72 5.4. Global IPv6 over SRv6 Core . . . . . . . . . . . . . . . 14 73 6. BGP based Ethernet VPN (EVPN) over SRv6 . . . . . . . . . . . 14 74 6.1. Ethernet Auto-discovery Route over SRv6 Core . . . . . . 16 75 6.1.1. Ethernet A-D per ES Route . . . . . . . . . . . . . . 16 76 6.1.2. Ethernet A-D per EVI Route . . . . . . . . . . . . . 17 77 6.2. MAC/IP Advertisement Route over SRv6 Core . . . . . . . . 17 78 6.2.1. MAC/IP Advertisement Route with MAC Only . . . . . . 19 79 6.2.2. MAC/IP Advertisement Route with MAC+IP . . . . . . . 19 80 6.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core . . 20 81 6.4. Ethernet Segment Route over SRv6 Core . . . . . . . . . . 21 82 6.5. IP Prefix Route over SRv6 Core . . . . . . . . . . . . . 22 83 6.6. EVPN Multicast Routes (Route Types 6, 7, 8) over SRv6 84 Core . . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 86 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 88 9.1. BGP Prefix-SID TLV Types Registry . . . . . . . . . . . . 24 89 9.2. SRv6 Service Sub-TLV Types Registry . . . . . . . . . . . 25 90 9.3. SRv6 Service Data Sub-Sub-TLV Types Registry . . . . . . 25 91 9.4. BGP SRv6 Service SID Flags Registry . . . . . . . . . . . 26 92 9.5. Subsequent Address Family Identifiers (SAFI) Parameters 93 Registry . . . . . . . . . . . . . . . . . . . . . . . . 26 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 95 10.1. BGP Session Related Considerations . . . . . . . . . . . 26 96 10.2. BGP Services Related Considerations . . . . . . . . . . 26 97 10.3. SR over IPv6 Data Plane Related Considerations . . . . . 27 98 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 99 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 101 13.1. Normative References . . . . . . . . . . . . . . . . . . 30 102 13.2. Informative References . . . . . . . . . . . . . . . . . 32 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 105 1. Introduction 107 SRv6 refers to Segment Routing instantiated on the IPv6 dataplane 108 [RFC8402]. 110 BGP is used to advertise the reachability of prefixes of a particular 111 service from an egress PE to ingress PE nodes. 113 SRv6 based BGP services refers to the Layer-3 and Layer-2 overlay 114 services with BGP as control plane and SRv6 as dataplane. This 115 document defines procedures and messages for SRv6-based BGP services 116 including L3VPN, EVPN, and Internet services. It builds on [RFC4364] 117 "BGP/MPLS IP Virtual Private Networks (VPNs)" and [RFC7432] "BGP 118 MPLS-Based Ethernet VPN". 120 SRv6 SID refers to an SRv6 Segment Identifier as defined in 121 [RFC8402]. 123 SRv6 Service SID refers to an SRv6 SID associated with one of the 124 service-specific SRv6 Endpoint behaviors on the advertising Provider 125 Edge (PE) router, such as (but not limited to), End.DT (Table lookup 126 in a VRF) or End.DX (cross-connect to a nexthop) behaviors in the 127 case of Layer-3 Virtual Private Network (L3VPN) service as defined in 128 [RFC8986]. This document describes how existing BGP messages between 129 PEs may carry SRv6 Service SIDs to interconnect PEs and form VPNs. 131 To provide SRv6 service with best-effort connectivity, the egress PE 132 signals an SRv6 Service SID with the BGP overlay service route. The 133 ingress PE encapsulates the payload in an outer IPv6 header where the 134 destination address is the SRv6 Service SID provided by the egress 135 Provider Edge (PE). The underlay between the PEs only needs to 136 support plain IPv6 forwarding [RFC8200]. 138 To provide SRv6 service in conjunction with an underlay SLA from the 139 ingress PE to the egress PE, the egress PE colors the overlay service 140 route with a Color Extended Community 141 [I-D.ietf-idr-segment-routing-te-policy] for steering of flows for 142 those routes as specified in section 8 of 143 [I-D.ietf-spring-segment-routing-policy]. The ingress PE 144 encapsulates the payload packet in an outer IPv6 header with the 145 segment list of SR policy associated with the related SLA along with 146 the SRv6 Service SID associated with the route using the Segment 147 Routing Header (SRH) [RFC8754]. The underlay nodes whose SRv6 SID's 148 are part of the SRH segment list MUST support SRv6 data plane. 150 1.1. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 2. SRv6 Services TLVs 160 This document extends the use of the BGP Prefix-SID attribute 161 [RFC8669] to carry SRv6 SIDs and their associated information with 162 the BGP address-families that are listed further in this section. 164 The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix- 165 SID Attribute to achieve signaling of SRv6 SIDs for L3 and L2 166 services. 168 o SRv6 L3 Service TLV: This TLV encodes Service SID information for 169 SRv6 based L3 services. It corresponds to the equivalent 170 functionality provided by an MPLS Label when received with a Layer 171 3 service route as defined in [RFC4364] [RFC4659] [RFC8950] 172 [RFC9136]. Some SRv6 Endpoint behaviors which may be encoded, but 173 not limited to, are End.DX4, End.DT4, End.DX6, End.DT6, and 174 End.DT46. 176 o SRv6 L2 Service TLV: This TLV encodes Service SID information for 177 SRv6 based L2 services. It corresponds to the equivalent 178 functionality provided by an MPLS Label1 for Ethernet VPN (EVPN) 179 Route-Types as defined in [RFC7432]. Some SRv6 Endpoint behaviors 180 which may be encoded, but not limited to, are End.DX2, End.DX2V, 181 End.DT2U, and End.DT2M. 183 When an egress PE is enabled for BGP Services over SRv6 data-plane, 184 it signals one or more SRv6 Service SIDs enclosed in SRv6 Service 185 TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs 186 defined in [RFC4760] [RFC4659] [RFC8950] [RFC7432] [RFC4364] 187 [RFC9136] where applicable as described in Section 5 and Section 6. 189 The support for BGP Multicast VPN (MVPN) Services [RFC6513] with SRv6 190 is outside the scope of this document. 192 The following depicts the SRv6 Service TLVs encoded in the BGP 193 Prefix-SID Attribute: 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | TLV Type | TLV Length | RESERVED | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | SRv6 Service Sub-TLVs // 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 1: SRv6 Service TLVs 205 o TLV Type (1 octet): This field is assigned values from the IANA 206 registry "BGP Prefix-SID TLV Types". It is set to 5 for SRv6 L3 207 Service TLV. It is set to 6 for SRv6 L2 Service TLV. 209 o TLV Length (2 octets): Specifies the total length, in octets, of 210 the TLV Value. 212 o RESERVED (1 octet): This field is reserved; it MUST be set to 0 by 213 the sender and ignored by the receiver. 215 o SRv6 Service Sub-TLVs (variable): This field contains SRv6 Service 216 related information and is encoded as an unordered list of Sub- 217 TLVs whose format is described below. 219 A BGP speaker receiving a route containing BGP Prefix-SID Attribute 220 with one or more SRv6 Service TLVs observes the following rules when 221 advertising the received route to other peers: 223 o if the nexthop is unchanged during the advertisement, the SRv6 224 Service TLVs, including any unrecognized Types of Sub-TLV and Sub- 225 Sub-TLV, SHOULD be propagated further. In addition, all Reserved 226 fields in the TLV or Sub-TLV or Sub-Sub-TLV MUST be propagated 227 unchanged. 229 o if the nexthop is changed, the TLVs, Sub-TLVs, and Sub-Sub-TLVs 230 SHOULD be updated with the locally allocated SRv6 SID information. 231 Any unrecognized received Sub-TLVs and Sub-Sub-TLVs MUST be 232 removed. 234 3. SRv6 Service Sub-TLVs 236 The format of a single SRv6 Service Sub-TLV is depicted below: 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | SRv6 Service | SRv6 Service | SRv6 Service // 242 | Sub-TLV | Sub-TLV | Sub-TLV // 243 | Type | Length | value // 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 2: SRv6 Service Sub-TLVs 248 o SRv6 Service Sub-TLV Type (1 octet): Identifies the type of SRv6 249 service information. It is assigned values from the IANA Registry 250 "SRv6 Service Sub-TLV Types". 252 o SRv6 Service Sub-TLV Length (2 octets): Specifies the total 253 length, in octets, of the Sub-TLV Value field. 255 o SRv6 Service Sub-TLV Value (variable): Contains data specific to 256 the Sub-TLV Type. In addition to fixed-length data, it contains 257 other properties of the SRv6 Service encoded as a set of SRv6 258 Service Data Sub-Sub-TLVs whose format is described in Section 3.2 259 below. 261 3.1. SRv6 SID Information Sub-TLV 263 SRv6 Service Sub-TLV Type 1 is assigned for SRv6 SID Information Sub- 264 TLV. This Sub-TLV contains a single SRv6 SID along with its 265 properties. Its encoding is depicted below: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | SRv6 Service | SRv6 Service | | 271 | Sub-TLV | Sub-TLV | | 272 | Type=1 | Length | RESERVED1 | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | SRv6 SID Value (16 octets) // 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Svc SID Flags | SRv6 Endpoint Behavior | RESERVED2 | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | SRv6 Service Data Sub-Sub-TLVs // 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 3: SRv6 SID Information Sub-TLV 283 o SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to 284 represent SRv6 SID Information Sub-TLV. 286 o SRv6 Service Sub-TLV Length (2 octets): This field contains the 287 total length, in octets, of the Value field of the Sub-TLV. 289 o RESERVED1 (1 octet): MUST be set to 0 by the sender and ignored by 290 the receiver. 292 o SRv6 SID Value (16 octets): Encodes an SRv6 SID as defined in 293 [RFC8986] 295 o SRv6 Service SID Flags (1 octet): Encodes SRv6 Service SID Flags - 296 none are currently defined. SHOULD be set to 0 by the sender and 297 any unknown flags MUST be ignored by the receiver. 299 o SRv6 Endpoint Behavior (2 octets): Encodes SRv6 Endpoint behavior 300 codepoint value that is associated with SRv6 SID. The codepoints 301 used are from the "SRv6 Endpoint Behavior" registry under the IANA 302 "Segment Routing" parameters registry that was introduced by 303 [RFC8986]. The opaque endpoint behavior (i.e., value 0xFFFF) MAY 304 be used when the advertising router wishes to abstract the actual 305 behavior of it's locally instantiated SRv6 SID. 307 o RESERVED2 (1 octet): MUST be set to 0 by the sender and ignored by 308 the receiver. 310 o SRv6 Service Data Sub-Sub-TLV Value (variable): Used to advertise 311 properties of the SRv6 SID. It is encoded as a set of SRv6 312 Service Data Sub-Sub-TLVs. 314 The choice of SRv6 Endpoint behavior of the SRv6 SID is entirely up 315 to the originator of the advertisement. While Section 5 and 316 Section 6 list the SRv6 Endpoint Behaviors that are normally expected 317 to be used by the specific route advertisements, the reception of 318 other SRv6 Endpoint behaviors (e.g., new behaviors that may be 319 introduced in the future) is not considered an error. An 320 unrecognized endpoint behavior MUST NOT be considered invalid by the 321 receiver except for behaviors that involve the use of arguments 322 (refer to Section 3.2.1 for details on argument validation). An 323 implementation MAY log a rate-limited warning when it receives an 324 unexpected behavior. 326 When multiple SRv6 SID Information Sub-TLVs are present, the ingress 327 PE SHOULD use the SRv6 SID from the first instance of the Sub-TLV. 328 An implementation MAY provide a local policy to override this 329 selection. 331 3.2. SRv6 Service Data Sub-Sub-TLVs 333 The format of the SRv6 Service Data Sub-Sub-TLV is depicted below: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Service Data | Sub-Sub-TLV Length |Sub-Sub TLV // 339 | Sub-Sub-TLV | | Value // 340 | Type | | // 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 4: SRv6 Service Data Sub-Sub-TLVs 345 o SRv6 Service Data Sub-Sub-TLV Type (1 octet): Identifies the type 346 of Sub-Sub-TLV. It is assigned values from the IANA Registry 347 "SRv6 Service Data Sub-Sub-TLVs". 349 o SRv6 Service Data Sub-Sub-TLV Length (2 octets): Specifies the 350 total length, in octets, of the Sub-Sub-TLV Value field. 352 o SRv6 Service Data Sub-Sub-TLV Value (variable): Contains data 353 specific to the Sub-Sub-TLV Type. 355 3.2.1. SRv6 SID Structure Sub-Sub-TLV 357 SRv6 Service Data Sub-Sub-TLV Type 1 is assigned for SRv6 SID 358 structure Sub-Sub-TLV. SRv6 SID Structure Sub-Sub-TLV is used to 359 advertise the lengths of the individual parts of the SRv6 SID as 360 defined in [RFC8986]. The terms Locator Block and Locator Node 361 correspond to the B and N parts respectively of the SRv6 Locator that 362 are defined in section 3.1 of [RFC8986]. It is carried as Sub-Sub- 363 TLV in SRv6 SID Information Sub-TLV 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | SRv6 Service | SRv6 Service | Locator Block | 368 | Data Sub-Sub | Data Sub-Sub-TLV | Length | 369 | -TLV Type=1 | Length | | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Locator Node | Function | Argument | Transposition | 372 | Length | Length | Length | Length | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Transposition | 375 | Offset | 376 +-+-+-+-+-+-+-+-+ 378 Figure 5: SRv6 SID Structure Sub-Sub-TLV 380 o SRv6 Service Data Sub-Sub-TLV Type (1 octet): This field is set to 381 1 to represent SRv6 SID Structure Sub-Sub-TLV. 383 o SRv6 Service Data Sub-Sub-TLV Length (2 octets): This field 384 contains a total length of 6 octets. 386 o Locator Block Length (1 octet): Contains the length of SRv6 SID 387 Locator Block in bits. 389 o Locator Node Length (1 octet): Contains the length of SRv6 SID 390 Locator Node in bits. 392 o Function Length (1 octet): Contains the length of SRv6 SID 393 Function in bits. 395 o Argument Length (1 octet): Contains the length of SRv6 SID 396 Argument in bits. 398 o Transposition Length (1 octet): Size in bits for the part of SID 399 that has been transposed (or shifted) into a MPLS label field 401 o Transposition Offset (1 octet): The offset position in bits for 402 the part of SID that has been transposed (or shifted) into a MPLS 403 label field. 405 Section 4 describes mechanisms for signaling of the SRv6 Service SID 406 by transposing a variable part of the SRv6 SID value and carrying 407 them in existing MPLS label fields to achieve more efficient packing 408 of those service prefix NLRIs in BGP update messages. The SRv6 SID 409 Structure Sub-Sub-TLV contains appropriate length fields when the 410 SRv6 Service SID is signaled in split parts to enable the receiver to 411 put together the SID accurately. 413 Transposition Offset indicates the bit position and Transposition 414 Length indicates the number of bits that are being taken out of the 415 SRv6 SID value and put into high order bits of MPLS label field. The 416 bits that have been shifted out MUST be set to 0 in the SID value. 418 Transposition Length of 0 indicates nothing is transposed and that 419 the entire SRv6 SID value is encoded in the SID Information Sub-TLV. 420 In this case, the Transposition Offset MUST be set to 0. 422 The size of the MPLS label field limits the bits transposed from the 423 SRv6 SID value into it. E.g., the size of MPLS label field in 424 [RFC4364] [RFC8277] is 20 bits while in [RFC7432] is 24 bits. 426 As defined in [RFC8986], the sum of the Locator Block Length (LBL), 427 Locator Node Length (LNL), Function Length (FL), and Argument Length 428 (AL) fields MUST be less than or equal to 128 and greater than the 429 sum of Transposition Offset and Transposition Length. 431 As an example, consider that the sum of the Locator Block and the 432 Locator Node parts is 64. For an SRv6 SID where the entire Function 433 part of size 16 bits is transposed, then the transposition offset is 434 set to 64 and the transposition length is set to 16. While for an 435 SRv6 SID where the Function length is 24 bits and only the lower 436 order 20 bits are transposed (e.g. due to the limit of the MPLS label 437 field size), then the transposition offset is set to 68 and the 438 transposition length is set to 20. 440 BGP speakers that do not support this specification may misinterpret, 441 on the reception of an SRv6-based BGP service route update, the part 442 of the SRv6 SID encoded in MPLS label field(s) as MPLS label values 443 for MPLS-based services. Implementations supporting this 444 specification MUST provide a mechanism to control the advertisement 445 of SRv6-based BGP service routes on a per-neighbor and per-service 446 basis. The details of deployment designs and implementation options 447 are outside the scope of this document. 449 Arguments may be generally applicable for SIDs of only specific SRv6 450 Endpoint behaviors (e.g., End.DT2M) and therefore the Argument length 451 MUST be set to 0 for SIDs where the Argument is not applicable. A 452 receiver is unable to validate the applicability of arguments for 453 SRv6 Endpoint behaviors that are unknown to it and hence MUST ignore 454 SRv6 SIDs with arguments (indicated by non-zero argument length) with 455 unknown endpoint behaviors. For SIDs corresponding to an endpoint 456 behavior that is known, a receiver MUST validate that the consistency 457 of the argument length with the specific endpoint behavior 458 definition. 460 4. Encoding SRv6 SID Information 462 The SRv6 Service SID(s) for a BGP Service Prefix are carried in the 463 SRv6 Services TLVs of the BGP Prefix-SID Attribute. 465 For certain types of BGP Services like L3VPN where a per-VRF SID 466 allocation is used (i.e., End.DT4 or End.DT6 behaviors), the same SID 467 is shared across multiple NLRIs thus providing efficient packing. 468 However, for certain other types of BGP Services like EVPN VPWS where 469 a per-PW SID allocation is required (i.e., End.DX2 behavior), each 470 NLRI would have its own unique SID thereby resulting in inefficient 471 packing. 473 To achieve efficient packing, this document allows the encoding of 474 the SRv6 Service SID either as a whole in the SRv6 Services TLVs or 475 the encoding of only the common part of the SRv6 SID (e.g., Locator) 476 in the SRv6 Services TLVs and encoding the variable (e.g., Function 477 or Argument parts) in the existing label fields specific to that 478 service encoding. This later form of encoding is referred to as the 479 Transposition Scheme where the SRv6 SID Structure Sub-Sub-TLV 480 describes the sizes of the parts of the SRv6 SID and also indicates 481 the offset of the variable part along with its length in SRv6 SID 482 value. The use of the Transposition Scheme is RECOMMENDED for the 483 specific service encodings that allow it as described further in 484 Section 5 and Section 6. 486 As an example, for the EVPN VPWS service prefix described further in 487 Section 6.1.2, the Function part of the SRv6 SID is encoded in the 488 MPLS Label field of the NLRI and the SID value in the SRv6 Services 489 TLV carries only the Locator part with the SRv6 SID Structure Sub- 490 Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV defines the lengths of 491 Locator Block, Locator Node, and Function parts (Arguments are not 492 applicable for the End.DX2 behavior). Transposition Offset indicates 493 the bit position and Transposition Length indicates the number of 494 bits that are being taken out of the SID and put into the label 495 field. 497 In yet another example, for the EVPN Ethernet A-D per Ethernet 498 Segment (ES) route described further in Section 6.1.1, only the 499 Argument of the SID needs to be signaled. This Argument part of the 500 SRv6 SID MAY be transposed in the Ethernet Segment Identifier (ESI) 501 Label field of the ESI Label Extended Community and the SID value in 502 the SRv6 Services TLV is set to 0 along with the inclusion of SRv6 503 SID Structure Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV 504 defines the lengths of Locator Block, Locator Node, Function and 505 Argument parts. The offset and length of the Argument part SID value 506 moved to label field is set in transposition offset and length of SID 507 structure TLV. The receiving router is then able to put together the 508 entire SRv6 Service SID (e.g., for the End.DT2M behavior) placing the 509 label value received in the ESI Label field of the Ethernet A-D per 510 ES route into the correct transposition offset and length in the SRv6 511 SID with the End.DT2M behavior received for an EVPN Route Type 3 512 value. 514 5. BGP based L3 Service over SRv6 516 BGP egress nodes (egress PEs) advertise a set of reachable prefixes. 517 Standard BGP update propagation schemes [RFC4271], which may make use 518 of route reflectors [RFC4456], are used to propagate these prefixes. 519 BGP ingress nodes (ingress PEs) receive these advertisements and may 520 add the prefix to the RIB in an appropriate VRF. 522 Egress PEs which supports SRv6 based L3 services advertises overlay 523 service prefixes along with a Service SID enclosed in an SRv6 L3 524 Service TLV within the BGP Prefix-SID Attribute. This TLV serves two 525 purposes - first, it indicates that the egress PE supports SRv6 526 overlay and the BGP ingress PE receiving this route MUST perform IPv6 527 encapsulation and insert an SRH [RFC8754] when required; second, it 528 indicates the value of the Service SID to be used in the 529 encapsulation. 531 The Service SID thus signaled only has local significance at the 532 egress PE, where it may be allocated or configured on a per-CE or 533 per-VRF basis. In practice, the SID may encode a cross-connect to a 534 specific Address Family table (End.DT) or next-hop/interface (End.DX) 535 as defined in [RFC8986]. 537 The SRv6 Service SID SHOULD be routable (refer section 3.3 of 538 [RFC8986]) within the AS of the egress PE and serves the dual purpose 539 of providing reachability between ingress PE and egress PE while also 540 encoding the SRv6 Endpoint behavior. 542 When steering for SRv6 services is based on shortest path forwarding 543 (e.g., best-effort or IGP Flexible Algorithm 544 [I-D.ietf-lsr-flex-algo]) to the egress PE, the ingress PE 545 encapsulates the IPv4 or IPv6 customer packet in an outer IPv6 header 546 (using H.Encaps or H.Encaps.Red flavors specified in [RFC8986]) where 547 the destination address is the SRv6 Service SID associated with the 548 related BGP route update. Therefore, the ingress PE MUST perform 549 resolvability check for the SRv6 Service SID before considering the 550 received prefix for the BGP best path computation. The resolvability 551 is evaluated as per [RFC4271]. If the SRv6 SID is reachable via more 552 than one forwarding table, local policy is used to determine which 553 table to use. The result of an SRv6 Service SID resolvability (e.g., 554 when provided via IGP Flexible Algorithm) can be ignored if the 555 ingress PE has a local policy that allows an alternate steering 556 mechanism to reach the egress PE. The details of such steering 557 mechanisms are outside the scope of this document. 559 For service over SRv6 core, the egress PE sets the next-hop to one of 560 its IPv6 addresses. Such an address MAY be covered by the SRv6 561 Locator from which the SRv6 Service SID is allocated. The next-hop 562 is used for tracking the reachability of the egress PE based on 563 existing BGP procedures. 565 When the BGP route is received at an ingress PE is colored with a 566 Color Extended community and a valid SRv6 Policy is available, the 567 steering for service flows is performed as described in Section 8 of 568 [I-D.ietf-spring-segment-routing-policy]. When the ingress PE 569 determines (with the help of SRv6 SID Structure) that the Service SID 570 belongs to the same SRv6 Locator as the last SRv6 SID (of the egress 571 PE) in the SR Policy segment list, it MAY exclude that last SRv6 SID 572 when steering the service flow. For example, the effective segment 573 list of the SRv6 Policy associated with SID list would 574 be . 576 5.1. IPv4 VPN Over SRv6 Core 578 The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN 579 Over IPv6 Core defined in [RFC8950]. 581 Label field of IPv4-VPN NLRI is encoded as specified in [RFC8277] 582 with the 20-bit Label Value set to the whole or a portion of the 583 Function part of the SRv6 SID when the Transposition Scheme of 584 encoding (Section 4) is used and otherwise set to Implicit NULL. 585 When using the Transposition Scheme, the Transposition Length MUST be 586 less than or equal to 20 and less than or equal to the Function 587 Length. 589 SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 590 SRv6 Endpoint behavior SHOULD be one of these: End.DX4, End.DT4, 591 End.DT46. 593 5.2. IPv6 VPN Over SRv6 Core 595 The MP_REACH_NLRI over SRv6 core is encoded according to IPv6 VPN 596 over IPv6 Core is defined in [RFC4659]. 598 Label field of the IPv6-VPN NLRI is encoded as specified in [RFC8277] 599 with the 20-bit Label Value set to the whole or a portion of the 600 Function part of the SRv6 SID when the Transposition Scheme of 601 encoding (Section 4) is used and otherwise set to Implicit NULL. 602 When using the Transposition Scheme, the Transposition Length MUST be 603 less than or equal to 20 and less than or equal to the Function 604 Length. 606 SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 607 SRv6 Endpoint behavior SHOULD be one of these: End.DX6, End.DT6, 608 End.DT46. 610 5.3. Global IPv4 over SRv6 Core 612 The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 over 613 IPv6 Core is defined in [RFC8950]. 615 SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 616 SRv6 Endpoint behavior SHOULD be one of these: End.DX4, End.DT4, 617 End.DT46. 619 5.4. Global IPv6 over SRv6 Core 621 The MP_REACH_NLRI over SRv6 core is encoded according to [RFC2545] 623 SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 624 SRv6 Endpoint behavior SHOULD be one of these: End.DX6, End.DT6, 625 End.DT46. 627 6. BGP based Ethernet VPN (EVPN) over SRv6 629 [RFC7432] provides an extendable method of building an Ethernet VPN 630 (EVPN) overlay. It primarily focuses on MPLS based EVPNs and 631 [RFC8365] extends to IP-based EVPN overlays. [RFC7432] defines Route 632 Types 1, 2, and 3 which carry prefixes and MPLS Label fields; the 633 Label fields have a specific use for MPLS encapsulation of EVPN 634 traffic. Route Type 5 carrying MPLS label information (and thus 635 encapsulation information) for EVPN is defined in [RFC9136]. Route 636 Types 6, 7, and 8 are defined in [I-D.ietf-bess-evpn-igmp-mld-proxy]. 638 o Ethernet Auto-discovery Route (Route Type 1) 640 o MAC/IP Advertisement Route (Route Type 2) 642 o Inclusive Multicast Ethernet Tag Route (Route Type 3) 644 o Ethernet Segment route (Route Type 4) 646 o IP prefix route (Route Type 5) 648 o Selective Multicast Ethernet Tag route (Route Type 6) 650 o Multicast Membership Report Synch route (Route Type 7) 651 o Multicast Leave Synch route (Route Type 8) 653 The specifications for other EVPN Route Types are outside the scope 654 of this document. 656 To support SRv6 based EVPN overlays, one or more SRv6 Service SIDs 657 are advertised with Route Type 1, 2, 3, and 5. The SRv6 Service 658 SID(s) per Route Type are advertised in SRv6 L3/L2 Service TLVs 659 within the BGP Prefix-SID Attribute. Signaling of SRv6 Service 660 SID(s) serves two purposes - first, it indicates that the BGP egress 661 device supports SRv6 overlay and the BGP ingress device receiving 662 this route MUST perform IPv6 encapsulation and insert an SRH 663 [RFC8754] when required; second, it indicates the value of the 664 Service SID(s) to be used in the encapsulation. 666 The SRv6 Service SID SHOULD be routable (refer section 3.3 of 667 [RFC8986]) within the AS of the egress PE and serves the dual purpose 668 of providing reachability between ingress PE and egress PE while also 669 encoding the SRv6 Endpoint behavior. 671 When steering for SRv6 services is based on shortest path forwarding 672 (e.g., best-effort or IGP Flexible Algorithm 673 [I-D.ietf-lsr-flex-algo]) to the egress PE, the ingress PE 674 encapsulates the customer Layer 2 Ethernet packet in an outer IPv6 675 header (using H.Encaps.L2 or H.Encaps.L2.Red flavors specified in 676 [RFC8986]) where the destination address is the SRv6 Service SID 677 associated with the related BGP route update. Therefore, the ingress 678 PE MUST perform resolvability check for the SRv6 Service SID before 679 considering the received prefix for the BGP best path computation. 680 The resolvability is evaluated as per [RFC4271]. If the SRv6 SID is 681 reachable via more than one forwarding table, local policy is used to 682 determine which table to use. The result of an SRv6 Service SID 683 resolvability (e.g., when provided via IGP Flexible Algorithm) can be 684 ignored if the ingress PE has a local policy that allows an alternate 685 steering mechanism to reach the egress PE. The details of such 686 steering mechanisms are outside the scope of this document. 688 For service over SRv6 core, the egress PE sets the next-hop to one of 689 its IPv6 addresses. Such an address MAY be covered by the SRv6 690 Locator from which the SRv6 Service SID is allocated. The next-hop 691 is used for tracking the reachability of the egress PE based on 692 existing BGP procedures. 694 When the BGP route is received at an ingress PE is colored with a 695 Color Extended community and a valid SRv6 Policy is available, the 696 steering for service flows is performed as described in Section 8 of 697 [I-D.ietf-spring-segment-routing-policy]. When the ingress PE 698 determines (with the help of SRv6 SID Structure) that the Service SID 699 belongs to the same SRv6 Locator as the last SRv6 SID (of the egress 700 PE) in the SR Policy segment list, it MAY exclude that last SRv6 SID 701 when steering the service flow. For example, the effective segment 702 list of the SRv6 Policy associated with SID list would 703 be . 705 6.1. Ethernet Auto-discovery Route over SRv6 Core 707 Ethernet Auto-Discovery (A-D) routes are Route Type 1 defined in 708 [RFC7432] and may be used to achieve split-horizon filtering, fast 709 convergence, and aliasing. EVPN Route Type 1 is also used in EVPN- 710 VPWS as well as in EVPN flexible cross-connect; mainly used to 711 advertise point-to-point services ID. 713 As a reminder, EVPN Route Type 1 is encoded as follows: 715 +---------------------------------------+ 716 | RD (8 octets) | 717 +---------------------------------------+ 718 |Ethernet Segment Identifier (10 octets)| 719 +---------------------------------------+ 720 | Ethernet Tag ID (4 octets) | 721 +---------------------------------------+ 722 | MPLS label (3 octets) | 723 +---------------------------------------+ 725 Figure 6: EVPN Route Type 1 727 6.1.1. Ethernet A-D per ES Route 729 Ethernet A-D per ES route NLRI encoding over SRv6 core is as per 730 [RFC7432]. 732 The 24-bit ESI label field of the ESI label extended community 733 carries the whole or a portion of the Argument part of the SRv6 SID 734 when the ESI filtering approach is used along with the Transposition 735 Scheme of encoding (Section 4) and otherwise set to Implicit NULL 736 value. In either case, the value is set in the high order 20 bits 737 (e.g., as 0x000030 in the case of Implicit NULL). When using the 738 Transposition Scheme, the Transposition Length MUST be less than or 739 equal to 24 and less than or equal to the Argument Length. 741 A Service SID enclosed in an SRv6 L2 Service TLV within the BGP 742 Prefix-SID attribute is advertised along with the A-D route. The 743 SRv6 Endpoint behavior SHOULD be End.DT2M. When the ESI filtering 744 approach is used, the Service SID is used to signal Arg.FE2 SID 745 Argument for applicable End.DT2M behavior [RFC8986]. When the local- 746 bias approach [RFC8365] is used, the Service SID MAY be of value 0. 748 6.1.2. Ethernet A-D per EVI Route 750 Ethernet A-D per EVI route NLRI encoding over SRv6 core is similar to 751 [RFC7432] and [RFC8214] with the following change: 753 o MPLS Label: 24-bit field carries the whole or a portion of the 754 Function part of the SRv6 SID when the Transposition Scheme of 755 encoding (Section 4) is used and otherwise set to Implicit NULL 756 value. In either case, the value is set in the high order 20 bits 757 (e.g., as 0x000030 in the case of Implicit NULL). When using the 758 Transposition Scheme, the Transposition Length MUST be less than 759 or equal to 24 and less than or equal to the Function Length. 761 A Service SID enclosed in an SRv6 L2 Service TLV within the BGP 762 Prefix-SID attribute is advertised along with the A-D route. The 763 SRv6 Endpoint behavior SHOULD be one of these: End.DX2, End.DX2V, 764 End.DT2U. 766 6.2. MAC/IP Advertisement Route over SRv6 Core 768 EVPN Route Type 2 is used to advertise unicast traffic MAC+IP address 769 reachability through MP-BGP to all other PEs in a given EVPN 770 instance. 772 As a reminder, EVPN Route Type 2 is encoded as follows: 774 +---------------------------------------+ 775 | RD (8 octets) | 776 +---------------------------------------+ 777 |Ethernet Segment Identifier (10 octets)| 778 +---------------------------------------+ 779 | Ethernet Tag ID (4 octets) | 780 +---------------------------------------+ 781 | MAC Address Length (1 octet) | 782 +---------------------------------------+ 783 | MAC Address (6 octets) | 784 +---------------------------------------+ 785 | IP Address Length (1 octet) | 786 +---------------------------------------+ 787 | IP Address (0, 4, or 16 octets) | 788 +---------------------------------------+ 789 | MPLS Label1 (3 octets) | 790 +---------------------------------------+ 791 | MPLS Label2 (0 or 3 octets) | 792 +---------------------------------------+ 794 Figure 7: EVPN Route Type 2 796 NLRI encoding over SRv6 core is similar to [RFC7432] with the 797 following changes: 799 o MPLS Label1: Is associated with the SRv6 L2 Service TLV. This 800 24-bit field carries the whole or a portion of the Function part 801 of the SRv6 SID when the Transposition Scheme of encoding 802 (Section 4) is used and otherwise set to Implicit NULL value. In 803 either case, the value is set in the high order 20 bits (e.g., as 804 0x000030 in the case of Implicit NULL). When using the 805 Transposition Scheme, the Transposition Length MUST be less than 806 or equal to 24 and less than or equal to the Function Length. 808 o MPLS Label2: Is associated with the SRv6 L3 Service TLV. This 809 24-bit field carries the whole or a portion of the Function part 810 of the SRv6 SID when the Transposition Scheme of encoding 811 (Section 4) is used and otherwise set to Implicit NULL value. In 812 either case, the value is set in the high order 20 bits (e.g., as 813 0x000030 in the case of Implicit NULL). When using the 814 Transposition Scheme, the Transposition Length MUST be less than 815 or equal to 24 and less than or equal to the Function Length. 817 Service SIDs enclosed in SRv6 L2 Service TLV and optionally in SRv6 818 L3 Service TLV within the BGP Prefix-SID attribute is advertised 819 along with the MAC/IP Advertisement route. 821 Described below are different types of Route Type 2 advertisements. 823 6.2.1. MAC/IP Advertisement Route with MAC Only 825 o MPLS Label1: Is associated with the SRv6 L2 Service TLV. This 826 24-bit field carries the whole or a portion of the Function part 827 of the SRv6 SID when the Transposition Scheme of encoding 828 (Section 4) is used and otherwise set to Implicit NULL value. In 829 either case, the value is set in the high order 20 bits (e.g., as 830 0x000030 in the case of Implicit NULL). When using the 831 Transposition Scheme, the Transposition Length MUST be less than 832 or equal to 24 and less than or equal to the Function Length. 834 A Service SID enclosed in an SRv6 L2 Service TLV within the BGP 835 Prefix-SID attribute is advertised along with the route. The SRv6 836 Endpoint behavior SHOULD be one of these: End.DX2, End.DT2U. 838 6.2.2. MAC/IP Advertisement Route with MAC+IP 840 o MPLS Label1: Is associated with the SRv6 L2 Service TLV. This 841 24-bit field carries the whole or a portion of the Function part 842 of the SRv6 SID when the Transposition Scheme of encoding 843 (Section 4) is used and otherwise set to Implicit NULL value. In 844 either case, the value is set in the high order 20 bits (e.g., as 845 0x000030 in the case of Implicit NULL). When using the 846 Transposition Scheme, the Transposition Length MUST be less than 847 or equal to 24 and less than or equal to the Function Length. 849 o MPLS Label2: Is associated with the SRv6 L3 Service TLV. This 850 24-bit field carries the whole or a portion of the Function part 851 of the SRv6 SID when the Transposition Scheme of encoding 852 (Section 4) is used and otherwise set to Implicit NULL value. In 853 either case, the value is set in the high order 20 bits (e.g., as 854 0x000030 in the case of Implicit NULL). When using the 855 Transposition Scheme, the Transposition Length MUST be less than 856 or equal to 24 and less than or equal to the Function Length. 858 An L2 Service SID enclosed in an SRv6 L2 Service TLV within the BGP 859 Prefix-SID attribute is advertised along with the route. In 860 addition, an L3 Service SID enclosed in an SRv6 L3 Service TLV within 861 the BGP Prefix-SID attribute MAY also be advertised along with the 862 route. The SRv6 Endpoint behavior SHOULD be one of these: for the L2 863 Service SID - End.DX2, End.DT2U; for the L3 Service SID - End.DT46, 864 End.DT4, End.DT6, End.DX4, End.DX6. 866 6.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core 868 EVPN Route Type 3 is used to advertise multicast traffic reachability 869 information through MP-BGP to all other PEs in a given EVPN instance. 871 As a reminder, EVPN Route Type 3 is encoded as follows: 873 +---------------------------------------+ 874 | RD (8 octets) | 875 +---------------------------------------+ 876 | Ethernet Tag ID (4 octets) | 877 +---------------------------------------+ 878 | IP Address Length (1 octet) | 879 +---------------------------------------+ 880 | Originating Router's IP Address | 881 | (4 or 16 octets) | 882 +---------------------------------------+ 884 Figure 8: EVPN Route Type 3 886 NLRI encoding over SRv6 core is similar to [RFC7432]. 888 PMSI Tunnel Attribute [RFC6514] is used to identify the P-tunnel used 889 for sending broadcast, unknown unicast, or multicast (BUM) traffic. 890 The format of PMSI Tunnel Attribute is encoded as follows over SRv6 891 Core: 893 +---------------------------------------+ 894 | Flag (1 octet) | 895 +---------------------------------------+ 896 | Tunnel Type (1 octet) | 897 +---------------------------------------+ 898 | MPLS label (3 octet) | 899 +---------------------------------------+ 900 | Tunnel Identifier (variable) | 901 +---------------------------------------+ 903 Figure 9: PMSI Tunnel Attribute 905 o Flag: zero value defined per [RFC7432] 907 o Tunnel Type: defined per [RFC6514] 909 o MPLS label: This 24-bit field carries the whole or a portion of 910 the Function part of the SRv6 SID when ingress replication is used 911 and the Transposition Scheme of encoding (Section 4) is used and 912 otherwise, it is set as defined in [RFC6514]. When using the 913 Transposition Scheme, the Transposition Length MUST be less than 914 or equal to 24 and less than or equal to the Function Length. 916 o Tunnel Identifier: IP address of egress PE 918 A Service SID enclosed in an SRv6 L2 Service TLV within the BGP 919 Prefix-SID attribute is advertised along with the route. The SRv6 920 Endpoint behavior SHOULD be End.DT2M. 922 o When ESI-based filtering is used for Multi-Homing or E-Tree 923 procedures, the ESI Filtering Argument (the Arg.FE2 notation 924 introduced in [RFC8986]) of the Service SID carried along with 925 EVPN Route Type 1 route SHOULD be merged with the applicable 926 End.DT2M SID of Type 3 route advertised by remote PE by doing a 927 bit-wise logical-OR operation to create a single SID on the 928 ingress PE. Details of split-horizon ESI-based filtering 929 mechanisms for multihoming are described in [RFC7432]. Details of 930 filtering mechanisms for Leaf-originated BUM traffic in EVPN 931 E-Tree services are provided in [RFC8317]. 933 o When "local-bias" is used as the Multi-Homing split-horizon 934 method, the ESI Filtering Argument SHOULD NOT be merged with the 935 corresponding End.DT2M SID on the ingress PE. Details of the 936 "local-bias" procedures are described in [RFC8365]. 938 Usage of multicast trees as P-tunnels is outside the scope of this 939 document. 941 6.4. Ethernet Segment Route over SRv6 Core 943 As a reminder, an Ethernet Segment route (i.e., EVPN Route Type 4) is 944 encoded as follows: 946 +---------------------------------------+ 947 | RD (8 octets) | 948 +---------------------------------------+ 949 | Ethernet Tag ID (4 octets) | 950 +---------------------------------------+ 951 | IP Address Length (1 octet) | 952 +---------------------------------------+ 953 | Originating Router's IP Address | 954 | (4 or 16 octets) | 955 +---------------------------------------+ 957 Figure 10: EVPN Route Type 4 959 NLRI encoding over SRv6 core is similar to [RFC7432]. 961 SRv6 Service TLVs within the BGP Prefix-SID attribute are not 962 advertised along with this route. The processing of the route has 963 not changed - it remains as described in [RFC7432]. 965 6.5. IP Prefix Route over SRv6 Core 967 EVPN Route Type 5 is used to advertise IP address reachability 968 through MP-BGP to all other PEs in a given EVPN instance. The IP 969 address may include a host IP prefix or any specific subnet. 971 As a reminder, EVPN Route Type 5 is encoded as follows: 973 +---------------------------------------+ 974 | RD (8 octets) | 975 +---------------------------------------+ 976 |Ethernet Segment Identifier (10 octets)| 977 +---------------------------------------+ 978 | Ethernet Tag ID (4 octets) | 979 +---------------------------------------+ 980 | IP Prefix Length (1 octet) | 981 +---------------------------------------+ 982 | IP Prefix (4 or 16 octets) | 983 +---------------------------------------+ 984 | GW IP Address (4 or 16 octets) | 985 +---------------------------------------+ 986 | MPLS Label (3 octets) | 987 +---------------------------------------+ 989 Figure 11: EVPN Route Type 5 991 NLRI encoding over SRv6 core is similar to [RFC9136] with the 992 following change: 994 o MPLS Label: This 24-bit field carries the whole or a portion of 995 the Function part of the SRv6 SID when the Transposition Scheme of 996 encoding (Section 4) is used and otherwise set to Implicit NULL 997 value. In either case, the value is set in the high order 20 bits 998 (e.g., as 0x000030 in the case of Implicit NULL). When using the 999 Transposition Scheme, the Transposition Length MUST be less than 1000 or equal to 24 and less than or equal to the Function Length. 1002 SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 1003 SRv6 Endpoint behavior SHOULD be one of these: End.DT4, End.DT6, 1004 End.DT46, End.DX4, End.DX6. 1006 6.6. EVPN Multicast Routes (Route Types 6, 7, 8) over SRv6 Core 1008 These routes do not require the advertisement of SRv6 Service TLVs 1009 along with them. Similar to EVPN Route Type 4, the BGP Nexthop is 1010 equal to the IPv6 address of egress PE. 1012 7. Implementation Status 1014 [Note to RFC Editor: This section needs to be removed before 1015 publication as RFC.] 1017 The [I-D.matsushima-spring-srv6-deployment-status] describes the 1018 current deployment and implementation status of SRv6 which also 1019 includes the BGP services over SRv6 as specified in this document. 1021 8. Error Handling 1023 In case of any errors encountered while processing SRv6 Service TLVs, 1024 the details of the error SHOULD be logged for further analysis. 1026 If multiple instances of SRv6 L3 Service TLV are encountered, all but 1027 the first instance MUST be ignored. 1029 If multiple instances of SRv6 L2 Service TLV are encountered, all but 1030 the first instance MUST be ignored. 1032 An SRv6 Service TLV is considered malformed in the following cases: 1034 o the TLV Length is less than 1 1036 o the TLV Length is inconsistent with the length of BGP Prefix-SID 1037 attribute 1039 o at least one of the constituent Sub-TLVs is malformed 1041 An SRv6 Service Sub-TLV is considered malformed in the following 1042 cases: 1044 o the Sub-TLV Length is inconsistent with the length of the 1045 enclosing SRv6 Service TLV 1047 An SRv6 SID Information Sub-TLV is considered malformed in the 1048 following cases: 1050 * the Sub-TLV Length is less than 21 1051 * the Sub-TLV Length is inconsistent with the length of the 1052 enclosing SRv6 Service TLV 1054 * at least one of the constituent Sub-Sub-TLVs is malformed 1056 An SRv6 Service Data Sub-Sub-TLV is considered malformed in the 1057 following cases: 1059 o the Sub-Sub-TLV Length is inconsistent with the length of the 1060 enclosing SRv6 service Sub-TLV 1062 Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because 1063 its Type is unrecognized. 1065 Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because 1066 of failing any semantic validation of its Value field. 1068 SRv6 overlay service requires Service SID for forwarding. The treat- 1069 as-withdraw action [RFC7606] MUST be performed when at least one 1070 malformed SRV6 Service TLV is present in the BGP Prefix-SID 1071 attribute. 1073 SRv6 SID value in SRv6 SID Information Sub-TLV is invalid when SID 1074 Structure Sub-Sub-TLV transposition length is greater than the number 1075 of bits of the label field or if any of the conditions for the fields 1076 of the sub-sub-TLV as specified in Section 3.2.1 is not met. The 1077 transposition offset and length MUST be 0 when the Sub-Sub-TLV is 1078 advertised along with routes where transposition scheme is not 1079 applicable (e.g., for Global IPv6 Service [RFC2545] where there is no 1080 label field). The path having such Prefix-SID Attribute without any 1081 valid SRv6 SID information MUST be considered ineligible during the 1082 selection of the best path for the corresponding prefix. 1084 9. IANA Considerations 1086 9.1. BGP Prefix-SID TLV Types Registry 1088 This document introduces two new TLV Types of the BGP Prefix-SID 1089 attribute. IANA has assigned Type values in the registry "BGP 1090 Prefix-SID TLV Types" as follows: 1092 Value Type Reference 1093 -------------------------------------------- 1094 4 Deprecated 1095 5 SRv6 L3 Service TLV 1096 6 SRv6 L2 Service TLV 1098 Figure 12: BGP Prefix-SID TLV Types 1100 The value 4 previously corresponded to the SRv6-VPN SID TLV, which 1101 was specified in previous versions of this document and used by early 1102 implementations of this specification. It was deprecated and 1103 replaced by the SRv6 L3 Service and SRv6 L2 Service TLVs. 1105 9.2. SRv6 Service Sub-TLV Types Registry 1107 IANA is requested to create and maintain a new registry called "SRv6 1108 Service Sub-TLV Types" under the "Border Gateway Protocol (BGP) 1109 Parameters" registry. The allocation policy for this registry is: 1111 0 : Reserved 1112 1-127 : IETF Review 1113 128-254 : First Come First Served 1114 255 : Reserved 1116 Figure 13: SRv6 Service Sub-TLV Types Allocation Policy 1118 The following Sub-TLV Type is defined in this document: 1120 Value Type Reference 1121 ---------------------------------------------------- 1122 1 SRv6 SID Information Sub-TLV 1124 Figure 14: SRv6 Service Sub-TLV Types 1126 9.3. SRv6 Service Data Sub-Sub-TLV Types Registry 1128 IANA is requested to create and maintain a new registry called "SRv6 1129 Service Data Sub-Sub-TLV Types" under the "Border Gateway Protocol 1130 (BGP) Parameters" registry. The allocation policy for this registry 1131 is: 1133 0 : Reserved 1134 1-127 : IETF Review 1135 128-254 : First Come First Served 1136 255 : Reserved 1138 Figure 15: SRv6 Service Data Sub-Sub-TLV Types Allocation Policy 1140 The following Sub-Sub-TLV Type is defined in this document: 1142 Value Type Reference 1143 ---------------------------------------------------- 1144 1 SRv6 SID Structure Sub-Sub-TLV 1146 Figure 16: SRv6 Service Data Sub-Sub-TLV Types 1148 9.4. BGP SRv6 Service SID Flags Registry 1150 IANA is requested to create and maintain a new registry called "BGP 1151 SRv6 Service SID Flags" under the "Border Gateway Protocol (BGP) 1152 Parameters" registry. The allocation policy for this registry is 1153 IETF Review and all 8 bit positions of the flags are currently 1154 unassigned. 1156 9.5. Subsequent Address Family Identifiers (SAFI) Parameters Registry 1158 IANA is requested to add this document as a reference for value 128 1159 in the "Subsequent Address Family Identifiers (SAFI) Parameters" 1160 registry. 1162 10. Security Considerations 1164 This document specifies extensions to the BGP protocol for signaling 1165 of services for SRv6. These specifications leverage existing BGP 1166 protocol mechanisms for the signaling of various types of services. 1167 It also builds upon existing elements of the SR architecture (more 1168 specifically SRv6). As such, this section largely provides pointers 1169 (as a reminder) to the security considerations of those existing 1170 specifications while also covering certain newer security aspects for 1171 the specifications newly introduced by this document. 1173 10.1. BGP Session Related Considerations 1175 Techniques related to authentication of BGP sessions for securing 1176 messages between BGP peers as discussed in the BGP specification 1177 [RFC4271] and, in the security analysis for BGP [RFC4272] apply. The 1178 discussion of the use of the TCP Authentication option to protect BGP 1179 sessions is found in [RFC5925], while [RFC6952] includes an analysis 1180 of BGP keying and authentication issues. This document does not 1181 introduce any additional BGP session security considerations. 1183 10.2. BGP Services Related Considerations 1185 This document does not introduce new services or BGP NLRI types but 1186 extends the signaling of existing ones for SRv6. Therefore, the 1187 security considerations for the respective BGP services BGP IPv4 over 1188 IPv6 NH [RFC8950], BGP IPv6 L3VPN [RFC4659], BGP IPv6 [RFC2545], BGP 1189 EVPN [RFC7432] and IP EVPN [RFC9136] apply as discussed in their 1190 respective documents. [RFC8669] discusses mechanisms to prevent 1191 leaking of BGP Prefix-SID attribute, that carries SR information, 1192 outside the SR domain. 1194 As a reminder, several of the BGP services (i.e., the AFI/SAFI used 1195 for their signaling) were initially introduced for one encapsulation 1196 mechanism and later extended for others e.g., EVPN MPLS [RFC7432] was 1197 extended for VXLAN/NVGRE encapsulation [RFC8365]. [RFC9012] enables 1198 the use of various IP encapsulation mechanisms along with different 1199 BGP SAFIs for their respective services. The existing filtering 1200 mechanisms for preventing the leak of the encapsulation information 1201 (carried in BGP attributes) and to prevent the advertisement of 1202 prefixes from the provider's internal address space (especially the 1203 SRv6 Block as discussed in [RFC8986]) to external peers (or into the 1204 Internet) also apply in the case of SRv6. 1206 Specific to SRv6, a misconfig or error in the above mentioned BGP 1207 filtering mechanisms may result in exposing information such as SRv6 1208 Service SIDs to external peers or other unauthorized entities. 1209 However, an attempt to exploit this information or to raise an attack 1210 by injecting packets into the network (e.g. customer networks in case 1211 of VPN services) is mitigated by the existing SRv6 data plane 1212 security mechanisms as described in the next section. 1214 10.3. SR over IPv6 Data Plane Related Considerations 1216 This section provides a brief reminder and an overview of the 1217 security considerations related to SRv6 with pointers to existing 1218 specifications. This document introduces no new security 1219 considerations of its own from the SRv6 data plane perspective. 1221 SRv6 operates within a trusted SR domain. The data packets 1222 corresponding to service flows between PE routers are encapsulated 1223 (using SRv6 SIDs advertised via BGP) and carried within this trusted 1224 SR domain (e.g., within a single AS or between multiple ASes within a 1225 single provider network). 1227 The security considerations of the Segment Routing architecture are 1228 covered by [RFC8402]. More detailed security considerations 1229 specifically of SRv6 and SRH are covered by [RFC8754] as they relate 1230 to SR Attacks (section 7.1), Service Theft (section 7.2) and Topology 1231 Disclosure (section 7.3). As such an operator deploying SRv6 MUST 1232 follow the considerations described in [RFC8754] section 7 to 1233 implement the infrastructure ACLs, BCP 38 [RFC2827] and BCP 84 1234 [RFC3704] recommendations. 1236 The SRv6 deployment and SID allocation guidelines as described in 1237 [RFC8986] simplify the deployment of the ACL filters (e.g., a single 1238 ACL corresponding to the SRv6 Block applied to the external 1239 interfaces on border nodes is sufficient to block packets destined to 1240 any SRv6 SID in the domain from external/unauthorized networks). 1241 While there is an assumed trust model within a SR domain such that 1242 any node sending packet to an SRv6 SID is assumed to be allowed to do 1243 so, there is also the option of using SRH HMAC TLV [RFC8754] as 1244 described in [RFC8986] for validation. 1246 The SRv6 SID Endpoint behaviors implementing the services signalled 1247 in this document are defined in [RFC8986] and hence the security 1248 considerations of that document apply. These considerations are 1249 independent of the protocol used for service deployment, i.e. 1250 independent of BGP signaling of SRv6 services. 1252 These considerations help protect transit traffic as well as 1253 services, such as VPNs, to avoid service theft or injection of 1254 traffic into customer VPN. 1256 11. Acknowledgments 1258 The authors of this document would like to thank Stephane Litkowski, 1259 Rishabh Parekh, Xiejingrong, Rajesh M, Mustapha Aissaoui, Alexander 1260 Vainshtein, Eduard Metz, Shraddha Hegde, Eduard Vasilenko, Ron 1261 Bonica, and Joel Halpern for their comments and review of this 1262 document. The authors would also like to thank Matthew Bocci for his 1263 document shepherd review and Martin Vigoureux for his AD review that 1264 resulted in helpful comments for improving this document. 1266 12. Contributors 1268 Clarence Filsfils 1269 Cisco 1271 Email: cfilsfil@cisco.com 1273 Satoru Matsushima 1274 SoftBank 1276 Email: satoru.matsushima@g.softbank.co.jp 1278 Dirk Steinberg 1279 Steinberg Consulting 1281 Email: dirk@lapishills.com 1283 Daniel Bernier 1284 Bell Canada 1286 Email: daniel.bernier@bell.ca 1287 Daniel Voyer 1288 Bell Canada 1290 Email: daniel.voyer@bell.ca 1292 Jonn Leddy 1293 Individual 1295 Email: john@leddy.net 1297 Swadesh Agrawal 1298 Cisco 1300 Email: swaagraw@cisco.com 1302 Patrice Brissette 1303 Cisco 1305 Email: pbrisset@cisco.com 1307 Ali Sajassi 1308 Cisco 1310 Email: sajassi@cisco.com 1312 Bart Peirens 1313 Proximus 1314 Belgium 1316 Email: bart.peirens@proximus.com 1318 Darren Dukes 1319 Cisco 1321 Email: ddukes@cisco.com 1323 Pablo Camarilo 1324 Cisco 1326 Email: pcamaril@cisco.com 1328 Shyam Sethuram 1329 Cisco 1331 Email: shyam.ioml@gmail.com 1332 Zafar Ali 1333 Cisco 1335 Email: zali@cisco.com 1337 13. References 1339 13.1. Normative References 1341 [I-D.ietf-bess-evpn-igmp-mld-proxy] 1342 Sajassi, A., Thoria, S., Mishra, M., Drake, J., and W. 1343 Lin, "IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn- 1344 igmp-mld-proxy-20 (work in progress), March 2022. 1346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1347 Requirement Levels", BCP 14, RFC 2119, 1348 DOI 10.17487/RFC2119, March 1997, 1349 . 1351 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1352 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 1353 DOI 10.17487/RFC2545, March 1999, 1354 . 1356 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1357 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1358 DOI 10.17487/RFC4271, January 2006, 1359 . 1361 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1362 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1363 2006, . 1365 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1366 Reflection: An Alternative to Full Mesh Internal BGP 1367 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1368 . 1370 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1371 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1372 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 1373 . 1375 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1376 "Multiprotocol Extensions for BGP-4", RFC 4760, 1377 DOI 10.17487/RFC4760, January 2007, 1378 . 1380 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1381 Encodings and Procedures for Multicast in MPLS/BGP IP 1382 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1383 . 1385 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1386 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1387 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1388 2015, . 1390 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1391 Patel, "Revised Error Handling for BGP UPDATE Messages", 1392 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1393 . 1395 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1396 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1397 May 2017, . 1399 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1400 (IPv6) Specification", STD 86, RFC 8200, 1401 DOI 10.17487/RFC8200, July 2017, 1402 . 1404 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 1405 Rabadan, "Virtual Private Wire Service Support in Ethernet 1406 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 1407 . 1409 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 1410 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 1411 . 1413 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 1414 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 1415 Support in Ethernet VPN (EVPN) and Provider Backbone 1416 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 1417 January 2018, . 1419 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 1420 Uttaro, J., and W. Henderickx, "A Network Virtualization 1421 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 1422 DOI 10.17487/RFC8365, March 2018, 1423 . 1425 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1426 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1427 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1428 July 2018, . 1430 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 1431 A., and H. Gredler, "Segment Routing Prefix Segment 1432 Identifier Extensions for BGP", RFC 8669, 1433 DOI 10.17487/RFC8669, December 2019, 1434 . 1436 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1437 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1438 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1439 . 1441 [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. 1442 Patel, "Advertising IPv4 Network Layer Reachability 1443 Information (NLRI) with an IPv6 Next Hop", RFC 8950, 1444 DOI 10.17487/RFC8950, November 2020, 1445 . 1447 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1448 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1449 (SRv6) Network Programming", RFC 8986, 1450 DOI 10.17487/RFC8986, February 2021, 1451 . 1453 [RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and 1454 A. Sajassi, "IP Prefix Advertisement in Ethernet VPN 1455 (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021, 1456 . 1458 13.2. Informative References 1460 [I-D.ietf-idr-segment-routing-te-policy] 1461 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 1462 Jain, D., and S. Lin, "Advertising Segment Routing 1463 Policies in BGP", draft-ietf-idr-segment-routing-te- 1464 policy-16 (work in progress), March 2022. 1466 [I-D.ietf-lsr-flex-algo] 1467 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1468 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1469 algo-18 (work in progress), October 2021. 1471 [I-D.ietf-spring-segment-routing-policy] 1472 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1473 P. Mattes, "Segment Routing Policy Architecture", draft- 1474 ietf-spring-segment-routing-policy-21 (work in progress), 1475 March 2022. 1477 [I-D.matsushima-spring-srv6-deployment-status] 1478 Matsushima, S., Filsfils, C., Ali, Z., Li, Z., Rajaraman, 1479 K., and A. Dhamija, "SRv6 Implementation and Deployment 1480 Status", draft-matsushima-spring-srv6-deployment-status-13 1481 (work in progress), March 2022. 1483 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1484 Defeating Denial of Service Attacks which employ IP Source 1485 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1486 May 2000, . 1488 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1489 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 1490 2004, . 1492 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1493 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1494 . 1496 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1497 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1498 June 2010, . 1500 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1501 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1502 2012, . 1504 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1505 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1506 and Authentication for Routing Protocols (KARP) Design 1507 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1508 . 1510 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 1511 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 1512 DOI 10.17487/RFC9012, April 2021, 1513 . 1515 Authors' Addresses 1517 Gaurav Dawra (editor) 1518 LinkedIn 1519 USA 1521 Email: gdawra.ietf@gmail.com 1523 Ketan Talaulikar (editor) 1524 Cisco Systems 1525 India 1527 Email: ketant.ietf@gmail.com 1529 Robert Raszuk 1530 NTT Network Innovations 1531 940 Stewart Dr 1532 Sunnyvale, CA 94085 1533 USA 1535 Email: robert@raszuk.net 1537 Bruno Decraene 1538 Orange 1539 France 1541 Email: bruno.decraene@orange.com 1543 Shunwan Zhuang 1544 Huawei Technologies 1545 China 1547 Email: zhuangshunwan@huawei.com 1549 Jorge Rabadan 1550 Nokia 1551 USA 1553 Email: jorge.rabadan@nokia.com