Internet DRAFT - draft-zhuang-bess-evpn-pe-ce
draft-zhuang-bess-evpn-pe-ce
Network Working Group S. Zhuang
Internet-Draft W. Hao
Intended status: Standards Track Z. Li
Expires: April 21, 2016 Huawei Technologies
October 19, 2015
Using BGP between PE and CE in EVPN
draft-zhuang-bess-evpn-pe-ce-00
Abstract
This document identifies the possible applications which can benefit
from MAC learning through the control plane between PEs and CEs.
Then this document specifies protocols and procedures of using BGP as
PE-CE control protocol for carrying customer MAC routing information.
Requirements Language
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].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 21, 2016.
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
Zhuang, et al. Expires April 21, 2016 [Page 1]
Internet-Draft Using BGP between PE & CE in EVPN October 2015
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Applications . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. DCI Traffic Optimization . . . . . . . . . . . . . . . . 3
3.2. Inter-AS EVPN Option-A Solution . . . . . . . . . . . . . 4
3.3. Fast Convergence . . . . . . . . . . . . . . . . . . . . 4
4. BGP EVPN NLRI Extensions . . . . . . . . . . . . . . . . . . 6
5. Exchanging C-MAC Routes . . . . . . . . . . . . . . . . . . . 6
5.1. Originating MAC Route at the CE router . . . . . . . . . 6
5.2. Receiving a MAC Route by the PE router . . . . . . . . . 8
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. References . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
[RFC7432] describes protocols and procedures for BGP MPLS based
Ethernet VPNs. BGP is used for MAC learning by exchanging customer
MAC routing information between PEs in the control plane instead of
MAC learning between PEs in the data plane. It also states that MAC
learning between PEs and CEs MAY be done in the control plane, but it
does not define the detailed protocols and procedures. This document
identifies the possible applications which can benefit from MAC
learning through the control plane between PEs and CEs. Then this
document specifies protocols and procedures of using BGP as PE-CE
control protocol for carrying customer MAC routing information.
2. Terminology
This document uses terminology described in [RFC7432].
Zhuang, et al. Expires April 21, 2016 [Page 2]
Internet-Draft Using BGP between PE & CE in EVPN October 2015
3. Applications
3.1. DCI Traffic Optimization
Figure 1 describes the Data Center Interconnect (DCI) solution when
the GW and WAN PE functions are implemented in different systems.
+----------+
|Controller|
+----------+
|
+------+------+
+---------+ | | +---------+
+----+ | +---+ +----+ +----+ +---+ | +----+
|NVE1|--| | | |WAN | |WAN | | | |--|NVE3|
+----+ | |GW1|----|PE1 | |PE3 |----|GW3| | +----+
| +---+\ /+----+ +----+\ /+---+ |
| NVO-1 | \/ | WAN | \/ | NVO-2 |
| +---+ /\ +----+ +----+ /\ +---+ |
| | |/ \|WAN | |WAN |/ \| | |
+----+ | |GW2|----|PE2 | |PE4 |----|GW4| | +----+
|NVE2|--| +---+ +----+ +----+ +---+ |--|NVE4|
+----+ +---------+ | | +---------+ +----+
+--------------+
Figure 1 DCI Traffic Optimization
In the reference model depicted by Figure 1, all WAN PE routers run
BGP and are connected by a Controller. For each GW, it multihoming
connects to the WAN PEs, in this scenario, GW acts as an EVPN CE and
WAN PE acts as an EVPN PE.
1. Requirements of outbound traffic control:
Outbound traffic control adjusts the transmission paths of outbound
traffic from the WAN network to ensure that the traffic is evenly
shared among PEs/links between WAN PEs and NVO networks and the
bandwidth usage of each PE/link is below the specified threshold.
In outbound traffic control scenario, if the bandwidth usage of a
link exceeds the specified threshold, the Controller automatically
identifies which traffic needs to be scheduled and the Controller
automatically calculates traffic control paths based on network
topology and traffic information.
For such requirements, if the MAC routing learning between PEs and
CEs or can be done through the control plane, Controller can control
the multiple paths to the same destination which are receiving from
Zhuang, et al. Expires April 21, 2016 [Page 3]
Internet-Draft Using BGP between PE & CE in EVPN October 2015
different GWs and decide which MAC route to be used for outbound
traffic.
2. Requirements of Inbound traffic control:
Inbound traffic control adjusts the transmission paths of traffic
bound for the WAN network to ensure that the traffic is evenly shared
among PEs/links between GWs and WAN PEs and the bandwidth usage of
each PE/link is below the specified threshold.
For such requirements, if the MAC routing learning between PEs and
CEs or can be done through the control plane, the controller can
control the path attributes of the EVPN MAC route that is advertised
to the different GWs and steer the inbound traffic.
3.2. Inter-AS EVPN Option-A Solution
Currently, a typical connection mechanism between two EVPN networks
can be similar to Inter-AS Option-A of [RFC4364]. In Option-A Inter-
AS solution, peering ASBRs are connected by multiple sub-interfaces,
each ASBR acts as a PE, and thinks that the other ASBR is a CE. For
tradition L3VPN, Inter-AS Option-A has been widely deployed and MP-
BGP is always adopted between ASBRs to learn IP routes. If the EVPN
is introduced, there will be propose the inconsistency that IP route
can be learned through the control plane while the MAC route will be
learned through the forwarding plane. This will propose the
challenge caused by the complex the operation and management. So in
Inter-AS EVPN Option-A solution, using BGP between ASBRs, the
operators can get following benefits:
1. Learning of MAC Addresses can be controlled via Peer-Based Policy
between ASBRs.
2. Unified Control-Plane for MAC routing information.
3.3. Fast Convergence
The following illustrates the benefits with an example of fast
convergence in the event of PE to CE network failure.
[RFC7432] defines a mechanism to efficiently and quickly signal, to
remote PE nodes, the need to update their forwarding tables upon the
occurrence of a failure in connectivity to an Ethernet Segment. This
mechanism optimizes the withdrawal of MAC Advertisement routes, and
then optimizes the network convergence time in the event of PE to CE
failures. But it still cannot fully provide convergence time that is
independent of the number of MAC addresses learned by the PE. There
exist a situation where the network convergence time is dependent on
Zhuang, et al. Expires April 21, 2016 [Page 4]
Internet-Draft Using BGP between PE & CE in EVPN October 2015
the local MAC learning of PE and the advertisement of them to remote
PE.
+--------------+
| |
+----+ | |
| | | |
M1 ES1/| PE1|-| IP/MPLS | +----+ M2
+----+ / | | | Network | | | +----+
| |/ +----+ | |-| PE3|---| CE2|
| CE1|\ +----+ | | | | +----+
+----+ \ | | | | +----+
\| PE2|-| |
| | | |
+----+ +--------------+
Figure 2 Multi-homed EVPN Network
To illustrate this with an example in the Figure 2, consider two PEs
(PE1 and PE2) connected to a multi-homed Ethernet Segment ES1. All-
Active redundancy mode is assumed. A given MAC address M1 is learned
by PE1 but not PE2. On PE3, the following states may arise:
o T1- PE3 receives the Ethernet A-D routes per ESI from PE1 and PE2.
o T2- When the MAC Advertisement Route from PE1 and the Ethernet A-D
routes per ESI from PE1 and PE2 are received, PE3 can forward
traffic destined to M1 to both PE1 and PE2.
o T3- After T2, when the ES1 connected to PE1 fails, PE1 MUST
withdraw its Ethernet A-D route per ESI, then PE3 forwards traffic
destined to M1 to PE2 only.
o T4- After T3, PE1 MUST also withdraw the MAC advertisement routes
(M1) that are impacted by the failure. Before PE2 learns M1 and
advertises a MAC route for M1, PE3 will treat traffic to M1 as
unknown unicast. If the behavior is to drop the unknown unicast
based on administrative policy, the traffic to M1 on PE3 will be
interrupted. Note that had PE2 also advertised a MAC route for M1
before PE1 withdraws its MAC route, then PE3 would have continued
forwarding traffic destined to M1.
In the above example, once the local MAC learning of PE was done via
control plane, both PE1 and PE2 will advertise a MAC Advertisement
route for M1, then PE3 could continue forwarding traffic destined to
M1 in the event of ES1 connected to PE1 or PE2 fails. In this case,
the network convergence time is not dependent of the local MAC
learning and advertisement of MAC addresses learned by the PE any
more.
Zhuang, et al. Expires April 21, 2016 [Page 5]
Internet-Draft Using BGP between PE & CE in EVPN October 2015
The benefit can also be achieved in case of single-active redundancy
mode.
4. BGP EVPN NLRI Extensions
A new route type is defined for EVPN NLRI to advertise customer MAC
route between PE and CE in EVPN:
+ 6 - Customer MAC Advertisement route
A customer MAC Advertisement route type specific EVPN NLRI consists
of the following:
+-----------------------------------------+
| Ethernet Segment Identifier (10 octets) |
+-----------------------------------------+
| Ethernet Tag ID (4 octets) |
+-----------------------------------------+
| MAC Address Length (1 octet) |
+-----------------------------------------+
| MAC Address (6 octets) |
+-----------------------------------------+
| IP Address Length (1 octet) |
+-----------------------------------------+
| IP Address (4 or 16 octets) |
+-----------------------------------------+
It should be noted that the Route Distinguisher (RD) is not used
since the customer MAC routes are always exchanged in the context of
unawareness of Ethernet VPN.
Another solution option is to reuse EVPN MAC Advertisement Route
defined in [RFC7432] to exchange MAC route information between CE and
PE. In this case RD, MPLS Label1 and MPLS Label2 fields SHOULD be
set as 0. In addition, the RT for the route SHOULD also be set as 0.
5. Exchanging C-MAC Routes
This section describes the procedures of exchanging customer MAC
routes between PE and CE. This document assumes that a CE and a PE
exchange MAC routes over a direct BGP session.
5.1. Originating MAC Route at the CE router
When a CE receives packets in a given VLAN from interfaces, other
than interfaces connected to the PE, it learns MAC addresses in the
data plane. If the given VLAN is in the setting of VLANs across the
Ethernet links attached to a given PE, the CE MAY advertises the MAC
Zhuang, et al. Expires April 21, 2016 [Page 6]
Internet-Draft Using BGP between PE & CE in EVPN October 2015
addresses it learns in the data plane to the given PE, using MP-BGP
and the specific MAC Route, in the control plane. The MAC Route is
constructed as follows:
+ The field of the Ethernet Segment Identifier is reserved for
future use.
+ The Ethernet Tag ID is set to the VLAN ID from which the MAC
addresses are learned.
+ The MAC address length field is in bits and it is typically set to
48. However this specification enables specifying the MAC address
as a prefix; in which case, the MAC address length field is set to
the length of the prefix. This provides the ability to aggregate
MAC addresses if the deployment environment supports that.
+ The MAC address is set to the value of MAC address the CE learned.
The encoding of a MAC address MUST be the 6-octet MAC address
specified by [802.1D-ORIG] [802.1D-REV]. If the MAC address is
advertised as a prefix then the trailing bits of the prefix MUST
be set to 0 to ensure that the entire prefix is encoded as 6
octets.
+ The IP Address field is optional. By default, the IP Address
Length field is set to 0 and the IP Address field is omitted from
the route. When a valid IP address or address prefix needs to be
advertised (e.g., for ARP suppression purposes or for inter-subnet
switching), it is then encoded in this route. In this case, the
IP Address Length field is in bits and it is the length of the IP
prefix. This provides the ability to advertise IP address
prefixes when the deployment environment supports that.
+ The encoding of an IP Address MUST be either 4 octets for IPv4 or
16 octets for IPv6. When the IP Address is advertised as a
prefix, then the trailing bits of the prefix MUST be set to 0 to
ensure that the entire prefix is encoded as either 4 or 16 octets.
The length field of Ethernet NLRI is sufficient to determine
whether an IP address/prefix is encoded in this route and if so,
whether the encoded IP address/prefix is IPv4 or IPv6.
+ The Next Hop field of the MP_REACH_NLRI attribute of the route
MUST be set to the IPv4 or IPv6 address of the advertising CE.
It should be noted that the BGP advertisement for the MAC route does
not need to carry the Route Target (RT) attributes because of its
unawareness of Ethernet VPN.
Zhuang, et al. Expires April 21, 2016 [Page 7]
Internet-Draft Using BGP between PE & CE in EVPN October 2015
5.2. Receiving a MAC Route by the PE router
When a PE receives a MAC route from a CE, it learns the MAC addresses
advertised in the MAC route in the control plane and associates the
MAC addresses with the Ethernet Segment from which it can reach to
the advertising CE and the VLAN carried in the MAC route.
The PE SHOULD install forwarding state for the associated MAC
addresses based on the Ethernet Segment and VLAN inferred from the
MAC route.
In addition, the PE SHOULD advertises the MAC addresses it learns
from CE in the control plane, to all the other PEs in the associated
EVPN instance, using MP-BGP and the MAC Advertisement route defined
in [RFC7432]. For example, the PE learns a MAC address M1 on a
multi-homed Ethernet Segment (ES1) and on a VLAN 10, and the VLAN 10
is bundled to EVPN A. The PE SHOULD advertise the MAC address M1 to
all the other PEs in EVPN A.
The construction of the MAC Advertisement route and procedures of
handling the MAC Advertisement route on receiving it are specified in
[RFC7432].
6. Contributors
The following people have substantially contributed to the solution
and to the editing of this document:
Junlin Zhang
Huawei
Email: jackey.zhang@huawei.com
7. IANA Considerations
This document requires IANA to assign a new route type value for EVPN
NLRI.
8. Security Considerations
There are no additional security aspects beyond those of EVPN
([RFC7432]).
9. References
Zhuang, et al. Expires April 21, 2016 [Page 8]
Internet-Draft Using BGP between PE & CE in EVPN October 2015
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <http://www.rfc-editor.org/info/rfc7432>.
9.2. References
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
Authors' Addresses
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Weiguo Hao
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Email: haoweiguo@huawei.com
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Zhuang, et al. Expires April 21, 2016 [Page 9]
