Internet DRAFT - draft-hao-bess-evpn-df-handshaking
draft-hao-bess-evpn-df-handshaking
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]
