Network Working Group S. Zhuang Internet-Draft W. Hao Intended status: Standards Track Z. Li Expires: April 21, 2016 Huawei Technologies October 19, 2015 Using BGP between PE and CE in EVPN draft-zhuang-bess-evpn-pe-ce-00 Abstract This document identifies the possible applications which can benefit from MAC learning through the control plane between PEs and CEs. Then this document specifies protocols and procedures of using BGP as PE-CE control protocol for carrying customer MAC routing information. Requirements Language 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]. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 21, 2016. Copyright Notice Copyright (c) 2015 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 Zhuang, et al. Expires April 21, 2016 [Page 1] Internet-Draft Using BGP between PE & CE in EVPN October 2015 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. DCI Traffic Optimization . . . . . . . . . . . . . . . . 3 3.2. Inter-AS EVPN Option-A Solution . . . . . . . . . . . . . 4 3.3. Fast Convergence . . . . . . . . . . . . . . . . . . . . 4 4. BGP EVPN NLRI Extensions . . . . . . . . . . . . . . . . . . 6 5. Exchanging C-MAC Routes . . . . . . . . . . . . . . . . . . . 6 5.1. Originating MAC Route at the CE router . . . . . . . . . 6 5.2. Receiving a MAC Route by the PE router . . . . . . . . . 8 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. References . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction [RFC7432] describes protocols and procedures for BGP MPLS based Ethernet VPNs. BGP is used for MAC learning by exchanging customer MAC routing information between PEs in the control plane instead of MAC learning between PEs in the data plane. It also states that MAC learning between PEs and CEs MAY be done in the control plane, but it does not define the detailed protocols and procedures. This document identifies the possible applications which can benefit from MAC learning through the control plane between PEs and CEs. Then this document specifies protocols and procedures of using BGP as PE-CE control protocol for carrying customer MAC routing information. 2. Terminology This document uses terminology described in [RFC7432]. Zhuang, et al. Expires April 21, 2016 [Page 2] Internet-Draft Using BGP between PE & CE in EVPN October 2015 3. Applications 3.1. DCI Traffic Optimization Figure 1 describes the Data Center Interconnect (DCI) solution when the GW and WAN PE functions are implemented in different systems. +----------+ |Controller| +----------+ | +------+------+ +---------+ | | +---------+ +----+ | +---+ +----+ +----+ +---+ | +----+ |NVE1|--| | | |WAN | |WAN | | | |--|NVE3| +----+ | |GW1|----|PE1 | |PE3 |----|GW3| | +----+ | +---+\ /+----+ +----+\ /+---+ | | NVO-1 | \/ | WAN | \/ | NVO-2 | | +---+ /\ +----+ +----+ /\ +---+ | | | |/ \|WAN | |WAN |/ \| | | +----+ | |GW2|----|PE2 | |PE4 |----|GW4| | +----+ |NVE2|--| +---+ +----+ +----+ +---+ |--|NVE4| +----+ +---------+ | | +---------+ +----+ +--------------+ Figure 1 DCI Traffic Optimization In the reference model depicted by Figure 1, all WAN PE routers run BGP and are connected by a Controller. For each GW, it multihoming connects to the WAN PEs, in this scenario, GW acts as an EVPN CE and WAN PE acts as an EVPN PE. 1. Requirements of outbound traffic control: Outbound traffic control adjusts the transmission paths of outbound traffic from the WAN network to ensure that the traffic is evenly shared among PEs/links between WAN PEs and NVO networks and the bandwidth usage of each PE/link is below the specified threshold. In outbound traffic control scenario, if the bandwidth usage of a link exceeds the specified threshold, the Controller automatically identifies which traffic needs to be scheduled and the Controller automatically calculates traffic control paths based on network topology and traffic information. For such requirements, if the MAC routing learning between PEs and CEs or can be done through the control plane, Controller can control the multiple paths to the same destination which are receiving from Zhuang, et al. Expires April 21, 2016 [Page 3] Internet-Draft Using BGP between PE & CE in EVPN October 2015 different GWs and decide which MAC route to be used for outbound traffic. 2. Requirements of Inbound traffic control: Inbound traffic control adjusts the transmission paths of traffic bound for the WAN network to ensure that the traffic is evenly shared among PEs/links between GWs and WAN PEs and the bandwidth usage of each PE/link is below the specified threshold. For such requirements, if the MAC routing learning between PEs and CEs or can be done through the control plane, the controller can control the path attributes of the EVPN MAC route that is advertised to the different GWs and steer the inbound traffic. 3.2. Inter-AS EVPN Option-A Solution Currently, a typical connection mechanism between two EVPN networks can be similar to Inter-AS Option-A of [RFC4364]. In Option-A Inter- AS solution, peering ASBRs are connected by multiple sub-interfaces, each ASBR acts as a PE, and thinks that the other ASBR is a CE. For tradition L3VPN, Inter-AS Option-A has been widely deployed and MP- BGP is always adopted between ASBRs to learn IP routes. If the EVPN is introduced, there will be propose the inconsistency that IP route can be learned through the control plane while the MAC route will be learned through the forwarding plane. This will propose the challenge caused by the complex the operation and management. So in Inter-AS EVPN Option-A solution, using BGP between ASBRs, the operators can get following benefits: 1. Learning of MAC Addresses can be controlled via Peer-Based Policy between ASBRs. 2. Unified Control-Plane for MAC routing information. 3.3. Fast Convergence The following illustrates the benefits with an example of fast convergence in the event of PE to CE network failure. [RFC7432] defines a mechanism to efficiently and quickly signal, to remote PE nodes, the need to update their forwarding tables upon the occurrence of a failure in connectivity to an Ethernet Segment. This mechanism optimizes the withdrawal of MAC Advertisement routes, and then optimizes the network convergence time in the event of PE to CE failures. But it still cannot fully provide convergence time that is independent of the number of MAC addresses learned by the PE. There exist a situation where the network convergence time is dependent on Zhuang, et al. Expires April 21, 2016 [Page 4] Internet-Draft Using BGP between PE & CE in EVPN October 2015 the local MAC learning of PE and the advertisement of them to remote PE. +--------------+ | | +----+ | | | | | | M1 ES1/| PE1|-| IP/MPLS | +----+ M2 +----+ / | | | Network | | | +----+ | |/ +----+ | |-| PE3|---| CE2| | CE1|\ +----+ | | | | +----+ +----+ \ | | | | +----+ \| PE2|-| | | | | | +----+ +--------------+ Figure 2 Multi-homed EVPN Network To illustrate this with an example in the Figure 2, consider two PEs (PE1 and PE2) connected to a multi-homed Ethernet Segment ES1. All- Active redundancy mode is assumed. A given MAC address M1 is learned by PE1 but not PE2. On PE3, the following states may arise: o T1- PE3 receives the Ethernet A-D routes per ESI from PE1 and PE2. o T2- When the MAC Advertisement Route from PE1 and the Ethernet A-D routes per ESI from PE1 and PE2 are received, PE3 can forward traffic destined to M1 to both PE1 and PE2. o T3- After T2, when the ES1 connected to PE1 fails, PE1 MUST withdraw its Ethernet A-D route per ESI, then PE3 forwards traffic destined to M1 to PE2 only. o T4- After T3, PE1 MUST also withdraw the MAC advertisement routes (M1) that are impacted by the failure. Before PE2 learns M1 and advertises a MAC route for M1, PE3 will treat traffic to M1 as unknown unicast. If the behavior is to drop the unknown unicast based on administrative policy, the traffic to M1 on PE3 will be interrupted. Note that had PE2 also advertised a MAC route for M1 before PE1 withdraws its MAC route, then PE3 would have continued forwarding traffic destined to M1. In the above example, once the local MAC learning of PE was done via control plane, both PE1 and PE2 will advertise a MAC Advertisement route for M1, then PE3 could continue forwarding traffic destined to M1 in the event of ES1 connected to PE1 or PE2 fails. In this case, the network convergence time is not dependent of the local MAC learning and advertisement of MAC addresses learned by the PE any more. Zhuang, et al. Expires April 21, 2016 [Page 5] Internet-Draft Using BGP between PE & CE in EVPN October 2015 The benefit can also be achieved in case of single-active redundancy mode. 4. BGP EVPN NLRI Extensions A new route type is defined for EVPN NLRI to advertise customer MAC route between PE and CE in EVPN: + 6 - Customer MAC Advertisement route A customer MAC Advertisement route type specific EVPN NLRI consists of the following: +-----------------------------------------+ | Ethernet Segment Identifier (10 octets) | +-----------------------------------------+ | Ethernet Tag ID (4 octets) | +-----------------------------------------+ | MAC Address Length (1 octet) | +-----------------------------------------+ | MAC Address (6 octets) | +-----------------------------------------+ | IP Address Length (1 octet) | +-----------------------------------------+ | IP Address (4 or 16 octets) | +-----------------------------------------+ It should be noted that the Route Distinguisher (RD) is not used since the customer MAC routes are always exchanged in the context of unawareness of Ethernet VPN. Another solution option is to reuse EVPN MAC Advertisement Route defined in [RFC7432] to exchange MAC route information between CE and PE. In this case RD, MPLS Label1 and MPLS Label2 fields SHOULD be set as 0. In addition, the RT for the route SHOULD also be set as 0. 5. Exchanging C-MAC Routes This section describes the procedures of exchanging customer MAC routes between PE and CE. This document assumes that a CE and a PE exchange MAC routes over a direct BGP session. 5.1. Originating MAC Route at the CE router When a CE receives packets in a given VLAN from interfaces, other than interfaces connected to the PE, it learns MAC addresses in the data plane. If the given VLAN is in the setting of VLANs across the Ethernet links attached to a given PE, the CE MAY advertises the MAC Zhuang, et al. Expires April 21, 2016 [Page 6] Internet-Draft Using BGP between PE & CE in EVPN October 2015 addresses it learns in the data plane to the given PE, using MP-BGP and the specific MAC Route, in the control plane. The MAC Route is constructed as follows: + The field of the Ethernet Segment Identifier is reserved for future use. + The Ethernet Tag ID is set to the VLAN ID from which the MAC addresses are learned. + The MAC address length field is in bits and it is typically set to 48. However this specification enables specifying the MAC address as a prefix; in which case, the MAC address length field is set to the length of the prefix. This provides the ability to aggregate MAC addresses if the deployment environment supports that. + The MAC address is set to the value of MAC address the CE learned. The encoding of a MAC address MUST be the 6-octet MAC address specified by [802.1D-ORIG] [802.1D-REV]. If the MAC address is advertised as a prefix then the trailing bits of the prefix MUST be set to 0 to ensure that the entire prefix is encoded as 6 octets. + The IP Address field is optional. By default, the IP Address Length field is set to 0 and the IP Address field is omitted from the route. When a valid IP address or address prefix needs to be advertised (e.g., for ARP suppression purposes or for inter-subnet switching), it is then encoded in this route. In this case, the IP Address Length field is in bits and it is the length of the IP prefix. This provides the ability to advertise IP address prefixes when the deployment environment supports that. + The encoding of an IP Address MUST be either 4 octets for IPv4 or 16 octets for IPv6. When the IP Address is advertised as a prefix, then the trailing bits of the prefix MUST be set to 0 to ensure that the entire prefix is encoded as either 4 or 16 octets. The length field of Ethernet NLRI is sufficient to determine whether an IP address/prefix is encoded in this route and if so, whether the encoded IP address/prefix is IPv4 or IPv6. + The Next Hop field of the MP_REACH_NLRI attribute of the route MUST be set to the IPv4 or IPv6 address of the advertising CE. It should be noted that the BGP advertisement for the MAC route does not need to carry the Route Target (RT) attributes because of its unawareness of Ethernet VPN. Zhuang, et al. Expires April 21, 2016 [Page 7] Internet-Draft Using BGP between PE & CE in EVPN October 2015 5.2. Receiving a MAC Route by the PE router When a PE receives a MAC route from a CE, it learns the MAC addresses advertised in the MAC route in the control plane and associates the MAC addresses with the Ethernet Segment from which it can reach to the advertising CE and the VLAN carried in the MAC route. The PE SHOULD install forwarding state for the associated MAC addresses based on the Ethernet Segment and VLAN inferred from the MAC route. In addition, the PE SHOULD advertises the MAC addresses it learns from CE in the control plane, to all the other PEs in the associated EVPN instance, using MP-BGP and the MAC Advertisement route defined in [RFC7432]. For example, the PE learns a MAC address M1 on a multi-homed Ethernet Segment (ES1) and on a VLAN 10, and the VLAN 10 is bundled to EVPN A. The PE SHOULD advertise the MAC address M1 to all the other PEs in EVPN A. The construction of the MAC Advertisement route and procedures of handling the MAC Advertisement route on receiving it are specified in [RFC7432]. 6. Contributors The following people have substantially contributed to the solution and to the editing of this document: Junlin Zhang Huawei Email: jackey.zhang@huawei.com 7. IANA Considerations This document requires IANA to assign a new route type value for EVPN NLRI. 8. Security Considerations There are no additional security aspects beyond those of EVPN ([RFC7432]). 9. References Zhuang, et al. Expires April 21, 2016 [Page 8] Internet-Draft Using BGP between PE & CE in EVPN October 2015 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . 9.2. References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . Authors' Addresses Shunwan Zhuang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Weiguo Hao Huawei Technologies 101 Software Avenue, Nanjing 210012 China Email: haoweiguo@huawei.com Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Zhuang, et al. Expires April 21, 2016 [Page 9]