idnits 2.17.00 (12 Aug 2021) /tmp/idnits20866/draft-sr-bess-evpn-dpath-01.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 document date (7 March 2022) is 68 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 (-04) exists of draft-ietf-bess-rfc7432bis-03 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 M. Gautam 5 Expires: 8 September 2022 Nokia 6 P. Brissette 7 Cisco Systems 8 W. Lin 9 Juniper 10 7 March 2022 12 Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks 13 draft-sr-bess-evpn-dpath-01 15 Abstract 17 The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet 18 Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. 19 When used along with EVPN IP Prefix routes or IP-VPN routes, it 20 identifies the domain(s) through which the routes have passed and 21 that information can be used by the receiver BGP speakers to detect 22 routing loops or influence the BGP best path selection. This 23 document extends the use of D-PATH so that it can also be used along 24 with other EVPN route types. 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 8 September 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 (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. D-PATH to Prevent Loops for EVPN Routes . . . . . . . . . 3 61 1.2. Add Path Visibility and Influence Best Path Selection for 62 EVPN Routes . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Conventions used in this document . . . . . . . . . . . . . . 5 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Use of Domain Path Attribute (D-PATH) with EVPN routes . . . 6 66 4.1. D-PATH and Best Path Selection for MAC/IP Advertisement 67 routes . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2. D-PATH and Best Path Selection for Ethernet A-D per EVI 69 routes . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.3. D-PATH and Best Path Selection for Inclusive Multicast 71 Ethernet Tag routes . . . . . . . . . . . . . . . . . . . 10 72 4.4. Loop Detection . . . . . . . . . . . . . . . . . . . . . 10 73 4.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 11 74 5. Use-Case Examples . . . . . . . . . . . . . . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 78 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 10.2. Informative References . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 The BGP Domain PATH (D-PATH) attribute 87 [I-D.ietf-bess-evpn-ipvpn-interworking] is defined for Inter-Subnet 88 Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. 89 When used along with EVPN IP Prefix routes or IP-VPN routes, it 90 identifies the domain(s) through which the routes have passed and 91 that information can be used by the receiver BGP speakers to detect 92 routing loops or influence the BGP best path selection. This 93 document extends the use of D-PATH so that it can also be used along 94 with other EVPN route types. 96 The D-PATH attribute can be used to prevent control plane loops for 97 EVPN routes, or to provide full path visibility of all the EVPN 98 Interconnect Gateways through which a route has gone and modify the 99 best path selection based on it. Some use cases in which D-PATH can 100 be used along with (non-IP Prefix) EVPN routes follow, but the use 101 cases are not limited to the ones described in this section. 103 1.1. D-PATH to Prevent Loops for EVPN Routes 105 Figure 1 illustrates an EVPN Interconnect case where EVPN MAC/IP 106 Advertisement routes can be looped indefinitely. The three Gateways 107 (GW1, GW2 and GW3) and PE1 in the diagram are attached to the same 108 EVPN Broadcast Domain (BD1). However, BD1 is extended throughout 109 three different domains that are interconnected by the Gateways, 110 which follow [RFC9014] procedures. Suppose a host with MAC address 111 M1 is learned on GW1 and GW1 advertises an EVPN MAC/IP Advertisement 112 route for M1 into Domain-1 and Domain-2. When the route gets 113 imported by GW2 and GW3 and later exported into Domain-3, GW2 and GW3 114 may redistribute each other's route for M1 back into Domain-1 and 115 Domain-2, respectively, creating a loop. D-PATH can be used by the 116 Gateways when redistributing the route between Domains, to identify 117 the Domains through which the route for M1 has gone. When GW1 118 receives an EVPN MAC/IP Advertisement route for M1 that contains a 119 D-PATH with a domain-id locally assigned, GW1 identifies the route as 120 "looped". 122 +----------------+ GW2 123 | EVPN +-------+ 124 | Domain-1 | +---+ | 125 | | |BD1| |---------------+ 126 | | +---+ | | 127 GW1 | +-------+ | PE1 128 +-------+ | | EVPN +-------+ 129 | +---+ |---------------+ | Domain-3 | +---+ | 130 | |BD1| | | | |BD1| | 131 | +---+ |---------------+ | | +---+ | 132 +---|---+ | GW3 | +---|---+ 133 | | EVPN +-------+ | | 134 M1--+ | Domain-2 | +---+ | | +--M2 135 | | |BD1| |---------------+ 136 | | +---+ | 137 | +-------+ 138 +----------------+ 140 Figure 1: Loops for EVPN routes 142 Similar examples are possible with EVPN VPWS services on the Gateways 143 and PEs, where loop prevention for the redistributed A-D per EVI 144 routes is needed. D-PATH provides the end to end path visibility 145 that is required to prevent the loop. 147 1.2. Add Path Visibility and Influence Best Path Selection for EVPN 148 Routes 150 Figure 2 illustrates another [RFC9014] EVPN Interconnect case where, 151 in addition to using D-PATH to prevent EVPN MAC/IP Advertisement 152 route loops when redistributing routes between domains, the D-PATH 153 attribute can also influence the best path selection for the routes. 154 For example, if all the Gateways in the diagram are attached to the 155 same BD1, an EVPN MAC/IP Advertisement route for MAC address M1 156 advertised by GW1 is advertised into Domain-1 and Domain-4. Two 157 routes for M1 will arrive at GW3 with different Route Distinguishers 158 and BGP Next Hops. If D-PATH is used by all the Gateways, the two 159 routes arriving at GW3 will have a different sequence of domain-ids 160 in the D-PATH attribute. GW3 can use the length of the D-PATH as a 161 way of influencing the selection (i.e., the shortest D-PATH route is 162 selected). D-PATH improves the path visibility of the route since it 163 provides information about all the Domains through which the route 164 has passed. 166 +----------+ GW11 +----------+ GW2 +----------+ 167 | EVPN +-------+ EVPN +-------+ EVPN | 168 | Domain-1 | +---+ | Domain-2 | +---+ | Domain-3 | 169 | | |BD1| | | |BD1| | | 170 | | +---+ | | +---+ | | 171 GW1 | +-------+ +-------+ | GW3 172 +-------+ | | | | +-------+ 173 | +---+ |---------+ +----------+ +---------| +---+ | 174 | |BD1| | | |BD1| | 175 | +---+ |---------+ +----------------------------| +---+ | 176 +---|---+ | GW12 | +---|---+ 177 | | EVPN +-------+ EVPN | | 178 M1--+ | Domain-4 | +---+ | Domain-5 | +--M2 179 | | |BD1| | | 180 | | +---+ | | 181 | +-------+ | 182 +----------+ +-----------------------------+ 184 Figure 2: Influence Best Path Selection for EVPN routes 186 2. Conventions used in this document 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in BCP 191 14 [RFC2119] [RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 3. Terminology 196 This section summarizes the terminology that is used throughout the 197 rest of the document. 199 * AC: Attachment Circuit or logical interface associated to a given 200 BT. To determine the AC on which a packet arrived, the PE 201 examines the combination of a physical port and VLAN tags (where 202 the VLAN tags can be individual c-tags, s-tags or ranges of both). 204 * BD and BT: a Broadcast Domain and Bridge Table, as defined in 205 [I-D.ietf-bess-rfc7432bis]. A BD is a group of PEs attached to 206 the same EVPN layer-2 multipoint service. A BT is the 207 instantiation of a Broadcast Domain in a PE. When there is a 208 single Broadcast Domain in a given EVI, the MAC-VRF in each PE 209 contains a single BT. When there are multiple BTs within the same 210 MAC-VRF, each BT is associated to a different Ethernet Tag. The 211 EVPN routes specific to a BT indicate which Ethernet Tag the route 212 corresponds to. 214 * ES and ESI: Ethernet Segment and Ethernet Segment Identifier, as 215 defined in [I-D.ietf-bess-rfc7432bis]. 217 * EVPN Domain: two PEs are in the same EVPN Domain if they are 218 attached to the same service and the packets between them do not 219 require a data path lookup of the inner frame (e.g., in the BT of 220 a MAC-VRF) in any intermediate router. An EVPN Domain Gateway PE 221 is always configured with multiple Domain identifiers (EVPN 222 Domain-ID) in the MAC-VRF or VPWS that connects those EVPN 223 Domains, each EVPN Domain-ID representing an EVPN Domain. 225 Example: Figure 3 illustrates an example where PE1 and PE2 belong 226 to different EVPN Domains since packets between them (for flows 227 between hosts with MAC addresses M1 and M2) require a MAC lookup 228 in two of the gateways that are connecting the three EVPN Domains. 229 E.g., if frames from M1 to M2 go through PE1, GW1, GW3 and PE2, a 230 MAC lookup is performed at GW1 and GW3. 232 GW1------------GW3 233 +------+ +------+ 234 +-------------| BD1 | | BD1 |-------------+ 235 PE1 +------+ +------+ PE2 236 +------+ | | +------+ 237 M1-| BD1 | EVPN | EVPN | EVPN | BD1 |-M2 238 +------+ GW2 GW4 +---+--+ 239 | +------+ +------+ | 240 +-------------| BD1 | | BD1 |-------------+ 241 +------+ +------+ 242 +--------------+ 243 EVPN Domain 1 EVPN Domain 2 EVPN Domain 3 244 <---------------> <------------> <----------------> 246 Figure 3: EVPN Domain Interconnect Example 248 * EVPN Domain Gateway: a PE where a service (BD or VPWS instance) is 249 instantiated and is attached to two or more EVPN Domains. An 250 example of EVPN Domain Gateway is a PE following the procedures in 251 section 4.4 or section 4.6 of [RFC9014]. In the example in 252 Figure 3, GW1 and GW2 connect EVPN Domains 1 and 2, whereas GW3 253 and GW4 connect EVPN Domains 2 and 3. GW1 and GW2 import the MAC/ 254 IP Advertisement route for M1 coming from the EVPN Domain 1 into 255 the MAC-VRF for BD1, and redistribute it into EVPN Domain 2. 256 Likewise, GW3 and GW4 import the route into their MAC-VRF and re- 257 advertise it into EVPN Domain 3. 259 * MAC-VRF: a MAC Virtual Routing and Forwarding table, as defined in 260 [I-D.ietf-bess-rfc7432bis]. It is also the instantiation of an 261 EVI (EVPN Instance) in a PE. 263 4. Use of Domain Path Attribute (D-PATH) with EVPN routes 265 This document extends the use of the D-PATH attribute specified in 266 [I-D.ietf-bess-evpn-ipvpn-interworking] so that D-PATH can be 267 advertised and processed along with the following EVPN route types: 269 * EVPN MAC/IP Advertisement routes that are not used for Inter- 270 Subnet Forwarding (ISF). Note that if the EVPN MAC/IP 271 Advertisement route is used for Inter-Subnet Forwarding as in 272 [RFC9135], the procedures for the D-PATH advertisement and 273 processing are described in 274 [I-D.ietf-bess-evpn-ipvpn-interworking]. 276 * EVPN A-D per EVI routes that are used for EVPN VPWS [RFC8214]. 277 Advertised A-D per EVI routes not used for EVPN VPWS SHOULD NOT 278 contain D-PATH. 280 * EVPN Inclusive Multicast Ethernet Tag routes 281 [I-D.ietf-bess-rfc7432bis]. 283 As discussed, the use of D-PATH with EVPN IP Prefix routes is 284 specified in [I-D.ietf-bess-evpn-ipvpn-interworking]. When used 285 along with EVPN routes other than IP Prefix routes, the D-PATH 286 attribute is characterized as follows: 288 1. D-PATH is composed of a sequence of Domain segments following the 289 format specified in [I-D.ietf-bess-evpn-ipvpn-interworking] where 290 each Domain is represented as . In this 291 specification, DOMAIN-ID is an EVPN Domain identifier configured 292 in an EVPN Domain Gateway and ISF_SAFI_TYPE is set to either 70 293 (EVPN) or 0 (local route). To simplify the explanation, this 294 document represents the domains for EVPN routes as . 297 2. D-PATH identifies the sequence of EVPN Domains the route has gone 298 through, with the last entry (rightmost) 299 identifying the first PE or EVPN Domain Gateway that added the 300 D-PATH attribute. 302 3. For non-ISF MAC/IP Advertisement routes or A-D per EVI routes, 303 D-PATH SHOULD be added/modified by a EVPN Domain Gateway that 304 redistributes the route between EVPN Domains and MAY be added by 305 a PE or EVPN Domain Gateway that originates the route, as 306 follows: 308 a. An EVPN Domain Gateway that connects two EVPN Domains "X" and 309 "Y", and receives a route on a EVPN Domain identified by a 310 Domain-ID "X" SHOULD append a domain to the existing 311 (or newly added) D-PATH attribute when redistributing the 312 route to EVPN Domain "Y". The route is redistributed if it 313 is first imported in a MAC-VRF (or VPWS instance), the MAC 314 (or Ethernet Tag) is active, and policy allows the re-export 315 of the route to a BGP neighbor. 317 b. An EVPN Domain Gateway MAY also add the D-PATH attribute for 318 locally learned MACs or MAC/IP pairs. In this case, the 319 domain added would be , where "A" is the Domain-ID 320 configured on the Gateway's MAC-VRF that is specific to local 321 routes (MAC/IP learned via local AC), and "0" is the TYPE of 322 the EVPN Domain and indicates that the route is locally 323 originated and not redistributed after receiving it from a 324 BGP-EVPN neighbor. The EVPN Domain-ID for local routes MAY 325 be shared by all the EVPN Domain Gateways of the same 326 redundancy group for local routes, or each EVPN Domain 327 Gateway of the redundancy group can use its own Domain-ID. 329 c. A PE that is connected to a single EVPN Domain (therefore the 330 PE is not an EVPN Domain Gateway) MAY add the D-PATH with a 331 domain , where "B" is the Domain-ID configured on the 332 PE's MAC-VRF (or VPWS) for locally learned MAC/IPs (or 333 Ethernet Tag IDs for VPWS). "0" is the TYPE that indicates 334 the route is not re-advertised, but originated in the PE. 336 4. For EVPN Inclusive Multicast Ethernet Tag routes, an EVPN Domain 337 Gateway must not redistribute routes between Domains as specified 338 in [RFC9014]. An EVPN Domain Gateway originates an EVPN 339 Inclusive Multicast Ethernet Tag route per Domain to which the 340 Gateway is attached, so that BUM traffic can be attracted from 341 one Domain to the rest. Therefore, only the above point 3.b. 342 applies to EVPN Domain Gateways. That is, an EVPN Domain Gateway 343 MAY add a D-PATH attribute for the Inclusive Multicast 344 Ethernet Tag routes generated for the EVPN Domains, where "A" is 345 the configured local Domain-ID, and "0" is the TYPE that 346 indicates the route is locally originated and not redistributed 347 across EVPN Domains. When two EVPN Domain Gateways of the same 348 redundancy group connect two EVPN Domains "X" and "Y" and D-PATH 349 is used for EVPN Inclusive Multicast Ethernet Tag routes, it is 350 RECOMMENDED to add the D-PATH attribute with the same local 351 Domain-ID and only on "X" or "Y" but not on both Domains. 353 5. On received EVPN routes, D-PATH is processed and used for loop 354 detection (Section 4.4) as well as to influence the best path 355 selection (Section 4.1, Section 4.2 and Section 4.3). 357 4.1. D-PATH and Best Path Selection for MAC/IP Advertisement routes 359 When two (or more) MAC/IP Advertisement routes with the same route 360 key (and same or different RDs) are received, a best path selection 361 algorithm is used to select and install only one route. This section 362 summarizes the best path selection for MAC/IP Advertisement routes, 363 which extends the rules in [I-D.ietf-bess-rfc7432bis] by including 364 D-PATH in the tie-breaking algorithm. While the algorithm may be 365 implemented in different ways, the selection result SHOULD be the 366 same as the result of the rules that follow. 368 The tie-breaking algorithm begins by considering all EVPN MAC/IP 369 Advertisement routes equally preferable routes to the same 370 destination, and then selects routes to be removed from 371 consideration. The process terminates as soon as only one route 372 remains in consideration. 374 1. When the Default Gateway extended community is present in some of 375 the routes, the MAC/IP Advertisement routes without the Default 376 Gateway indication are removed from consideration, as defined in 377 [I-D.ietf-bess-rfc7432bis]. 379 2. Then the routes with the Static bit set in the MAC Mobility 380 extended community are preferred, and the routes without the 381 Static bit set are removed from consideration, as defined in 382 [I-D.ietf-bess-rfc7432bis]. Note that this rule does not apply 383 to routes with the Default Gateway extended community, since 384 these routes SHALL NOT convey the MAC Mobility extended community 385 [I-D.ietf-bess-rfc7432bis]. Therefore if two or more routes with 386 the Default Gateway extended community remain in consideration, 387 the selection process skips this step. 389 3. Then the routes with the highest MAC Mobility Sequence number are 390 preferred, hence the routes that are not tied for having the 391 highest Sequence number are removed from consideration, as 392 defined in [I-D.ietf-bess-rfc7432bis]. If two or more routes 393 with the Default Gateway extended community remain in 394 consideration, the selection process skips this step (for the 395 same reason as in step 2). 397 4. Then routes with the highest Local Preference are preferred, 398 hence routes that are not tied for having the highest Local 399 Preference are removed from consideration, as defined in 400 [RFC4271]. 402 5. Then routes with the shortest D-PATH are preferred, hence routes 403 not tied for the shortest D-PATH are removed. Routes without 404 D-PATH are considered zero-length D-PATH. 406 6. Then routes with the numerically lowest left-most Domain-ID are 407 preferred, hence routes not tied for the numerically lowest left- 408 most Domain-ID are removed from consideration. 410 7. If the steps above do not produce a single route, the rest of the 411 rules after the highest Local Preference in [RFC4271] apply after 412 step 6. 414 The above selection criteria is followed irrespective of the ESI 415 value in the routes. EVPN Multi-Homing procedures for Aliasing or 416 Backup paths in [I-D.ietf-bess-rfc7432bis] are applied to the 417 selected MAC/IP Advertisement route. 419 4.2. D-PATH and Best Path Selection for Ethernet A-D per EVI routes 421 When two (or more) EVPN A-D per EVI routes with the same route key 422 (and same or different RDs) are received for a VPWS, a best path 423 selection algorithm is used. The selection algorithm follows the 424 same steps as in Section 4.1 except for steps 1-3 which do not apply 425 since the Default Gateway and MAC Mobility extended community are 426 irrelevant to the EVPN A-D per EVI routes. 428 The above selection is followed for A-D per EVI routes with ESI=0. 429 For non-zero ESI routes, the EVPN Multi-Homing procedures in 430 [RFC8214] for Aliasing and Backup path are followed to select the 431 routes (P and B flags are considered for the selection of the routes 432 when sending traffic to a remote Ethernet Segment). If the mentioned 433 Multi-Homing procedures do not produce a single route to each of the 434 remote PEs attached to the same ES, steps 4-7 in Section 4.1 are 435 followed. 437 4.3. D-PATH and Best Path Selection for Inclusive Multicast Ethernet 438 Tag routes 440 When two (or more) EVPN Inclusive Multicast Ethernet Tag routes with 441 the same route key (and same or different RDs) are received for a 442 MAC-VRF, a best path selection algorithm is used. The selection 443 algorithm follows the same steps as in Section 4.1 except for steps 444 1-3 which do not apply. 446 4.4. Loop Detection 448 An EVPN route received by a PE with a D-PATH attribute that contains 449 one or more of its locally associated Domain-IDs for the MAC-VRF or 450 VPWS instance is considered to be a looped route. A looped route 451 MUST NOT be redistributed to a different domain and SHOULD be flagged 452 as "looped". 454 EVPN A-D per EVI looped routes and Inclusive Multicast Ethernet Tag 455 looped routes MUST NOT be installed, where "install" means "create 456 forwarding state" in this document. An EVPN MAC/IP Advertisement 457 looped route MAY be installed if selected as the best route. 459 For instance, in the example of Figure 3, assuming PE1 advertises 460 M1's MAC/IP and does not add the D-PATH attribute, the EVPN Domain 461 Gateway GW1 receives two MAC/IP Advertisement routes for M1's MAC/IP: 463 * A MAC/IP Advertisement route with next-hop PE1 and no D-PATH. 465 * A MAC/IP Advertisement route with next-hop GW2 and 466 D-PATH={length=1,<6500:1:EVPN>}, assuming that the Domain-ID for 467 EVPN Domain 1 is 6500:1. 469 In this case, EVPN Domain Gateway GW1 flags the MAC/IP Advertisement 470 route with D-PATH as "looped", and does not install the MAC in the BT 471 of the MAC-VRF and does not redistribute the route back to EVPN 472 Domain 1 (since the route includes one of GW1's Domain-IDs). In case 473 the MAC/IP Advertisement route with next-hop PE1 is withdrawn, GW1 474 may install the route with next-hop GW2 and D-PATH <6500:1:EVPN>; 475 this may help speed up convergence in case of failures. 477 4.5. Error Handling 479 The error handling for the D-PATH attribute is described in 480 [I-D.ietf-bess-evpn-ipvpn-interworking]. This document extends the 481 use of D-PATH to non-ISF EVPN routes. 483 5. Use-Case Examples 485 This section illustrates the use of D-PATH in EVPN routes with 486 examples. 488 Figure 4 and Figure 5 illustrate an integrated interconnect solution 489 for an EVPN BD, as described in section 4.4 and section 4.6 of 490 [RFC9014]. GW1 and GW2 are EVPN Domain Gateways connecting two EVPN 491 Domains identified by D-PATH domain {1:1:EVPN} and {1:2:EVPN}, 492 respectively. Received Ethernet A-D routes, ES routes, and Inclusive 493 Multicast routes from the routers in one EVPN Domain are consumed and 494 processed by GW1 and GW2, but not redistributed to the other EVPN 495 Domain. However, MAC/IP Advertisement routes received by GW1 and GW2 496 in one EVPN Domain are processed and, if installed, redistributed 497 into the other EVPN Domain. 499 +----EVPN Domain-1---+ +----EVPN Domain-2--+ 500 | 1:1:EVPN | GW1 | 1:2:EVPN | 501 | +---------+ | 502 | | +-----+ | | 503 | | | BD1 | X <-+ | 504 PE1 | +-----+ | | PE2 505 +---------+ +---------+ | +---------+ 506 | +-----+ | | | | | +-----+ | 507 M1-----| BD1 | | | | | | | BD1 |-----M2 508 | +-----+ | -------> | | | | +-----+ | 509 +---------+ (RT2)M1/IP1 | | | +---------+ 510 | +---------+ | | 511 | | +-----+ | |(RT2)M1/IP1 | 512 | | | BD1 | | --+ <1:1:EVPN> | 513 | | +-----+ | | 514 | +---------+ | 515 | | GW2 | | 516 +---------------------+ +-------------------+ 518 Figure 4: EVPN Interconnect 520 Consider the example of Figure 4, where PE1 advertises a MAC/IP 521 Advertisement route for M1/IP1. The route is processed and installed 522 by GW1 and GW2 in BD1, and both redistribute the routes into the EVPN 523 Domain-2. By using D-PATH in GW1 and GW2, when the route is received 524 on PE2, PE2 has the visibility of the EVPN Domains through which the 525 route has gone, and can also use the D-PATH for best path selection. 526 In addition, GW1 and GW2 can compare the D-PATH of the incoming 527 routes with their local list of EVPN Domain-IDs, and detect looped 528 routes if any of the local EVPN Domain-IDs matches a domain in the 529 received D-PATH. This procedure prevents the redistribution of the 530 route back into EVPN Domain-1. For example, when GW1 receives the 531 MAC/IP Advertisement route for M1/IP1 with D-PATH <1:1:EVPN>, GW1 532 identifies the route as looped and it does not redistribute it back 533 to Domain-1. The M1/IP1 route with Next Hop PE1 is installed. If 534 M1/IP1 with Next Hop PE1 is withdrawn, GW1 MAY install the route M1/ 535 IP1 with Next Hop GW2, as specified in Section 4.4. 537 The example of Figure 5 illustrates how GW1 and GW2 can also have 538 local ACs in BD1 and learn local MAC (or MAC/IP) addresses from 539 devices connected to the ACs. 541 +----EVPN Domain-1---+ +----EVPN Domain-2--+ 542 | 1:1:EVPN | GW1 | 1:2:EVPN | 543 | +---------+ | 544 | | +-----+ | | 545 | +-->X| | BD1 | |X<--+ | 546 PE1 | | +-----+ | | PE2 547 +---------+ | +---------+ | +---------+ 548 | +-----+ | | | | | | +-----+ | 549 M1-----| BD1 | | | | | +---> | | BD1 |-----M2 550 | +-----+ | | | | | | +-----+ | 551 +---------+ | | | | +---------+ 552 | | | GW2 | | | 553 | <---+-- +---------+ (RT2)M3/IP3 | 554 | (RT2)M3/IP3 | +-----+ | {1:3:0} | 555 | {1:3:0} | | BD1 | | | | 556 | | +-----+ | ---+ | 557 | +----|----+ | 558 | | | | | 559 +---------------------+ | +-------------------+ 560 + 561 M3 563 Figure 5: EVPN Interconnect local AC 565 Assuming GW2 learns M3/IP3 via local AC, GW2 advertises a MAC/IP 566 Advertisement route for M3/IP3 into each of the EVPN Domains that GW2 567 is connected to. As described in Section 4, GW2 can advertise these 568 two MAC/IP Advertisement routes with a configured EVPN Domain-ID for 569 local MAC/IPs routes that can be shared with GW1. Consider this EVPN 570 Domain-ID is 1:3 and it is configured on both, GW1 and GW2. When GW2 571 advertises the route into each EVPN Domain, it adds the D-PATH 572 attribute with a domain {1:3:0}. These routes are flagged by GW1 as 573 "looped" since 1:3 is configured as a local EVPN Domain-ID in GW1. 574 In addition, PE1 and PE2 receive the routes with the D-PATH and they 575 have the visibility of the origin of the routes, in this case local 576 EVPN Domain Gateway routes. This information can be used to 577 influence the best path selection in case of multiple routes for M3/ 578 IP3 are received on PE1 or PE2 for BD1. 580 As an alternative solution to configuring the same EVPN Domain-ID for 581 local routes on both EVPN Domain Gateways, GW2 can be configured with 582 EVPN Domain-ID 1:3 for local routes, and GW1 can use a different EVPN 583 Domain-ID, e.g., 1:4. In this case, GW2 advertises the route for M3/ 584 IP3 into each EVPN Domain as before, but now GW1 does not flag the 585 route as "looped" since 1:3 is not on the list of GW1's local EVPN 586 Domain-IDs. GW1 receives the routes from both EVPN Domains, and GW1 587 selects the route from e.g., EVPN Domain-1. GW1 then installs the 588 route in its BT and redistributes the route into EVPN Domain-2 with 589 D-PATH {1:1:EVPN, 1:3:0}. When PE2 receives two routes for M3/IP3, 590 one from GW2 with D-PATH {1:3:0} and another from GW1 with D-PATH 591 {1:1:EVPN, 1:3:0}, PE2 uses best path selection and choose to send 592 its traffic to GW2. Also GW2 receives the route for M3/IP3 from GW1 593 and mark it as "looped" since that route conveys its own EVPN Domain- 594 IDs 1:1 and 1:3. 596 In a nutshell, the use of D-PATH in MAC/IP Advertisement routes helps 597 prevent loops and influences the best path selection so that PEs 598 choose the shortest paths to the destination PEs. 600 6. Security Considerations 602 Most of the considerations included in 603 [I-D.ietf-bess-evpn-ipvpn-interworking] apply to this document. 605 7. IANA Considerations 607 None. 609 8. Acknowledgments 611 9. Contributors 613 10. References 615 10.1. Normative References 617 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 618 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 619 DOI 10.17487/RFC4271, January 2006, 620 . 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, 624 DOI 10.17487/RFC2119, March 1997, 625 . 627 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 628 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 629 May 2017, . 631 [I-D.ietf-bess-evpn-ipvpn-interworking] 632 Rabadan, J., Sajassi, A., Rosen, E., Drake, J., Lin, W., 633 Uttaro, J., and A. Simpson, "EVPN Interworking with 634 IPVPN", Work in Progress, Internet-Draft, draft-ietf-bess- 635 evpn-ipvpn-interworking-06, 22 September 2021, 636 . 639 [I-D.ietf-bess-rfc7432bis] 640 Sajassi, A., Burdet, L. A., Drake, J., and J. Rabadan, 641 "BGP MPLS-Based Ethernet VPN", Work in Progress, Internet- 642 Draft, draft-ietf-bess-rfc7432bis-03, 28 February 2022, 643 . 646 [RFC9014] Rabadan, J., Ed., Sathappan, S., Henderickx, W., Sajassi, 647 A., and J. Drake, "Interconnect Solution for Ethernet VPN 648 (EVPN) Overlay Networks", RFC 9014, DOI 10.17487/RFC9014, 649 May 2021, . 651 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 652 Rabadan, "Virtual Private Wire Service Support in Ethernet 653 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 654 . 656 10.2. Informative References 658 [RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 659 Rabadan, "Integrated Routing and Bridging in Ethernet VPN 660 (EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021, 661 . 663 Authors' Addresses 665 J. Rabadan (editor) 666 Nokia 667 520 Almanor Avenue 668 Sunnyvale, CA 94085 669 United States of America 670 Email: jorge.rabadan@nokia.com 672 S. Sathappan 673 Nokia 674 520 Almanor Avenue 675 Sunnyvale, CA 94085 676 United States of America 677 Email: senthil.sathappan@nokia.com 678 M. Gautam 679 Nokia 680 520 Almanor Avenue 681 Sunnyvale, CA 94085 682 United States of America 683 Email: mallika.gautam@nokia.com 685 P. Brissette 686 Cisco Systems 687 Canada 688 Email: pbrisset@cisco.com 690 W. Lin 691 Juniper 692 United States of America 693 Email: wlin@juniper.net