idnits 2.17.1 draft-ietf-bess-evpn-ipvpn-interworking-05.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 (June 22, 2021) is 1031 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 (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-13 Summary: 0 errors (**), 0 flaws (~~), 2 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 Nokia 4 Intended status: Standards Track A. Sajassi, Ed. 5 Expires: December 24, 2021 Cisco 6 E. Rosen 7 Individual 8 J. Drake 9 W. Lin 10 Juniper 11 J. Uttaro 12 AT&T 13 A. Simpson 14 Nokia 15 June 22, 2021 17 EVPN Interworking with IPVPN 18 draft-ietf-bess-evpn-ipvpn-interworking-05 20 Abstract 22 EVPN is used as a unified control plane for tenant network intra and 23 inter-subnet forwarding. When a tenant network spans not only EVPN 24 domains but also domains where BGP VPN-IP or IP families provide 25 inter-subnet forwarding, there is a need to specify the interworking 26 aspects between BGP domains of type EVPN, VPN-IP and IP, so that the 27 end to end tenant connectivity can be accomplished. This document 28 specifies how EVPN interworks with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 29 BGP families for inter-subnet forwarding. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 24, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction and Problem Statement . . . . . . . . . . . . . 2 66 2. Conventions used in this document . . . . . . . . . . . . . . 3 67 3. Terminology and Interworking PE Components . . . . . . . . . 3 68 4. Domain Path Attribute (D-PATH) . . . . . . . . . . . . . . . 9 69 5. BGP Path Attribute Propagation across ISF SAFIs . . . . . . . 14 70 5.1. No-Propagation-Mode . . . . . . . . . . . . . . . . . . . 14 71 5.2. Uniform-Propagation-Mode . . . . . . . . . . . . . . . . 14 72 5.3. Aggregation of Routes and Path Attribute Propagation . . 16 73 6. Route Selection Process between EVPN and other ISF SAFIs . . 16 74 7. Composite PE Procedures . . . . . . . . . . . . . . . . . . . 18 75 8. Gateway PE Procedures . . . . . . . . . . . . . . . . . . . . 20 76 9. Interworking Use-Cases . . . . . . . . . . . . . . . . . . . 22 77 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 79 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 80 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 81 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 82 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 15.1. Normative References . . . . . . . . . . . . . . . . . . 25 84 15.2. Informative References . . . . . . . . . . . . . . . . . 26 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 87 1. Introduction and Problem Statement 89 EVPN is used as a unified control plane for tenant network intra and 90 inter-subnet forwarding. When a tenant network spans not only EVPN 91 domains but also domains where BGP VPN-IP or IP families provide 92 inter-subnet forwarding, there is a need to specify the interworking 93 aspects between the different families, so that the end to end tenant 94 connectivity can be accomplished. This document specifies how EVPN 95 should interwork with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families 96 for inter-subnet forwarding. 98 EVPN supports the advertisement of IPv4 or IPv6 prefixes in two 99 different route types: 101 o Route Type 2 - MAC/IP route (only for /32 and /128 host routes), 102 as described by [I-D.ietf-bess-evpn-inter-subnet-forwarding]. 104 o Route Type 5 - IP Prefix route, as described by 105 [I-D.ietf-bess-evpn-prefix-advertisement]. 107 When interworking with other BGP address families (AFIs/SAFIs) for 108 inter-subnet forwarding, the IP prefixes in those two EVPN route 109 types must be propagated to other domains using different SAFIs. 110 Some aspects of that propagation must be clarified. Examples of 111 these aspects or procedures across BGP families are: route selection, 112 loop prevention or BGP Path attribute propagation. The Interworking 113 PE concepts are defined in section 2, and the rest of the document 114 describes the interaction between Interworking PEs and other PEs for 115 end-to-end inter-subnet forwarding. 117 2. Conventions used in this document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 3. Terminology and Interworking PE Components 127 This section summarizes the terminology related to the "Interworking 128 PE" concept that will be used throughout the rest of the document. 130 +-------------------------------------------------------------+ 131 | | 132 | +------------------+ Interworking PE | 133 | Attachment | +------------------+ | 134 | Circuit(AC1) | | +----------+ | MPLS/NVO tnl 135 ----------------------*Bridge | | +------ 136 | | | |Table(BT1)| | +-----------+ / \ \ 137 MPLS/NVO tnl +-------->| *---------* |<--> | Eth | 138 -------+ | | | |Eth-Tag x + |IRB1| | \ / / 139 / Eth / \<-+ | | +----------+ | | | +------ 140 | | | | | ... | | IP-VRF1 | | 141 \ \ /<-+ | | +----------+ | | RD2/RT2 |MPLS/NVO tnl 142 -------+ | | | |Bridge | | | | +------ 143 | +-------->|Table(BT2)| |IRB2| | / \ \ 144 | | | | *---------* |<--> | IP | 145 ----------------------*Eth-Tag y | | +-----*-----+ \ / / 146 | AC2 | | +----------+ | AC3| +------ 147 | | | MAC-VRF1 | | | 148 | +-+ RD1/RT1 | | | 149 | +------------------+ | SAFIs | 150 | | 1 +---+ | 151 -------------------------------------------------+ 128 |BGP| | 152 | EVPN +---+ | 153 | | 154 +-------------------------------------------------------------+ 156 Figure 1: EVPN-IPVPN Interworking PE 158 o ISF SAFI: Inter-Subnet Forwarding (ISF) SAFI is a MP-BGP Sub- 159 Address Family that advertises reachability for IP prefixes and 160 can be used for inter-subnet forwarding within a given tenant 161 network. The ISF SAFIs are 1 (including IPv4 and IPv6 AFIs), 128 162 (including IPv4 and IPv6 AFIs) and 70 (EVPN, including only AFI 163 25). This document uses the following terms interchangeably: ISF 164 SAFI 1 or BGP IP, ISF SAFI 128 or IPVPN, ISF SAFI 70 or EVPN. 166 o ISF route: a route for a given prefix whose ISF SAFI may change as 167 it transits different domains. 169 o IP-VRF: an IP Virtual Routing and Forwarding table, as defined in 170 [RFC4364]. It is also the instantiation of an IPVPN in a PE. 171 Route Distinguisher and Route Target(s) are required properties of 172 an IP-VRF. 174 o MAC-VRF: a MAC Virtual Routing and Forwarding table, as defined in 175 [RFC7432]. It is also the instantiation of an EVI (EVPN Instance) 176 in a PE. Route Distinguisher and Route Target(s) are required 177 properties and they are normally different than the ones defined 178 in the associated IP-VRF. 180 o BT: a Bridge Table, as defined in [RFC7432]. A BT is the 181 instantiation of a Broadcast Domain in a PE. When there is a 182 single Broadcast Domain in a given EVI, the MAC-VRF in each PE 183 will contain a single BT. When there are multiple BTs within the 184 same MAC-VRF, each BT is associated to a different Ethernet Tag. 185 The EVPN routes specific to a BT, will indicate which Ethernet Tag 186 the route corresponds to. 188 Example: In Figure 1, MAC-VRF1 has two BTs: BT1 and BT2. Ethernet 189 Tag x is defined in BT1 and Ethernet Tag y in BT2. 191 o AC: Attachment Circuit or logical interface associated to a given 192 BT or IP-VRF. To determine the AC on which a packet arrived, the 193 PE will examine the combination of a physical port and VLAN tags 194 (where the VLAN tags can be individual c-tags, s-tags or ranges of 195 both). 197 Example: In Figure 1, AC1 is associated to BT1, AC2 to BT2 and AC3 198 to IP-VRF1. 200 o IRB: Integrated Routing and Bridging interface. It refers to the 201 logical interface that connects a BT to an IP-VRF and allows to 202 forward packets with destination in a different subnet. 204 o MPLS/NVO tnl: It refers to a tunnel that can be MPLS or NVO-based 205 (Network Virtualization Overlays) and it is used by MAC-VRFs and 206 IP-VRFs. Irrespective of the type, the tunnel may carry an 207 Ethernet or an IP payload. MAC-VRFs can only use tunnels with 208 Ethernet payloads (setup by EVPN), whereas IP-VRFs can use tunnels 209 with Ethernet (setup by EVPN) or IP payloads (setup by EVPN or 210 IPVPN). IPVPN-only PEs have IP-VRFs but they cannot send or 211 receive traffic on tunnels with Ethernet payloads. 213 Example: Figure 1 shows an MPLS/NVO tunnel that is used to 214 transport Ethernet frames to/from MAC-VRF1. The PE determines the 215 MAC-VRF and BT the packets belong to based on the EVPN label (MPLS 216 or VNI). Figure 1 also shows two MPLS/NVO tunnels being used by 217 IP-VRF1, one carrying Ethernet frames and the other one carrying 218 IP packets. 220 o RT-2: Route Type 2 or MAC/IP route, as per [RFC7432]. 222 o RT-5: Route Type 5 or IP Prefix route, as per 223 [I-D.ietf-bess-evpn-prefix-advertisement]. 225 o Domain: Two PEs are in the same domain if they are attached to the 226 same tenant and the packets between them do not require a data 227 path IP lookup (in the tenant space) in any intermediate router. 228 A gateway PE is always configured with multiple DOMAIN-IDs. 230 Example 1: Figure 2 depicts an example where TS1 and TS2 belong to 231 the same tenant, and they are located in different Data Centers 232 that are connected by gateway PEs (see the gateway PE definition 233 later). These gateway PEs use IPVPN in the WAN. When TS1 sends 234 traffic to TS2, the intermediate routers between PE1 and PE2 235 require a tenant IP lookup in their IP-VRFs so that the packets 236 can be forwarded. In this example there are three different 237 domains. The gateway PEs connect the EVPN domains to the IPVPN 238 domain. 240 GW1------------GW3 241 +------+ +------+ 242 +-------------|IP-VRF| |IP-VRF|-------------+ 243 PE1 +------+ +------+ PE2 244 +------+ DC1 | WAN | DC2 +------+ 245 TS1-|IP-VRF| EVPN | IPVPN | EVPN |IP-VRF|-TS2 246 +------+ GW2 GW4 +---+--+ 247 | +------+ +------+ | 248 +-------------|IP-VRF| |IP-VRF|-------------+ 249 +------+ +------+ 250 +--------------+ 251 DOMAIN 1 DOMAIN 2 DOMAIN 3 252 <---------------> <------------> <----------------> 254 Figure 2: Multiple domain DCI example 256 Example 2: Figure 3 illustrates a similar example, but PE1 and PE2 257 are now connected by a BGP-LU (BGP Labeled Unicast) tunnel, and 258 they have a BGP peer relationship for EVPN. Contrary to Example 1, 259 there is no need for tenant IP lookups on the intermediate routers 260 in order to forward packets between PE1 and PE2. Therefore, there 261 is only one domain in the network and PE1/PE2 belong to it. 263 EVPN 264 <-------------------------------------------------> 265 BGP-LU 266 <-------------------------------------------------> 268 ASBR------------ASBR 269 +------+ +------+ 270 +-------------| | | |-------------+ 271 PE1 +------+ +--+---+ PE2 272 +------+ DC1 | WAN | DC2 +------+ 273 TS1-|IP-VRF| EVPN | | EVPN |IP-VRF|-TS2 274 +------+ ASBR ASBR +---+--+ 275 | +------+ +------+ | 276 +-------------| | | |-------------+ 277 +------+ +------+ 278 +--------------+ 280 <--------------------DOMAIN-1---------------------> 282 Figure 3: Single domain DCI example 284 o Regular Domain: a domain in which a single control plane, BGP IP, 285 IPVPN or EVPN, is used and which is composed of regular PEs, see 286 below. In Figure 2 and Figure 3, above, all domains are regular 287 domains. 289 o Composite Domain: a domain in which multiple control planes, BGP 290 IP, IPVPN and EVPN, are used and which is composed of regular PEs, 291 see below, and composite PEs, see below. 293 o Regular PE: a PE that is attached to a domain, either regular or 294 composite, and which uses one of the control plane protocols (BGP 295 IP, IPVPN or EVPN) operating in the domain. 297 o Interworking PE: a PE that may advertise a given prefix with an 298 EVPN ISF route (RT-2 or RT-5) and/or an IPVPN ISF route and/or a 299 BGP IP ISF route. An interworking PE has one IP-VRF per tenant, 300 and zero, one or multiple MAC-VRFs per tenant. Each MAC-VRF may 301 contain one or more BTs, where each BT may be attached to that IP- 302 VRF via IRB. There are two types of Interworking PEs: composite 303 PEs and gateway PEs. Both PE functions can be independently 304 implemented per tenant and they may both be implemented for the 305 same tenant. 307 Example: Figure 1 shows an interworking PE of type gateway, where 308 ISF SAFIs 1, 128 and 70 are enabled. IP-VRF1 and MAC-VRF1 are 309 instantiated on the PE, and together provide inter-subnet 310 forwarding for the tenant. 312 o Composite PE: an interworking PE that is attached to a composite 313 domain and advertises a given prefix to an IPVPN peer with an 314 IPVPN ISF route, to an EVPN peer with an EVPN ISF route, and to a 315 route reflector with both an IPVPN and EVPN ISF route. A 316 composite PE performs the procedures of Sections 5 and 6. 318 Example: Figure 4 shows an example where PE1 is a composite PE 319 since PE1 has EVPN and another ISF SAFI enabled to the same route- 320 reflector, and PE1 advertises a given IP prefix IPn/x twice, one 321 using EVPN and another one using ISF SAFI 128. PE2 and PE3 are 322 not composite PEs. 324 +---+ 325 |PE2| 326 +---+ 327 ^ 328 |EVPN 329 IW EVPN v 330 +---+ IPVPN ++-+ +---+ 331 |PE1| <----> |RR| <---> |PE3| 332 +---+ +--+ IPVPN +---+ 333 Composite 335 Figure 4: Interworking composite PE example 337 o Gateway PE: an interworking PE that is attached to two domains, 338 each either regular or composite, and which, based on 339 configuration, does one of the following: 341 - Propagates the same control plane protocol, BGP IP, IPVPN or 342 EVPN, between the two domains. 344 - Propagates an ISF route with different ISF SAFIs between the 345 two domains. E.g., propagate an EVPN ISF route in one domain 346 as an IPVPN ISF route in the other domain and vice versa. A 347 gateway PE performs the procedures of Sections Section 4, 348 Section 5, Section 6 and Section 8. 350 A gateway PE is always configured with multiple DOMAIN-IDs. The 351 DOMAIN-ID is encoded in the Domain Path Attribute (D-PATH), and 352 advertised along with ISF SAFI routes. Section 4 describes the 353 D-PATH attribute. 355 Example: Figure 5 illustrates an example where PE1 is a gateway PE 356 since the EVPN and IPVPN SAFIs are enabled on different BGP peers, 357 and a given local IP prefix IPn/x is sent to both BGP peers for 358 the same tenant. PE2 and PE1 are in one domain and PE3 and PE1 359 are in another domain. 361 IW 362 +---+ EVPN +---+ IPVPN +---+ 363 |PE2| <----> |PE1| <----> |PE3| 364 +---+ +---+ +---+ 365 Gateway 367 Figure 5: Interworking gateway PE example 369 o Composite/Gateway PE: an interworking PE that is both a composite 370 PE and a gateway PE that is attached to two domains, one regular 371 and one composite, and which does the following: 373 - Propagates an ISF route from the regular domain into the 374 composite domain. Within the composite domain it acts as a 375 composite PE. 377 - Propagates an ISF route from the composite domain into the 378 regular domain. Within the regular domain it is propagated as 379 an ISF route using the ISF SAFI for that domain. 381 This is particularly useful when a tenant network is attached to 382 multiple ISF SAFIs (BGP IP, IPVPN and EVPN domains) and any-to-any 383 connectivity is required, and also end-to-end control plane 384 consistency, when possible, is desired. 386 It would be instantiated by attaching the disparate, regular BGP 387 IP, IPVPN and EVPN domains via these PEs to a central composite 388 domain. 390 4. Domain Path Attribute (D-PATH) 392 The BGP Domain Path (D-PATH) attribute is an optional and transitive 393 BGP path attribute. 395 Similar to AS_PATH, D-PATH is composed of a sequence of Domain 396 segments. Each Domain segment is comprised of , where the domain segment value is a 398 sequence of one or more Domains, as illustrated in Figure 6. Each 399 domain is represented by . 401 Octets 402 0 1 8 n 403 +---------------+----------------//--+----//-------------------+ 404 |Domain Segment | Last Domain | Domain of Origin | 405 | Length | | | 406 +---------------+----------------//--+----//-------------------+ 407 \__________________/ 408 | 409 Octets v 410 0 6 7 411 +------------------//-----+----------------+ 412 | DOMAIN-ID | ISF_SAFI_TYPE | 413 +------------------//-----+----------------+ 414 \________________________/ 415 | 416 Octets v 417 0 1 2 3 4 5 6 418 +-----------------------+-----------+ 419 | Global | Local | 420 | Admin | Admin | 421 +-----------------------+-----------+ 423 Figure 6: D-PATH Domain Segment 425 o The domain segment length field is a 1-octet field, containing the 426 number of domains in the segment. 428 o DOMAIN-ID is a 6-octet field that represents a domain. It is 429 composed of a 4-octet Global Administrator sub-field and a 2-octet 430 Local Administrator sub-field. The Global Administrator sub-field 431 MAY be filled with an Autonomous System Number (ASN), an IPv4 432 address, or any value that guarantees the uniqueness of the 433 DOMAIN-ID when the tenant network is connected to multiple 434 Operators. 436 o ISF_SAFI_TYPE is a 1-octet field that indicates the Inter-Subnet 437 Forwarding SAFI type in which a route was received, before the 438 route is re-exported into a different domain. The following types 439 are valid in this document: 441 Value Type 442 ----- -------------------------- 443 0 Gateway PE local ISF route 444 1 SAFI 1 445 70 EVPN 446 128 SAFI 128 448 About the BGP D-PATH attribute: 450 a. Identifies the sequence of domains, each identified by a through which a given ISF route has passed. 453 - This attribute list MAY contain one or more segments. 455 - The first entry in the list (leftmost) is the from which a gateway PE is propagating an 457 ISF route. The last entry in the list (rightmost) is the 458 from which a gateway PE received an 459 ISF route without a D-PATH attribute (the Domain of Origin). 460 Intermediate entries in the list are domains that the ISF 461 route has transited. 463 - As an example, an ISF route received with a D-PATH attribute 464 containing a domain segment of {length=2, 465 <6500:2:IPVPN>,<6500:1:EVPN>} indicates that the ISF route was 466 originated in EVPN domain 6500:1, and propagated into IPVPN 467 domain 6500:2. 469 b. It is added/modified by a gateway PE when propagating an update 470 to a different domain: 472 - A gateway PE's IP-VRF, that connects two domains, belongs to 473 two DOMAIN-IDs, e.g. 6500:1 for EVPN and 6500:2 for IPVPN. 475 - Whenever a prefix arrives at a gateway PE in a particular ISF 476 SAFI route, if the gateway PE needs to export that prefix to a 477 BGP peer, the gateway PE MUST prepend a to the list of domains in the received 479 D-PATH, as long as the gateway PE works in Uniform- 480 Propagation-Mode, as explain in Section 5.2 . 482 - For instance, in an IP-VRF configured with DOMAIN-IDs 6500:1 483 for EVPN and 6500:2 for IPVPN, if an EVPN route for prefix P 484 is received and P installed in the IP-VRF, the IPVPN route for 485 P that is exported to an IPVPN peer will prepend the domain 486 <6500:1:EVPN> to the previously received D-PATH attribute. 487 Likewise, IP-VRF prefixes that are received from IP-VPN, will 488 be exported to EVPN peers with the domain <6500:2:IPVPN> added 489 to the segment. 491 - In the above example, if the EVPN route is received without 492 D-PATH, the gateway PE will add the D-PATH attribute with one 493 segment {length=1, <6500:1:EVPN>} when re-advertising to 494 domain 6500:2. 496 - Within the Domain of Origin, the update does not contain a 497 D-PATH attribute because the update has not passed through a 498 gateway PE yet. 500 c. For a local ISF route, i.e., a configured route or a route 501 learned from a local attachment circuit, a gateway PE has three 502 choices: 504 1. It MAY advertise that ISF route without a D-PATH attribute 505 into one or more of its configured domains, in which case the 506 D-PATH attribute will be added by the other gateway PEs in 507 each of those domains. 509 2. It MAY advertise that ISF route with a D-PATH attribute into 510 one or more of its configured domains, in which case the 511 D-PATH attribute in each copy of the ISF route is initialized 512 with an ISF_SAFI_TYPE of 0 and the DOMAIN-ID of the domain 513 with which the ISF route is associated. 515 3. It MAY advertise that ISF route with a D-PATH attribute that 516 contains a configured domain specific to its local ISF routes 517 into one or more of its configured domains, in which case the 518 D-PATH attribute in each copy of the ISF route is initialized 519 with a ISF_SAFI_TYPE of 0 and the DOMAIN-ID for the local ISF 520 routes. This DOMAIN-ID MUST be globally unique and MAY be 521 shared by two or more gateway PEs. 523 d. An ISF route received by a gateway PE with a D-PATH attribute 524 that contains one or more of its locally associated domains for 525 the IP-VRF is considered to be a looped ISF route and MUST NOT be 526 installed in that IP-VRF. The ISF route in this case MUST be 527 flagged as "looped". 529 For instance, in the example of Figure 2, gateway GW1 receives 530 TS1 prefix in two different ISF routes: 532 - In an EVPN RT-5 with next-hop PE1 and no D-PATH attribute. 534 - In a SAFI 128 route with next-hop GW2 and D-PATH = {length=1, 535 <6500:1:EVPN>}, assuming that DOMAIN-ID for domain 1 is 536 6500:1. 538 Gateway GW1 flags the SAFI 128 route as "looped" and it will not 539 install it in the tenant IP-VRF, since the route includes one of 540 the GW1's local domains. 542 e. A DOMAIN-ID value on a GW-PE (gateway PE) MAY be globally 543 assigned for a peering domain or MAY be scoped for an individual 544 tenant IP-VRF. 546 - If globally allocated for a peering domain, the DOMAIN-ID 547 applies to all tenant IP-VRFs for that domain. 549 - If allocated for a specific tenant IP-VRF, the processing of 550 the received D-PATH and its propagation will be in the context 551 of the IP-VRF DOMAIN-ID. Route leaking is a use-case where a 552 per-IP-VRF DOMAIN-ID assignment is necessary. Suppose 553 gateways PE1 and PE2 are attached to two different tenant IP- 554 VRFs, IP-VRF-1 and IP-VRF-2. ISF SAFI routes advertised by 555 gateway PE1 for IP-VRF-1 are received on gateway PE2 with 556 DOMAIN-ID 6500:1. If the routes are leaked from IP-VRF-1 into 557 IP-VRF-2 on PE2, and re-advertised back to PE1 in the context 558 of IP-VRF-2, PE1 will not treat the route as a looped route. 559 This is because PE1 processes the route in the context of IP- 560 VRF-2, where DOMAIN-ID 6500:1 is not a local DOMAIN-ID. 562 f. The number of domains in the D-PATH attribute indicates the 563 number of gateway PEs that the ISF route update has transited. 564 If one of the transit gateway PEs leaks a given ISF route between 565 two local IP-VRFs, it MAY prepend a domain with a ISF_SAFI_TYPE 566 of 0 for the leaked route when the route is exported into an ISF 567 SAFI. In that case, the number of domains in the D-PATH 568 attribute indicates the number of tenant IP-VRFs that the ISF 569 route update has transited. 571 g. The following error-handling rules apply to the D-PATH attribute: 573 1. A received D-PATH attribute is considered malformed if it 574 contains a malformed Domain Segment. 576 2. A Domain Segment is considered malformed in any of the 577 following cases: 579 * The Domain Segment length of the last Domain Segment 580 causes the D-PATH attribute length to be exceeded. 582 * After the last successfully parsed Domain Segment there is 583 only one single octet remaining. 585 * The Domain Segment has a Domain Segment Length of zero. 587 3. A PE receiving an UPDATE message with a malformed D-PATH 588 attribute SHALL apply "treat-as-withdraw" [RFC7606]. 590 4. Domains in the D-PATH attribute with unknown ISF_SAFI_TYPE 591 values are accepted and not considered an error. 593 5. BGP Path Attribute Propagation across ISF SAFIs 595 Based on its configuration, a gateway PE is required to propagate an 596 ISF route with different ISF SAFIs between two domains. This 597 requires a definition of what a gateway PE has to do with Path 598 attributes attached to the ISF route that it is propagating. 600 5.1. No-Propagation-Mode 602 This is the default mode of operation for gateway PEs that re-export 603 ISF routes from any ISF SAFI into EVPN, and from EVPN into any other 604 SAFI. In this mode, the gateway PE will simply re-initialize the 605 Path Attributes when propagating an ISF route, as though it would for 606 direct or local IP prefixes. This model may be enough in those use- 607 cases where the EVPN domain is considered an "abstracted" CE and 608 remote IPVPN/IP PEs don't need to consider the original EVPN 609 Attributes for path calculations. 611 Since this mode of operation does not propagate the D-PATH attribute 612 either, redundant gateway PEs are exposed to routing loops. Those 613 loops may be resolved by policies and the use of other attributes, 614 such as the Route Origin extended community [RFC4360], however not 615 all the loop situations may be solved. 617 5.2. Uniform-Propagation-Mode 619 In this mode, the gateway PE simply keeps accumulating or mapping 620 certain key commonly used Path Attributes when propagating an ISF 621 route. This mode is typically used in networks where EVPN and IPVPN 622 SAFIs are used seamlessly to distribute IP prefixes. 624 The following rules MUST be observed by the gateway PE when 625 propagating Path Attributes: 627 1. The gateway PE imports an ISF route in the IP-VRF and stores the 628 original Path Attributes. The following set of Path Attributes 629 SHOULD be propagated by the gateway PE to other ISF SAFIs (other 630 Path Attributes SHOULD NOT be propagated): 632 - AS_PATH 634 - D-PATH 636 - IBGP-only Path Attributes: LOCAL_PREF, ORIGINATOR_ID, 637 CLUSTER_ID 639 - MED 641 - AIGP 643 - Communities, Extended Communities and Large Communities, 644 except for the EVPN extended communities, Route Target 645 extended communities and BGP Encapsulation extended 646 communities. 648 2. When propagating an ISF route to a different ISF SAFI and IBGP 649 peer, the gateway PE SHOULD keep the AS_PATH of the originating 650 family and add it to the destination family without any 651 modification. When re-advertising to a different ISF SAFI and 652 EBGP peer, the gateway PE SHOULD keep the AS_PATH of the 653 originating family and prepend the IP-VRF's AS before sending the 654 route. 656 3. When propagating an ISF route to IBGP peers, the gateway PE 657 SHOULD keep the IBGP-only Path Attributes from the originating 658 SAFI to the re-advertised route. 660 4. As discussed, Communities, Extended Communities and Large 661 Communities SHOULD be kept by the gateway PE from the originating 662 SAFI route. Exceptions of Extended Communities that SHOULD NOT 663 be kept are: 665 A. BGP Encapsulation extended communities 666 [I-D.ietf-idr-tunnel-encaps]. 668 B. Route Target extended communities. Route Targets are always 669 initialized when readvertising an ISF route into a different 670 domain, i.e., they are not propagated. The initialized Route 671 Target in the re-advertised ISF route may or may not have the 672 same value as the Route Target of the originating ISF route. 674 C. All the extended communities of type EVPN. 676 The gateway PE SHOULD NOT copy the above extended communities 677 from the originating ISF route to the re-advertised ISF route. 679 5. For a given ISF route, only the Path Attributes of the best path 680 can be propagated to another ISF route. If multiple paths are 681 received for the same route in an ISF SAFI, the BGP best path 682 selection will determine what the best path is, and therefore the 683 set of Path Attributes to be propagated. Even if Equal Cost 684 Multi-Path (ECMP) is enabled on the IP-VRF by policy, only the 685 Path Attributes of the selected best path are propagated. 687 5.3. Aggregation of Routes and Path Attribute Propagation 689 Instead of propagating a high number of (host) ISF routes between ISF 690 SAFIs, a gateway PE that receives multiple ISF routes of one ISF SAFI 691 MAY choose to propagate a single ISF aggregate route into a different 692 domain. In this document, aggregation is used to combine the 693 characteristics of multiple ISF routes of the same ISF SAFI in such 694 way that a single aggregate ISF route of a different ISF SAFI can be 695 propagated. Aggregation of multiple ISF routes of one ISF SAFI into 696 an aggregate ISF route is only done by a gateway PE. 698 Aggregation on gateway PEs may use either the No-Propagation-Mode or 699 the Uniform-Propagation-Mode explained in Section 5.1 and 700 Section 5.2, respectively. 702 When using Uniform-Propagation-Mode, Path Attributes of the same type 703 code MAY be aggregated according to the following rules: 705 o AS_PATH is aggregated based on the rules in [RFC4271]. The 706 gateway PEs SHOULD NOT receive AS_PATH attributes with path 707 segments of type AS_SET [RFC6472]. Routes received with AS_PATH 708 attributes including AS_SET path segments MUST NOT be aggregated. 710 o ISF routes that have different attributes of the following type 711 codes MUST NOT be aggregated: D-PATH, LOCAL_PREF, ORIGINATOR_ID, 712 CLUSTER_ID, MED or AIGP. 714 o The Community, Extended Community and Large Community attributes 715 of the aggregate ISF route MUST contain all the Communities/ 716 Extended Communities/Large Communities from all of the aggregated 717 ISF routes, with the exceptions of the extended communities listed 718 in Section 5.2 that are not propagated. 720 Assuming the aggregation can be performed (the above rules are 721 applied), the operator should consider aggregation to deal with 722 scaled tenant networks where a significant number of host routes 723 exists. For example, large Data Centers. 725 6. Route Selection Process between EVPN and other ISF SAFIs 727 A PE may receive an IP prefix in ISF routes with different ISF SAFIs, 728 from the same or different BGP peer. It may also receive the same IP 729 prefix (host route) in an EVPN RT-2 and RT-5. A route selection 730 algorithm across all ISF SAFIs is needed so that: 732 o Different gateway and composite PEs have a consistent and 733 deterministic view on how to reach a given prefix. 735 o Prefixes advertised in EVPN and other ISF SAFIs can be compared 736 based on path attributes commonly used by operators across 737 networks. 739 o Equal Cost Multi-Path (ECMP) is allowed across EVPN and other ISF 740 SAFI routes. 742 For a given prefix advertised in one or more non-EVPN ISF routes, the 743 BGP best path selection procedure will produce a set of "non-EVPN 744 best paths". For a given prefix advertised in one or more EVPN ISF 745 routes, the BGP best path selection procedure will produce a set of 746 "EVPN best paths". To support EVPN/non-EVPN ISF interworking in the 747 context of the same IP-VRF receiving non-EVPN and EVPN ISF routes for 748 the same prefix, it is then necessary to run a tie-breaking selection 749 algorithm on the union of these two sets. This tie-breaking 750 algorithm begins by considering all EVPN and other ISF SAFI routes, 751 equally preferable routes to the same destination, and then selects 752 routes to be removed from consideration. The process terminates as 753 soon as only one route remains in consideration. 755 The route selection algorithm must remove from consideration the 756 routes following the rules and the order defined in [RFC4271], with 757 the following exceptions and in the following order: 759 1. Immediately after removing from consideration all routes that are 760 not tied for having the highest Local Preference, any routes that 761 do not have the shortest D-PATH are also removed from 762 consideration. Routes with no D-PATH are considered to have a 763 zero-length D-PATH. 765 2. Then regular [RFC4271] selection criteria is followed. 767 3. At the end of the selection algorithm, if at least one route 768 still under consideration is an RT-2 route, remove from 769 consideration any RT-5 routes. 771 4. Steps 1-3 could possibly leave Equal Cost Multi-Path (ECMP) 772 between non-EVPN and EVPN paths. By default, the EVPN path is 773 considered (and the non-EVPN path removed from consideration). 774 However, if ECMP across ISF SAFIs is enabled by policy, and one 775 EVPN path and one non-EVPN path remain at the end of step 3, both 776 path types will be used. 778 Example 1 - PE1 receives the following routes for IP1/32, that are 779 candidate to be imported in IP-VRF-1: 781 {SAFI=EVPN, RT-2, Local-Pref=100, AS-Path=(100,200)} 782 {SAFI=EVPN, RT-5, Local-Pref=100, AS-Path=(100,200)} 783 {SAFI=128, Local-Pref=100, AS-Path=(100,200)} 785 Selected route: {SAFI=EVPN, RT-2, Local-Pref=100, AS-Path=100,200] 786 (due to step 3, and no ECMP) 788 Example 2 - PE1 receives the following routes for IP2/24, that are 789 candidate to be imported in IP-VRF-1: 791 {SAFI=EVPN, RT-5, D-PATH=(6500:3:IPVPN), AS-Path=(100,200), 792 MED=10} 793 {SAFI=128, D-PATH=(6500:1:EVPN,6500:2:IPVPN), AS-Path=(200), 794 MED=200} 796 Selected route: {SAFI=EVPN, RT-5, D-PATH=(6500:3:IPVPN), AS- 797 Path=(100,200), MED=10} (due to step 1) 799 7. Composite PE Procedures 801 As described in Section 3, composite PEs are typically used in tenant 802 networks where EVPN and IPVPN are both used to provide inter-subnet 803 forwarding within the same composite domain. 805 Figure 7 depicts an example of a composite domain, where PE1/PE2/PE4 806 are composite PEs (they support EVPN and IPVPN ISF SAFIs on their 807 peering to the Route Reflector), and PE3 is a regular IPVPN PE. 809 +-----------------------------------+ 810 | | 811 | MPLS IPVPN PE3 812 | Network +----------+ IP3/24 813 | IPVPN |+------+ | +---+ 814 | +----->||IP-VRF|------|CE3| 815 Composite PE1 | |+------+ | +---+ 816 +---------------+ | +----------+ 817 | +------+ | EVPN v | 818 | |IP-VRF| | IPVPN +--+ | 819 | +----| | | <------> |RR| | 820 +---+ | | +------+ | +--+ Composite PE4 821 |CE2|----|MAC-VRF| | ^ ^ +---------+ IP4/24 822 +---+ | +-------+ | EVPN | | EVPN |+------+ | +---+ 823 +---|-----------+ IPVPN | | IPVPN ||IP-VRF|-----|CE4| 824 | | +----+ +-------->|+------+ | +---+ 825 IP1/24 | | v +---------+ 826 +---+ | | +---------------+ | 827 |CE1|--+ +----| +------+ +--------------+ 828 +---+ | |IP-VRF| | 829 | | +----| | | 830 | | | +------+ | 831 +--------------|MAC-VRF| | 832 | +-------+ | 833 +---------------+ 834 Composite PE2 836 Figure 7: Composite PE example 838 In a composite domain with composite and regular PEs: 840 o The composite PEs advertise the same IP prefixes in each ISF SAFI 841 to the RR. For example, in Figure 7, the prefix IP1/24 is 842 advertised by PE1 and PE2 to the RR in two separate NLRIs, one for 843 AFI/SAFI 1/128 and another one for EVPN. 845 o The RR does not forward EVPN routes to PE3 (since the RR does not 846 have the EVPN SAFI enabled on its BGP session to PE3), whereas the 847 IPVPN routes are forwarded to all the PEs. 849 o PE3 receives only the IPVPN route for IP1/24 and resolves the BGP 850 next-hop to an MPLS tunnel (with IP payload) to PE1 and/or PE2. 852 o Composite PE4 receives IP1/24 encoded in EVPN and another ISF SAFI 853 route (EVPN RT-5 and IPVPN). The route selection follows the 854 procedures in Section 6. Assuming an EVPN route is selected, PE4 855 resolves the BGP next-hop to an MPLS tunnel (with Ethernet or IP 856 payload) to PE1 and/or PE2. As described in Section 3, two EVPN 857 PEs may use tunnels with Ethernet or IP payloads to connect their 858 IP-VRFs, depending on the 859 [I-D.ietf-bess-evpn-prefix-advertisement] model implemented. If 860 some attributes are modified so that the route selection process 861 (Section 6) results in PE4 selecting the IPVPN path instead of the 862 EVPN path, the operator should be aware that the EVPN advanced 863 forwarding features, e.g. recursive resolution to overlay indexes, 864 will be lost for PE4. 866 o The other composite PEs (PE1 and PE2) receive also the same IP 867 prefix via EVPN and IPVPN SAFIs and they also follow the route 868 selection in Section 6. 870 o When a given route has been selected as the route for a particular 871 packet, the transmission of the packet is done according to the 872 rules for that route's AFI/SAFI. 874 o It is important to note that in composite domains, such as the one 875 in Figure 7, the EVPN advanced forwarding features will only be 876 available to composite and EVPN PEs (assuming they select an RT-5 877 to forward packets for a given IP prefix), and not to IPVPN PEs. 878 For example, assuming PE1 sends IP1/24 in an EVPN and an IPVPN 879 route and the EVPN route is the best one in the selection, the 880 recursive resolution of the EVPN RT-5s can only be used in PE2 and 881 PE4 (composite PEs), and not in PE3 (IPVPN PE). As a consequence 882 of this, the indirection provided by the RT5's recursive 883 resolution and its benefits in a scaled network, will not be 884 available in all the PEs in the network. 886 8. Gateway PE Procedures 888 Section 3 defines a gateway PE as an Interworking PE that advertises 889 IP prefixes to different BGP peers, using EVPN to one BGP peer and 890 another ISF SAFI to another BGP peer. Examples of gateway PEs are 891 Data Center gateways connecting domains that make use of EVPN and 892 other ISF SAFIs for a given tenant. Figure 8 illustrates this use- 893 case, in which PE1 and PE2 (and PE3/PE4) are gateway PEs 894 interconnecting domains for the same tenant. 896 <----EVPN----> <----------IPVPN---------> <----EVPN----> 897 6500:1:EVPN 6500:2:IPVPN 6500:3:EVPN 898 899 +-----------------------+ 900 Gateway PE1 Gateway PE3 901 +----------+ +----------+ 902 +-----------|+------+ | MPLS tnls |+------+ |-------------+ 903 | ||IP-VRF| | ||IP-VRF| | | 904 PE5 |+------+ | |+------+ | PE6 905 +------+ +----------+ +----------+ +------+ 906 |IP-VRF| NVO tnls | | | | NVO tnls |IP-VRF| 907 | | | | | | | | 908 +------+ +----------+ +----------+ +------+ 909 IP1/24--> |+------+ | |+------+ | | 910 | ||IP-VRF| | ||IP-VRF| | | 911 +-----------|+------+ | |+------+ |-------------+ 912 +----------+ +----------+ 913 Gateway PE2 +------+ Gateway PE4 914 +-------|IP-VRF|---------+ 915 | | 916 +------+ 917 PE7 919 Figure 8: Gateway PE example 921 The gateway PE procedures are described as follows: 923 o A gateway PE that imports an ISF SAFI-x route to prefix P in an 924 IP-VRF, MUST export P in ISF SAFI-y if: 926 1. P is installed in the IP-VRF (hence the SAFI-x route is the 927 best one for P) and 929 2. PE has a BGP peer for SAFI-y (enabled for the same IP-VRF) 931 In the example of Figure 8, gateway PE1 and PE2 receive an EVPN 932 RT-5 with IP1/24, install the prefix in the IP-VRF and re- 933 advertise it using SAFI 128. 935 o ISF SAFI routes advertised by a gateway PE MUST include a D-PATH 936 attribute, so that loops can be detected in remote gateway PEs. 937 When a gateway PE propagates an IP prefix between EVPN and another 938 ISF SAFI, it MUST prepend a to the 939 received D-PATH attribute. The DOMAIN-ID and ISF_SAFI_TYPE fields 940 refer to the domain over which the gateway PE received the IP 941 prefix and the ISF SAFI of the route, respectively. If the 942 received IP prefix route did not include any D-PATH attribute, the 943 gateway IP MUST add the D-PATH when readvertising. The D-PATH in 944 this case will have only one segment on the list, the of the received route. 947 In the example of Figure 8, gateway PE1/PE2 receive the EVPN RT-5 948 with no D-PATH attribute since the route is originated at PE5. 949 Therefore PE1 and PE2 will add the D-PATH attribute including 950 = <6500:1:EVPN>. Gateways PE3/PE4 will 951 propagate the route again, now prepending their = <6500:2:IPVPN>. PE6 receives the EVPN RT-5 953 routes with D-PATH = {<6500:2:IPVPN>,<6500:1:EVPN>} and can use 954 that information to make BGP path decisions. 956 o The gateway PE MAY use the Route Distinguisher of the IP-VRF to 957 readvertise IP prefixes in EVPN or the other ISF SAFI. 959 o The label allocation used by each gateway PE is a local 960 implementation matter. The IP-VRF advertising IP prefixes for 961 EVPN and another ISF SAFI may use a label per-VRF, per-prefix, 962 etc. 964 o The gateway PE MUST be able to use the same or different set of 965 Route Targets per ISF SAFI on the same IP-VRF. In particular, if 966 different domains use different set of Route Targets for the same 967 tenant, the gateway PE MUST be able to import and export routes 968 with the different sets. 970 o Even though Figure 8 only shows two domains per gateway PE, the 971 gateway PEs may be connected to more than two domains. 973 o There is no limitation of gateway PEs that a given IP prefix can 974 pass through until it reaches a given PE. 976 o It is worth noting that an IP prefix that was originated in an 977 EVPN domain but traversed a different ISF SAFI domain, will lose 978 EVPN-specific attributes that are used in advanced EVPN 979 procedures. For example, even if PE1 advertises IP1/24 along with 980 a given non-zero ESI (for recursive resolution to that ESI), when 981 PE6 receives the IP prefix in an EVPN route, the ESI value will be 982 zero. This is because the route traverses an ISF SAFI domain that 983 is different than EVPN. 985 9. Interworking Use-Cases 987 While Interworking PE networks may well be similar to the examples 988 described in Section 7 and Section 8, in some cases a combination of 989 both functions may be required. Figure 9 illustrates an example 990 where the gateway PEs are also composite PEs, since not only they 991 need to re-advertise IP prefixes from EVPN routes to another ISF SAFI 992 routes, but they also need to interwork with IPVPN-only PEs in a 993 domain with a mix of composite and IPVPN-only PEs. 995 +-----------------------------------+ 996 | | 997 | MPLS IPVPN PE3 998 | Network +---------+ 999 | IPVPN |+------+ | 1000 | +----->||IP-VRF|---TS3 1001 (GW+composite) PE1 | |+------+ | 1002 +---------------+ | +---------+ 1003 | +------+ | EVPN v | 1004 | |IP+VRF| | IPVPN +-++ | 1005 | +----| | | <------> |RR| | 1006 +--------| | +------+ | +--+ Composite PE4 1007 | | |MAC+VRF| | ^ ^ +---------+ 1008 | | +-------+ | EVPN | | EVPN |+------+ | 1009 +----+ +---------------+ IPVPN | | IPVPN ||IP-VRF|---TS4 1010 TS1-|NVE1| | +----+ +-------->|+------+ | 1011 +----+ | v +---------+ 1012 | EVPN DC | +---------------+ | 1013 | NVO tnls +----| +------+ |-------------+ 1014 | | |IP+VRF| | 1015 | | +----| | | 1016 | | | +------+ | 1017 | +----+ | |MAC+VRF| | 1018 +-----|NVE2|---------| +-------+ | 1019 +----+ +---------------+ 1020 | (GW+composite) PE2 1021 TS2 1023 Figure 9: Gateway and composite combined functions - example 1025 In the example above, PE1 and PE2 MUST follow the procedures 1026 described in Section 7 and Section 8. Compared to Section 8, PE1 and 1027 PE2 now need to also propagate prefixes from EVPN to EVPN, in 1028 addition to propagating prefixes from EVPN to IPVPN. 1030 It is worth noting that PE1 and PE2 will receive TS4's IP prefix via 1031 IPVPN and RT-5 routes. When readvertising to NVE1 and NVE2, PE1 and 1032 PE2 will consider the D-PATH rules and attributes of the selected 1033 route for TS4 (Section 6 describes the Route Selection Process). 1035 10. Conclusion 1037 This document describes the procedures required in PEs that use EVPN 1038 and another Inter-Subnet Forwarding SAFI to import and export IP 1039 prefixes for a given tenant. In particular, this document defines: 1041 o A route selection algorithm so that a PE can determine what path 1042 to choose between EVPN paths and other ISF SAFI paths. 1044 o A new BGP Path attribute called D-PATH that provides loop 1045 protection and visibility on the domains a particular route has 1046 traversed. 1048 o The way Path attributes should be propagated between EVPN and 1049 another ISF SAFI. 1051 o The procedures that must be followed on Interworking PEs that 1052 behave as composite PEs, gateway PEs or a combination of both. 1054 The above procedures provide an operator with the required tools to 1055 build large tenant networks that may span multiple domains, use 1056 different ISF SAFIs to handle IP prefixes, in a deterministic way and 1057 with routing loop protection. 1059 11. Security Considerations 1061 In general, the security considerations described in 1062 [I-D.ietf-bess-evpn-prefix-advertisement] and [RFC4364] apply to this 1063 document. 1065 Section 4 introduces the use of the D-PATH attribute, which provides 1066 a security tool against control plane loops that may be introduced by 1067 the use of gateway PEs that export ISF routes between domains. A 1068 correct use of the D-PATH will prevent control plane and data plane 1069 loops in the network, however an incorrect configuration of the 1070 DOMAIN-IDs on the gateway PEs may lead to the detection of false 1071 route loops and the blackholing of the traffic. An attacker may 1072 benefit of this transitive attribute to propagate the wrong domain 1073 information across multiple domains. 1075 In addition, Section 5.2 introduces the propagation of attributes 1076 between ISF SAFIs on gateway PEs. Without this mode of propagation, 1077 Path Attributes are re-initialized when re-exporting ISF routes into 1078 a different ISF SAFI, however this mode introduces the capability of 1079 propagating Path Attributes beyond the ISF SAFI scope. While this is 1080 a useful tool to provide end to end visibility across multiple 1081 domains, it can also be used by an attacker to propagate wrong 1082 (although correctly formed) Path Attributes that can influence the 1083 BGP path selection in remote domains. 1085 12. IANA Considerations 1087 This document defines a new BGP path attribute known as the BGP 1088 Domain Path (D-PATH) attribute. 1090 IANA has assigned a new attribute code type from the "BGP Path 1091 Attributes" subregistry under the "Border Gateway Protocol (BGP) 1092 Parameters" registry: 1094 Path Attribute Value Code Reference 1095 -------------------- ------------------------ --------------- 1096 36 BGP Domain Path (D-PATH) [This document] 1098 13. Acknowledgments 1100 The authors want to thank Russell Kelly, Dhananjaya Rao, Suresh 1101 Basavarajappa, Mallika Gautam, Senthil Sathappan, Arul Mohan Jovel, 1102 Naveen Tubugere, Mathanraj Petchimuthu and Amit Kumar for their 1103 review and suggestions. 1105 14. Contributors 1107 15. References 1109 15.1. Normative References 1111 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1112 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1113 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1114 2015, . 1116 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1117 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1118 DOI 10.17487/RFC4271, January 2006, 1119 . 1121 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1122 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1123 2006, . 1125 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1126 Requirement Levels", BCP 14, RFC 2119, 1127 DOI 10.17487/RFC2119, March 1997, 1128 . 1130 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1131 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1132 May 2017, . 1134 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1135 Patel, "Revised Error Handling for BGP UPDATE Messages", 1136 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1137 . 1139 [I-D.ietf-bess-evpn-prefix-advertisement] 1140 Rabadan, J., Henderickx, W., Drake, J. E., Lin, W., and A. 1141 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 1142 bess-evpn-prefix-advertisement-11 (work in progress), May 1143 2018. 1145 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 1146 Sajassi, A., Salam, S., Thoria, S., Drake, J. E., and J. 1147 Rabadan, "Integrated Routing and Bridging in EVPN", draft- 1148 ietf-bess-evpn-inter-subnet-forwarding-13 (work in 1149 progress), February 2021. 1151 15.2. Informative References 1153 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1154 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1155 February 2006, . 1157 [I-D.ietf-idr-tunnel-encaps] 1158 Patel, K., Velde, G. V. D., Sangli, S. R., and J. Scudder, 1159 "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr- 1160 tunnel-encaps-22 (work in progress), January 2021. 1162 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using 1163 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, 1164 DOI 10.17487/RFC6472, December 2011, 1165 . 1167 Authors' Addresses 1169 J. Rabadan (editor) 1170 Nokia 1171 777 Middlefield Road 1172 Mountain View, CA 94043 1173 USA 1175 Email: jorge.rabadan@nokia.com 1176 A. Sajassi (editor) 1177 Cisco 1178 225 West Tasman Drive 1179 San Jose, CA 95134 1180 USA 1182 Email: sajassi@cisco.com 1184 E. Rosen 1185 Individual 1187 Email: erosen52@gmail.com 1189 J. Drake 1190 Juniper 1192 Email: jdrake@juniper.net 1194 W. Lin 1195 Juniper 1197 Email: wlin@juniper.net 1199 J. Uttaro 1200 AT&T 1202 Email: ju1738@att.com 1204 A. Simpson 1205 Nokia 1207 Email: adam.1.simpson@nokia.com