Network Working Group Z. Li Internet-Draft L. Yong Intended status: Experimental J. Zhang Expires: January 07, 2014 Huawei Technologies July 06, 2013 Segment-Based EVPN(S-EVPN) draft-li-l2vpn-segment-evpn-00 Abstract This document proposes an enhanced EVPN mechanism, segment-based EVPN (S-EVPN). It satisfies the requirements of PBB-EVPN but does not require PBB implementation on PE. The solution uses a global label for each Ethernet Segment (ES) in an EVPN. It inserts the source ES label into packets at ingress PE and learns C-MAC and source ES label binding at egress PE. The solution makes the implementation easier and closer to EVPN's compared to PBB-EVPN but has the PBB-EVPN benefits. 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 07, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Li, et al. Expires January 07, 2014 [Page 1] Internet-Draft Segment-Based EVPN July 2013 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Challenges of PBB-EVPN Implementation . . . . . . . . . . . . 4 4. Architecture of S-EVPN . . . . . . . . . . . . . . . . . . . 5 4.1. C-MAC Learning . . . . . . . . . . . . . . . . . . . . . 6 4.2. ES Global Label Assignment . . . . . . . . . . . . . . . 7 4.3. Ethernet A-D Route Per EVI . . . . . . . . . . . . . . . 8 4.4. Ethernet A-D Route Per ES . . . . . . . . . . . . . . . . 9 5. Improvement on EVPN . . . . . . . . . . . . . . . . . . . . . 9 5.1. Split Horizon . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Unifying MPLS Forwarding . . . . . . . . . . . . . . . . 10 6. BGP E-VPN NLRI Extensions . . . . . . . . . . . . . . . . . . 10 6.1. ES Global Label Request Extended Community . . . . . . . 11 6.2. ES Global Label Mapping Route . . . . . . . . . . . . . . 11 7. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. ES Global Label Request . . . . . . . . . . . . . . . . . 12 7.2. ES Global Label Allocation . . . . . . . . . . . . . . . 12 8. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 12. Normative References . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction E-VPN [I-D.ietf-l2vpn-evpn] introduces a solution for multipoint L2VPN services. It has multi-homing capability and uses BGP for distributing customer/client MAC address reachability information over the core MPLS/IP network. PBB-EVPN [I-D.ietf-l2vpn-pbb-evpn] integrates PBB and E-VPN to achieves these: 1. reduce the number of MAC advertisement routes in BGP; 2. provide client MAC address mobility; Li, et al. Expires January 07, 2014 [Page 2] Internet-Draft Segment-Based EVPN July 2013 3. confine the scope of C-MAC learning to only active flows; 4. offer per site policies and avoid C-MAC address flushing on topology changes. This document discusses the challenges faced by PBB-EVPN in the implementation and operation. It proposes an enhanced E-VPN mechanism, i.e. segment-based EVPN (S-EVPN), that provides the same benefits as of PBB-EVPN but does not require implementing PBB function on PE. S-EVPN mechanism allocates a global label for each Ethernet Segments in E-VPN, inserts the source ES label into the packet at ingress PE, and learns C-MAC and source ES label binding at egress PE. As a result it is not necessary to determine the source of C-MAC according to the B-MAC encapsulation which is required in PBB-EVPN. S-EVPN has simpler operation and management of EVPN and better encapsulation efficiency of packets compared to PBB-EVPN. In addition, it is easy to enhance the E-VPN to support S-EVPN and S-EVPN can unify the unicast traffic forwarding no matter C-MACs are learned by control plane or data plane. 2. Terminology BEB: Backbone Edge Bridge B-MAC: Backbone MAC Address CE: Customer Edge C-MAC: Customer/Client MAC Address LACP: Link Aggregation Control Protocol P2P: Point to Point PE: Provider Edge PBB: Provider Backbone Bridge E-VPN: Ethernet VPN S-EVPN: Segment-based EVPN ES: Ethernet Segment ESI: Ethernet Segment Identifier EVI: Ethernet VPN Instance Li, et al. Expires January 07, 2014 [Page 3] Internet-Draft Segment-Based EVPN July 2013 3. Challenges of PBB-EVPN Implementation PBB-EVPN has advantages in the following aspects as [I-D.ietf-l2vpn-pbb-evpn]: -- MAC Advertisement Route Scalability -- C-MAC Mobility with MAC Sub-netting -- C-MAC Address Learning and Confinement -- Seamless Interworking with TRILL and 802.1aq Access Networks -- Per Site Policy Support -- Avoiding C-MAC Address Flushing However, there are some challenges to implement PBB-EVPN. 1. Creation and Management B-MAC For PBB-EVPN, the choice of B-MAC address(es) for the PE nodes must be examined carefully as it has implications on the proper operation of multi-homing. These addresses are usually locally administered by the Service Provider which involves a lot of operation and management such as design, configuration and checking. Automating B-MAC Address Assignment can be applied, but for some scenarios the method cannot work and manual provision is inevitable. A more general automated solution can be proposed to reduce manual intervention. 2. Encapsulation Efficiency of PBB-EVPN When PBB encapsulation (shown in the figure 1) is adopted in PBB- EVPN, the B-DA, I-Tag, etc. fields in the encapsulation are useless in PBB-EVPN which reduce the effective payload. +------+------+------+-----+------+-------+------------+-------+ | | |Ether | |Ether | | Customer | | | B-DA | B-SA |Type |B-VID|Type | I-Tag | Ethernet | B-FCS | | | |0x88A8| |0x88E7| | Frame | | +------+------+------+-----+------+-------+------------+-------+ 6 6 2 2 2 4 64-1510 4 Figure 1: PBB Encapsulation In the PBB encapsulation for PBB-EVPN, the source B-MAC is necessary since the egress PE need to learn the correspondence between C-MACs Li, et al. Expires January 07, 2014 [Page 4] Internet-Draft Segment-Based EVPN July 2013 and B-MACs. The destination B-MAC is not necessary since the destination (egress PE) is reachable through the tunnel setup in advance instead of searching routes according to the destination B-MAC. The I-SID is also not necessary any more. PBB divides the Ethernet network into two layers: I-Component and B-Component. In the egress PE, B-Component need identify I-Component through I-SID. For PBB- VPLS, MAC learning is through the data plane which is always to use broadcast or multicast for unknown unicast traffic. In order to indentify different forwarding instance, I-SID must be adopted. For PBB-EVPN, the forwarding instance is constructed through the control plane. That is, the forwarding instance is constructed through the RT matching of EVIs and identified by the label advertised. So I-SID information in PBB encapsulation for PBB-EVPN is no use any more. In addition B-VID in PBB encapsulation is almost never used. In a summary, in the PBB encapsulation for PBB-EVPN, only source B-MAC is indispensable. The encapsulation efficiency can be optimized. 3. Combination of PBB and E-VPN The issues are dealt with by PBB-EVPN through the combination of two distinct technologies: PBB (layer 2 technology) and MPLS technology. In order to reduce the number of BGP MAC advertisement routes in E-VPN, PBB-EVPN can aggregate Customer/Client MAC (C- MAC) addresses via Provider Backbone MAC address (B-MAC). In fact, C-MAC addresses can be aggregated via MPLS label. Thus the issue solved by PBB-VPN can be solved in the method that is based on only MPLS technology. That is, the method is similar as E-VPN which is only based on MPLS technology. In other word, we can enhance E-VPN according to the similar way to gain PBB-EVPN benefits but not implement PBB on PE, which is a clean and simpler solution than PBB-EVPN. 4. Architecture of S-EVPN To implement C-MAC summarization scheme, Segment-based EVPN (S-EVPN) introduces a global label for each Ethernet Segment in an EVPN regardless single homed or multi-homed CE. BGP needs to advertise the global label and Ethernet Segment binding to all PEs. In data plane, ingress PE inserts the source ES label into packets; egress PE learns the C-MAC and source ES label binding upon receiving packets. S-EVPN purely relies on BGP IP/MPLS technology. The encapsulation of S-EVPN is shown in figure 2. The outmost label is the label for MPLS tunnel. The second label is the label which is allocated for Ethernet A-D route per EVI as E-VPN [I-D.ietf-l2vpn-evpn] and can identify a given Li, et al. Expires January 07, 2014 [Page 5] Internet-Draft Segment-Based EVPN July 2013 tuple per EVI or per (where the Ethernet Tag ID is set to 0). The third label is a global label which identify an Ethernet Segment uniquely. The global label allocated for a specific Ethernet Segment will be described in section 4.2. +--------------+---------------+------------------------+---------------+ | Tunnel Label | EVI Label | Source ES Global Label | Payload | +--------------+---------------+------------------------+---------------+ Figure 2: S-EVPN Encapsulation 4.1. C-MAC Learning In S-EVPN, C-MACs can be learned in the data plane to determine which source Ethernet Segment they are from and which EVI they belongs to. The forwarding entry to these learned C-MACs can be installed according to the source ES and EVI information. In S-EVPN, Ingress PE needs to send unknown traffic with source C-MACs to all remote PEs according to the encapsulation as shown in figure 2. When a specific egress PE receives the packet: 1. it can learn the C-MAC and possible VLAN Tag in the payload; 2. it can learns the EVI the C-MAC belongs to according to the EVI label which is allocated by the egress PE; 3. it can learns the Source Ethernet Segment the CMAC belongs to according to the advertised the global label and Ethernet Segment binding in BGP. Then the egress PE needs to install the forwarding entry to the learned C-MAC. The forwarding entry to the C-MAC need two types of information: the reachability information to the ingress PE which the C-MAC belongs to; the identification for the Ethernet Segment of the EVI on the ingress PE through which the packet can send to the C-MAC. 1. Tunnel to the ingress PE: Egress PE determines PE which the Source Ethernet Segment belongs according to the advertised the global label and Ethernet Segment binding in BGP. Then egress PE can determine the tunnel to the ingress PE. 2. Label for the Ethernet Segment of the EVI on the ingress PE: The ingress PE needs to allocate label for the tuple per EVI or per and advertise the corresponding Ethernet A-D Route per EVI to remote PEs. The egress PE can determines the Source Ethernet Segment, the EVI and the possible VLAN Li, et al. Expires January 07, 2014 [Page 6] Internet-Draft Segment-Based EVPN July 2013 which the learned the C-MAC belongs to. Then it can determine the label binded to the tuple per EVI or per which is advertised though the Ethernet A-D Route per EVI by the ingress PE. Besides the two types of forwarding information, when the egress PE sends a specific packet to the learned C-MAC, it needs to determine the Ethernet Segment from which the packet come and encapsulate the global label for the Ethernet Segment firstly in the packet. According to above procedures in S-EVPN, the egress PE can learn C-MACs and install forwarding entries to these C-MACs. 4.2. ES Global Label Assignment In S-EVPN, C-MAC summarization is done per an Ethernet Segment. The global ES label is introduced to identify the Ethernet Segment. The advantages of using global label are: 1. identify the ES globally; 2. leverage existing MPLS label stack implementation; 3. the label can be allocated dynamically to automate provision. +---------------+ | IP/MPLS | | Network | +----+ ES1 +----+ | | +----+ ES2 +----+ | CE1|-----| | | | | |-----| CE2| +----+\ | PE1|\| +---- + |/| PE3| +----+ \ +----+ \____| | / +----+ \ | RR+ |___/| ES1\ +----+ /----| | | \| |/| +-----+ | | PE2| | | +----+ | | +---------------+ Figure 3: S-EVPN Network In order to allocate a global label for an Ethernet Segment, there should be a centralized control point. Route Reflector (RR) of BGP may serve this role and we call this type of RR as RR+. The S-EVPN network is shown in the figure 3. All PEs of S-EVPN connects with RR+. The procedure is as follows: Li, et al. Expires January 07, 2014 [Page 7] Internet-Draft Segment-Based EVPN July 2013 1. Auto-Discovery of Ethernet Segment RR+ can learn Ethernet Segment through the Ethernet A-D route per Ethernet Segment defined by [I-D.ietf-l2vpn-evpn]. Note that, in S-EVPN, every ES must has a unique identifier including the single- homed CEs. That is, ESI 0 cannot denote for a single-homed CE in S-EVPN. The ESI for the single-homed CE must be unique network wide and can be created automatically. The ESI is encoded as a ten octets integer. One way to generate ESI value for a single-homed CE is to use the MAC address of the Ethernet Segment with the low order 4 octets filled by value 0. The ESI value generation for multi-homed CE is specified in EVPN and can be reused in S-EVPN. Through Ethernet A-D route per Ethernet Segment, RR+ can learn all Ethernet Segments on all PEs. 2. ES Global Label Allocation RR+ allocates global labels for the Ethernet Segments discovered and advertises pair to all PEs. The PEs that are members of E-VPN keep track of the global label/Ethernet Segment mappings. The PE nodes perform the following functions: - Learn customer/client MAC addresses (C-MACs) over the attachment circuits in the data- plane, per normal bridge operation. - Learn remote C-MAC to B-MAC bindings in the data-plane from traffic ingress from the core per [802.1ah] bridging operation. - Advertise local B-MAC address reach-ability information in BGP to all other PE nodes in the same set of service instances. Note that every PE has a set of local B-MAC addresses that uniquely identify the device. More on the PE addressing in section 5. - Build a forwarding table from remote BGP advertisements received associating remote B-MAC addresses with remote PE IP addresses and the associated MPLS label(s). 4.3. Ethernet A-D Route Per EVI The procedures defined for Ethernet A-D router per EVI in [I-D.ietf-l2vpn-evpn] will be reused by S-EVPN. In S-EVPN, both single home CE and multi-home CE have a unique ES identification. So for both single-homed CEs and multi-homed CEs, PEs needs to allocate MPLS label for the tuple per EVI or per and advertise corresponding Ethernet A-D routes per EVI. The MPLS label is used to identify a specific ES in an EVI. Li, et al. Expires January 07, 2014 [Page 8] Internet-Draft Segment-Based EVPN July 2013 4.4. Ethernet A-D Route Per ES In S-EVPN, support of Ethernet A-D Route per Ethernet Segment is still MANDATORY. PEs can learn Ethernet Segments through this type of route as E-VPN. In S-EVPN, RR+ which all PEs connect to can also learn Ethernet Segments. When constructing the Ethernet A-D Route per Ethernet Segment, there are following differences from E-VPN: -- The ESI for the single-homed CE in this route must be unique network wide instead of 0. -- The "ESI Label Extended Community" MUST be included in the route and the "Active-Standby" bit in the flags MUST be set accordingly. But the MPLS label in the extended community can be set as 0 (Invalid MPLS label value) since ES global label is introduced in S-EVPN which can substitute ESI label. 5. Improvement on EVPN When S-EVPN process is introduced, the E-VPN process defined by [I-D.ietf-l2vpn-evpn] can also be improved. The improvement includes split horizon, unifying unicast and multicast forwarding. 5.1. Split Horizon ES global label is introduced to identify the Ethernet Segment globally. Thus S-EVPN can fulfill requirements proposed PBB-EVPN. Besides this, the ES global label can also be used for split horizon in EVPN. In order to achieve split horizon function, E-VPN adopts ESI label to encapsulate it in every BUM packet originating from a non-DF PE to identify the Ethernet Segment of origin. ES global label can use for the same purpose since it can identify the Ethernet Segment. Every BUM packet originating from a non-DF PE is encapsulated as the encapsulation which is shown in the figure 2. Since the original ESI label in E-VPN can be substituted by the ES global label, the ESI label in the ESI Label Extended Community can be an invalid label value. For the reason of compatibility, the ESI Label Extended Community can carry a valid ESI label. Both ESI label and ES global label should be used for split horizon no matter which label is encapsulated in the packet. ES global label can also solve the possible issue for split horizon when MP2MP LSP is used to transport BUM traffic. When P2MP LSPs is used, the upstream label assignment mechanism is introduced for split horizon. When PE received the packet, it decapsulates the top MPLS label and forwards the packet using the context label space determined by the top label. If the next label is the ESI label allocated by the ingress PE for a specific Ethernet Segment, the Li, et al. Expires January 07, 2014 [Page 9] Internet-Draft Segment-Based EVPN July 2013 received PE will not forward the packet on the corresponding ES. In the MP2MP LSP scenarios, there are multiple roots and the upstream label allocated for Ethernet Segment maybe the same. So the received PE cannot determine a correct context label space according the top label for the MP2MP LSP. That is, the upstream label assignment mechanism for split horizon introduced in the P2MP LSP scenario can not be reused in the MP2MP LSP. But if the ES global label is used, in the MP2MP LSP scenario the received PE can also determine not to forward the packet on the specific ES which is identified by the ES global label. In one word, no matter ingress replication, P2MP LSP, or MP2MP, S-EVPN provides a unified solution based on the ES global label. It can reduce the complexity of the split horizon mechanism in E-VPN. 5.2. Unifying MPLS Forwarding S-EVPN adopts MPLS forwarding for C-MAC learning. In the control plane, it is just to add one new route type for E-VPN. It is a smooth upgrading of E-VPN and can switch easily between C-MAC learning through control plane and C-MAC learning through data plane. When C-MACs is learned through the control plane, the unicast forwarding uses the label for the MAC route which is shown as follows: +--------------+-----------+---------------+ | Tunnel Label | MAC Label | Payload | +--------------+-----------+---------------+ Figure 4: E-VPN Unicast Forwarding Encapsulation When C-MACs is learned through the data plane, the unicast forwarding uses the EVI label and the Segment global label which is shown in figure 2. In fact even if the C-MAC is learned through the data plane, the data plane can also use following encapsulation. In this case, the label in MAC advertisement route should not be used. From the comparison, we can see that when E-VPN and S-EVPN are introduced, the forwarding encapsulation can be unified no matter which way C-MACs are learned by. +--------------+---------------+------------------------+---------------+ | Tunnel Label | EVI Label | Source ES Global Label | Payload | +--------------+---------------+------------------------+---------------+ Figure 5: Unicast Forwarding Encapsulation without MAC Label 6. BGP E-VPN NLRI Extensions Li, et al. Expires January 07, 2014 [Page 10] Internet-Draft Segment-Based EVPN July 2013 6.1. ES Global Label Request Extended Community ES Global Label Request Extended Community may be advertised along Ethernet A-D route per Ethernet Segment. ES Global Label Request Extended Community can reuse ESI Label Extended Community defined in [I-D.ietf-l2vpn-evpn] which is shown in the following figure: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x06 | Sub-Type=0x01 | Flags (One Octet) |Reserved=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved = 0| ESI Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There defines a new bit of the flag octet as the "Global Label Request" bit. +-+-+-+-+-+-+-+-+ |*|*|*|*|*|2|1|0| +-+-+-+-+-+-+-+-+ Bit0: "Active-Standby" bit Bit1: "Root-Leaf" bit Bit2: "Global Label Request" bit The third low order bit of the flags octet is defined as the "Global Label Request". A value of 0 means there is no global label request for the Ethernet A-D route. A value of 1 means that global label request is associated with the Ethernet A-D route. 6.2. ES Global Label Mapping Route A new route type is defined for E-VPN NLRI to allocate global label for Ethernet Segment: +5 - ES Global Label Mapping Route An ES Global Label Mapping route type specific E-VPN NLRI consists of the following: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ |Ethernet Segment Identifier (10 octets)| +---------------------------------------+ | Ethernet Tag ID (4 octets) | Li, et al. Expires January 07, 2014 [Page 11] Internet-Draft Segment-Based EVPN July 2013 +---------------------------------------+ | MPLS Global Label (3 octets) | +---------------------------------------+ | ....... | +---------------------------------------+ | MPLS Global Label (3 octets) | +---------------------------------------+ 7. Operations 7.1. ES Global Label Request Global label request is only for the Ethernet A-D route per Ethernet Segment. The Ethernet A-D route per Ethernet Segment is constructed as defined by [I-D.ietf-l2vpn-evpn]. The Ethernet Segment Identifier MUST be a unique ten octet entity. Even if the CE is single-homed, the corresponding Ethernet Segment Identifier MUST NOT be the reserved value 0. When request a global label for a specific Ethernet Segment, ES Global Label Request Extended Community MUST be used for the Ethernet A-D route. ES Global Label Request Extended Community of S-EVPN can reuse the ESI Label Extended Community. The "Global Label Request" bit of the flag octet MUST be set as 1 for Global Label Request. According to Section 5 "Improvement on E-VPN", if ES global label is introduced, the original ESI label may not be used. The "root-leaf" bit of the flag octet and the ESI Label value in the ESI Label Extended Community can always be 0 to simplify the process. One or more Route Target(RT) MUST be carried with the Ethernet A-D route. These RTs are the set of RTs associated with all the EVIs to which the Ethernet Segment belongs. Since the Global label is allocated per Ethernet Segment, RTs carried by the Ethernet A-D route will be ignored by the RR+ when allocate global label for the Ethernet Segment specified in the Ethernet A-D routes. The global label per Ethernet Segment is advertised to all PEs. For multi-homed Ethernet Segment, if one EVI on one PE requests label allocation for the Ethernet Segment and the ES Global Label Mapping Route has been advertised corresponding to the Ethernet Segment, other EVIs on other PEs SHOULD NOT send the global label request for the Ethernet Segment again, that is, the "Global Label Request" bit SHOULD set as 0 when advertise Ethernet A-D routes for the Ethernet Segment by these EVIs. 7.2. ES Global Label Allocation Li, et al. Expires January 07, 2014 [Page 12] Internet-Draft Segment-Based EVPN July 2013 When RR+ receives the Ethernet A-D route per Ethernet Segment and the "Global Label Request" bit of the ES Global Label Request Extended Community is set as 1, RR+ MUST allocate global label for the Ethernet Segment and advertise the ES Global Mapping route to all PEs. The ES Global Label Mapping route is constructed as follows: RD, Ethernet Segment Identifier and Ethernet Tag ID values can be directly derived from the corresponding Ethernet A-D route per Ethernet Segment. The MPLS Global Label field carries one or more labels (that corresponds to the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 octets, where the high-order 20 bits contain the label value, and the low order bit contains "Bottom of Stack" (as defined in [MPLS- ENCAPS]). One or more Route Target(RT) MUST be carried with the ES Global Label Mapping route. These RTs can be directly derived from the RTs associated with the corresponding Ethernet A-D route. For multi-homed Ethernet Segment, there maybe multiple global label request for the same Ethernet Segment advertised to RR+ by different PEs. When RR+ receives them, if RTs for these routes are same, owing to the Ethernet Segment Identifier is the same, it SHOULD advertise only one corresponding ES Global Label Mapping Route to all PEs. That is, the subsequent global label request for the same Ethernet Segment SHOULD be ignored. If RTs carried with the Ethernet A-D routes for the Ethernet Segment are different, RR+ SHOULD advertise multiple ES Global Label Mapping Routes with the same global label value and different RTs. 8. Solution Advantages S-EVN has following advantages: 1. Remove the requirement of automating B-MAC address assignment to simplify provision of PBB-EVPN. 2. Improve the encapsulation efficiency of PBB-EVPN. 3. Seamless MPLS thoughts to solve the issue dealt with by PBB-EVPN instead of combination of two distinct technologies. 4. Be able to unify the split horizon mechanisms for ingress replication, P2MP LSP, and MP2MP LSP in E-VPN. Li, et al. Expires January 07, 2014 [Page 13] Internet-Draft Segment-Based EVPN July 2013 5. Be able to unify unicast traffic forwarding of E-VPN to implement seamless switch between C-MACs learning through control plane and C-MACs learning through data plane. 9. IANA Considerations This document requires IANA to assign a new route type value for E-VPN NLRI. 10. Security Considerations There are no additional security aspects beyond those of VPLS/H-VPLS that need to be discussed here. 11. Acknowledgements TBD. 12. Normative References [I-D.ietf-l2vpn-evpn-req] Sajassi, A., Aggarwal, R., Bitar, N., and A. Isaac, "Requirements for Ethernet VPN (E-VPN)", draft-ietf-l2vpn- evpn-req-03 (work in progress), May 2013. [I-D.ietf-l2vpn-evpn] Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F., Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-evpn-03 (work in progress), February 2013. [I-D.ietf-l2vpn-pbb-evpn] Sajassi, A., Salam, S., Boutros, S., Bitar, N., Isaac, A., and L. Jin, "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn-04 (work in progress), February 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Li, et al. Expires January 07, 2014 [Page 14] Internet-Draft Segment-Based EVPN July 2013 Lucy Yong Huawei Technologies 1700 Alma Dr. Suite 500 Plano, TX 75075 USA Email: lucyyong@huawei.com Junlin Zhang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: jackey.zhang@huawei.com Li, et al. Expires January 07, 2014 [Page 15]