idnits 2.17.1 draft-sr-bess-evpn-dpath-00.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 (October 25, 2021) is 914 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 (-10) exists of draft-ietf-bess-evpn-ipvpn-interworking-06 == Outdated reference: A later version (-08) exists of draft-ietf-bess-rfc7432bis-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup J. Rabadan, Ed. 3 Internet-Draft S. Sathappan 4 Intended status: Standards Track Nokia 5 Expires: April 28, 2022 October 25, 2021 7 Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks 8 draft-sr-bess-evpn-dpath-00 10 Abstract 12 The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet 13 Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. 14 When used along with EVPN IP Prefix routes or IP-VPN routes, it 15 identifies the domain(s) through which the routes have passed and 16 that information can be used by the receiver BGP speakers to detect 17 routing loops or influence the BGP best path selection. This 18 document extends the use of D-PATH so that it can also be used along 19 with EVPN MAC/IP Advertisement routes in EVPN Broadcast Domains (BD) 20 and Auto-Discovery per EVPN Instance routes in Virtual Private Wire 21 Services (VPWS). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 28, 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction and Problem Statement . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 2 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Use of Domain Path Attribute (D-PATH) with EVPN MAC/IP 61 Advertisement routes . . . . . . . . . . . . . . . . . . . . 4 62 4.1. Loop Detection . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. D-PATH and Best Path Selection for MAC/IP Advertisement 64 routes . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.3. D-PATH and Best Path Selection for Ethernet A-D per EVI 66 routes . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 68 5. Use-Case Examples . . . . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 72 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 10.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction and Problem Statement 80 The BGP Domain PATH (D-PATH) attribute 81 [I-D.ietf-bess-evpn-ipvpn-interworking] is defined for Inter-Subnet 82 Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. 83 When used along with EVPN IP Prefix routes or IP-VPN routes, it 84 identifies the domain(s) through which the routes have passed and 85 that information can be used by the receiver BGP speakers to detect 86 routing loops or influence the BGP best path selection. This 87 document extends the use of D-PATH so that it can also be used along 88 with EVPN MAC/IP Advertisement routes in EVPN Broadcast Domains (BD) 89 [I-D.ietf-bess-rfc7432bis] and Auto-Discovery per EVPN Instance 90 routes in Virtual Private Wire Services (VPWS) [RFC8214]. 92 2. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 3. Terminology 102 This section summarizes the terminology that is used throughout the 103 rest of the document. 105 o MAC-VRF: a MAC Virtual Routing and Forwarding table, as defined in 106 [I-D.ietf-bess-rfc7432bis]. It is also the instantiation of an 107 EVI (EVPN Instance) in a PE. 109 o BD and BT: a Broadcast Domain and Bridge Table, as defined in 110 [I-D.ietf-bess-rfc7432bis]. A BD is a group of PEs attached to 111 the same EVPN layer-2 multipoint service. A BT is the 112 instantiation of a Broadcast Domain in a PE. When there is a 113 single Broadcast Domain in a given EVI, the MAC-VRF in each PE 114 will contain a single BT. When there are multiple BTs within the 115 same MAC-VRF, each BT is associated to a different Ethernet Tag. 116 The EVPN routes specific to a BT, will indicate which Ethernet Tag 117 the route corresponds to. 119 o AC: Attachment Circuit or logical interface associated to a given 120 BT. To determine the AC on which a packet arrived, the PE will 121 examine the combination of a physical port and VLAN tags (where 122 the VLAN tags can be individual c-tags, s-tags or ranges of both). 124 o RT-2: Route Type 2 or MAC/IP Advertisement route, as per 125 [I-D.ietf-bess-rfc7432bis]. 127 o RT-1: Route Type 1 or Ethernet Auto-Discovery route, as per 128 [I-D.ietf-bess-rfc7432bis]. 130 o ES and ESI: Ethernet Segment and Ethernet Segment Identifier, as 131 defined in [I-D.ietf-bess-rfc7432bis]. 133 o TS: Tenant System. 135 o EVPN Layer2-Domain: two PEs are in the same Layer2-Domain if they 136 are attached to the same tenant and the packets between them do 137 not require a data path MAC lookup (in the BT of a MAC-VRF) in any 138 intermediate router. A Layer2-Domain Gateway PE is always 139 configured with multiple Layer2-Domain identifiers (Layer2-Domain- 140 ID) in the MAC-VRF that connects those Layer2-Domains, each 141 Layer2-Domain-ID representing a Layer2-Domain. 143 Example: Figure 1 illustrates an example where PE1 and PE2 belong 144 to different Layer2-Domains since packets between them (for flows 145 between TS1 and TS2) require a MAC lookup in two of the gateways 146 that are connecting the three EVPN Layer2-Domains. E.g., if 147 frames from TS1 to TS2 go through PE1, GW1, GW3 and PE2, a MAC 148 lookup is performed at GW1 and GW3. 150 GW1------------GW3 151 +------+ +------+ 152 +-------------| BD1 | | BD1 |-------------+ 153 PE1 +------+ +------+ PE2 154 +------+ | Interconnect | +------+ 155 TS1-| BD1 | EVPN | EVPN | EVPN | BD1 |-TS2 156 +------+ GW2 GW4 +---+--+ 157 | +------+ +------+ | 158 +-------------| BD1 | | BD1 |-------------+ 159 +------+ +------+ 160 +--------------+ 161 Layer2-Domain 1 Layer2-Domain 2 Layer2-Domain 3 162 <---------------> <------------> <----------------> 164 Figure 1: EVPN Sub-Domain example 166 o Layer2-Domain Gateway PE: a PE that is attached to two or more 167 EVPN Layer2-Domains. An example of Layer2-Domain Gateway PE is a 168 PE following the procedures in section 4.4 or section 4.6 of 169 [RFC9014]. In the example in Figure 1, GW1 and GW2 connect 170 Layer2-Domains 1 and 2, whereas GW3 and GW4 connect Layer2-Domains 171 2 and 3. GW1 and GW2 import the MAC/IP Advertisement route for 172 TS1 coming from the Layer2-Domain 1 into the MAC-VRF for BD1, and 173 re-advertise it into Layer2-Domain 2. Likewise, GW3 and GW4 174 import the route into their MAC-VRF and re-advertise it into 175 Layer2-Domain 3. 177 4. Use of Domain Path Attribute (D-PATH) with EVPN MAC/IP Advertisement 178 routes 180 This document extends the use of the D-PATH attribute specified in 181 [I-D.ietf-bess-evpn-ipvpn-interworking] so that D-PATH can be 182 advertised and processed along with the following EVPN route types: 184 o EVPN MAC/IP Advertisement routes that are not used for Inter- 185 Subnet Forwarding (ISF) [RFC9135]. Note: if the EVPN MAC/IP 186 Advertisement route is used for Inter-Subnet Forwarding, the 187 procedures for the D-PATH advertisement and processing are 188 described in [I-D.ietf-bess-evpn-ipvpn-interworking]. 190 o EVPN A-D per EVI routes that are used for EVPN-VPWS [RFC8214]. 191 The use of D-PATH in A-D per EVI routes not used for EVPN-VPWS is 192 out of scope of this document. 194 The use of D-PATH along with other EVPN route types will be described 195 in future versions of this document. 197 When used along with non-ISF MAC/IP Advertisement routes or A-D per 198 EVI routes, the D-PATH attribute is characterized as follows: 200 1. D-PATH is composed of a sequence of Domain segments following the 201 format specified in [I-D.ietf-bess-evpn-ipvpn-interworking] where 202 each Domain is represented as . In this 203 specification, DOMAIN-ID is a Layer2-Domain identifier configured 204 in a MAC-VRF and ISF_SAFI_TYPE is set to either 70 (EVPN) or 0 205 (local route). To simplify the explanation, this document 206 represents the domains for EVPN RT-1s and RT-2s as . 209 2. D-PATH identifies the sequence of Layer2-Domains the route has 210 gone through, with the last entry 211 (rightmost) identifying the first PE that added the D-PATH 212 attribute. 214 3. D-PATH SHOULD be added/modified by a Layer2-Domain Gateway PE 215 that re-advertises the route and MAY be added by a PE that 216 originates the route, as follows: 218 A. A Layer2-Domain Gateway PE that connects two Layer2-Domains 219 "X" and "Y", and receives a route on a Layer2-Domain 220 identified by a Layer2-Domain-ID "X" SHOULD append a domain 221 to the existing (or newly added) D-PATH attribute 222 when re-advertising the route to Layer2-Domain "Y". The 223 route is re-advertised if it is first imported in a MAC-VRF 224 (or VPWS instance), the MAC (or Ethernet Tag) is active, and 225 policy allows the re-export of the route to a BGP neighbor. 227 B. A Layer2-Domain Gateway PE MAY also add the D-PATH attribute 228 for locally learned MACs or MAC/IP pairs. In this case, the 229 domain added would be , where A is the Layer2-Domain-ID 230 configured on the Gateway PE's MAC-VRF that is specific to 231 local routes (MAC/IP learned via local AC), and "0" is the 232 TYPE of the Layer2-Domain and indicates that the route is 233 locally originated and not re-advertised after receiving it 234 from a BGP-EVPN neighbor. The Layer2-Domain-ID for local 235 routes MAY be shared by all the redundant Layer2-Domain 236 Gateway PEs for local routes, or each Layer2-Domain Gateway 237 PE of the redundancy group can use its own Layer2-Domain-ID. 239 C. A PE that is connected to a single Layer2-Domain (therefore 240 the PE is not a Layer2-Domain Gateway) MAY add the D-PATH 241 with a domain , where B is the Layer2-Domain-ID 242 configured on the PE's MAC-VRF (or VPWS) for locally learned 243 MAC/IPs (or Ethernet Tag IDs for VPWS). "0" is the TYPE that 244 indicates the route is not re-advertised, but originated in 245 the PE. 247 4. On received EVPN routes, D-PATH is processed and used for loop 248 detection (Section 4.1) as well as to influence the best path 249 selection (Section 4.2 and Section 4.3). 251 4.1. Loop Detection 253 An EVPN route received by a PE with a D-PATH attribute that contains 254 one or more of its locally associated Layer2-Domain-IDs for the MAC- 255 VRF or VPWS instance is considered to be a looped route. A looped 256 route MUST NOT be installed, but kept in the BGP RIB, flagged as 257 "looped". 259 For instance, in the example of Figure 1, assuming PE1 advertises 260 TS1's MAC/IP and does not add the D-PATH attribute, the Layer2-Domain 261 Gateway GW1 receives two MAC/IP Advertisement routes for TS1's MAC/ 262 IP: 264 o A RT-2 with next-hop PE1 and no D-PATH. 266 o A RT-2 with next-hop GW2 and D-PATH={length=1,<6500:1:EVPN>}, 267 assuming that the Layer2-Domain-ID for Layer2-Domain 1 is 6500:1. 269 In this case, Layer2-Domain Gateway GW1 flags the RT-2 with D-PATH as 270 "looped", and does not install the MAC in the BT of the MAC-VRF, 271 since the route includes one of GW1's Layer2-Domain-IDs. 273 4.2. D-PATH and Best Path Selection for MAC/IP Advertisement routes 275 When two (or more) MAC/IP Advertisement routes with the same route 276 key (and same or different RDs) are received, a best path selection 277 algorithm is used. This section summarizes the best path selection 278 for MAC/IP Advertisement routes, which extends the rules in 279 [I-D.ietf-bess-rfc7432bis] by including D-PATH in the tie-breaking 280 algorithm. While the algorithm may be implemented in different ways, 281 the selection result SHOULD be the same as the result of the rules 282 that follow. 284 The tie-breaking algorithm begins by considering all EVPN MAC/IP 285 Advertisement routes equally preferable routes to the same 286 destination, and then selects routes to be removed from 287 consideration. The process terminates as soon as only one route 288 remains in consideration. 290 1. When the Default Gateway extended community is present in some of 291 the routes, the MAC/IP Advertisement routes without the Default 292 Gateway indication are removed from consideration, as defined in 293 [I-D.ietf-bess-rfc7432bis]. 295 2. Then the routes with the Static bit set in the MAC Mobility 296 extended community are preferred, and the routes without the 297 Static bit set are removed from consideration, as defined in 298 [I-D.ietf-bess-rfc7432bis]. Note that this rule does not apply 299 to routes with the Default Gateway extended community, since 300 these routes SHALL NOT convey the MAC Mobility extended community 301 [I-D.ietf-bess-rfc7432bis]. 303 3. Then the routes with the highest MAC Mobility Sequence number are 304 preferred, hence the routes that are not tied for having the 305 highest Sequence number are removed from consideration, as 306 defined in [I-D.ietf-bess-rfc7432bis]. 308 4. Then routes with the highest Local Preference are preferred, 309 hence routes that are not tied for having the highest Local 310 Preference are removed from consideration, as defined in 311 [RFC4271]. 313 5. Then routes with the shortest D-PATH are preferred, hence routes 314 not tied for the shortest D-PATH are removed. Routes without 315 D-PATH are considered zero-length D-PATH. 317 6. Then routes with the numerically lowest left-most Sub-Domain-ID 318 are preferred, hence routes not tied for the numerically lowest 319 left-most Sub-Domain-ID are removed from consideration. 321 7. If the steps above do not produce a single route, the rest of the 322 rules after the highest Local Preference in [RFC4271] apply after 323 step 6. 325 The above selection criteria is followed irrespective of the ESI 326 value in the routes. EVPN Multi-Homing procedures for Aliasing or 327 Backup paths in [I-D.ietf-bess-rfc7432bis] are applied to the 328 selected MAC/IP Advertisement route. 330 4.3. D-PATH and Best Path Selection for Ethernet A-D per EVI routes 332 When two (or more) EVPN A-D per EVI routes with the same route key 333 (and same or different RDs) are received for a VPWS, a best path 334 selection algorithm is used. The selection algorithm follows the 335 same steps as in Section 4.2 except for steps 1-3 which do not apply 336 since the Default Gateway and MAC Mobility extended community are 337 irrelevant to the EVPN A-D per EVI routes. 339 The above selection is followed for A-D per EVI routes with ESI=0. 340 For non-zero ESI routes, the EVPN Multi-Homing procedures in 341 [RFC8214] for Aliasing and Backup path are followed to select the 342 routes (P and B flags are considered for the selection of the routes 343 when sending traffic to a remote Ethernet Segment). If the mentioned 344 Multi-Homing procedures do not produce a single route to each of the 345 remote PEs attached to the same ES, steps 4-7 in Section 4.2 are 346 followed. 348 4.4. Error Handling 350 The error handling for the D-PATH attribute is described in 351 [I-D.ietf-bess-evpn-ipvpn-interworking]. This document extends the 352 use of D-PATH to non-ISF EVPN routes. 354 5. Use-Case Examples 356 This section illustrates the use of D-PATH in EVPN routes with 357 examples. 359 Figure 2 and Figure 3 illustrate an integrated interconnect solution 360 for an EVPN BD, as described in section 4.4 and section 4.6 of 361 [RFC9014]. GW1 and GW2 are Layer2-Domain Gateway PEs connecting two 362 L2-Domains identified by D-PATH domain {1:1:EVPN} and {1:2:EVPN}, 363 respectively. Received Ethernet A-D routes, ES routes, and Inclusive 364 Multicast routes from the routers in one Layer2-Domain are consumed 365 and processed by GW1 and GW2, but not re-advertised to the other 366 Layer2-Domain. However, MAC/IP Advertisement routes received by GW1 367 and GW2 in one Layer2-Domain are processed and, if installed, re- 368 advertised into the other Layer2-Domain. 370 Consider the example of Figure 2, where PE1 advertises a MAC/IP 371 Advertisement route for M1/IP1. The route is processed and installed 372 by GW1 and GW2 in BD1, and both will re-advertise the routes into the 373 Layer2-Domain-2. By using D-PATH in GW1 and GW2, when the route is 374 received on PE2, PE2 has the visibility of the Layer2-Domains through 375 which the route has gone, and can also use the D-PATH for best path 376 selection in case PE2 receives a MAC/IP Advertisement route for M1/ 377 IP1 by some other means. In addition, GW1 and GW2 can compare the 378 D-PATH of the incoming routes with their local list of Layer2-Domain- 379 IDs, and detect a loop if any of the local Layer2-Domain-IDs matches 380 a domain in the received D-PATH. This procedure prevents the re- 381 advertisement of the route back into Layer2-Domain-1. 383 +--Layer2-Domain-1---+ +--Layer2-Domain-2--+ 384 | 1:1:EVPN | GW1 | 1:2:EVPN | 385 | +---------+ | 386 | | +-----+ | | 387 | | | BD1 | X <-+ | 388 PE1 | +-----+ | | PE2 389 +---------+ +---------+ | +---------+ 390 | +-----+ | | | | | +-----+ | 391 M1-----| BD1 | | | | | | | BD1 |-----M2 392 | +-----+ | -------> | | | | +-----+ | 393 +---------+ (RT2)M1/IP1 | | | +---------+ 394 | +---------+ | | 395 | | +-----+ | |(RT2)M1/IP1 | 396 | | | BD1 | | --+ {1:1:EVPN} | 397 | | +-----+ | | 398 | +---------+ | 399 | | GW2 | | 400 +---------------------+ +-------------------+ 402 Figure 2: EVPN Interconnect 404 The example of Figure 3 illustrates how GW1 and GW2 can also have 405 local ACs in BD1 and learn local MAC (or MAC/IP) addresses from 406 devices connected to the ACs. Assuming GW2 learns M3/IP3 via local 407 AC, GW2 advertises a MAC/IP Advertisement route for M3/IP3 into each 408 of the Layer2-Domains that GW2 is connected to. As described in 409 Section 4, GW2 can advertise these two MAC/IP Advertisement routes 410 with a configured Layer2-Domain-ID for local MAC/IPs routes that can 411 be shared with GW1. Consider this Layer2-Domain-ID is 1:3 and it is 412 configured on both, GW1 and GW2. When GW2 advertises the route into 413 each Layer2-Domain, it adds the D-PATH attribute with a domain 414 {1:3:0}. These routes will be flagged by GW1 as "looped" since 1:3 is 415 configured as a local Layer2-Domain-ID in GW1. In addition, PE1 and 416 PE2 will receive the routes with the D-PATH and they will have the 417 visibility of the origin of the routes, in this case local 418 Layer2-Domain Gateway routes. This information can be used to 419 influence the best path selection in case of multiple routes for M3/ 420 IP3 are received on PE1 or PE2 for BD1. 422 +--Layer2-Domain-1---+ +--Layer2-Domain-2--+ 423 | 1:1:EVPN | GW1 | 1:2:EVPN | 424 | +---------+ | 425 | | +-----+ | | 426 | +-->X| | BD1 | |X<--+ | 427 PE1 | | +-----+ | | PE2 428 +---------+ | +---------+ | +---------+ 429 | +-----+ | | | | | | +-----+ | 430 M1-----| BD1 | | | | | +---> | | BD1 |-----M2 431 | +-----+ | | | | | | +-----+ | 432 +---------+ | | | | +---------+ 433 | | | GW2 | | | 434 | <---+-- +---------+ (RT2)M3/IP3 | 435 | (RT2)M3/IP3 | +-----+ | {1:3:0} | 436 | {1:3:0} | | BD1 | | | | 437 | | +-----+ | ---+ | 438 | +----|----+ | 439 | | | | | 440 +---------------------+ | +-------------------+ 441 + 442 M3 444 Figure 3: EVPN Interconnect local AC 446 As an alternative solution to configuring the same Layer2-Domain-ID 447 for local routes on both Layer2-Domain Gateways, GW2 can be 448 configured with Layer2-Domain-ID 1:3 for local routes, and GW1 can 449 use a different Layer2-Domain-ID, e.g., 1:4. In this case, GW2 450 advertises the route for M3/IP3 into each Layer2-Domain as before, 451 but now GW1 will not flag the route as "looped" since 1:3 is not on 452 the list of GW1's local Layer2-Domain-IDs. GW1 receives the routes 453 from both Layer2-Domains, and GW1 selects the route from e.g., 454 Layer2-Domain-1. GW1 then installs the route in its BT and re- 455 advertises the route into Layer2-Domain-2 with D-PATH {1:1:EVPN, 456 1:3:0}. When PE2 receives two routes for M3/IP3, one from GW2 with 457 D-PATH {1:3:0} and another from GW1 with D-PATH {1:1:EVPN, 1:3:0}, 458 PE2 will use best path selection and choose to send its traffic to 459 GW2. Also GW2 will receive the route for M3/IP3 from GW1 and mark it 460 as "looped" since that route conveys its own Layer2-Domain-IDs 1:1 461 and 1:3. 463 In a nutshell, the use of D-PATH in MAC/IP Advertisement routes helps 464 prevent loops and influences the best path selection so that PEs 465 choose the shortest paths to the destination PEs. 467 6. Security Considerations 469 To be added. 471 7. IANA Considerations 473 None. 475 8. Acknowledgments 477 9. Contributors 479 10. References 481 10.1. Normative References 483 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 484 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 485 DOI 10.17487/RFC4271, January 2006, 486 . 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, 490 DOI 10.17487/RFC2119, March 1997, 491 . 493 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 494 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 495 May 2017, . 497 [I-D.ietf-bess-evpn-ipvpn-interworking] 498 Rabadan, J., Sajassi, A., Rosen, E., Drake, J., Lin, W., 499 Uttaro, J., and A. Simpson, "EVPN Interworking with 500 IPVPN", draft-ietf-bess-evpn-ipvpn-interworking-06 (work 501 in progress), September 2021. 503 [I-D.ietf-bess-rfc7432bis] 504 Sajassi, A., Burdet, L. A., Drake, J., and J. Rabadan, 505 "BGP MPLS-Based Ethernet VPN", draft-ietf-bess- 506 rfc7432bis-01 (work in progress), July 2021. 508 [RFC9014] Rabadan, J., Ed., Sathappan, S., Henderickx, W., Sajassi, 509 A., and J. Drake, "Interconnect Solution for Ethernet VPN 510 (EVPN) Overlay Networks", RFC 9014, DOI 10.17487/RFC9014, 511 May 2021, . 513 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 514 Rabadan, "Virtual Private Wire Service Support in Ethernet 515 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 516 . 518 10.2. Informative References 520 [RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 521 Rabadan, "Integrated Routing and Bridging in Ethernet VPN 522 (EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021, 523 . 525 Authors' Addresses 527 J. Rabadan (editor) 528 Nokia 529 777 Middlefield Road 530 Mountain View, CA 94043 531 USA 533 Email: jorge.rabadan@nokia.com 535 S. Sathappan 536 Nokia 537 701 Middlefield Road 538 Mountain View, CA 94043 539 USA 541 Email: senthil.sathappan@nokia.com