idnits 2.17.1 draft-rs-bess-evpn-attr-prop-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 3 instances of lines with control characters in the document. ** The abstract seems to contain references ([INTER-SUBNET], [IP-PREFIX]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2598 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) == Missing Reference: 'RFC6368' is mentioned on line 352, but not defined == Missing Reference: 'RFC2119' is mentioned on line 440, but not defined == Missing Reference: 'RFC7432' is mentioned on line 460, but not defined == Unused Reference: 'ENCAP-ATT' is defined on line 487, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bess-evpn-prefix-advertisement-04 == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-03 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-03 Summary: 3 errors (**), 0 flaws (~~), 8 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 A. Simpson, Ed. 4 Intended status: Standards Track Nokia 6 J. Uttaro 7 AT&T 9 Expires: September 14, 2017 March 13, 2017 11 EVPN Path Attribute Propagation 12 draft-rs-bess-evpn-attr-prop-00 14 Abstract 16 EVPN is being actively used to provide tenant inter-subnet-forwarding 17 in DC networks, as described in [IP-PREFIX] and [INTER-SUBNET]. When 18 those tenant networks are interconnected to vpn-ipv4/vpn-ipv6 or 19 ipv4/ipv6 BGP networks, there is a need for the EVPN BGP Path 20 Attributes to be seamlessly propagated so that the receiver PE or NVE 21 can consider the original EVPN Attributes in its path calculations. 22 This document analyses the use-cases, requirements and rules based on 23 which the BGP Path Attributes should be propagated between EVPN and 24 other BGP families. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on September 14, 2017. 48 Copyright Notice 50 Copyright (c) 2017 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 (http://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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. EVPN Path Attribute Propagation Use Cases . . . . . . . . . . . 3 67 2.1 DCI using a Different Administrative Domain . . . . . . . . 3 68 2.2 DCI within the Same Administrative Domain . . . . . . . . . 4 69 2.3 DCI using a Public IP Network . . . . . . . . . . . . . . . 5 70 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . . 6 71 4. Solution Description . . . . . . . . . . . . . . . . . . . . . 6 72 4.1 EVPN Path Attribute No-Propagation-Mode . . . . . . . . . . 6 73 4.2 EVPN Path Attribute Propagation Tunnel-Mode . . . . . . . . 7 74 4.3 EVPN Path Attribute Propagation Uniform-Mode . . . . . . . . 8 75 4.4 Path Selection across EVPN and IP-VPN . . . . . . . . . . . 9 76 5. Deployment Examples . . . . . . . . . . . . . . . . . . . . . . 9 77 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 6. Conventions used in this document . . . . . . . . . . . . . . . 10 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 81 9. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 84 9.2 Informative References . . . . . . . . . . . . . . . . . . . 11 85 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 86 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Problem Statement 90 EVPN is being actively used to provide tenant inter-subnet-forwarding 91 in DC networks, as described in [IP-PREFIX] and [INTER-SUBNET]. When 92 those tenant networks are interconnected to vpn-ipv4/vpn-ipv6 or 93 ipv4/ipv6 BGP networks, there is a need for the EVPN BGP Path 94 Attributes to be seamlessly propagated so that the receiver PE or NVE 95 can consider the original EVPN Attributes in its path calculations. 96 This document analyses the use-cases, requirements and rules based on 97 which the BGP Path Attribute propagation should be propagated between 98 EVPN and other BGP families. 100 EVPN supports the advertisement of ipv4 or ipv6 prefixes in two 101 different route types: 103 o Route Type 2 - MAC/IP route (only for /32 and /128 host routes), as 104 described by [INTER-SUBNET]. 106 o Route Type 5 - IP Prefix route, as described by [IP-PREFIX]. 108 This proposal describes how the BGP Path Attributes sent along those 109 routes should be propagated to other BGP families being used to 110 advertise tenant IP-Prefixes, such as VPN-IPv4 (AFI/SAFI 1/128), VPN- 111 IPv6 (AFI/SAFI 2/128), IPv4 (AFI/SAFI 1/1) or IPv6 (AFI/SAFI 2/1). 113 2. EVPN Path Attribute Propagation Use Cases 115 The following Data Center Interconnect (DCI) use-cases have been 116 identified and will be used as a reference in this document. 118 2.1 DCI using a Different Administrative Domain 120 The assumption in this use-case is that Data Centers (DCs) are 121 connected to other DCs by provider networks that are managed by 122 different administrative entities. While EVPN is used within the DCs 123 to exchange IP Prefixes, the provider interconnect network uses IP- 124 VPN to exchange IP reachability. DC Gateway pairs DGW1 and DGW2 125 provide a Boundary Router (BR) function between the EVPN and IP-VPN 126 families. 128 As an example, let's assume NVE1 and NVE2 both advertise an "anycast" 129 prefix A/32. NVE1 uses a Route Type 2 (RT2) or MAC/IP route to encode 130 the A/32 prefix, while NVE1 uses a Route Type 5 (RT5) or IP-Prefix 131 route to encode A/32. DGW1 routers import the routes into the IP-VRF 132 routing table and re-advertise them to the IP-VPN network using a 133 different RD, probably different route-target and their own Next-Hop. 134 DGW2 routers do the opposite translation and re-advertise the host 135 routes using EVPN RT5s. NVE4 uses a PE-CE eBGP session to advertise 136 the host routes to the CE. 138 While NVEs at DC1 and DC2 set the proper Path Attributes, for example 139 LOCAL_PREFERENCE and Communities 'red' and 'blue', so that NVEs 140 within the DCs can make the right path selection, those Path 141 Attributes are lost when the routes are re-generated at the Boundary 142 Routers (BRs). When the EVPN routes arrive at NVE3 or CE, the path 143 selection cannot be influenced as intended by the NVEs that 144 originated the routes. A set of procedures is needed so that the IP- 145 VPN provider network tunnels all the relevant original EVPN Path 146 Attributes transparently up to the destination EVPN DC. 148 RT5 A/32 149 Comm:red 150 ----LP200-----> RT5 A/32 151 VPN A/32-----> LP100---> 152 NVE1----DC1------+ NVE3 153 +-----+ | +-----+ 154 TS1--| VRF | EVPN | +--------------+ +--DC3---| VRF |-TS3 155 A/32 +-----+ DGW1| DGW2| +-+---+ 156 | +-----+ IPVPN +-----+ EVPN | 157 +-------------| VRF | | VRF | | 158 | |-+ | |-+ NVE4 159 +-----+ | +-----+ | +-----+ 160 +---DC2-----| | | |------| VRF | 161 NVE2 +-----+ +-----+ +-----+ 162 +-----+ EVPN | | | RT5 A/32 ^ 163 TS2--| VRF |--------+ +--------------+ LP100---> |eBGP 164 A/32 +-----+ v 165 ----RT2-A/32--> VPN A/32------> +--+ 166 Comm:blue |CE|-TS4 167 LP500 +--+ 169 Figure 1 DCI using a Different Administrative Domain 171 2.2 DCI within the Same Administrative Domain 173 Use-case 2.1 assumed that EVPN DCs were connected using an IP-VPN 174 provider network and there was a need to "tunnel" the original EVPN 175 Path Attributes through the provider IP-VPN network up to the 176 destination EVPN DC. In this section, the entire network is managed 177 by the same entity. The destination PE2 in Figure 2 will receive the 178 two host routes using VPN-IPv4 family directly, even though the 179 routes were originated in the EVPN family. 181 Multiple models may exist for defining the over-arching VPN solution 182 defined by this family interaction: 184 a) In some cases, the BRs (Boundary Routers) need to re-originate the 185 two host routes with the original EVPN Path Attributes 186 (LOCAL_PREFERENCE and Communities in Figure 2) so that they are 187 not lost for PE2's path calculations. 189 b) In some other cases, the EVPN domains are considered abstracted 190 "CEs" for the IP-VPN network and the BRs just need to reinitialize 191 the Path Attributes so that PE2 does not take the original EVPN 192 Path Attribute into consideration for path calculations. 194 RT5 A/32 195 Comm:red 196 ----LP200-----> 198 NVE1----DC1------+ 199 +-----+ | VPN A/32---> 200 TS1--| VRF | EVPN | +-------------+ +--+ 201 A/32 +-----+ DGW1| |PE2 |CE| 202 | +-----+ IPVPN +-----+ +--+ 203 +-------------| VRF | | VRF |--+ 204 | |-+ +-----+ 205 +-----+ | | 206 ----DC2-----| | VPN A/32---> 207 NVE2 +-----+ | 208 +-----+ EVPN | | | 209 TS2--| VRF |--------+ +-------------+ 210 A/32 +-----+ 211 ----RT2 A/32--> 212 Comm:blue 213 LP500 215 Figure 2 DCI within the Same Administrative Domain 217 The solution must support both models. 219 2.3 DCI using a Public IP Network 221 Figure 3 depicts a use-case similar to the one described in section 222 2.2, however the subnet RT5 is converted to an IPv4 route that gets 223 propagated by BGP throughout a Public Network. As in the previous 224 sections, when the route arrives at the CE router, the originating 225 EVPN Path Attributes are lost. While this may be the desired 226 situation in some cases, in some other cases there is a need to 227 propagate the original EVPN Path Attributes all the way up to the CE 228 router. 230 RT5 B/24 Public IP 231 ---Comm:red---> Network 232 +-----------+ 233 NVE1----DC1-----DGW1 | | eBGP 234 +-----+ +-----+ +-+--+ +--+-+ +--+ 235 TS1+-+ VRF | EVPN | VRF +-----+ASBR| |ASBR+-----+CE| 236 B/24 +---+-+ | | +-+--+ +--+-+ +--+ 237 | +-----+ eBGP | | 238 +---------------+ +-----------+ 240 -------> ----------> -----> 241 B/24 B/24 B/24 243 Figure 3 DCI using a Public IP Network 245 3. Solution Requirements 247 The following requirements have been identified for the Propagation 248 of EVPN Path Attributes: 250 o The EVPN Path Attribute Propagation solution MUST allow the 251 propagation of path attributes among EVPN (SAFI 70), VPN (SAFI 128) 252 and IP (SAFI 1) families, for IPv4 and IPv6 routes (AFIs 1 and 2). 254 o The solution SHOULD allow the tunneling of the set of relevant Path 255 Attributes between two BRs of the same family that are connected by 256 another family. Figure 1 provides an example. 258 o The solution SHOULD allow the propagation of certain key attributes 259 (that are commonly used) between two different families. Figure 2 260 and 3 show two examples of cases where EVPN Path Attributes should 261 keep accumulating or mapped rather than being tunneled. 263 4. Solution Description 265 This document proposes three Path Attribute Propagation Modes that 266 satisfy the use-cases and requirements described in sections 2 and 3: 267 No-Propagation-Mode, Tunnel-Mode and Uniform-Mode. In the following 268 sections, the term "BR" or "Boundary Router" refers to the PE router 269 that supports more than one SAFI to manage IP-prefixes in the same 270 IP-VRF and is responsible for the Path Attribute Propagation across 271 families. 273 4.1 EVPN Path Attribute No-Propagation-Mode 275 This is the default mode of operation. In this mode, the BR will 276 simply re-initialize the Path Attributes when re-advertising a route 277 to a different SAFI, as though it would for direct or local IP- 278 Prefixes. This model will meet the requirements in those use-cases 279 where the EVPN domain is considered an "abstracted" CE and remote IP- 280 VPN/IP PEs don't need to consider the original EVPN Attributes for 281 path calculations. 283 4.2 EVPN Path Attribute Propagation Tunnel-Mode 285 In this mode, the Path Attributes are "tunneled" between an ingress 286 and an egress BR. The ingress BR tunnels a set of path attributes for 287 a given family across a provider network that uses a different 288 family. It is typically used for DCs interconnected thru a different 289 administrative domain, as in section 2.1. 291 The ATT_SET path attribute (defined in RFC6368) is used for this Path 292 Attribute Propagation Tunnel-Mode as follows: 294 +---------------------------------------+ 295 | Attr Flags (O|T) Code =128 | 296 +---------------------------------------+ 297 | Attr. Length (1 or 2 octets) | 298 +---------------------------------------+ 299 | Origin AS (4 octets) | 300 +---------------------------------------+ 301 | Path Attributes (variable) | 302 +---------------------------------------+ 304 Figure 4 ATT_SET path attribute used for Tunnel-Mode 306 The following rules MUST be observed: 308 o These are the Path Attributes that MUST NOT be inserted in the 309 ATT_SET by the ingress BR: 310 - MP_REACH_NLRI 311 - MP_UNREACH_NLRI 312 - NEXT_HOP 313 - PTA (PMSI Tunnel Attribute) 314 - RFC5512 BGP Encapsulation extended community 315 - Tunnel Encapsulation Attribute 316 - EVPN-type (0x6) Extended Communities 318 o ATT_SET insertion rules at ingress BR: 320 - IP Prefix routes (RT5 and RT2) learned by the ingress BR on the 321 IP-VRF are imported and re-exported as a different AFI/SAFI with 322 the ATT_SET added. 324 - The ATT_SET contains an exact copy of all received path 325 attributes except for those that must not be propagated (see 326 bullet above). 328 - The Origin AS in the attribute encodes the ASN of the exporting 329 VRF. 331 - Once the ATTR_SET attribute is added to the route, the other path 332 attributes are re-initialized to the basic values that would 333 apply to an exported local/direct IP-VRF route (that is, a route 334 without BGP attributes). 336 - Note that, compared to RFC6368, in this document ingress BR's IP- 337 VRF does not need IBGP to the CE/NVE. EBGP is possible too. And 338 also, the main focus of this document is EVPN to other families. 340 o ATT_SET extraction rules at the egress BR: 342 - The egress BR receiving the ATT_SET, imports the IP-Prefix routes 343 into the IP-VRF, based on the IP-VRF import policies. Different 344 RDs are expected for same routes received from different Next- 345 Hops. 347 - The Path Attributes in ATT_SET replace the Path Attributes of the 348 received route at the import process (so that the BGP decision 349 process of each IP-VRF considers the original Path Attributes). 351 - The route, that is re-constructed from ATT_SET, is advertised to 352 the BGP peers of the importing IP-VRF as per [RFC6368]: 354 + If the peer is IBGP-based and ATT_SET's Origin AS matches the 355 configured IP-VRF's AS, then the route is advertised "as-is" 356 with Next-Hop-Self (and the original Path Attributes). 358 + If the peer is IBGP-based and ATT_SET's Origin AS is different 359 than the configured IP-VRF's AS, then the IBGP-specific Path 360 Attributes are removed, and the ATT_SET Origin AS is prepended 361 to the AS_PATH. 363 + If the peer is EBGP-based, then the IBGP-specific Path 364 Attributes are removed and the new AS_PATH will be composed of 365 (ATT_SET Origin AS + received AS_PATH + configured IP-VRF's 366 AS). 368 4.3 EVPN Path Attribute Propagation Uniform-Mode 370 In this mode, the BR simply keeps accumulating or mapping certain key 371 commonly used Path Attributes when re-advertising routes to a 372 different family. This mode is typically used for DCs interconnected 373 by the same administrative domain that manages the DCs, as in section 374 2.2. 376 The following rules MUST be observed by the BR when propagating Path 377 Attributes: 379 o The BR imports the routes in the IP-VRF and stores the original 380 Path Attributes. Only the following set of Path Attributes SHOULD 381 be propagated by the BR: 383 - AS_PATH 384 - IBGP-only Path Attributes: LOCAL_PREF, ORIGINATOR_ID, CLUSTER_ID 385 - Communities, (non-EVPN) Extended Communities and Large 386 Communities 388 o When re-advertising a route to a destination family, the BR MUST 389 copy the AS_PATH of the originating family and prepend the IP-VRF's 390 AS (only for EBGP peers). 392 o When re-advertising a route to IBGP peers, the BR MUST copy the 393 IBGP-only Path Attributes from the originating family to the re- 394 advertised route. 396 o Communities, non-EVPN Extended Communities and Large Communities 397 MUST be copied by the BR from the originating family. 399 Note: the need to include other Path Attributes, such as MED or AIGP, 400 or modify the above behavior will be analyzed in future revisions of 401 this document. 403 4.4 Path Selection across EVPN and IP-VPN 405 In some cases, an NVE/PE receives the same IP-Prefix from two 406 different families, e.g. EVPN and IP-VPN. This section discusses how 407 the NVE/PE should compare both routes and the rules of selection. 409 NOTE: this section will be completed in a future revision. 411 5. Deployment Examples 413 This section will be added in the next revision of the document. 415 6. Conclusions 416 This document describes the need to propagate EVPN Path Attributes so 417 that NVE/PEs receiving IP-Prefix routes can select paths based on the 418 Attributes that the advertising NVE/PE originally added to the route. 419 In order to achieve that goal, three EVPN Path Attribute Propagation 420 Modes are discussed: 422 a) No-Propagation-Mode 423 b) Tunnel-Mode 424 c) Uniform-Mode 426 While (a) is the default mode, (b) is required to preserve all the 427 relevant EVPN Path Attributes in use-cases where different 428 Administrative Domains provide connectivity; (c) provides a simple 429 solution to propagate only certain commonly used Path Attributes that 430 are typically used by providers. 432 This solution will help providers have a seamless EVPN integration in 433 existing IP-VPN and IP networks. 435 6. Conventions used in this document 437 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 438 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 439 document are to be interpreted as described in RFC-2119 [RFC2119]. 441 In this document, these words will appear with that interpretation 442 only when in ALL CAPS. Lower case uses of these words are not to be 443 interpreted as carrying RFC-2119 significance. 445 In this document, the characters ">>" preceding an indented line(s) 446 indicates a compliance requirement statement using the key words 447 listed above. This convention aids reviewers in quickly identifying 448 or finding the explicit compliance requirements of this RFC. 450 7. Security Considerations 452 This section will be added in future versions. 454 8. IANA Considerations 456 9. Terminology 458 BR: Boundary Router - refers to the router responsible for the Path 459 Attribute Propagation. 460 RT2: Route Type 2 or MAC/IP route, as per [RFC7432]. 461 RT5: Route Type 5 or IP-Prefix, as per [IP-PREFIX]. 463 9. References 465 9.1 Normative References 467 [RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 468 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 469 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . 472 [RFC6368]Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. 473 Yamagata, "Internal BGP as the Provider/Customer Edge Protocol for 474 BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 6368, DOI 475 10.17487/RFC6368, September 2011, . 478 9.2 Informative References 480 [IP-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN", draft- 481 ietf-bess-evpn-prefix-advertisement-04, February, 2017. 483 [INTER-SUBNET] Sajassi et al., "IP Inter-Subnet Forwarding in EVPN", 484 draft-ietf-bess-evpn-inter-subnet-forwarding-03.txt, work in 485 progress, February, 2017 487 [ENCAP-ATT] Rosen et al., "The BGP Tunnel Encapsulation Attribute", 488 draft-ietf-idr-tunnel-encaps-03.txt, work in progress, November, 489 2016. 491 10. Acknowledgments 493 11. Contributors 495 17. Authors' Addresses 497 Jorge Rabadan 498 Nokia 499 777 E. Middlefield Road 500 Mountain View, CA 94043 USA 501 Email: jorge.rabadan@nokia.com 502 Adam Simpson 503 Nokia 504 Email: adam.1.simpson@nokia.com 506 Jim Uttaro 507 AT&T 508 Email: ju1738@att.com