BESS Workgroup J. Rabadan, Ed. Internet Draft A. Simpson, Ed. Intended status: Standards Track Nokia J. Uttaro AT&T Expires: September 14, 2017 March 13, 2017 EVPN Path Attribute Propagation draft-rs-bess-evpn-attr-prop-00 Abstract EVPN is being actively used to provide tenant inter-subnet-forwarding in DC networks, as described in [IP-PREFIX] and [INTER-SUBNET]. When those tenant networks are interconnected to vpn-ipv4/vpn-ipv6 or ipv4/ipv6 BGP networks, there is a need for the EVPN BGP Path Attributes to be seamlessly propagated so that the receiver PE or NVE can consider the original EVPN Attributes in its path calculations. This document analyses the use-cases, requirements and rules based on which the BGP Path Attributes should be propagated between EVPN and other BGP families. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Rabadan, Simpson et al.Expires September 14, 2017 [Page 1] Internet-Draft EVPN Path Attribute Propagation March 13, 2017 This Internet-Draft will expire on September 14, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 2 2. EVPN Path Attribute Propagation Use Cases . . . . . . . . . . . 3 2.1 DCI using a Different Administrative Domain . . . . . . . . 3 2.2 DCI within the Same Administrative Domain . . . . . . . . . 4 2.3 DCI using a Public IP Network . . . . . . . . . . . . . . . 5 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . . 6 4. Solution Description . . . . . . . . . . . . . . . . . . . . . 6 4.1 EVPN Path Attribute No-Propagation-Mode . . . . . . . . . . 6 4.2 EVPN Path Attribute Propagation Tunnel-Mode . . . . . . . . 7 4.3 EVPN Path Attribute Propagation Uniform-Mode . . . . . . . . 8 4.4 Path Selection across EVPN and IP-VPN . . . . . . . . . . . 9 5. Deployment Examples . . . . . . . . . . . . . . . . . . . . . . 9 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Conventions used in this document . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 9. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 9.2 Informative References . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 1. Problem Statement Rabadan, Simpson et al.Expires September 14, 2017 [Page 2] Internet-Draft EVPN Path Attribute Propagation March 13, 2017 EVPN is being actively used to provide tenant inter-subnet-forwarding in DC networks, as described in [IP-PREFIX] and [INTER-SUBNET]. When those tenant networks are interconnected to vpn-ipv4/vpn-ipv6 or ipv4/ipv6 BGP networks, there is a need for the EVPN BGP Path Attributes to be seamlessly propagated so that the receiver PE or NVE can consider the original EVPN Attributes in its path calculations. This document analyses the use-cases, requirements and rules based on which the BGP Path Attribute propagation should be propagated between EVPN and other BGP families. EVPN supports the advertisement of ipv4 or ipv6 prefixes in two different route types: o Route Type 2 - MAC/IP route (only for /32 and /128 host routes), as described by [INTER-SUBNET]. o Route Type 5 - IP Prefix route, as described by [IP-PREFIX]. This proposal describes how the BGP Path Attributes sent along those routes should be propagated to other BGP families being used to advertise tenant IP-Prefixes, such as VPN-IPv4 (AFI/SAFI 1/128), VPN- IPv6 (AFI/SAFI 2/128), IPv4 (AFI/SAFI 1/1) or IPv6 (AFI/SAFI 2/1). 2. EVPN Path Attribute Propagation Use Cases The following Data Center Interconnect (DCI) use-cases have been identified and will be used as a reference in this document. 2.1 DCI using a Different Administrative Domain The assumption in this use-case is that Data Centers (DCs) are connected to other DCs by provider networks that are managed by different administrative entities. While EVPN is used within the DCs to exchange IP Prefixes, the provider interconnect network uses IP- VPN to exchange IP reachability. DC Gateway pairs DGW1 and DGW2 provide a Boundary Router (BR) function between the EVPN and IP-VPN families. As an example, let's assume NVE1 and NVE2 both advertise an "anycast" prefix A/32. NVE1 uses a Route Type 2 (RT2) or MAC/IP route to encode the A/32 prefix, while NVE1 uses a Route Type 5 (RT5) or IP-Prefix route to encode A/32. DGW1 routers import the routes into the IP-VRF routing table and re-advertise them to the IP-VPN network using a different RD, probably different route-target and their own Next-Hop. DGW2 routers do the opposite translation and re-advertise the host routes using EVPN RT5s. NVE4 uses a PE-CE eBGP session to advertise the host routes to the CE. Rabadan, Simpson et al.Expires September 14, 2017 [Page 3] Internet-Draft EVPN Path Attribute Propagation March 13, 2017 While NVEs at DC1 and DC2 set the proper Path Attributes, for example LOCAL_PREFERENCE and Communities 'red' and 'blue', so that NVEs within the DCs can make the right path selection, those Path Attributes are lost when the routes are re-generated at the Boundary Routers (BRs). When the EVPN routes arrive at NVE3 or CE, the path selection cannot be influenced as intended by the NVEs that originated the routes. A set of procedures is needed so that the IP- VPN provider network tunnels all the relevant original EVPN Path Attributes transparently up to the destination EVPN DC. RT5 A/32 Comm:red ----LP200-----> RT5 A/32 VPN A/32-----> LP100---> NVE1----DC1------+ NVE3 +-----+ | +-----+ TS1--| VRF | EVPN | +--------------+ +--DC3---| VRF |-TS3 A/32 +-----+ DGW1| DGW2| +-+---+ | +-----+ IPVPN +-----+ EVPN | +-------------| VRF | | VRF | | | |-+ | |-+ NVE4 +-----+ | +-----+ | +-----+ +---DC2-----| | | |------| VRF | NVE2 +-----+ +-----+ +-----+ +-----+ EVPN | | | RT5 A/32 ^ TS2--| VRF |--------+ +--------------+ LP100---> |eBGP A/32 +-----+ v ----RT2-A/32--> VPN A/32------> +--+ Comm:blue |CE|-TS4 LP500 +--+ Figure 1 DCI using a Different Administrative Domain 2.2 DCI within the Same Administrative Domain Use-case 2.1 assumed that EVPN DCs were connected using an IP-VPN provider network and there was a need to "tunnel" the original EVPN Path Attributes through the provider IP-VPN network up to the destination EVPN DC. In this section, the entire network is managed by the same entity. The destination PE2 in Figure 2 will receive the two host routes using VPN-IPv4 family directly, even though the routes were originated in the EVPN family. Multiple models may exist for defining the over-arching VPN solution Rabadan, Simpson et al.Expires September 14, 2017 [Page 4] Internet-Draft EVPN Path Attribute Propagation March 13, 2017 defined by this family interaction: a) In some cases, the BRs (Boundary Routers) need to re-originate the two host routes with the original EVPN Path Attributes (LOCAL_PREFERENCE and Communities in Figure 2) so that they are not lost for PE2's path calculations. b) In some other cases, the EVPN domains are considered abstracted "CEs" for the IP-VPN network and the BRs just need to reinitialize the Path Attributes so that PE2 does not take the original EVPN Path Attribute into consideration for path calculations. RT5 A/32 Comm:red ----LP200-----> NVE1----DC1------+ +-----+ | VPN A/32---> TS1--| VRF | EVPN | +-------------+ +--+ A/32 +-----+ DGW1| |PE2 |CE| | +-----+ IPVPN +-----+ +--+ +-------------| VRF | | VRF |--+ | |-+ +-----+ +-----+ | | ----DC2-----| | VPN A/32---> NVE2 +-----+ | +-----+ EVPN | | | TS2--| VRF |--------+ +-------------+ A/32 +-----+ ----RT2 A/32--> Comm:blue LP500 Figure 2 DCI within the Same Administrative Domain The solution must support both models. 2.3 DCI using a Public IP Network Figure 3 depicts a use-case similar to the one described in section 2.2, however the subnet RT5 is converted to an IPv4 route that gets propagated by BGP throughout a Public Network. As in the previous sections, when the route arrives at the CE router, the originating EVPN Path Attributes are lost. While this may be the desired situation in some cases, in some other cases there is a need to propagate the original EVPN Path Attributes all the way up to the CE router. Rabadan, Simpson et al.Expires September 14, 2017 [Page 5] Internet-Draft EVPN Path Attribute Propagation March 13, 2017 RT5 B/24 Public IP ---Comm:red---> Network +-----------+ NVE1----DC1-----DGW1 | | eBGP +-----+ +-----+ +-+--+ +--+-+ +--+ TS1+-+ VRF | EVPN | VRF +-----+ASBR| |ASBR+-----+CE| B/24 +---+-+ | | +-+--+ +--+-+ +--+ | +-----+ eBGP | | +---------------+ +-----------+ -------> ----------> -----> B/24 B/24 B/24 Figure 3 DCI using a Public IP Network 3. Solution Requirements The following requirements have been identified for the Propagation of EVPN Path Attributes: o The EVPN Path Attribute Propagation solution MUST allow the propagation of path attributes among EVPN (SAFI 70), VPN (SAFI 128) and IP (SAFI 1) families, for IPv4 and IPv6 routes (AFIs 1 and 2). o The solution SHOULD allow the tunneling of the set of relevant Path Attributes between two BRs of the same family that are connected by another family. Figure 1 provides an example. o The solution SHOULD allow the propagation of certain key attributes (that are commonly used) between two different families. Figure 2 and 3 show two examples of cases where EVPN Path Attributes should keep accumulating or mapped rather than being tunneled. 4. Solution Description This document proposes three Path Attribute Propagation Modes that satisfy the use-cases and requirements described in sections 2 and 3: No-Propagation-Mode, Tunnel-Mode and Uniform-Mode. In the following sections, the term "BR" or "Boundary Router" refers to the PE router that supports more than one SAFI to manage IP-prefixes in the same IP-VRF and is responsible for the Path Attribute Propagation across families. 4.1 EVPN Path Attribute No-Propagation-Mode This is the default mode of operation. In this mode, the BR will Rabadan, Simpson et al.Expires September 14, 2017 [Page 6] Internet-Draft EVPN Path Attribute Propagation March 13, 2017 simply re-initialize the Path Attributes when re-advertising a route to a different SAFI, as though it would for direct or local IP- Prefixes. This model will meet the requirements in those use-cases where the EVPN domain is considered an "abstracted" CE and remote IP- VPN/IP PEs don't need to consider the original EVPN Attributes for path calculations. 4.2 EVPN Path Attribute Propagation Tunnel-Mode In this mode, the Path Attributes are "tunneled" between an ingress and an egress BR. The ingress BR tunnels a set of path attributes for a given family across a provider network that uses a different family. It is typically used for DCs interconnected thru a different administrative domain, as in section 2.1. The ATT_SET path attribute (defined in RFC6368) is used for this Path Attribute Propagation Tunnel-Mode as follows: +---------------------------------------+ | Attr Flags (O|T) Code =128 | +---------------------------------------+ | Attr. Length (1 or 2 octets) | +---------------------------------------+ | Origin AS (4 octets) | +---------------------------------------+ | Path Attributes (variable) | +---------------------------------------+ Figure 4 ATT_SET path attribute used for Tunnel-Mode The following rules MUST be observed: o These are the Path Attributes that MUST NOT be inserted in the ATT_SET by the ingress BR: - MP_REACH_NLRI - MP_UNREACH_NLRI - NEXT_HOP - PTA (PMSI Tunnel Attribute) - RFC5512 BGP Encapsulation extended community - Tunnel Encapsulation Attribute - EVPN-type (0x6) Extended Communities o ATT_SET insertion rules at ingress BR: - IP Prefix routes (RT5 and RT2) learned by the ingress BR on the IP-VRF are imported and re-exported as a different AFI/SAFI with the ATT_SET added. Rabadan, Simpson et al.Expires September 14, 2017 [Page 7] Internet-Draft EVPN Path Attribute Propagation March 13, 2017 - The ATT_SET contains an exact copy of all received path attributes except for those that must not be propagated (see bullet above). - The Origin AS in the attribute encodes the ASN of the exporting VRF. - Once the ATTR_SET attribute is added to the route, the other path attributes are re-initialized to the basic values that would apply to an exported local/direct IP-VRF route (that is, a route without BGP attributes). - Note that, compared to RFC6368, in this document ingress BR's IP- VRF does not need IBGP to the CE/NVE. EBGP is possible too. And also, the main focus of this document is EVPN to other families. o ATT_SET extraction rules at the egress BR: - The egress BR receiving the ATT_SET, imports the IP-Prefix routes into the IP-VRF, based on the IP-VRF import policies. Different RDs are expected for same routes received from different Next- Hops. - The Path Attributes in ATT_SET replace the Path Attributes of the received route at the import process (so that the BGP decision process of each IP-VRF considers the original Path Attributes). - The route, that is re-constructed from ATT_SET, is advertised to the BGP peers of the importing IP-VRF as per [RFC6368]: + If the peer is IBGP-based and ATT_SET's Origin AS matches the configured IP-VRF's AS, then the route is advertised "as-is" with Next-Hop-Self (and the original Path Attributes). + If the peer is IBGP-based and ATT_SET's Origin AS is different than the configured IP-VRF's AS, then the IBGP-specific Path Attributes are removed, and the ATT_SET Origin AS is prepended to the AS_PATH. + If the peer is EBGP-based, then the IBGP-specific Path Attributes are removed and the new AS_PATH will be composed of (ATT_SET Origin AS + received AS_PATH + configured IP-VRF's AS). 4.3 EVPN Path Attribute Propagation Uniform-Mode In this mode, the BR simply keeps accumulating or mapping certain key Rabadan, Simpson et al.Expires September 14, 2017 [Page 8] Internet-Draft EVPN Path Attribute Propagation March 13, 2017 commonly used Path Attributes when re-advertising routes to a different family. This mode is typically used for DCs interconnected by the same administrative domain that manages the DCs, as in section 2.2. The following rules MUST be observed by the BR when propagating Path Attributes: o The BR imports the routes in the IP-VRF and stores the original Path Attributes. Only the following set of Path Attributes SHOULD be propagated by the BR: - AS_PATH - IBGP-only Path Attributes: LOCAL_PREF, ORIGINATOR_ID, CLUSTER_ID - Communities, (non-EVPN) Extended Communities and Large Communities o When re-advertising a route to a destination family, the BR MUST copy the AS_PATH of the originating family and prepend the IP-VRF's AS (only for EBGP peers). o When re-advertising a route to IBGP peers, the BR MUST copy the IBGP-only Path Attributes from the originating family to the re- advertised route. o Communities, non-EVPN Extended Communities and Large Communities MUST be copied by the BR from the originating family. Note: the need to include other Path Attributes, such as MED or AIGP, or modify the above behavior will be analyzed in future revisions of this document. 4.4 Path Selection across EVPN and IP-VPN In some cases, an NVE/PE receives the same IP-Prefix from two different families, e.g. EVPN and IP-VPN. This section discusses how the NVE/PE should compare both routes and the rules of selection. NOTE: this section will be completed in a future revision. 5. Deployment Examples This section will be added in the next revision of the document. 6. Conclusions Rabadan, Simpson et al.Expires September 14, 2017 [Page 9] Internet-Draft EVPN Path Attribute Propagation March 13, 2017 This document describes the need to propagate EVPN Path Attributes so that NVE/PEs receiving IP-Prefix routes can select paths based on the Attributes that the advertising NVE/PE originally added to the route. In order to achieve that goal, three EVPN Path Attribute Propagation Modes are discussed: a) No-Propagation-Mode b) Tunnel-Mode c) Uniform-Mode While (a) is the default mode, (b) is required to preserve all the relevant EVPN Path Attributes in use-cases where different Administrative Domains provide connectivity; (c) provides a simple solution to propagate only certain commonly used Path Attributes that are typically used by providers. This solution will help providers have a seamless EVPN integration in existing IP-VPN and IP networks. 6. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC. 7. Security Considerations This section will be added in future versions. 8. IANA Considerations 9. Terminology BR: Boundary Router - refers to the router responsible for the Path Attribute Propagation. RT2: Route Type 2 or MAC/IP route, as per [RFC7432]. RT5: Route Type 5 or IP-Prefix, as per [IP-PREFIX]. Rabadan, Simpson et al.Expires September 14, 2017 [Page 10] Internet-Draft EVPN Path Attribute Propagation March 13, 2017 9. References 9.1 Normative References [RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC6368]Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. Yamagata, "Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 6368, DOI 10.17487/RFC6368, September 2011, . 9.2 Informative References [IP-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN", draft- ietf-bess-evpn-prefix-advertisement-04, February, 2017. [INTER-SUBNET] Sajassi et al., "IP Inter-Subnet Forwarding in EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-03.txt, work in progress, February, 2017 [ENCAP-ATT] Rosen et al., "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-03.txt, work in progress, November, 2016. 10. Acknowledgments 11. Contributors 17. Authors' Addresses Jorge Rabadan Nokia 777 E. Middlefield Road Mountain View, CA 94043 USA Email: jorge.rabadan@nokia.com Rabadan, Simpson et al.Expires September 14, 2017 [Page 11] Internet-Draft EVPN Path Attribute Propagation March 13, 2017 Adam Simpson Nokia Email: adam.1.simpson@nokia.com Jim Uttaro AT&T Email: ju1738@att.com Rabadan, Simpson et al.Expires September 14, 2017 [Page 12]