BESS Weiguo Hao Lucy Yong Qiandeng Liang Internet Draft Huawei Intended status: Standard Track February 6, 2015 Expires: August 2015 Handshaking mechanism for DF election draft-hao-bess-evpn-df-handshaking-00.txt Abstract In [EVPN], DF election process on each PE connecting to same ESI is triggered by independent timer expiring, DF and non-DF PEs can't ensure that unblocking and blocking action take effect at the same time, sometimes long time traffic disruption will occur. Handshaking mechanism for DF election is introduced in this draft, it can effectively reduce traffic disruption and avoid potential issues of packet duplication and loop in all-active access scenario. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 6, 2015. Hao & et,al Expires August 6, 2015 [Page 1] Internet-Draft Handshaking mechanism for DF February 2015 Copyright Notice Copyright (c) 2013 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. Table of Contents 1. Introduction ................................................ 2 2. Conventions used in this document............................ 4 3. Handshaking mechanism for DF election in EVPN network.........4 4. Handshaking mechanism for DF election in PBB-EVPN network.....6 5. Network Migration Analysis................................... 7 6. DF election extended community............................... 7 7. Security Considerations...................................... 8 8. IANA Considerations ......................................... 8 9. References .................................................. 8 9.1. Normative References.................................... 8 9.2. Informative References.................................. 8 10. Acknowledgments ............................................ 8 1. Introduction [EVPN] is a solution for L2VPN services that supports All-active multi-homing and use of BGP for distributing customer/client MAC address reachability information over the core MPLS/IP network. In all-active multi-homing 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. Hao & et,al Expires August 6, 2015 [Page 2] Internet-Draft Handshaking mechanism for DF February 2015 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. This timer value should be same across all PEs connected to the same Ethernet Segment. 3. 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. Because each PE relies on independent timer expiring to trigger local DF election process, DF and non-DF PEs can't ensure blocking and blocking action take effect on each PE at the same time, traffic disruption will be incurred, sometimes up to the timer value(default 3 seconds)disruption. +------+ | CE2 | +------+ | +-----------+ | PE4 | +-----------+ | | | -------- | -------- | | | +------+ +------+ +------+ | PE1 | | PE2 | | PE3 | +------+ +------+ +------+ | | | | | | | | | ----------------------------- MC-LAG1 | +------+ | CE1 | +------+ Figure 1 EVPN DF election for CE1 Hao & et,al Expires August 6, 2015 [Page 3] Internet-Draft Handshaking mechanism for DF February 2015 In figure 1, CE1 are accessed to PE1,PE2 and PE3 in all-active mode. PE2 and PE3 boot up in the initial time, DF and non-DF are negotiated between PE2 and PE3. The ultimate DF election result is PE2 as non-DF and PE3 as DF. Later PE1 boots up and advertises an Ethernet Segment(ES) route to PE2 and PE3, DF re-election will be triggered on PE2 and PE3, assuming PE1 will be elected as DF ultimately. After PE1 advertise an Ethernet Segment(ES) route to PE2 and PE3, PE1 starts a 3 seconds timer, only when the timer expires PE1 can change to DF. When PE2 and PE3 receive the ES route, PE3 will degrade to non-DF immediately. Normally the ES route reception timer by PE2 and PE3 is very short and even can be neglected in normal case. However, PE1 can only upgrade to DF PE in 3 seconds later. PE1 upgrading to DF and PE3 degrading to non-DF are not at the same time. So in this case, traffic disruption will last nearly 3 seconds. This draft will introduce a new handshaking mechanism for DF election to ensure state consistency among all PEs connecting to same ESI nearly at the same time, it can effectively reduce traffic disruption in DF election and re-election case. 2. 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'. 3. 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: Hao & et,al Expires August 6, 2015 [Page 4] Internet-Draft Handshaking mechanism for DF February 2015 ------- ------- ------- | PE1 | | PE2 | | PE3 | ------- ------- ------- Discover ESI | | | and start timer| | | -------------->| | | |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 associates 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 Hao & et,al Expires August 6, 2015 [Page 5] Internet-Draft Handshaking mechanism for DF February 2015 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 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 and avoid potential issues of packet duplication and loop incurred by all-active access. 4. Handshaking mechanism for DF election in PBB-EVPN network In PBB-EVPN network, Ethernet Auto-Discovery Routes are not needed. Hao & et,al Expires August 6, 2015 [Page 6] Internet-Draft Handshaking mechanism for DF February 2015 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. 5. Network Migration Analysis To support handshaking mechanism for DF election, software upgrade in all member PEs connecting to an ESI is needed. 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. 6. 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. Hao & et,al Expires August 6, 2015 [Page 7] Internet-Draft Handshaking mechanism for DF February 2015 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. 7. Security Considerations NA. 8. 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 9. References 9.1. Normative References [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [2] [EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf- l2vpn-evpn-11.txt, work in progress, October, 2014 10. Acknowledgments Authors like to thank Lili Wang, Ziqing Cao, Feng Qian for his valuable inputs. Hao & et,al Expires August 6, 2015 [Page 8] 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 6, 2015 [Page 9]