Internet DRAFT - draft-jiang-bess-evpn-split-horizon-enhancement
draft-jiang-bess-evpn-split-horizon-enhancement
BESS Working Group J. He, Ed.
Internet-Draft B. Nie
Intended status: Standards Track Ericsson
Expires: December 5, 2020 June 3, 2020
EVPN Split Horizon Filtering Enhancement
draft-jiang-bess-evpn-split-horizon-enhancement-00
Abstract
Ethernet Virtual Private Network (EVPN) multi-homing accommodates
load balance, link/node redundancy and fast convergence. The split
horizon filtering in EVPN avoids loop happens on multi-homed CE.
However, this mechanism brings challenges switching chipsets on data
plane. This document describes an approach for the challenges by
enhancing current split horizon filtering mechanism. The advantage
of this approach is that it simplifies data plane behaviors.
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 December 5, 2020.
Copyright Notice
Copyright (c) 2020 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
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
He & Nie Expires December 5, 2020 [Page 1]
Internet-Draft EVPN Split Horizon Filtering Enhancement June 2020
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. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Advertising EVPN VRF Route Import Extended Community . . 4
4.2. Constructing IMET Routes . . . . . . . . . . . . . . . . 4
4.3. Flooding Handling on Data Plane . . . . . . . . . . . . . 5
5. EVPN VRF Route Import Extended Community . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6.1. EVPN VRF Route Import Extended Community . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Ethernet Virtual Private Network (EVPN) multi-homing accommodates
load balance, link/node redundancy and fast convergence. The split
horizon filtering in EVPN avoids loop happens on multi-homed CE. In
particular, there are two split horizon filtering mechanisms to avoid
looped frames on the multi-homed CE: ESI Label based [RFC7432] for
MPLS based tunnels and Local Bias[RFC8365] for non-MPLS NVO tunnels,
E.g. VXLAN tunnels.
However, each mechanism introduces challenges for data plane because
extra logic is introduced but not available on some typical switching
chipsets. ESI Label based mechanism requires ingress PE to push ESI
label into MPLS stack to indicate Ethernet Segment Identifier, and
requires egress PE to filter out the corresponding port based on ESI
label before flooding. Local Bias does not require ingress PE to
have extra procedure but still requires egress PE to filter out the
corresponding ports based on source IP address before flooding.
This document describes an approach towards the challenges, by
enhancing current Local Bias split horizon filtering mechanism, for
MPLS based tunnels and non-MPLS NVO tunnels. The advantage of this
approach is that it simplifies data plane behaviors.
2. 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 BCP
He & Nie Expires December 5, 2020 [Page 2]
Internet-Draft EVPN Split Horizon Filtering Enhancement June 2020
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
BUM: Broadcast, Unknown unicast and Multicast
CE: Customer Edge device, e.g., a host, router, or switch.
Ethernet Segment (ES): When a customer site (device or network) is
connected to one 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'.
EVI: An EVPN instance spanning the Provider Edge (PE) devices
participating in that EVPN.
EVPN: Ethernet Virtual Private Network
NVO: Network Virtualization Overlay
PE: Provider Edge device.
VXLAN: Virtual Extensible LAN
NVGRE: Network Virtualization using Generic Routing Encapsulation
VNI: VXLAN Network Identifier
VSID: Virtual Subnet Identifier (for NVGRE)
3. Approach
When the PE advertises Inclusive Multicast Ethernet Tag (IMET) Routes
to PEs which share the same multi-homed CE, it allocates unique label
for each PE, rather than using the same label for all PEs. To
accomplish this, An EVPN VRF Route Import Extended Community is
introduced.
When the PE receives BUM packet from ingress PE, based on the BUM
label encapsulated, it can determine the packet is from PEs which
share the same multi-homed CE or not. If yes, the PE can also
determine which PE the packet is from. Because the PE has determined
the ingress PE, Local Bias based mechanism can be implemented for
split horizon filtering without source IP information, but simply
based on a single BUM label to determine the flooding scope.
He & Nie Expires December 5, 2020 [Page 3]
Internet-Draft EVPN Split Horizon Filtering Enhancement June 2020
For NVO solution, this approach requires locally assigned VNIs to be
used just like downstream-assigned MPLS labels.
Based on this extended mechanism, for MPLS based tunnels, no ESI
label encapsulation is required on ingress PE either.
4. Procedures
Let's suppose an EVPN network, where CE1 is multi-homed to PE1 and
PE2 with all-active mode, CE2 and CE3 are single-homed to PE2 and PE3
separately.
+--------------+
/--- PE1 | |
CE1 | EVPN | PE3 --- CE3
\--- PE2 | |
| +--------------+
CE2
Figure 1: Sample EVPN Multi-homing Scenario
4.1. Advertising EVPN VRF Route Import Extended Community
In order to receive IMET route with unique label assigned by multi-
homed peer, each VRF on PE1 MUST have an import Route Target Extended
Community, and communicate the value to all other multi-homed peers.
We refer to this Route Target as the "EVPN IMET Import RT", as this
Route Target controls imports of EVPN IMET routes into a particular
VRF.
To communicate the value to all other multi-homed peers, PE1 when
advertising an Ethernet Auto-discovery Route per EVI SHALL carry the
EVPN VRF Route Import Extended Community (as defined in Section 5)
that has the value of the EVPN IMET Import RT of the VRF associated
with the route.
4.2. Constructing IMET Routes
Once EVPN routes with EVPN VRF Route Import Extended Community
received on PE2, PE2 extracts the value of the EVPN VRF Route Import
Extended Community. The value of EVPN IMET Import RT is set to this
value.
Besides advertising IMET routes to other PEs as usual, PE2 advertises
IMET route with unique BUM label to each multi-homed peer (here only
PE1) by using EVPN IMET Import RT as route target. It is suggested
He & Nie Expires December 5, 2020 [Page 4]
Internet-Draft EVPN Split Horizon Filtering Enhancement June 2020
to set a higher LOCAL_PREF for this BGP message, if another general
IMET route is sent to PE1 also.
Now suppose PE3 receives IMET route with label BUM0 from PE2, and PE1
receives IMET route with label BUM1 from PE2.
4.3. Flooding Handling on Data Plane
Once PE2 advertises all IMET routes, including general and unique
ones, it sets data plane to handle BUM labels as figure 2 described
below (Suppose it is the Designated Forwarder).
+-----------+-------------+
| In Label | Out Ports |
+-----------+-------------+
(from PE3) -> | BUM0 | CE1, CE2 |
+-----------+-------------+
(from PE1) -> | BUM1 | CE2 |
+-----------+-------------+
Figure 2: Flooding handling on PE2 Data Plane
Now BUM traffic is properly handled, no matter from multi-homed peers
(E.g. PE1) or other PEs (E.g. PE3). Unlike ESI Label based or
Local Bias which requires two parameters for flooding decision, this
flooding behavior requires only one parameter, the single BUM label.
5. EVPN VRF Route Import Extended Community
This document defines a new BGP Extended Community called "EVPN VRF
Route Import".
The EVPN VRF Route Import is an IP-address-specific Extended
Community, of an extended type, and is transitive across AS
boundaries [RFC4360].
The EVPN VRF Route Import Extended Community has following format:
0 1 2 3
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 | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator (cont.) | Local Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
He & Nie Expires December 5, 2020 [Page 5]
Internet-Draft EVPN Split Horizon Filtering Enhancement June 2020
This document expands the definition of EVPN Extended Community
[RFC7153]. This Extended Community has a Type field value of 0x06
and the Sub-Type TBD.
The Global Administrator field of the EVPN VRF Route Import EC MUST
be set to an IP address of the PE. This address SHOULD be common for
all the VRFs on the PE (e.g., this address may be the PE's loopback
address).The Local Administrator field of the EVPN VRF Route Import
EC associated with a given VRF contains a 2-octet number that
uniquely identifies that VRF within the PE.
For procedures and usage of this attribute, please see Section 4
6. IANA Considerations
6.1. EVPN VRF Route Import Extended Community
This document makes the following registrations for EVPN VRF Route
Import Extended Community.
Type Description
---- -----------
TBD EVPN VRF Route Import Extended Community
7. Security Considerations
If BGP is used as a CE-PE routing protocol, then when a PE receives a
route from a CE, if this route carries the EVPN VRF Route Import
Extended Community, the PE MUST remove this Community from the route
before turning it into a VPF. Routes that a PE advertises to a CE
MUST NOT carry the EVPN VRF Route Import Extended Community.
8. 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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <https://www.rfc-editor.org/info/rfc7153>.
He & Nie Expires December 5, 2020 [Page 6]
Internet-Draft EVPN Split Horizon Filtering Enhancement June 2020
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
Authors' Addresses
Jiang He (editor)
Ericsson
No. 5, Lize east street, Chaoyang district
Beijing 100102
CN
Email: jiang.he@ericsson.com
Bolin Nie
Ericsson
No. 5, Lize east street, Chaoyang district
Beijing 100102
CN
Email: zephyr.nie@ericsson.com
He & Nie Expires December 5, 2020 [Page 7]
