Internet DRAFT - draft-hao-l2vpn-evpn-mhn
draft-hao-l2vpn-evpn-mhn
L2VPN Weiguo Hao
Yizhou Li
Pei Xu
Internet Draft Huawei
Intended status: Standards Track June 14, 2013
Expires: December 2013
Multi-homed network in EVPN
draft-hao-l2vpn-evpn-mhn-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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."
Hao & Li Expires December 14, 2013 [Page 1]
Internet-Draft Multi-homed network in EVPN June 2013
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 December 14, 2013.
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. 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.
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.
Abstract
To enhance the reliability, bridged network is normally multi-homed
to an EVPN network, there are two categories of mechanisms to avoid
the layer 2 traffic loop. The first category does not require the PEs
participating in the control protocol of the bridged network, while
the second category requires that. [EVPN] described one of the first
category mechanisms called designated forwarder (DF) election to
achieve loop avoidance and vlan-based load balancing. This draft
mainly focuses on the second category of mechanisms which can achieve
intra-vlan MAC-based load balancing. MAC-based VLAN balancing is more
applicable than DF election mechanism if all end stations in bridged
network are on the same VLAN which can cause traffic congestion in DF
link.
Hao & Li Expires December 14, 2013 [Page 2]
Internet-Draft Multi-homed network in EVPN June 2013
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document............................ 4
3. Recap on Designated Forwarder (DF) election mechanism.........4
4. Active/Active MAC-based load balancing mechanism .............6
4.1. Emulated MSTP root bridge solution ......................7
4.2. Bridge control plane protocol tunneling solution.........8
4.2.1. Scenario 1: Local bridged network is MSTP..........10
4.2.2. Scenario 2: Local bridged network is G.8032........10
4.2.3. Fast convergence.................................. 10
5. EVPN protocol extension..................................... 11
6. Security Considerations..................................... 11
7. IANA Considerations ........................................ 11
7.1. Normative References................................... 12
7.2. Informative References................................. 12
8. Acknowledgments ............................................ 12
1. Introduction
[EVPN] introduces a solution for multipoint L2VPN services. In EVPN
networks, MAC learning between PEs is not via the data
plane( different from what happens in traditional bridging network)
but via the control plane using multi-protocol (MP) BGP.
To enhance the reliability, the PE nodes need offer multi-homed
connectivity to a CE or access Network, i.e, both multi-homed device
(MHD) as well as multi-homed network (MHN) scenarios in [EVPN-REQ]
should be covered by E-VPN solution. In MHN scenario, the multi-homed
Ethernet network would typically run a resiliency mechanism such as
Multiple Spanning Tree Protocol [802.1Q] or Ethernet Ring Protection
Switching [G.8032]. For example, EVPN can be used for Data Center(DC)
interconnection to provide LAN extension for each DC site and each
site is an MSTP networks. Normally each site should be multi-homed to
multiple EVPN PEs to ensure the reliability.
As defined in [EVPN-REQ], the following solutions should be provided
for MHN scenario:
A solution MUST support multi-homed network connectivity with
active/standby redundancy.
A solution MUST also support multi-homed network with active/active
VLAN-based load balancing (i.e. disjoint VLAN sets active on
disparate PEs).
Hao & Li Expires December 14, 2013 [Page 3]
Internet-Draft Multi-homed network in EVPN June 2013
A solution MAY support VLAN-based load balancing among PEs that are
member of a redundancy group spanning multiple ASes.
A solution MAY support multi-homed network with active/active MAC-
based load balancing (i.e. different MAC addresses on a VLAN are
reachable via different PEs).
The former three requirements can be addressed through designated
forwarder (DF) election mechanism as described in [EVPN], a brief
review of DF election mechanism will be given in section 3.
This draft will mainly focus on a new mechanism to achieve
active/active MAC-based load balancing to fulfil the fourth
requirement. The details of the solution will be illustrated in
section 4. Protocol extensions of EVPN for this mechanism will be
given in section 5.
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 RFC-2119
[RFC2119].
This document uses the terminologies defined in [RFC6325] along with
the following:
EVPN: Ethernet virtual private network.
G.8032: Ethernet ring protection switching.
NVO3: Network virtualization over layer3.
STP: Spanning Tree Protocol.
3. Recap on Designated Forwarder (DF) election mechanism
------------------
/ \
| EVPN Network |
\ /
------------------
Hao & Li Expires December 14, 2013 [Page 4]
Internet-Draft Multi-homed network in EVPN June 2013
| |
| |
+------+ +------+
DF --->| PE1 | | PE2 |
+------+ +------+
| |
+---------------------------------------------+
| | | |
| STP | | |
| +----+ root+----+ +----+ |
| | B4 |-------| B1 |-------| B2 | |
| +----+ +----+ +----+ |
| | | |
| | | |
| | |<---blocked |
|Bridged | +----+ | |
|LAN +-----| B3 |----+ |
| +----+ |
+---------------------------------------------+
Figure 1 DF election mechanism
As described in [EVPN], designated forwarder(DF) mechanism is
required for loop avoidance. Only one of the links between the
switched bridged network and the PEs is active for a given Ethernet
tag, as shown by Figure 1. This mechanism does not require the PEs to
participate in the control protocol of the bridged network. Bridges
in the local bridged network runs normal Multiple Spanning Tree
Protocol [802.1Q] or Ethernet Ring Protection Switching [G.8032].
Hao & Li Expires December 14, 2013 [Page 5]
Internet-Draft Multi-homed network in EVPN June 2013
Through this method VLAN-based load balancing among PEs can be
achieved. All end systems of one VLAN can access the EVPN network
through only one PE.
In this case, the Ethernet A-D route per Ethernet segment MUST be
advertised with the "Active-Standby" flag set to one. Only one PE is
elected as DF for each EVI(E-VPN Instance). Only DF is responsible
for sending multicast, broadcast and unknown unicast traffic, on a
given Ethernet tag to the bridged network. In order to perform better
traffic load-balancing within a given segment, multiple DFs per
Ethernet segment can be elected and each PE is the DF for a disjoint
set of EVIs. An EVI is an E-VPN routing and forwarding instance on a
PE and consists of one or more broadcast domains which is identified
by an Ethernet Tag which are assigned to the broadcast domains of a
given E-VPN instance by the provider of that E-VPN. The information
about an Ethernet Tag on a particular Ethernet segment is advertised
using an "Ethernet Auto-Discovery route(Ethernet A-D route)". In the
case of a multi-homed CE, this route MUST carry the "ESI Label
Extended Community" to enable split horizon. Also, the route can be
used for Designated Forwarder (DF) election and MAY be used to
optimize the withdrawal of MAC addresses upon failure.
For fast convergence case, upon a failure in connectivity to the
attached segment, the PE withdraws the corresponding Ethernet A-D
route. This triggers all PEs that receive the withdrawal to update
their next-hop adjacencies for all MAC addresses associated with the
Ethernet segment in question. If there is any other PE advertising
an Ethernet A-D route for the same segment, the PE updates the next-
hop adjacencies to point to this backup PE(s).
With DF mechanism, native frames enter and leave bridged network via
the same designated forwarder for a given VLAN. It may cause
congestion or suboptimal routing. PE and bridges should be carefully
configured so that end stations on a remnant bridged LAN are
separated into different VLANs that have different designated
forwarders to achieve better load balancing.
4. Active/Active MAC-based load balancing mechanism
Active/Active MAC-based load balancing mechanism requires the PEs to
participate in the control plane protocol of the bridged network.
With this mechanism, loop avoidance and per-vlan MAC-based load
balancing can be achieved. So it can achieve better load balancing
than DF election, and is more applicable if all end stations in
bridged network on the same VLAN may cause traffic congestion over
the link to DF.
Hao & Li Expires December 14, 2013 [Page 6]
Internet-Draft Multi-homed network in EVPN June 2013
The following two solutions can be used to achieve active/active MAC-
based load balancing. One is emulated MSTP root bridge solution;
another is bridge control plane protocol tunneling solution. We will
described them in the following subsections respectively.
4.1. Emulated MSTP root bridge solution
+------+
| PE3 |
+------+
|
|
|
------------------
/ \
| EVPN Network |
\ /
------------------
| |
| |
-----+-----------+----
/ +------+ +------+ \ <---emulated hig
| | PE1 | | PE2 | | priority roo
-------------| +------+ +------+ |---------
| \-----+-----------+-----/ |
| | | |
| | | |
Hao & Li Expires December 14, 2013 [Page 7]
Internet-Draft Multi-homed network in EVPN June 2013
| | | |
| +----+ +----+ \|/ +----+ |
| | B4 |-------| B1 |--- ---| B2 | |
| +----+ p1 +----+ /|\ +----+ |
| | | | |
| | blocked \|/ |
| | - ----blocked |
|Bridged | /|\ |
|LAN | +----+ | |
| +-----| B3 |----+ |
| p1 +----+ p2 |
-----------------------------------------------
Figure 2 emulated MSTP root bridge solution
PE1 and PE2 act as an emulated MSTP root bridge. PE1 & PE2 use the
same bridge ID to emit spanning tree BPDUs as the highest priority
root Bx. All bridges in bridged network see PE1 and PE2 as single
tree root. Therefore B1-B2 and B2-B3 links are blocked for loop
avoidance by the spanning tree protocol.
When B1-B3 link fails, alternate port p2 on B3 will start to send TC
BPDU and go to forwarding state. PE2 receives TC BPDU from B2
sequentially. PE2 tunnel the TC BPDU to PE1. At the same time, PE2
notifies remote PE3 to flush the MAC table through corresponding
Ethernet A-D route.
With this solution, PE1 and PE2 needs to tunnel TC BPDU to each other
when topology change occurs in the local bridged network.
4.2. Bridge control plane protocol tunneling solution
+------+
| PE3 |
Hao & Li Expires December 14, 2013 [Page 8]
Internet-Draft Multi-homed network in EVPN June 2013
+------+
|
|
------------------
/ \
| EVPN Network |
\ /
------------------
| |
| |
+------+ +------+ <---BPDU message is
tunneled
| PE1 | | PE2 | between PE1 and
PE2
------------- +------+ +------+ ---------
| | |
| | | |
| | | |
| | | |
| +----+ +----+ \|/ +----+ |
| | B4 |-------| B1 |--- ---| B2 | |
| +----+ p1 +----+ /|\ +----+ |
| | | | |
| | blocked \|/ |
| | - ----blocked |
Hao & Li Expires December 14, 2013 [Page 9]
Internet-Draft Multi-homed network in EVPN June 2013
|Bridged | /|\ |
|LAN | +----+ | |
| +-----| B3 |----+ |
| p1 +----+ p2 |
-----------------------------------------------
Figure 3 PE1 and PE2 act as normal MSTP bridge nodes
The solution described in the previous section is applicable for
STP/MSTP domain. Now we are going to present another solution which
can be used for both MSTP and G.8032 domain. The basic idea is to
tunnel the control plane messages of local domain among the multi-
homed PEs over EVPN network.
4.2.1. Scenario 1: Local bridged network is MSTP
PE1 and PE2 act as normal MSTP bridge nodes. MSTP root bridge can be
PE or any switch in the bridged network. BPDU message can be sent
through tunnel over EVPN network between PE1 and PE2. The tunnel can
be MPLS P2P LSP, MPLS P2MP LSP, or NVO3 tunnel, etc. PE1 and PE2
regard the BPDU tunnel as normal physical link. To avoid BPDU tunnel
blocked by MSTP, link cost of the tunnel should be set to 0 or
minimum value in MSTP network. With such configuration, it is
expected that the blocked port by MSTP protocol can never be the EVPN
network facing port on PEs.
4.2.2. Scenario 2: Local bridged network is G.8032
Similarly, PE1 and PE2 act as normal G.8032 ring nodes. They support
standard FDB MAC learning, forwarding, flush behavior and port
blocking/unblocking mechanisms. G.8032 message can be sent through
tunnel over EVPN network between PE1 and PE2. ring protection
link(RPL) owner node can be PE or any switch in bridged network. If
PE is RPL owner node, RPL can only be configured on access link and
can never be configured on the EVPN network facing port on PEs.
4.2.3. Fast convergence
For fast convergence, when a PE notice a topology change event, it
should flush local MAC entries and notify the remote PE of the same
EVPN instance to withdraw the corresponding Ethernet A-D route. The
remote PE that received the withdrawal simply invalidates the MAC
entries for that segment.
Hao & Li Expires December 14, 2013 [Page 10]
Internet-Draft Multi-homed network in EVPN June 2013
5. EVPN protocol extension
ESI Label Extended Community MUST be included in EVPN Ethernet A-D
route. All-Active multi-homing or active-standby multi-homing mode is
decided by the "Active-Standby" bit in the flags of the ESI Label
Extended Community through DF mechanism.
ESI Label Extended Community should be extended to support the
mechanisms illustrated in this document. "M" bit is introduced to
indicate multi-homing mode of MAC-based all active without DF
Election. DF selection procedures should be skipped if "M" bit is set
to be 1. When remote PE receives Ethernet A-D route withdraw message,
it simply invalidates the MAC entries for the segment that
corresponding to the Ethernet A-D route.
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 |DF|R|M| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved = 0| ESI Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DF: As defined in [EVPN]. It should be ignored if M bit is 1.
R: The bit is already defined as the "Root-Leaf" in [EVPN].
M: The bit is defined as "MAC-based all active without DF Election"
and may be set to 1. The above "DF" bit is significant only when "M"
bit is set to 0. A value of 1 for M bit means that multi-homed site
uses MAC-based active-active access.
6. Security Considerations
TBD
7. IANA Considerations
TBD
Hao & Li Expires December 14, 2013 [Page 11]
Internet-Draft Multi-homed network in EVPN June 2013
7.1. Normative References
[1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[1] [EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for
Ethernet VPN", draft-ietf-l2vpn-evpn-req-01.txt.
[2] [EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-
ietf-l2vpn-evpn-00.txt, work in progress, February, 2012.
8. Acknowledgments
The authors wish to acknowledge the important contributions of
Shunwan Zhuang.
Authors' Addresses
Weiguo Hao
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56625375
Email: liyizhou@huawei.com
Hao & Li Expires December 14, 2013 [Page 12]
Internet-Draft Multi-homed network in EVPN June 2013
Pei Xu
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56623590
Email: xupei@huawei.com
Hao & Li Expires December 14, 2013 [Page 13]
