Network Working Group Z. Li Internet-Draft J. Zhang Intended status: Standards Track Z. Zhuang Expires: January 5, 2015 Huawei Technologies July 04, 2014 Using BGP between PE and CE in EVPN draft-li-l2vpn-evpn-pe-ce-01 Abstract 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 January 5, 2015. Copyright Notice Copyright (c) 2014 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 Li, et al. Expires January 5, 2015 [Page 1] Internet-Draft Using BGP between PE & CE in EVPN July 2014 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. Application Scenarios . . . . . . . . . . . . . . . . . . . . 2 4. BGP EVPN NLRI Extensions . . . . . . . . . . . . . . . . . . 4 5. Exchanging C-MAC Routes . . . . . . . . . . . . . . . . . . . 4 5.1. Originating MAC Route at the CE router . . . . . . . . . 5 5.2. Receiving a MAC Route by the PE router . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction [I-D.ietf-l2vpn-evpn] 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 specifies protocols and procedures of using BGP as PE-CE control protocol for carrying customer MAC routing information. This can provide some benefits such as fast convergence in some situation. 2. Terminology This document uses terminology described in [I-D.ietf-l2vpn-evpn]. 3. Application Scenarios There are some benefits when control plane is introduced between PE and CE in EVPN network. The following illustrates the benefits with an example of fast convergence in the event of PE to CE network failure. [I-D.ietf-l2vpn-evpn] 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 Li, et al. Expires January 5, 2015 [Page 2] Internet-Draft Using BGP between PE & CE in EVPN July 2014 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 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 1 Multi-homed EVPN Network To illustrate this with an example in the Figure 1, 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: T0- PE3 receives the Ethernet A-D routes per ESI from PE1 and PE2. T1- When the MAC Advertisement route from PE1 and the Ethernet A-D routes per EVI from PE1 and PE2 are received, PE3 can forward traffic destined to M1 to both PE1 and PE2. T2- After T1, 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. T3- After T2, PE1 MUST also withdraw the MAC Advertisement routes (M1) that are impacted by the failure. Before PE2 learns M1 and advertises a MAC Advertisement route for M1, PE3 will treat traffic to M1 as unknown unicast. If the behavior is to drop the unknown unicast based on the administrative policy, the traffic to M1 on PE3 will be interrupted. Until PE2 has also advertised a MAC Advertisement 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, Li, et al. Expires January 5, 2015 [Page 3] Internet-Draft Using BGP between PE & CE in EVPN July 2014 the network convergence time is not dependent of the local MAC learning and advertisement of MAC addresses learned by the PE any more. 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 [I-D.ietf-l2vpn-evpn] 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. Li, et al. Expires January 5, 2015 [Page 4] Internet-Draft Using BGP between PE & CE in EVPN July 2014 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 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. Li, et al. Expires January 5, 2015 [Page 5] Internet-Draft Using BGP between PE & CE in EVPN July 2014 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. 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 [I-D.ietf-l2vpn-evpn]. 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 [I-D.ietf-l2vpn-evpn]. 6. IANA Considerations This document requires IANA to assign a new route type value for EVPN NLRI. 7. Security Considerations There are no additional security aspects beyond those of EVPN ([I-D.ietf-l2vpn-evpn]). 8. Normative References [I-D.ietf-l2vpn-evpn] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- evpn-07 (work in progress), May 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Li, et al. Expires January 5, 2015 [Page 6] Internet-Draft Using BGP between PE & CE in EVPN July 2014 Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Junlin Zhang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: jackey.zhang@huawei.com Shunwan Zhuang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Li, et al. Expires January 5, 2015 [Page 7]