BESS Weiguo Hao Lucy Yong Qiandeng Liang Internet Draft Huawei Intended status: Standard Track May 12, 2015 Expires: November 2015 Handshaking mechanism for DF election draft-hao-bess-evpn-df-handshaking-02.txt Abstract In [EVPN], in the DF re-election transient period, due to Ethernet Segment route transmission timer and timer clock discrepancy on each PEs, dual DF PEs will co-exist, traffic loop and disruption will be incurred. In MHN case, the consequences are particularly serious. Handshaking mechanism for DF election is introduced in this draft to resolve the problem. Status of this Memo This Internet-Draft is submitted to IETF 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Hao & et,al Expires August 12, 2015 [Page 1] Internet-Draft Handshaking mechanism for DF February 2015 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 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. Problems in MHN scenario..................................... 3 3. Conventions used in this document............................ 6 4. Handshaking mechanism for DF election in EVPN network.........6 5. Handshaking mechanism for DF election in PBB-EVPN network.....8 6. Network Migration Analysis................................... 8 7. DF election extended community............................... 9 8. Security Considerations..................................... 10 9. IANA Considerations ........................................ 10 10. References ................................................ 10 10.1. Normative References.................................. 10 10.2. Informative References................................ 10 11. Acknowledgments ........................................... 10 1. Introduction [EVPN] is a L2VPN solution using BGP for distributing customer/client MAC address reachability information over the core MPLS/IP network. EVPN provides flexible redundancy modes for both multi-homed device(MHD) and multi-homed network(MHN) scenarios. In MHD case, a CE node is normally accessed to a set of PE nodes leveraging multi-chassis Ethernet link aggregation groups(LAGs), both all-active and single-active redundancy mode can be achieved for the CE node. In MHN case, an Ethernet network, rather than a single device, is multi-homed to a group of PEs, only single-active redundancy mode can be achieved for the Ethernet network. Hao & et,al Expires August 12, 2015 [Page 2] Internet-Draft Handshaking mechanism for DF February 2015 No matter it is all-active or single-active case, DF election mechanism is used to avoid packet duplication to local Ethernet Segment(ES) from a remote PE and loop among local PEs connecting to same ESI. The Designated Forwarder (DF) PE in (PBB-)EVPN networks is the PE that is responsible for sending multicast, broadcast and unknown unicast traffic to a multi-homed CE, on a given Ethernet Tag on a particular Ethernet Segment (ES). The DF PE is selected based on the list of PEs that advertise the Ethernet Segment Identifier (ESI) to the EVPN network. The DF election procedure defined in [EVPN] is as follows: 1. When a PE discovers the ESI of the attached Ethernet Segment, it advertises an Ethernet Segment route with the associated ES-Import extended community attribute. 2. The PE then starts a timer (default value = 3 seconds) to allow the reception of Ethernet Segment routes from other PE nodes connected to the same Ethernet Segment. 3. The receiver PE(s) also starts a timer when the Ethernet Segment route is received. This timer value should be same across all PEs connected to the same Ethernet Segment. 4. When the timer expires, each PE starts DF election process independently using same algorithm. The PE elected as DF for a given EVPN instance will unblock the multi-destination traffic in the egress direction towards the Segment immediately, while the non-DF PEs will block the traffic immediately. If one CE device or network is accessed to multiple PEs, one PE failure and recovery will trigger EVPN DF re-election. Because each PE relies on independent timer expiring to trigger local DF election process, due to Ethernet Segment route transmission timer and timer clock discrepancy on each PEs, in the DF re-election transient period, dual DF PEs will co-exist, traffic loop and disruption will be incurred. In MHN case, the consequences are particularly serious and will be described in detail in section 2. 2. Problems in MHN scenario Hao & et,al Expires August 12, 2015 [Page 3] Internet-Draft Handshaking mechanism for DF February 2015 ----- ----- |PC1| |PC2| ----- ----- | | ------------------------ / Native Eth Network \ \ / ------------------------- | | ------ ------ |AGG1 | |AGG2 | ------ ------ DC1 Network | |--------------- ------ ------ |PE1 | |PE2 | ------ ------ | | ------------------------ / \ | IP/MPLS Network | \ / ------------------------- | | ------ ------ |PE3 | |PE4 | ------ ------ | |--------------- ------ ------ DC2 Network |AGG3 | |AGG4 | ------ ------ | | ------------------------ / Native Eth Network \ \ / ------------------------- | | ----- ----- |PC3| |PC4| ----- ----- Hao & et,al Expires August 12, 2015 [Page 4] Internet-Draft Handshaking mechanism for DF February 2015 Figure 1 DC Network interconnecting using EVPN In figure 1, both DC1 and DC2 networks are native Ethernet network and are multi-homed to two EVPN PEs in single-active mode respectively, i.e., DC 1 is connected to PE1 and PE2 while DC 2 is connected to PE3 and PE4. In regular time, PE1 and PE3 are DF PE, PE2 and PE4 are non-DF PE. PC1 to PC4 belong to same VLAN. When PE3 fails, PE4 will take over the duties of DF PE. After some time, PE3 recovers and starts DF PE re-election process. In the re- election process, due to Ethernet Segment route transmission timer and timer clock discrepancy on PE3 and PE4, both PE3 and PE4 will act as DF PE in short transient time. During the transient time, the following data plane and control plane process will be performed. Data plane: 1. PC1 in DC1 sends BUM traffic to PE1. 2. PE1 sends the traffic to PE3 (and PE4). Because both PE3 and PE4 are DF PE at this time, PE3 (and PE4) will forward the BUM traffic to DC2 local network. 3. PE4 (and PE3) will receive the BUM traffic from DC2 local access network and learn the PC1's MAC through data plane. 4. PE4 (and PE3) will forward the BUM traffic to PE1. 5. PE1 will forward the BUM traffic to DC1 network. MAC flip-flop of PC1 will occur on the switches in DC1. Control plane: 1. When PE4 (and PE3) learns PC1's MAC from DC2 local network, PE4 (and PE3) will announce the MAC of PC1 to PE1 using BGP control plane. 2. When PE1 receives PC1's MAC from PE4 (and PE3) through BGP, it will populate the MAC route of PC1 into local MAC-VRF, MAC flip-flop of PC1 on PE1 will occur. Hao & et,al Expires August 12, 2015 [Page 5] Internet-Draft Handshaking mechanism for DF February 2015 When PC1's MAC flip-flop occurs on DC1 local switches and PE1, the regular traffic to PC1 in DC1 local network will be disrupted. If there are multiple PCs sending BUM traffic proactively at the transient time, multiple MAC addresses fluctuation will occur. This will impose extra control plane burden on all related PEs and induce regular traffic disruption to these PCs. So in the MHN scenario, dual DF PEs in transient period will have serious consequences, it should be resolved. To resolve the problem of dual DF PEs in transient period, a new handshaking mechanism for DF election is introduced in this draft. 3. 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 [RFC2119]. Ethernet Segment (ES): If a multi-homed device or network is connected to two or more PEs via a set of Ethernet links, then that set of links is referred to as an 'Ethernet segment'. Ethernet Segment Identifier (ESI): A unique non-zero identifier that identifies an Ethernet Segment is called an 'Ethernet Segment Identifier'. 4. Handshaking mechanism for DF election in EVPN network In figure 1, initially PE2 and PE3 boot up and have already finished DF election process, later PE1 boots up and is elected as DF, the timing diagram from PE1 boots up is as follows: ------- ------- ------- | PE1 | | PE2 | | PE3 | ------- ------- ------- Discover ESI | | | and start timer| | | -------------->| | | Hao & et,al Expires August 12, 2015 [Page 6] Internet-Draft Handshaking mechanism for DF February 2015 |ES Route+DF Election EC| | |<--------------------->| | | ES Route+DF Election EC | |<------------------------------------------->| Timer expires | | | -------------->|AD Route+DF Election EC| | |---------------------->|Block traffic | | AD Route+DF Election EC | |--------------------------------------------->|Block traffic |AD Route+DF Election EC| | |<----------------------| | | AD Route+DF Election EC | |<--------------------------------------------| | Unblock traffic | | Figure 2 Handshaking DF Election Timing Diagram 1. When PE1 discovers the ESI of the attached Ethernet Segment, it advertises an Ethernet Segment route with the associated ES-Import extended community attribute. If the PE supports DF election handshaking mechanism, the ES route MUST associate with a new DF election BGP extended community with a DF handshaking capability Flag to show that the advertising PE itself supports DF election handshaking mechanism. 2. PE1 then starts a timer (default value = 3 seconds) to allow the reception of Ethernet Segment routes from other PE(PE2 and PE3) nodes connecting to the same Ethernet Segment. This timer value should be same across all PEs connected to the same Ethernet Segment. 3. When the timer expires, each PE knows all member PEs connecting to the same ESI and perform DF election algorithm independently as defined in [EVPN]. If all member PEs connecting to same ESI support DF handshaking mechanism, for the DF PE, at this time it doesn't unblock multi-destination traffic in the egress direction towards the Segment directly. For the non-DF PEs, they also should keep forwarding state unchanged(Because PE2 is old DF PE, so it keep forwarding multi-destination traffic in the egress direction). The DF PE of PE1 should shake hands with other non-DF PEs to ensure unblocking action on DF PE and blocking action on non-DF PE enforced at the same time. The elected DF PE of PE1 notifies other non-DF PEs an Ethernet Auto-Discovery (A-D) route associated with a DF election Hao & et,al Expires August 12, 2015 [Page 7] Internet-Draft Handshaking mechanism for DF February 2015 BGP extended community with DF Flag to show that the advertising PE1 itself is DF PE. 4. When each non-DF PE(PE2 and PE3) receives the A-D route from DF PE of PE1, the non-DF PE will block multi-destination traffic in the egress direction, then it advertises an Ethernet Auto-Discovery (A-D) route with the DF election extended community to DF PE. The DF election extended community carries a non-DF Flag to show that the advertising PE itself is non-DF PE and has blocked multi-destination traffic in the egress direction towards the Segment. 5. When the DF PE1 receives the A-D route with DF election extended community from all other non-DF PEs, the DF PE can start unblock multi-destination traffic in the egress direction towards the Segment. Because all non-DF PEs have blocked the traffic, so now no packet duplication and loop among local PEs will occur. When a DF election happens, there may be other uncompleted DF election process existed among same PEs connecting to same Ethernet Segments at the same time. In order to ensure that all PEs negotiate for the newest DF election, it is necessary to introduce a sequence number into the DF election extended community attribute. The sequence number is generated on DF PE corresponding to each DF election process, non-DF PEs don't generate the number and use same sequence number generated by DF PE. Each non-DF PE should stop negotiating old DF election when it receives a A-D route with larger sequence number. Through the handshaking mechanism, when a DF PE is elected, it notifies all non-DF PEs block traffic immediately, only when all non-DF PEs block traffic successfully, DF PE can unblock traffic, so it can effectively reduce traffic disruption , avoid potential issues of packet duplication and loop incurred by all-active access. 5. Handshaking mechanism for DF election in PBB-EVPN network In PBB-EVPN network, Ethernet Auto-Discovery Routes are not needed. DF election extended community should be carried with ES routes. The ES routes are used for DF election handshaking among the PBB-EVPN PEs connecting to same ESI. 6. Network Migration Analysis To support handshaking mechanism for DF election, software upgrade in all member PEs connecting to an ESI is needed. Hao & et,al Expires August 12, 2015 [Page 8] Internet-Draft Handshaking mechanism for DF February 2015 In ESI member PE discovery phase, if a member PE doesn't support the new DF election handshaking mechanism, it advertises ES route without the new DF election extended capability, in this case the PEs connecting to the same ESI use old DF election method as defined in [EVPN]. Only if all member PEs connecting to same ESI support the new DF election handshaking capability, the new DF election method can be used for the ESI. 7. DF election extended community This extended community is a new transitive extended community with the Type field of 0x06 and the Sub-Type of TBD. It may be advertised along with ES routes or A-D routes. The DF election Extended Community is encoded as an 8-octet value as follows: 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=TBD |C|D|N| Reserved=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DF election extended community o C. If C flag is one, it indicates that the advertising PE supports DF election handshaking mechanism. It's used in ESI member PE discovery phase for capability announcement. o D. If D flag is one, it indicates that the advertising PE is the DF, the non-DF PE connecting to same ESI can block egress multi- destination traffic immediately when it receives ES or AD route with the DF election extended community from DF PE. o N. If N flag is one, it indicates that the advertising PE is non-DF and has blocked multi-destination traffic in the egress direction towards the Segment. o Sequence. The sequence number is used to ensure that PEs connecting to same ESI are negotiating for same DF election. In ES member PEs discovery phase, the sequence number is 0. In DF election handshaking phase, the sequence number should be non-zero and is generated by DF PE. Hao & et,al Expires August 12, 2015 [Page 9] Internet-Draft Handshaking mechanism for DF February 2015 8. Security Considerations NA. 9. IANA Considerations IANA has allocated the following EVPN Extended Community sub-types in [RFC7153]. SUB-TYPE VALUE NAME 0x00 MAC Mobility 0x01 ESI Label 0x02 ES-Import Route Target IANA is requested to create and maintain a new registry for "EVPN DF Election Extended Community Sub-Types". SUB-TYPE VALUE NAME 0x03 DF Election 10. References 10.1. Normative References [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [2] [EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf- l2vpn-evpn-11.txt, work in progress, October, 2014 11. Acknowledgments Authors like to thank Lili Wang, Ziqing Cao, Feng Qian for his valuable inputs. Hao & et,al Expires August 12, 2015 [Page 10] Internet-Draft Handshaking mechanism for DF February 2015 Authors' Addresses Weiguo Hao Huawei Technologies 101 Software Avenue, Nanjing 210012 China Phone: +86-25-56623144 Email: haoweiguo@huawei.com Lucy Yong Huawei Technologies Phone: +1-918-808-1918 Email: lucy.yong@huawei.com Qiandeng Liang Huawei Technologies 101 Software Avenue, Nanjing 210012 China Email: liangqiandeng@huawei.com Hao & et,al Expires August 12, 2015 [Page 11]