Handshaking mechanism for DF election
draft-hao-bess-evpn-df-handshaking-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Hao Weiguo , Lucy Yong , liangqiandeng | ||
| Last updated | 2015-02-05 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hao-bess-evpn-df-handshaking-00
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]