Internet DRAFT - draft-glendon-bess-evpn-default-mac
draft-glendon-bess-evpn-default-mac
Network Working Group G. Liu
Internet-Draft H. Wang
Intended status: Standards Track Huawei Technologies
Expires: January 9, 2020 July 08, 2019
EVPN DEFAULT MAC
draft-glendon-bess-evpn-default-mac-00
Abstract
A principal feature of EVPN is the ability to support multihoming
from a customer equipment (CE) to multiple provider edge equipment
(PE) with all-active links. This draft specifies a mechanism of
default mac to reduce amounts of advertising mac route and enhance
EVPN network reliability.
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 [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 https://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 January 9, 2020.
Copyright Notice
Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of
Liu & Wang Expires January 9, 2020 [Page 1]
Internet-Draft EVPN DEFAULT MAC July 2019
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
1.1. Situation Anyalisis . . . . . . . . . . . . . . . . . . . 2
1.2. Alternative Solutions . . . . . . . . . . . . . . . . . . 3
1.3. Design Requirement . . . . . . . . . . . . . . . . . . . 3
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3. Default MAC Capability negotiation . . . . . . . . . . . . . 5
4. Default MAC Actions . . . . . . . . . . . . . . . . . . . . . 6
4.1. Mac Route Extension . . . . . . . . . . . . . . . . . . . 6
4.2. Default MAC Flow Transmission . . . . . . . . . . . . . . 6
5. Application Senario . . . . . . . . . . . . . . . . . . . . . 7
5.1. Remote Interaction . . . . . . . . . . . . . . . . . . . 7
5.2. Local Interaction . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
A principal feature of EVPN is the ability to support multihoming
from a customer equipment (CE) to multiple provider edge equipment
(PE) with links used in the all-active redundancy mode. That mode is
where a device is multihomed to a group of two or more PEs and where
all PEs in such a redundancy group can forward traffic to/from the
multihomed device or network for a given VLAN (RFC7209). This draft
specifies a mechanism of default mac to reduce amounts of advertising
mac route and enhance EVPN network reliability.
1.1. Situation Anyalisis
One of the biggest features of EVPN is to transfer the VPLS network
side MAC address learning and publishing process from the data plane
to the control plane.But it also brings obvious drawbacks. Firstly,
compared with the route aggregation in the EVPN L3VPN scenario, the
MAC address of the control plane cannot be aggregated, which results
in a large overhead for large-scale user MAC advertisements.
Secondly, different from routing, the local MAC address will age
Liu & Wang Expires January 9, 2020 [Page 2]
Internet-Draft EVPN DEFAULT MAC July 2019
periodically, causing intermittent MAC revoke routing in all EVPN
network. This kind of route revocation is directed to the EVPN
network, which has a great impact on the performance of the network.
At last, EVPN advertises all user MACs to all reachable neighbors.
For a single device, the MAC capacity is equal to the sum of MACs
sent by all neighbors. However, the mac capacity of a single device
is limited. The risk of insufficient MAC is widespread. MAC Once
exceeded, the EVPN network data traffic will be flooded.
1.2. Alternative Solutions
The MAC routing in 1.1 is based on the risk that the flooding of the
EVPN neighbors on the control plane may cause flooding of the network
traffic. Without modifying the basic principles of protocol
interaction and traffic forwarding, there are two main solutions for
mitigating risks:
1) Statically limit the number of local MAC learning on the AC side
of the routing source device. This limitation can be either
interface-based or broardcast domain-based. This solution has a
certain protection effect on the large-size MAC traffic injection on
the access side.
2) For the routing initiator device to limit the number of PEER-level
MAC routes to be advertised, the solution is especially applicable to
scenarios where the user MAC traffic is not large but the number of
EVPN neighbors is large. A scene with a large number of user MAC
addresses and a large number of EVPN neighbors needs to be combined
with 1) for protection.
1.3. Design Requirement
Although the user local MAC restriction and the neighbor-based MAC
restriction mentioned in 1.2 have an inhibitory effect on the size of
the entire network MAC route, the disadvantages are obvious:
1) The number of access users and the number of neighbors in each
device in the network are different, and the order of magnitude may
vary greatly. Therefore, the network administrator must be aware of
the dynamic changes of users and neighbors, and adjust the MAC limit
value in real time. The cost of maintenance is very high.
2) When the network environment is unstable, there may be a large
number of illegal user MAC attacks. The device cannot identify the
illegal MAC address and the legal MAC address. The illegal MAC
address causes the global MAC address to reach the upper limit. The
data traffic destined for the legitimate user MAC on the network side
continues to be flooded.
Liu & Wang Expires January 9, 2020 [Page 3]
Internet-Draft EVPN DEFAULT MAC July 2019
In order to avoid the problem that the number of network MAC routes
increases exponentially with the number of users and neighbors, the
solution of default MAC route generation and release is proposed by
referring to the default route scheme of the L3VPN scenario.
Draft ietf-bess-dci-evpn-overlay-10#section-3.5.1 only mentions the
concept of all-zero MAC routing, but does not describe the
application scenarios and implementation principles of all-zero MAC.
The purpose of this draft is to describe the default MAC capability
negotiation, default MAC routing sending and receiving, default MAC
application scenario, default MAC mobility and so on completely based
on all-zero MAC.
1.4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
"LOCAL PE": The local PE refers to the CSG PE. The local PE needs to
be configured with the default MAC route receiving enable.
"REMOTE PE": The remote PE refers to th RSG PE. The remote PE needs
to be configured with the default MAC route sending enable.
"default mac": Similar to the default route, it is used to guide the
forwarding behavior when the unicast traffic misses the detailed MAC
entry.
2. Solution Overview
The program includes the following points:
1) The default MAC advertisement is not the default behavior of the
device. You need to manually configure the default MAC route sending
enable (for the route sender) and the receive enable (for the route
receiver). The EVPN neighbors use the MAC route to implement the
default MAC capability negotiation.
2) default mac routing sending and receiving needs to be supported.
Unicast traffic additionally matches the default mac in case of
detailed MAC mismatching.
3) After the default MAC capability negotiation is successful, AC
interworking (including the same PE and cross-PE) needs to be
supported.
Liu & Wang Expires January 9, 2020 [Page 4]
Internet-Draft EVPN DEFAULT MAC July 2019
3. Default MAC Capability negotiation
Although the default MAC belongs to the device global capability,
considering the simplicity of the protocol extension, the MAC-IP
route carries the Layer 2 Attributes extended community to support
the default mac negotiation between the route sender and receiver.
The extention of the "Reserved" field is needed. The Layer 2
Attributes extended community defined here is defined as follows:
+-------------------------------------------+
| Type (0x06) / Sub-type (0x04) (2 octets) |
+-------------------------------------------+
| Control Flags (2 octets) |
+-------------------------------------------+
| L2 MTU (2 octets) |
+-------------------------------------------+
| Reserved (2 octets) |
+-------------------------------------------+
Figure 1: EVPN Layer 2 Attributes Extended Community
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. The extention of the "Reserved" field
The first bit in the "Reserved" field is used to indicate whether the
default MAC route is enabled on the route sender.
Name Meaning
-------------------------------------------------- -------------
D If set to 1, this flag indicates that default mac advertising
capabilicy is enabled by the advertising PE.
If the default mac advertising capability is not enabled, then the
bit must be set to 0.
For the receiving end PE, it is necessary to determine whether to
allow crossover based on the default MAC route receiving enable
configuration. If only the D bit is set and the receiving end PE
default MAC route receiving is enabled, the received route can
finally crossed successfully. From the perspective of route
Liu & Wang Expires January 9, 2020 [Page 5]
Internet-Draft EVPN DEFAULT MAC July 2019
optimization, if the default MAC route sending enable is not
configured on the sender, the default MAC route may not be sent.
4. Default MAC Actions
4.1. Mac Route Extension
Based on the D bit in the Layer 2 attributes extended community
defined in Section 3, the default MAC route is released by the
special 0 mac and Layer 2 attributes extended community. The
extended MAC routing format is as follows:
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
|Ethernet Segment Identifier (10 octets)|
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| MAC Address Length (=48) |
+---------------------------------------+
| MAC Address (=0) |
+---------------------------------------+
| IP Address Length (1 octet) |
+---------------------------------------+
| IP Address (0, 4, or 16 octets) |
+---------------------------------------+
| MPLS Label1 (3 octets) |
+---------------------------------------+
| MPLS Label2 (0 or 3 octets) |
+---------------------------------------+
Figure 3. Extended Mac Route Format
The Ethernet Tag ID, MAC Address Length, MAC Address, IP Address
Length, and IP Address fields are still considered to be part of the
prefix in the NLRI. At the same time, the MAC address field must be
filled in all zero.
4.2. Default MAC Flow Transmission
For the data traffic from the network side to the access side, the
BUM traffic still goes through the broadcast process, and unicast
traffic preferentially matches the detailed MAC, and the broadcast
process goes on for mismatching. For data traffic from the access
side to the network side, broadcast and multicast traffic still go
through the broadcast process. The priority control of unicast
traffic is as follows:
Liu & Wang Expires January 9, 2020 [Page 6]
Internet-Draft EVPN DEFAULT MAC July 2019
1) Query the detailed MAC entry, if it matches, the traffic is
forwarded according to the detailed MAC entry, otherwise go to 2);
2) Query the default MAC entry, if it matches, forward the traffic
according to the default MAC entry, otherwise go to 3);
3) Neither hit the detailed MAC entry nor hit the default MAC entry,
indicating that the device does not enable the MAC route receiving
capability and is unknown to unicast, and can only go through the
broadcast process.
5. Application Senario
5.1. Remote Interaction
The remote-side interaction refers to the interworking between the
users of different PEs. For the unicast traffic from the local PE to
the remote PE, the local PE hits the default MAC address and goes to
the remote PE. The unicast traffic of the local PE takes precedence
over the detailed MAC address. If the detailed MAC is missed, the
broadcast is performed.
For the case where the local PE is dual-homed to two remote PEs,
there exists two senarios:
1) In the dual-active scenario, the 0 MAC routes or the 0 MAC route/
EVI-AD routes sent by the remote PE1 and the remote PE2 form a load-
sharing relationship on the local PE.
2) For the single-live scenario, the 0 MAC routes or the 0 MAC route/
EVI-AD routes sent by the remote PE1 and the remote PE2 form a
master/slave relationship on the local PE.
Based on the implementation of 1) and 2), the local PE can be
instructed to go to the remote PE for unicast traffic with ms-level
fault fast switch.
For the case where the remote PE is dual-homed to two local PEs, the
existing dual-homing technology is completely inherited, and no
additional scenario expansion is required.
For ARP/ND pickup, the local ARP/ND learning extension is required to
generate a 0 MAC ARP/ND pickup entry. After the remote PE receives
the ARP/ND route, the extension supports the generation of a 0 MAC
ARP/ND pickup entry.
For the E-Tree function, the flag corresponding to the Root and Leaf
roles is carried in the MAC route as the E-Tree extended community
Liu & Wang Expires January 9, 2020 [Page 7]
Internet-Draft EVPN DEFAULT MAC July 2019
attribute content, and the default MAC route advertisement and
reception processing is not additionally processed.
5.2. Local Interaction
Local interaction refers to the interworking of user traffic on the
same PE. To prevent local traffic from hitting the default MAC
address, set the MAC aging time to be greater than the ARP aging time
on the local PE. For example, the default ARP aging time is 20
minutes, then the MAC aging time can be configured to 30 minutes. As
a result, MAC address entries for local interworking are always
present. You do not need to consider the impact of matching the
default MAC address.
When the MAC address aging time is less than 20 minutes, once the
destination MAC address is aged out, the local PE will match the
default MAC address. The solution may be: The access side is
flooded, and the default MAC address is taken on the network side.
Therefore, once the destination user goes online, the flooding on the
access side will disappear. However, the MAC address of the remote
interworking will continue to flood, and the impact on the network
may only be reduced by configuring BUM suppression.
6. Security Considerations
By default, the MAC route is an abnormal route. The route receiving
router may not support the forwarding process based on the default
MAC route. Forcibly receiving the 0 MAC route may cause the
forwarding exception. Therefore, if the MAC route receiving capacity
is not configured, 0 MAC routes must be discarded.
7. Acknowledgements
The author of this document would like to thank Yuan Gao, Yang Huang,
Tong Zhu for their comments and review of this document.
8. Contributors
The following individuals gave significant contributions to this
document:
Haibo Wang
Huawei Technologies
rainsword.wang@huawei.com
Liu & Wang Expires January 9, 2020 [Page 8]
Internet-Draft EVPN DEFAULT MAC July 2019
9. References
[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, <https://www.rfc-editor.org/info/rfc7432>.
Authors' Addresses
GuoLiang
Huawei Technologies
101 software Avenue, Yuhua District
Nanjing 210012
China
Email: liuguoliang@huawei.com
Haibo
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 10095
China
Email: rainsword.wang@huawei.com
Liu & Wang Expires January 9, 2020 [Page 9]
