idnits 2.17.1 draft-ietf-bess-evpn-ipvpn-interworking-04.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 (December 19, 2020) is 1224 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-11 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-20 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 Nokia 4 Intended status: Standards Track A. Sajassi, Ed. 5 Expires: June 22, 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 December 19, 2020 17 EVPN Interworking with IPVPN 18 draft-ietf-bess-evpn-ipvpn-interworking-04 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 June 22, 2021. 48 Copyright Notice 50 Copyright (c) 2020 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 or re-advertised. The ISF route in this 527 case MUST be 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 a "looped" in the tenant 539 IP-VRF, and does not re-advertise it to the EVPN neighbors since 540 the route includes the GW1's local domain. 542 e. A DOMAIN-ID value on a GW-PE MAY be globally assigned for a 543 peering domain or MAY be scoped for an individual tenant IP-VRF. 545 - If globally allocated for a peering domain, the DOMAIN-ID 546 applies to all tenant IP-VRFs for that domain. 548 - If allocated for a specific tenant IP-VRF, the processing of 549 the received D-PATH and its propagation will be in the context 550 of the IP-VRF DOMAIN-ID. Route leaking is a use-case where a 551 per-IP-VRF DOMAIN-ID assignment is necessary. Suppose 552 gateways PE1 and PE2 are attached to two different tenant IP- 553 VRFs, IP-VRF-1 and IP-VRF-2. ISF SAFI routes advertised by 554 gateway PE1 for IP-VRF-1 are received on gateway PE2 with 555 DOMAIN-ID 6500:1. If the routes are leaked from IP-VRF-1 into 556 IP-VRF-2 on PE2, and re-advertised back to PE1 in the context 557 of IP-VRF-2, PE1 will not treat the route as a looped route. 558 This is because PE1 processes the route in the context of IP- 559 VRF-2, where DOMAIN-ID 6500:1 is not a local DOMAIN-ID. 561 f. The number of domains in the D-PATH attribute indicates the 562 number of gateway PEs that the ISF route update has transited. 563 If one of the transit gateway PEs leaks a given ISF route between 564 two local IP-VRFs, it MAY prepend a domain with a ISF_SAFI_TYPE 565 of 0 for the leaked route when the route is exported into an ISF 566 SAFI. In that case, the number of domains in the D-PATH 567 attribute indicates the number of tenant IP-VRFs that the ISF 568 route update has transited. 570 g. The following error-handling rules apply to the D-PATH attribute: 572 1. A received D-PATH attribute is considered malformed if it 573 contains a malformed Domain Segment. 575 2. A Domain Segment is considered malformed in any of the 576 following cases: 578 * The Domain Segment length of the last Domain Segment 579 causes the D-PATH attribute length to be exceeded. 581 * After the last successfully parsed Domain Segment there is 582 only one single octet remaining. 584 * The Domain Segment has a Domain Segment Length of zero. 586 3. A PE receiving an UPDATE message with a malformed D-PATH 587 attribute SHALL apply "treat-as-withdraw" [RFC7606]. 589 5. BGP Path Attribute Propagation across ISF SAFIs 591 Based on its configuration, a gateway PE is required to propagate an 592 ISF route with different ISF SAFIs between two domains. This 593 requires a definition of what a gateway PE has to do with Path 594 attributes attached to the ISF route that it is propagating. 596 5.1. No-Propagation-Mode 598 This is the default mode of operation for gateway PEs that re-export 599 ISF routes from any ISF SAFI into EVPN, and from EVPN into any other 600 SAFI. In this mode, the gateway PE will simply re-initialize the 601 Path Attributes when propagating an ISF route, as though it would for 602 direct or local IP prefixes. This model may be enough in those use- 603 cases where the EVPN domain is considered an "abstracted" CE and 604 remote IPVPN/IP PEs don't need to consider the original EVPN 605 Attributes for path calculations. 607 Since this mode of operation does not propagate the D-PATH attribute 608 either, redundant gateway PEs are exposed to routing loops. Those 609 loops may be resolved by policies and the use of other attributes, 610 such as the Route Origin extended community [RFC4360], however not 611 all the loop situations may be solved. 613 5.2. Uniform-Propagation-Mode 615 In this mode, the gateway PE simply keeps accumulating or mapping 616 certain key commonly used Path Attributes when propagating an ISF 617 route. This mode is typically used in networks where EVPN and IPVPN 618 SAFIs are used seamlessly to distribute IP prefixes. 620 The following rules MUST be observed by the gateway PE when 621 propagating Path Attributes: 623 1. The gateway PE imports an ISF route in the IP-VRF and stores the 624 original Path Attributes. The following set of Path Attributes 625 SHOULD be propagated by the gateway PE to other ISF SAFIs (other 626 Path Attributes SHOULD NOT be propagated): 628 - AS_PATH 630 - D-PATH 632 - IBGP-only Path Attributes: LOCAL_PREF, ORIGINATOR_ID, 633 CLUSTER_ID 635 - MED 636 - AIGP 638 - Communities, Extended Communities and Large Communities, 639 except for the EVPN extended communities, Route Target 640 extended communities and BGP Encapsulation extended 641 communities. 643 2. When propagating an ISF route to a different ISF SAFI and IBGP 644 peer, the gateway PE SHOULD keep the AS_PATH of the originating 645 family and add it to the destination family without any 646 modification. When re-advertising to a different ISF SAFI and 647 EBGP peer, the gateway PE SHOULD keep the AS_PATH of the 648 originating family and prepend the IP-VRF's AS before sending the 649 route. 651 3. When propagating an ISF route to IBGP peers, the gateway PE 652 SHOULD keep the IBGP-only Path Attributes from the originating 653 SAFI to the re-advertised route. 655 4. As discussed, Communities, Extended Communities and Large 656 Communities SHOULD be kept by the gateway PE from the originating 657 SAFI route. Exceptions of Extended Communities that SHOULD NOT 658 be kept are: 660 A. BGP Encapsulation extended communities 661 [I-D.ietf-idr-tunnel-encaps]. 663 B. Route Target extended communities. Route Targets are always 664 initialized when readvertising an ISF route into a different 665 domain, i.e., they are not propagated. The initialized Route 666 Target in the re-advertised ISF route may or may not have the 667 same value as the Route Target of the originating ISF route. 669 C. All the extended communities of type EVPN. 671 The gateway PE SHOULD NOT copy the above extended communities 672 from the originating ISF route to the re-advertised ISF route. 674 5. For a given ISF route, only the Path Attributes of the best path 675 can be propagated to another ISF route. If multiple paths are 676 received for the same route in an ISF SAFI, the BGP best path 677 selection will determine what the best path is, and therefore the 678 set of Path Attributes to be propagated. Even if Equal Cost 679 Multi-Path (ECMP) is enabled on the IP-VRF by policy, only the 680 Path Attributes of the selected best path are propagated. 682 5.3. Aggregation of Routes and Path Attribute Propagation 684 Instead of propagating a high number of (host) ISF routes between ISF 685 SAFIs, a gateway PE that receives multiple ISF routes of one ISF SAFI 686 MAY choose to propagate a single ISF aggregate route into a different 687 domain. In this document, aggregation is used to combine the 688 characteristics of multiple ISF routes of the same ISF SAFI in such 689 way that a single aggregate ISF route of a different ISF SAFI can be 690 propagated. Aggregation of multiple ISF routes of one ISF SAFI into 691 an aggregate ISF route is only done by a gateway PE. 693 Aggregation on gateway PEs may use either the No-Propagation-Mode or 694 the Uniform-Propagation-Mode explained in Section 5.1 and 695 Section 5.2, respectively. 697 When using Uniform-Propagation-Mode, Path Attributes of the same type 698 code MAY be aggregated according to the following rules: 700 o AS_PATH is aggregated based on the rules in [RFC4271]. The 701 gateway PEs SHOULD NOT receive AS_PATH attributes with path 702 segments of type AS_SET [RFC6472]. Routes received with AS_PATH 703 attributes including AS_SET path segments MUST NOT be aggregated. 705 o ISF routes that have different attributes of the following type 706 codes MUST NOT be aggregated: D-PATH, LOCAL_PREF, ORIGINATOR_ID, 707 CLUSTER_ID, MED or AIGP. 709 o The Community, Extended Community and Large Community attributes 710 of the aggregate ISF route MUST contain all the Communities/ 711 Extended Communities/Large Communities from all of the aggregated 712 ISF routes, with the exceptions of the extended communities listed 713 in Section 5.2 that are not propagated. 715 Assuming the aggregation can be performed (the above rules are 716 applied), the operator should consider aggregation to deal with 717 scaled tenant networks where a significant number of host routes 718 exists. For example, large Data Centers. 720 6. Route Selection Process between EVPN and other ISF SAFIs 722 A PE may receive an IP prefix in ISF routes with different ISF SAFIs, 723 from the same or different BGP peer. It may also receive the same IP 724 prefix (host route) in an EVPN RT-2 and RT-5. A route selection 725 algorithm across all ISF SAFIs is needed so that: 727 o Different gateway and composite PEs have a consistent and 728 deterministic view on how to reach a given prefix. 730 o Prefixes advertised in EVPN and other ISF SAFIs can be compared 731 based on path attributes commonly used by operators across 732 networks. 734 o Equal Cost Multi-Path (ECMP) is allowed across EVPN and other ISF 735 SAFI routes. 737 For a given prefix advertised in one or more non-EVPN ISF routes, the 738 BGP best path selection procedure will produce a set of "non-EVPN 739 best paths". For a given prefix advertised in one or more EVPN ISF 740 routes, the BGP best path selection procedure will produce a set of 741 "EVPN best paths". To support EVPN/non-EVPN ISF interworking in the 742 context of the same IP-VRF receiving non-EVPN and EVPN ISF routes for 743 the same prefix, it is then necessary to run a tie-breaking selection 744 algorithm on the union of these two sets. This tie-breaking 745 algorithm begins by considering all EVPN and other ISF SAFI routes, 746 equally preferable routes to the same destination, and then selects 747 routes to be removed from consideration. The process terminates as 748 soon as only one route remains in consideration. 750 The route selection algorithm must remove from consideration the 751 routes following the rules and the order defined in [RFC4271], with 752 the following exceptions and in the following order: 754 1. Immediately after removing from consideration all routes that are 755 not tied for having the highest Local Preference, any routes that 756 do not have the shortest D-PATH are also removed from 757 consideration. Routes with no D-PATH are considered to have a 758 zero-length D-PATH. 760 2. Then regular [RFC4271] selection criteria is followed. 762 3. At the end of the selection algorithm, if at least one route 763 still under consideration is an RT-2 route, remove from 764 consideration any RT-5 routes. 766 4. Steps 1-3 could possibly leave Equal Cost Multi-Path (ECMP) 767 between non-EVPN and EVPN paths. By default, the EVPN path is 768 considered (and the non-EVPN path removed from consideration). 769 However, if ECMP across ISF SAFIs is enabled by policy, and one 770 EVPN path and one non-EVPN path remain at the end of step 3, both 771 path types will be used. 773 Example 1 - PE1 receives the following routes for IP1/32, that are 774 candidate to be imported in IP-VRF-1: 776 {SAFI=EVPN, RT-2, Local-Pref=100, AS-Path=(100,200)} 777 {SAFI=EVPN, RT-5, Local-Pref=100, AS-Path=(100,200)} 778 {SAFI=128, Local-Pref=100, AS-Path=(100,200)} 780 Selected route: {SAFI=EVPN, RT-2, Local-Pref=100, AS-Path=100,200] 781 (due to step 3, and no ECMP) 783 Example 2 - PE1 receives the following routes for IP2/24, that are 784 candidate to be imported in IP-VRF-1: 786 {SAFI=EVPN, RT-5, D-PATH=(6500:3:IPVPN), AS-Path=(100,200), 787 MED=10} 788 {SAFI=128, D-PATH=(6500:1:EVPN,6500:2:IPVPN), AS-Path=(200), 789 MED=200} 791 Selected route: {SAFI=EVPN, RT-5, D-PATH=(6500:3:IPVPN), AS- 792 Path=(100,200), MED=10} (due to step 1) 794 7. Composite PE Procedures 796 As described in Section 3, composite PEs are typically used in tenant 797 networks where EVPN and IPVPN are both used to provide inter-subnet 798 forwarding within the same composite domain. 800 Figure 7 depicts an example of a composite domain, where PE1/PE2/PE4 801 are composite PEs (they support EVPN and IPVPN ISF SAFIs on their 802 peering to the Route Reflector), and PE3 is a regular IPVPN PE. 804 +-----------------------------------+ 805 | | 806 | MPLS IPVPN PE3 807 | Network +----------+ IP3/24 808 | IPVPN |+------+ | +---+ 809 | +----->||IP-VRF|------|CE3| 810 Composite PE1 | |+------+ | +---+ 811 +---------------+ | +----------+ 812 | +------+ | EVPN v | 813 | |IP-VRF| | IPVPN +--+ | 814 | +----| | | <------> |RR| | 815 +---+ | | +------+ | +--+ Composite PE4 816 |CE2|----|MAC-VRF| | ^ ^ +---------+ IP4/24 817 +---+ | +-------+ | EVPN | | EVPN |+------+ | +---+ 818 +---|-----------+ IPVPN | | IPVPN ||IP-VRF|-----|CE4| 819 | | +----+ +-------->|+------+ | +---+ 820 IP1/24 | | v +---------+ 821 +---+ | | +---------------+ | 822 |CE1|--+ +----| +------+ +--------------+ 823 +---+ | |IP-VRF| | 824 | | +----| | | 825 | | | +------+ | 826 +--------------|MAC-VRF| | 827 | +-------+ | 828 +---------------+ 829 Composite PE2 831 Figure 7: Composite PE example 833 In a composite domain with composite and regular PEs: 835 o The composite PEs advertise the same IP prefixes in each ISF SAFI 836 to the RR. For example, in Figure 7, the prefix IP1/24 is 837 advertised by PE1 and PE2 to the RR in two separate NLRIs, one for 838 AFI/SAFI 1/128 and another one for EVPN. 840 o The RR does not forward EVPN routes to PE3 (since the RR does not 841 have the EVPN SAFI enabled on its BGP session to PE3), whereas the 842 IPVPN routes are forwarded to all the PEs. 844 o PE3 receives only the IPVPN route for IP1/24 and resolves the BGP 845 next-hop to an MPLS tunnel (with IP payload) to PE1 and/or PE2. 847 o Composite PE4 receives IP1/24 encoded in EVPN and another ISF SAFI 848 route (EVPN RT-5 and IPVPN). The route selection follows the 849 procedures in Section 6. Assuming an EVPN route is selected, PE4 850 resolves the BGP next-hop to an MPLS tunnel (with Ethernet or IP 851 payload) to PE1 and/or PE2. As described in Section 3, two EVPN 852 PEs may use tunnels with Ethernet or IP payloads to connect their 853 IP-VRFs, depending on the 854 [I-D.ietf-bess-evpn-prefix-advertisement] model implemented. If 855 some attributes are modified so that the route selection process 856 (Section 6) results in PE4 selecting the IPVPN path instead of the 857 EVPN path, the operator should be aware that the EVPN advanced 858 forwarding features, e.g. recursive resolution to overlay indexes, 859 will be lost for PE4. 861 o The other composite PEs (PE1 and PE2) receive also the same IP 862 prefix via EVPN and IPVPN SAFIs and they also follow the route 863 selection in Section 6. 865 o When a given route has been selected as the route for a particular 866 packet, the transmission of the packet is done according to the 867 rules for that route's AFI/SAFI. 869 o It is important to note that in composite domains, such as the one 870 in Figure 7, the EVPN advanced forwarding features will only be 871 available to composite and EVPN PEs (assuming they select an RT-5 872 to forward packets for a given IP prefix), and not to IPVPN PEs. 873 For example, assuming PE1 sends IP1/24 in an EVPN and an IPVPN 874 route and the EVPN route is the best one in the selection, the 875 recursive resolution of the EVPN RT-5s can only be used in PE2 and 876 PE4 (composite PEs), and not in PE3 (IPVPN PE). As a consequence 877 of this, the indirection provided by the RT5's recursive 878 resolution and its benefits in a scaled network, will not be 879 available in all the PEs in the network. 881 8. Gateway PE Procedures 883 Section 3 defines a gateway PE as an Interworking PE that advertises 884 IP prefixes to different BGP peers, using EVPN to one BGP peer and 885 another ISF SAFI to another BGP peer. Examples of gateway PEs are 886 Data Center gateways connecting domains that make use of EVPN and 887 other ISF SAFIs for a given tenant. Figure 8 illustrates this use- 888 case, in which PE1 and PE2 (and PE3/PE4) are gateway PEs 889 interconnecting domains for the same tenant. 891 <----EVPN----> <----------IPVPN---------> <----EVPN----> 892 6500:1:EVPN 6500:2:IPVPN 6500:3:EVPN 893 894 +-----------------------+ 895 Gateway PE1 Gateway PE3 896 +----------+ +----------+ 897 +-----------|+------+ | MPLS tnls |+------+ |-------------+ 898 | ||IP-VRF| | ||IP-VRF| | | 899 PE5 |+------+ | |+------+ | PE6 900 +------+ +----------+ +----------+ +------+ 901 |IP-VRF| NVO tnls | | | | NVO tnls |IP-VRF| 902 | | | | | | | | 903 +------+ +----------+ +----------+ +------+ 904 IP1/24--> |+------+ | |+------+ | | 905 | ||IP-VRF| | ||IP-VRF| | | 906 +-----------|+------+ | |+------+ |-------------+ 907 +----------+ +----------+ 908 Gateway PE2 +------+ Gateway PE4 909 +-------|IP-VRF|---------+ 910 | | 911 +------+ 912 PE7 914 Figure 8: Gateway PE example 916 The gateway PE procedures are described as follows: 918 o A gateway PE that imports an ISF SAFI-x route to prefix P in an 919 IP-VRF, MUST export P in ISF SAFI-y if: 921 1. P is installed in the IP-VRF (hence the SAFI-x route is the 922 best one for P) and 924 2. PE has a BGP peer for SAFI-y (enabled for the same IP-VRF) 926 In the example of Figure 8, gateway PE1 and PE2 receive an EVPN 927 RT-5 with IP1/24, install the prefix in the IP-VRF and re- 928 advertise it using SAFI 128. 930 o ISF SAFI routes advertised by a gateway PE MUST include a D-PATH 931 attribute, so that loops can be detected in remote gateway PEs. 932 When a gateway PE propagates an IP prefix between EVPN and another 933 ISF SAFI, it MUST prepend a to the 934 received D-PATH attribute. The DOMAIN-ID and ISF_SAFI_TYPE fields 935 refer to the domain over which the gateway PE received the IP 936 prefix and the ISF SAFI of the route, respectively. If the 937 received IP prefix route did not include any D-PATH attribute, the 938 gateway IP MUST add the D-PATH when readvertising. The D-PATH in 939 this case will have only one segment on the list, the of the received route. 942 In the example of Figure 8, gateway PE1/PE2 receive the EVPN RT-5 943 with no D-PATH attribute since the route is originated at PE5. 944 Therefore PE1 and PE2 will add the D-PATH attribute including 945 = <6500:1:EVPN>. Gateways PE3/PE4 will 946 propagate the route again, now prepending their = <6500:2:IPVPN>. PE6 receives the EVPN RT-5 948 routes with D-PATH = {<6500:2:IPVPN>,<6500:1:EVPN>} and can use 949 that information to make BGP path decisions. 951 o The gateway PE MAY use the Route Distinguisher of the IP-VRF to 952 readvertise IP prefixes in EVPN or the other ISF SAFI. 954 o The label allocation used by each gateway PE is a local 955 implementation matter. The IP-VRF advertising IP prefixes for 956 EVPN and another ISF SAFI may use a label per-VRF, per-prefix, 957 etc. 959 o The gateway PE MUST be able to use the same or different set of 960 Route Targets per ISF SAFI on the same IP-VRF. In particular, if 961 different domains use different set of Route Targets for the same 962 tenant, the gateway PE MUST be able to import and export routes 963 with the different sets. 965 o Even though Figure 8 only shows two domains per gateway PE, the 966 gateway PEs may be connected to more than two domains. 968 o There is no limitation of gateway PEs that a given IP prefix can 969 pass through until it reaches a given PE. 971 o It is worth noting that an IP prefix that was originated in an 972 EVPN domain but traversed a different ISF SAFI domain, will lose 973 EVPN-specific attributes that are used in advanced EVPN 974 procedures. For example, even if PE1 advertises IP1/24 along with 975 a given non-zero ESI (for recursive resolution to that ESI), when 976 PE6 receives the IP prefix in an EVPN route, the ESI value will be 977 zero. This is because the route traverses an ISF SAFI domain that 978 is different than EVPN. 980 9. Interworking Use-Cases 982 While Interworking PE networks may well be similar to the examples 983 described in Section 7 and Section 8, in some cases a combination of 984 both functions may be required. Figure 9 illustrates an example 985 where the gateway PEs are also composite PEs, since not only they 986 need to re-advertise IP prefixes from EVPN routes to another ISF SAFI 987 routes, but they also need to interwork with IPVPN-only PEs in a 988 domain with a mix of composite and IPVPN-only PEs. 990 +-----------------------------------+ 991 | | 992 | MPLS IPVPN PE3 993 | Network +---------+ 994 | IPVPN |+------+ | 995 | +----->||IP-VRF|---TS3 996 (GW+composite) PE1 | |+------+ | 997 +---------------+ | +---------+ 998 | +------+ | EVPN v | 999 | |IP+VRF| | IPVPN +-++ | 1000 | +----| | | <------> |RR| | 1001 +--------| | +------+ | +--+ Composite PE4 1002 | | |MAC+VRF| | ^ ^ +---------+ 1003 | | +-------+ | EVPN | | EVPN |+------+ | 1004 +----+ +---------------+ IPVPN | | IPVPN ||IP-VRF|---TS4 1005 TS1-|NVE1| | +----+ +-------->|+------+ | 1006 +----+ | v +---------+ 1007 | EVPN DC | +---------------+ | 1008 | NVO tnls +----| +------+ |-------------+ 1009 | | |IP+VRF| | 1010 | | +----| | | 1011 | | | +------+ | 1012 | +----+ | |MAC+VRF| | 1013 +-----|NVE2|---------| +-------+ | 1014 +----+ +---------------+ 1015 | (GW+composite) PE2 1016 TS2 1018 Figure 9: Gateway and composite combined functions - example 1020 In the example above, PE1 and PE2 MUST follow the procedures 1021 described in Section 7 and Section 8. Compared to Section 8, PE1 and 1022 PE2 now need to also propagate prefixes from EVPN to EVPN, in 1023 addition to propagating prefixes from EVPN to IPVPN. 1025 It is worth noting that PE1 and PE2 will receive TS4's IP prefix via 1026 IPVPN and RT-5 routes. When readvertising to NVE1 and NVE2, PE1 and 1027 PE2 will consider the D-PATH rules and attributes of the selected 1028 route for TS4 (Section 6 describes the Route Selection Process). 1030 10. Conclusion 1032 This document describes the procedures required in PEs that use EVPN 1033 and another Inter-Subnet Forwarding SAFI to import and export IP 1034 prefixes for a given tenant. In particular, this document defines: 1036 o A route selection algorithm so that a PE can determine what path 1037 to choose between EVPN paths and other ISF SAFI paths. 1039 o A new BGP Path attribute called D-PATH that provides loop 1040 protection and visibility on the domains a particular route has 1041 traversed. 1043 o The way Path attributes should be propagated between EVPN and 1044 another ISF SAFI. 1046 o The procedures that must be followed on Interworking PEs that 1047 behave as composite PEs, gateway PEs or a combination of both. 1049 The above procedures provide an operator with the required tools to 1050 build large tenant networks that may span multiple domains, use 1051 different ISF SAFIs to handle IP prefixes, in a deterministic way and 1052 with routing loop protection. 1054 11. Security Considerations 1056 In general, the security considerations described in 1057 [I-D.ietf-bess-evpn-prefix-advertisement] and [RFC4364] apply to this 1058 document. 1060 Section 4 introduces the use of the D-PATH attribute, which provides 1061 a security tool against control plane loops that may be introduced by 1062 the use of gateway PEs that export ISF routes between domains. A 1063 correct use of the D-PATH will prevent control plane and data plane 1064 loops in the network, however an incorrect configuration of the 1065 DOMAIN-IDs on the gateway PEs may lead to the detection of false 1066 route loops and the blackholing of the traffic. An attacker may 1067 benefit of this transitive attribute to propagate the wrong domain 1068 information across multiple domains. 1070 In addition, Section 5.2 introduces the propagation of attributes 1071 between ISF SAFIs on gateway PEs. Without this mode of propagation, 1072 Path Attributes are re-initialized when re-exporting ISF routes into 1073 a different ISF SAFI, however this mode introduces the capability of 1074 propagating Path Attributes beyond the ISF SAFI scope. While this is 1075 a useful tool to provide end to end visibility across multiple 1076 domains, it can also be used by an attacker to propagate wrong 1077 (although correctly formed) Path Attributes that can influence the 1078 BGP path selection in remote domains. 1080 12. IANA Considerations 1082 This document defines a new BGP path attribute known as the BGP 1083 Domain Path (D-PATH) attribute. 1085 IANA has assigned a new attribute code type from the "BGP Path 1086 Attributes" subregistry under the "Border Gateway Protocol (BGP) 1087 Parameters" registry: 1089 Path Attribute Value Code Reference 1090 -------------------- ------------------------ --------------- 1091 36 BGP Domain Path (D-PATH) [This document] 1093 13. Acknowledgments 1095 The authors want to thank Russell Kelly, Dhananjaya Rao, Suresh 1096 Basavarajappa, Mallika Gautam, Senthil Sathappan, Arul Mohan Jovel, 1097 Naveen Tubugere and Mathanraj Petchimuthu for their review and 1098 suggestions. 1100 14. Contributors 1102 15. References 1104 15.1. Normative References 1106 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1107 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1108 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1109 2015, . 1111 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1112 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1113 DOI 10.17487/RFC4271, January 2006, 1114 . 1116 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1117 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1118 2006, . 1120 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1121 Requirement Levels", BCP 14, RFC 2119, 1122 DOI 10.17487/RFC2119, March 1997, 1123 . 1125 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1126 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1127 May 2017, . 1129 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1130 Patel, "Revised Error Handling for BGP UPDATE Messages", 1131 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1132 . 1134 [I-D.ietf-bess-evpn-prefix-advertisement] 1135 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 1136 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 1137 bess-evpn-prefix-advertisement-11 (work in progress), May 1138 2018. 1140 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 1141 Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 1142 Rabadan, "Integrated Routing and Bridging in EVPN", draft- 1143 ietf-bess-evpn-inter-subnet-forwarding-11 (work in 1144 progress), October 2020. 1146 15.2. Informative References 1148 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1149 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1150 February 2006, . 1152 [I-D.ietf-idr-tunnel-encaps] 1153 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 1154 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 1155 encaps-20 (work in progress), November 2020. 1157 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using 1158 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, 1159 DOI 10.17487/RFC6472, December 2011, 1160 . 1162 Authors' Addresses 1164 J. Rabadan (editor) 1165 Nokia 1166 777 Middlefield Road 1167 Mountain View, CA 94043 1168 USA 1170 Email: jorge.rabadan@nokia.com 1171 A. Sajassi (editor) 1172 Cisco 1173 225 West Tasman Drive 1174 San Jose, CA 95134 1175 USA 1177 Email: sajassi@cisco.com 1179 E. Rosen 1180 Individual 1182 Email: erosen52@gmail.com 1184 J. Drake 1185 Juniper 1187 Email: jdrake@juniper.net 1189 W. Lin 1190 Juniper 1192 Email: wlin@juniper.net 1194 J. Uttaro 1195 AT&T 1197 Email: ju1738@att.com 1199 A. Simpson 1200 Nokia 1202 Email: adam.1.simpson@nokia.com