Light Weighted EVPN
draft-wang-bess-evpn-cmac-overload-reduction-05
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 | Yubao Wang , Ran Chen | ||
| Last updated | 2021-03-08 | ||
| 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-wang-bess-evpn-cmac-overload-reduction-05
BESS WG Y. Wang
Internet-Draft R. Chen
Intended status: Standards Track ZTE Corporation
Expires: 9 September 2021 8 March 2021
Light Weighted EVPN
draft-wang-bess-evpn-cmac-overload-reduction-05
Abstract
SRv6 EVPN [I-D.ietf-bess-srv6-services] is not sufficient for some
light-weighted use cases. When PBB EVPN [RFC7623] over SRv6 is used
to support these light-weighted EVPN services, it is complicated to
make use of the SID list to carry a function that is aiming for
C-MACs.
In [I-D.ietf-spring-srv6-network-programming], End.DX2 function is
defined, this function can be used in EVPN VPLS. When it is used in
EVPN VPLS, the data-plane learning defined in End.DT2U function can
also be transplanted into End.DX2 function. On the basis of such
extended End.DX2 function, SRv6 EVPN can be improved to meet all the
requirements per [RFC7623] and bring us some other benefits. Such
SRv6 EVPN is called light-weighted SRv6 EVPN, and it will be more
simpler than PBB EVPN over SRv6.
It is easy for the light-weighted SRv6 EVPN to carry a SID that is
aiming for customer ethernet packets, because there will be no other
ethernet header between the SID list and the customer ethernet
header. These SIDs may be user-defined functions for the customer
ethernet headers.
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 9 September 2021.
Wang & Chen Expires 9 September 2021 [Page 1]
Internet-Draft EVPN-lite March 2021
Copyright Notice
Copyright (c) 2021 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 the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. No C-MAC Awareness in the Backbone . . . . . . . . . . . 5
2.2. Flexible Multi-homing Remains Supported . . . . . . . . . 5
2.3. C-MAC Address Learning and Confinement . . . . . . . . . 6
2.4. No C-MAC Flushing for All-Active ESes . . . . . . . . . . 6
2.5. Independent C-MAC Flushing for Single-Active ESes . . . . 6
2.6. Independent Convergency per <ESI, EVI> . . . . . . . . . 6
2.7. ESI Route Aggregation in Backbone . . . . . . . . . . . . 7
2.8. Unequal load-balance . . . . . . . . . . . . . . . . . . 7
2.9. AC-aware Service Interface . . . . . . . . . . . . . . . 7
2.10. ESI-agnostical Core-Routers . . . . . . . . . . . . . . . 7
3. Light-Weighted SRv6 EVPN Overview . . . . . . . . . . . . . . 7
3.1. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Solution Overview . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Aggregatable End.DX2 SID . . . . . . . . . . . . . . 8
3.2.2. The Advertisement of ESI-Prefixes . . . . . . . . . . 9
3.3. Packet Walkthrough . . . . . . . . . . . . . . . . . . . 10
4. Decapsulation Optimizations . . . . . . . . . . . . . . . . . 12
4.1. Decapsulation Aggregation . . . . . . . . . . . . . . . . 12
4.2. End.DX2AGG Function and Arg.EGD . . . . . . . . . . . . . 13
5. Advanced Considerations . . . . . . . . . . . . . . . . . . . 13
5.1. ESI SID Aggregation . . . . . . . . . . . . . . . . . . . 14
5.2. ESI/AC SID Advertisement Optimization . . . . . . . . . . 14
5.2.1. Advertise ESI-Locators in Underlay Network . . . . . 14
5.2.2. Do not Advertise ESI-Locators in Underlay Network . . 15
5.2.2.1. Using EAD/EVI Route to Advertise AC SIDs . . . . 15
5.2.2.2. Using EAD/ES Route to Advertise ESI SIDs . . . . 15
5.2.3. The Reduction of EAD/EVI Routes . . . . . . . . . . . 16
Wang & Chen Expires 9 September 2021 [Page 2]
Internet-Draft EVPN-lite March 2021
5.3. Unequal LB Advertisement . . . . . . . . . . . . . . . . 16
5.4. AC-aware Bundling Service Interface . . . . . . . . . . . 17
5.5. C-MAC Flush Notification Procedure . . . . . . . . . . . 17
5.6. E-Tree Support Considerations . . . . . . . . . . . . . . 17
5.7. EVPN IRB Support Considerations . . . . . . . . . . . . . 17
6. Comparison with Other Solutions . . . . . . . . . . . . . . . 17
6.1. Detailed Comparisons with PBB EVPN over SRv6 . . . . . . 18
6.2. Detailed Comparisons with Anycast Node SID . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. End.DX2AGG SID . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10. Normative References . . . . . . . . . . . . . . . . . . . . 19
11. Informative References . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
1.1. Background
When there are too many customer-MACs (C-MACs), the RRs and/or ASBRs
will be overloaded by the RT-2 routes for these MACs according to
[RFC7432]. This issue can be solved by light-weighted EVPNs. PBB
EVPN [RFC7623] is a MPLS-based light-weighted EVPN solution. But in
SRv6 network, PBB EVPN over SRv6 is not a good choice for light-
weighted EVPN solution.
This document proposes some new extensions to
[I-D.ietf-bess-srv6-services] to achieve all-active mode ES
redundancy on TPEs and reduce the C-MAC loads for RRs and ASBRs at
the same time. The new solution will work even more better than PBB
EVPN under the help of these extensions, especially when there is no
deployment of MPLS dataplane.
Furthermore, it naturally brings the benefits of high scalability,
faster network convergence, and reduced operational complexity, and
we call it light-weighted EVPNs because of these advantages.
1.2. Overview
In [RFC7432], the C-MACs is advertised via RT-2 route. This behavior
is inheritted by [I-D.ietf-bess-srv6-services]. but in order to
solve the C-MAC overload problem for RRs and ASBRs, we have to return
to a PBB-like dataplane C-MAC learning procedures.
Wang & Chen Expires 9 September 2021 [Page 3]
Internet-Draft EVPN-lite March 2021
We discuss all the requirements for a light-weighted EVPN solution
which pushes no C-MAC entries into the backbone network in Section 2.
Note that some of these requirements is not supported well by PBB
EVPN.
In this document, the light-weighted EVPN solutions are also called
as EVPN-lite for short.
Note that the EVI here corresponds to the I-Component of [RFC7623],
not the B-Component. In fact, there will be no typical B-components
in EVPN-lite SRv6 solutions.
1.3. Terminology
Most of the terminology used in this documents comes from [RFC7432]
and [I-D.ietf-bess-srv6-services] except for the following:
* Light-weighted EVPN: The EVPN solution with high scalability and
reduced operational complexity.
* EVPN-lite: The Light-weighted EVPN is also called EVPN-lite for
short.
* C-MAC: Customer MAC, it is the same as the C-MAC of PBB EVPN.
* ISID: a broadcast domain identifier in PBB I-Component.
* LDV: Local Discreminating Value. It is similar to the Local
Discreminating Value of type 3 ESI.
* GDV: Global Discreminating Value. An identifier with global
uniqueness.
* EGD: EVI-GDV, an EVI's Global Discreminator, it is a GDV for an
EVI instance. A EGD is used to idenfify an EVPN Instance (EVI) in
data plane. The EGD is a Global Discreminating Value (GDV) of
that EVI, so it is also the abbreviation of EVI-GDV. e.g. The
EGD of [RFC7348] is a global VNI. In this draft, the EGD of an
EVI is that EVI's VPN ID of global uniqueness.
* AC SID: The End.DX2 SID of a specified AC, different ACs on the
same ES have different AC SIDs.
* ESI SID: An SRv6 SID whose function type is End.DX2AGG. Note that
when the ESI is all-active mode, the ESI SID is the same on all
PEs of that ES, according to Section 3.2. In such case, the ESI
SID can be called as ES anycast SID too. Different ACs on the
same ES have the same ESI SID with different Arg.EGD.
Wang & Chen Expires 9 September 2021 [Page 4]
Internet-Draft EVPN-lite March 2021
* ESI IP: The End.DX2AGG SID of a specified ESI, but with an empty
Arg.EGD.
* ESI Prefix: The IPv6 Prefix that covers all AC-SIDs of the
specified ESI.
* EAD/ES: Ethernet A-D route per EVI, or RT-1 per ES route.
* EAD/EVI: Ethernet A-D route per EVI, or RT-1 per ES route.
* Arg.EGD: The argument part of a SID of the End.DX2AGG function is
called as Arg.EGD, because the value of that argument will be a
AC-ID.
* RT-2: MAC/IP Advertise Route.
* MAC Entry: An entry in the EVPN MAC table in data-plane.
2. Requirements
Light-weighted SRv6 EVPNs should be provided together with the
following requirements:
2.1. No C-MAC Awareness in the Backbone
In typical operation, an EVPN PE sends a BGP MAC Advertisement route
per C-MAC address. In certain applications, this poses scalability
challenges, as is the case in data center interconnect (DCI)
scenarios where the number of virtual machines (VMs), and hence the
number of C-MAC addresses, can be in the millions. This is called as
C-MAC overload of DC Backbone. In such scenarios, it is required to
reduce the number of BGP MAC Advertisement routes by relying on a
'EVPN-lite' scheme, as is provided by ESI and its equivalents (e.g.
Pseudo B-MAC, ESI IP).
2.2. Flexible Multi-homing Remains Supported
Flexible multi-homing means that different ES instances can have
different adjacent-PEs. We call all the adjacent-PEs of the same ES
instances as that ES's location-set in this document. Flexible
multi-homing means that different ES can have different location-set.
For example, ES1's location-set is {PE1}, ES2's location-set is {PE2,
PE3}, ES3's location-set is {PE1, PE3}, and ES4's location-set is
{PE2,PE4}.
Wang & Chen Expires 9 September 2021 [Page 5]
Internet-Draft EVPN-lite March 2021
2.3. C-MAC Address Learning and Confinement
In EVPN, all the PE nodes participating in the same EVPN instance are
exposed to all the C-MAC addresses learnt by any one of these PE
nodes because a C-MAC learnt by one of the PE nodes is advertised in
BGP to other PE nodes in that EVPN instance. This is the case even
if some of the PE nodes for that EVPN instance are not involved in
forwarding traffic to, or from, these C-MAC addresses. Even if an
implementation does not install hardware forwarding entries for C-MAC
addresses that are not part of active traffic flows on that PE, the
device memory is still consumed by keeping record of the C-MAC
addresses in the routing information base (RIB) table. In network
applications with millions of C-MAC addresses, this introduces a non-
trivial waste of PE resources. As such, it is required to confine
the scope of visibility of C-MAC addresses to only those PE nodes
that are actively involved in forwarding traffic to, or from, these
addresses.
2.4. No C-MAC Flushing for All-Active ESes
Just as in [RFC7623], it is required to avoid C-MAC address flushing
upon link, port, or node failure for remote All-Active multihomed
segments.
Note that when an ESI fails on PE1, it may still works well on PE2,
so the C-MACs should not be flushed.
2.5. Independent C-MAC Flushing for Single-Active ESes
Just as in [RFC7623], upon single-active ESI's link or port failure,
the C-MACs of other single-active ESes from the same PE will not be
flushed.
2.6. Independent Convergency per <ESI, EVI>
When the physical port of an All-Active ES works well, but a single
Ethernet Tag ID (ETI) of that ES fails, The traffic to that ETI of
that ES will be re-routed to other adjacent PE of the same ES, but
the traffic to other ETIs of the same ES will not be affected.
Note that when AC (ES link) fails but PE node still works well, there
should not be steady bypassing traffic either. The steady bypassing
problem is discussed in [I-D.wang-bess-evpn-egress-protection].
Wang & Chen Expires 9 September 2021 [Page 6]
Internet-Draft EVPN-lite March 2021
2.7. ESI Route Aggregation in Backbone
In SRv6 EVPN, different sub-interfaces of the same ESI can have
different AC-SIDs in order to achieve Independent Convergency per
<ESI, EVI>. But only the common prefix (say ESI-Prefix) of them
should be advertised in underlay network.
Note that only the common prefix need to be advertised in the overlay
network before any of these sub-interfaces failed.
Note that different ESIs may use the same SRv6 locator. In such
case, these ESI SIDs are aggregated into that anycast SRv6 locator
while they are advertised in the underlay network.
2.8. Unequal load-balance
The light-weighted EVPNs should support the unequal load-balance
defined in [I-D.ietf-bess-evpn-unequal-lb].
2.9. AC-aware Service Interface
In AC-aware bundling service interface
[I-D.sajassi-bess-evpn-ac-aware-bundling], the ESes may make its two
VLANs to be attached to the same broadcast domain. These two VLANs
may be assigned to the same sub-interface, or to different sub-
interfaces.
2.10. ESI-agnostical Core-Routers
We should not make the core-routers aware of any per-EVI routing
information of an ESI. Because they are just underlay nodes.
The core-routers may not even want to aware of any SRv6 locators of
these ESIs either. In such case, the anycast ESI SID should be hiden
into the SRH, and it is the inner SID for the Node SID of the egress
PE.
3. Light-Weighted SRv6 EVPN Overview
3.1. Use Case
The ethernet segment ES1's ESI is ESI1, the ES1 is attached to EVPN
instance EVI1 via attachment circuit AC1 on PE1, the ES1 is attached
to EVPN instance EVI1 via attachment circuit AC2 on PE2, We assign an
End.DX2 SID SID_AC1 to AC1, and we assign an End.DX2 SID SID_AC2 to
AC2. The ethernet segment ES2's ESI is ESI2, the ES2 is attached to
EVPN instance EVI1 via attachment circuit AC3 on PE3, We assign an
End.DX2 SID SID_AC3 to AC3.
Wang & Chen Expires 9 September 2021 [Page 7]
Internet-Draft EVPN-lite March 2021
+----------+
PE1 | |
+-------------+ | |
| SID_AC1 | | | PE3
/| |----| | +-------------+
/ | | | SRv6 | | |
LAG / +-------------+ | Backbone | | SID_AC3 |---CE2
CE1===== | | | |
\ +-------------+ | |---| |
\ | | | | +-------------+
\| |----| |
| SID_AC2 | | |
+-------------+ | |
PE2 | |
+----------+
Figure 1: EVPN MAC Reduction Usecase
We use IMET routes to build a broadcast-list. The broadcast-list is
used to forward BUM traffics. The data-plane MAC learning for BUM
traffics produces the first batch of C-MAC entries. The subsequent
C-MAC entries can be learnt from Unicast traffics and/or BUM
traffics. It is clear that we don't use MAC/IP routes to advertise
C-MAC entries as usual, that is for fear that the RRs and/or SPEs are
overloaded by these C-MACs.
3.2. Solution Overview
3.2.1. Aggregatable End.DX2 SID
When an Ethernet Segment ES1 is attached to an EVI, the attachment-
circuit AC1 for that <ESI,EVI> is assigned with an End.DX2 SID.
Different ACs of the same ESI are assigned with different End.DX2
SIDs, we call them AC SIDs in this document. But these different
End.DX2 SIDs must be able to be aggregated into the same prefix, and
this prefix are called as ESI prefix in light-weighted SRv6 EVPNs.
The format of aggregatable End.DX2 SIDs is illustrated in the
following figure:
|<--- ESI-Prefix(128-N bits) ---->|<---- N bits --->|
+------------+------------+-----------+-------------------------+
| Block | Node | ESI.LDV | AC-ID |
+------------+------------+-----------+-------------------------+
|<------ Locator -------->|<------------- Function ------------>|
Figure 2: End.DX2 SID Formart for Aggregation
Wang & Chen Expires 9 September 2021 [Page 8]
Internet-Draft EVPN-lite March 2021
Note that the ESI.LDV field is the Local Discreminator Value (LDV) of
the ESI (especially the type 3/4/5 ESI). The AC-ID field is the
identifier of the AC's EVI. The ESI.LDV field and the AC-ID field
are integrated into the End.DX2 SID's Function part.
Note that in "AC-aware bundling service interface" the AC-ID field
MUST be the same as the Attachment Circuit ID of
[I-D.sajassi-bess-evpn-ac-aware-bundling]. But in other service
interfaces the AC-ID field can also be the EGD of that AC's EVPN
instance. Note that the EGD has a global meaning like a global VNI
or a PBB I-SID, while the ordinary AC-ID part for an aggregatable
End.DX2 SID typically is only a VLAN-ID on that ES.
Note that the ESI IP of an AC is that AC's End.DX2 SID but with a
zero AC-ID. The AC SIDs have non-zero AC-IDs, but the ESI-IPs always
have zero AC-IDs. Becuase an ESI-IP identifies an ESI, not an AC.
Note that if ESI1 is single-active mode, SID_AC1 is different from
SID_AC2, but if ESI1 is all-active mode, SID_AC1 is the same as
SID_AC2, we can call them SID21 in such case.
3.2.2. The Advertisement of ESI-Prefixes
The ESI-prefixes of SID_AC1 and SID_AC2 are defined in Figure 2, and
they are called ESI_Prefix1 and ESI_Prefix2 respectively. We can use
IGP protocols to advertise these ESI-Prefixes to PE3 respectively in
SRv6 underlay. So we don't have to use EAD/ES route or EAD/EVI route
in SRv6 EVPN in this section.
Note that the SRv6 SID in IMET route is an End.DT2M SID but with a
zero argument length.
Note that if ESI1 is single-active mode, ESI_Prefix1 is different
from ESI_Prefix2, but if ESI1 is all-active mode, ESI_Prefix1 is the
same as ESI_Prefix2.
Note that when PE1 node fails and the ESI is all active, the PLR node
will do underlay anycast FRR switching for SID21(=SID_AC2=SID_AC1).
This will bring out fast network convergency.
Note that when the PE-CE link of ESI1 fails, the IGP route of
ESI_Prefix1 will be withdrawn, So there will be no steady bypassing
for that ES, but a temporary bypassing can be performed to further
improve the convergency.
When two ESes are attached to the same redundancy group of PEs, they
can share the same anycast SRv6 Locator. In such case, only the
common SRv6 Locator is advertised by the underlay network. But they
Wang & Chen Expires 9 September 2021 [Page 9]
Internet-Draft EVPN-lite March 2021
should have different ESI-Prefix. Because that the ESI-SID
Aggregation is not recommanded to be activated in order to avoid the
steady bypass problems described in Section 5.1.
The detailed comparisons between light-weighted SRv6 EVPN and PBB
EVPN over SRv6 is described in Section 6.
3.3. Packet Walkthrough
#1 [PE1 forward ARP Request to PE2/PE3]
* When CE1 requests CE2's ARP, PE1 will receive the ARP Request BUM1
from AC1 of ESI1. PE1 will forward the ARP Request following the
broadcast-list of AC1's EVPN instance EVI1. The broadcast-list is
constructed by the IMET routes from PE2 and PE3. The End.DX2 SID
of AC1 is named as SID_AC1.
PE1 will forward the ARP Request to PE2 and PE3. The inner SMAC
of the ARP request is M1 which is CE1's MAC address.
* In this step, PE1 will forward the ARP Request BUM1 to PE2/PE3
with the following SRv6 encapsulation: It's underlay Source IP is
the End.DX2 SID (SID_AC1) on PE1 for the ingress AC; It's underlay
Destination IP is the End.DT2M SID (whose argument length is zero)
on PE2/PE3.
Note that the underlay SIP will be the End.DT2U SID (because they
don't need any dedicated End.DX2 SIDs) for the single-homed
ingress ACs. The multi-homed ingress ACs with single-active
behavior may not be assigned with a dedicated ESI-Prefix either.
In such situations, the underlay SIP can be the End.DT2U SID too.
Note that in such situations, the AC SIDs of all single-active
ESIs for the same EVI are aggregated into the same End.DT2U SID.
#2 [PE2/PE3's Dataplane MAC Learning]
* When PE2/PE3 receives the ARP Request packet BUM1, they do
dataplane MAC learning independently. They will learn that M1 is
behind SID_AC1.
Note that when PE2 learns that M1 is behind SID_AC1, it will
assume that M1 is behind the local AC (AC2) whose End.DX2 SID
(SID_AC2) is the same as SID_AC1 too. The local AC may have more
higher priority than the remote one.
After the dataplane MAC learning, the ARP request packet BUM1 is
broadcasted to the local ACs, behind one of which is CE2.
Wang & Chen Expires 9 September 2021 [Page 10]
Internet-Draft EVPN-lite March 2021
#3 [PE2 Discard ARP Request to CE1]
* On receiving BUM1 from PE1, PE2 use the ingress ESI information
(SID_AC1) in BUM1 to determine its ingress ESI-Prefix, When ESI1
is all-active mode and PE2 is about to forward the ARP request to
CE1, PE2 will find that the AC SID (SID_AC2) for the outgoing AC
(AC2) is of the same ESI-Prefix, so PE2 discards it for ESI loop-
free considerations.
Note that before that ARP Request packet is discarded, its source-
MAC can be learnt, especially in "AC-aware bundling service
interface". The MAC entry is learnt against SID_AC1, but it will
consider the local sub-interface (of the same AC SID) on that ES
as its outgoing interface, in order to avoid unknown-unicast
flooding.
When ESI1 is single-active mode, the outgoing AC may be in
blocking state, otherwise its corresponding sub-interface on CE1
will take charge of packet-drop behavior instead. So although the
AC-SID (SID_AC2) for the outgoing AC is not the same as SID_AC1,
no loop will arise in the Ethernet Segment.
* In this step, PE2 can compare the ingress AC-SID of BUM1 and the
AC-SID of outgoing AC directly, no SID-to-ESI lookup needed.
#4 [PE3 Forward ARP Replay to PE1/PE2]
* When CE2 replies to CE1 for the ARP request BUM1, PE3 will forward
the ARP reply U1 according to the MAC entry M1 learnt previously
as above.
PE3 will forward the ARP reply U1 to PE1 or PE2 according to
SID_AC1's SRv6 locator's IGP route.
When ESI1 is all-active mode, SID_AC1 will be the same as SID_AC2,
in such case, we call both of them SID21 instead. The traffics to
M1 will be load-balanced between PE1 and PE2. Because that
SID21's locator is advertised by both PE1 and PE2 in the underlay
IGP protocol.
* In this step, PE3 will forward the ARP reply U1 to PE1 with the
following SRv6 encapsulation: It's underlay Source IP is the
End.DX2 SID on PE3 for AC3; It's underlay Destination IP is the
End.DX2 SID (SID_AC1) on PE1 for AC1 according to the MAC entry
M1.
Wang & Chen Expires 9 September 2021 [Page 11]
Internet-Draft EVPN-lite March 2021
Note that if the DIP is just the anycast node SID of PE1 and PE2,
when the PE-CE link of ESI1 fails, the traffic will be steadily
bypassed untill that link recovers again. That's why MAC-entries
should be learnt against AC-SIDs.
#5 [PE1 Forward ARP Replay to CE1]
* When PE1 receives the ARP reply packet U1 from PE3, PE1 first
match the packet to the its EVI instance EVI1 by U1's destination
End.DX2 SID. And PE1 will not discard it because the egress AC's
AC-SID is not the same as the ingress AC-SID (which is represented
by U1's source IP).
* In this step, When PE1 receives the SRv6 encapsulated ARP reply
packet U1 from PE3, PE1 first match the packet to the End.DX2 SID
of AC1 by DIP, then match the packet to AC1's EVI instance EVI1.
4. Decapsulation Optimizations
4.1. Decapsulation Aggregation
We want to decapsulation the packets destining to different ESIs for
the same EVI using the same forwarding entry. In order to achieve
this benefit, we can use an AC's EVI's EGD as that AC's AC SID's AC-
ID.
These AC SIDs are aggregatable End.DX2 SIDs, so we can consider the
ESI prefix aggregated from these End.DX2 SIDs as a new SRv6 function
called End.DX2AGG SID, The format of the End.DX2AGG SID is
illustrated in the following figure:
|<------ Locator -------->|<- FUNC -->|<------ Arg.EGD -------->|
+------------+------------+-----------+-------------------------+
| Block | Node | ESI.LDV | EGD |
+------------+------------+-----------+-------------------------+
Figure 3: End.DX2AGG SID Format
Note that whether these SIDs are considered as lots of End.DX2 SIDs
or are considered as a single End.DX2AGG SID with different
arguments, it is just a local matter of their PE node's independent
choice, other PEs of the same EVI won't be aware of the difference of
these two implementations.
A SID with the End.DX2AGG function is called as an "ESI SID" in this
document. The ESI's ESI-Prefix is the locator and fuction part of
its corresponding ESI SID. The argument part of the ESI SID is the
AC-ID for the corresponding AC's End.DX2 SID. The AC-ID plus the
Wang & Chen Expires 9 September 2021 [Page 12]
Internet-Draft EVPN-lite March 2021
ESI.LDV works like the function part of an End.DX2 SID. The argument
part of an ESI SID is called as Arg.EGD in this document, where the
EGD is the abbreviation of EVPN Global Discreminator.
Note that when AC-ID is the EGD, PE2 can still decapsulate the packet
following the End.DX2 function or following the End.DX2AGG function.
It is just a local matter, while the End.DX2AGG function can reduce
the decapsulation forwarding entries. But when AC-ID is that AC's
VLAN-IDs, PE2 have to decapsulate the packet following the End.DX2
function.
4.2. End.DX2AGG Function and Arg.EGD
The "Endpoint with decapsulation and Aggregated L2 table forwarding"
behavior (End.DX2AGG for short) is a variant of the End.DX2 behavior.
Two of the applications of the End.DX2AGG behavior are the EVPN VPLS
[RFC7432] and the EVPN ETREE [RFC8317] use-cases.
Any SID instance of this behavior is associated with an ESI E. The
behavior also takes an argument: "Arg.EGD". This argument provides a
local mapping to an EVI V. The outgoing interface corresponds to
<ESI E, EVI V> is OIF, and the EVI V's bridge table is L2 Table T .
The End.DX2AGG SID MUST be the last segment in a SR Policy.
When N receives a packet whose IPv6 DA is S and S is a local
End.DX2AGG SID, the processing is identical to the End.DT2U behavior
except for the Upper-layer header processing which is as follows:
S01. If (Upper-Layer Header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 Header with all its extension headers.
S03. Determine the L2 Table T using Arg.EGD.
S04. Learn the exposed MAC Source Address in L2 Table T.
S05. Find out the OIF, and forward the Ethernet frame to the OIF.
S06. } Else {
S07. Process as per Section 4.1.1
of [I-D.ietf-spring-srv6-network-programming].
S08. }
Note that the OIF can be found out using the MAC-entries in L2
Table T, when the EVI V is an E-LAN service.
5. Advanced Considerations
Wang & Chen Expires 9 September 2021 [Page 13]
Internet-Draft EVPN-lite March 2021
5.1. ESI SID Aggregation
There are obvious difference between "Route Aggregation" and "SID
Aggregation" for an ESI. The "ESI Route Aggregation" is that
different End.DX2AGG SIDs are advertised by underlay protocols in a
common SRv6 locator, but different ESIs still have different
End.DX2AGG SIDs. The "ESI SID Aggregation" is that different ESIs
use the same SRv6 SID.
Note that the "ESI Route Aggregation" is recommanded as long as it is
possible, but the "ESI SID Aggregation" can only be used under
certain restraints.
When two ESes are attached to the same redundancy group of PEs, they
can share the same SRv6 SID. But this will bring out some issues
too. One of these issues is that they may be attached to different
groups of PEs in the future. Another issue is that when only one of
the ESes fails, that common SRv6 SID can't be withdrawn by that PE,
so the steady bypass of that ES arises immediately after its failture
on that PE. If these issues are not so important in some scenarios,
The ESI-SID Aggregation may be activated. This is an option.
Note that when ESI SID Aggregation is activated, the local-bias ES
split-horizon procedures or its variations should be used.
Note that ESI SID Aggregation works well with single-active ESIs (see
Section 3.3), its steadby bypassing problem will arise with all-
active ESIs only.
Note that the sub-interfaces of the same ESI may be assigned with
different End.DX2 SIDs, and these End.DX2 SIDs can be aggregated into
a common prefix, this common prefix is assigned with that ESI. In
such case, only the common prefix should be advertised before any of
the sub-interfaces fails. But this is not considered as "ESI SID
Aggregation", this is "ESI Route Aggregation".
5.2. ESI/AC SID Advertisement Optimization
5.2.1. Advertise ESI-Locators in Underlay Network
The End.DX2AGG SIDs can be advertised as an IP prefix in underlay IGP
protocols. Although it is the aggregation of many AC SIDs, the ESI
SIDs may still be too many for the underlay network. And the core
routers who are service-agnostic have to install these ESI prefixes.
In order to solve these problems, only the anycast SRv6 locators (say
ESI-Locators) of such ESI prefixes should be advertised in the
underlay network.
Wang & Chen Expires 9 September 2021 [Page 14]
Internet-Draft EVPN-lite March 2021
Note that in such case the ESI SID or AC SID don't have to be
advertised by EVPN routes in overlay network.
5.2.2. Do not Advertise ESI-Locators in Underlay Network
Once we use EVPN routes (EAD/ES route or EAD/EVI route) to advertise
ESI/AC SIDs among the PEs in the overlay network, their ESI-Locators
don't have to be advertised in underlay network again. Note that
these EVPN routes will not be installed by the core routers.
In such case, when the ESI SIDs are used as destination IP addresses,
they should be hiden in the SRH behind the node SID of the
corresponding egress PE router. This need to be encapsulated under
the help of EVPN routes of overlay network. So the ESI/AC SIDs must
be advertised in overlay network in such case.
Note that the association between an ESI/AC SID and its corresponding
Node SID is also advertised by such EVPN routes. The ESI-Locator may
not be advertised in underlay network because that the ESI/AC SIDs
won't be exposed untill they reached the egress PE.
5.2.2.1. Using EAD/EVI Route to Advertise AC SIDs
When the EAD/EVI routes here are used to advertise AC SIDs, the
End.DX2 SIDs are advertised in their SRv6 L2 Service TLVs, not in
their next hops. Their next hops will be the node SID of the
advertising PE.
In such case, the EAD/EVI routes will be installed as overlay routes,
and the AC SIDs learnt in the MAC entries is treated as the overlay
indexes for recursion.
5.2.2.2. Using EAD/ES Route to Advertise ESI SIDs
EAD/ES routes will be advertised/imported for EVIs but they should be
installed into Global Routing Table (GRT). Because there isn't a
dedicated B-component in EVPN-lite SRv6 like that in PBB VPLS and PBB
EVPN. The GRT plays a B-Component role in EVPN-lite SRv6.
Note that the EAD/ES routes won't be installed as overlay routes like
the EAD/EVI routes, because that we want to reduce the forwarding
table consumption.
Although ESI SIDs is installed into GRT, they are awared only on PE
nodes, the transit nodes in underlay network won't be aware of ESI
SIDs (they may aware the locators of these SIDs) in order to reduce
the FIB consumption.
Wang & Chen Expires 9 September 2021 [Page 15]
Internet-Draft EVPN-lite March 2021
Note that when the EAD/ES route here is used to advertise ESI SID,
the End.DX2AGG SID is advertised in its SRv6 L2 Service TLV, not in
its nexthop. Its nexthop will be the node SID of the advertising PE.
Note that in such case, the SRv6 source IP in the dataplane should be
set to the entire AC SID of the ingress AC, not just the ESI IP whose
AC-ID part is zero.
5.2.3. The Reduction of EAD/EVI Routes
In order to solve the problem described in Section 2.6, we may have
to advertise AC SIDs in the overlay network. But the amount of AC
SIDs may be hundreds of times larger than ESI SIDs. It is necessary
for the light-weighted SRv6 EVPNs to reduce the advertisement of AC
SIDs.
The AC SID of a specified <ESI,EVI> will not be advertised by its
PEs, until these PEs know that the <ESI,EVI> fails on at least one of
them.
Note that the entire AC SID for that <ESI,EVI> can be used as the
source IP of the SRv6 encapsulation before that AC SID is advertised
via EVPN routes. Because that when a MAC is learnt over that AC SID,
the packet for that MAC can also be forwarded according to the ESI-
Prefix or ESI-Locator of the corresponding ESI SID due to the longest
match procedures of IP lookup.
5.3. Unequal LB Advertisement
When the ESI SIDs are advertised by EVPN routes for the overlay
network according to Section 5.2.2, we can advertise the EVPN Link
Bandwidth extended community (see [I-D.ietf-bess-evpn-unequal-lb]) or
something else along with the ESI SIDs using such EVPN routes.
Note that these extra information (which are advertised along with
the EVPN routes) are awared by the PEs only. The underlay network
don't have to be aware of it.
Note that when the EVPN Link Bandwidth extended community is
advertised along with the ESI SID, The nexthop of the EAD/ES route
should not be set to the anycast ECMP Node SID of the advertising PE
(egress-PE). On receiving such EAD/ES route, the ingress PE may push
this EAD/ES route's nexthop onto the End.DX2AGG/End.DX2 SID when
constructing the SID stack, if unequal-LB is required.
Wang & Chen Expires 9 September 2021 [Page 16]
Internet-Draft EVPN-lite March 2021
5.4. AC-aware Bundling Service Interface
In AC-aware bundling service interface, each VLAN of the same AC
should have different AC-SID. So End.DX2AGG Function can't be used
in AC-aware bundling service interface.
Note that each VLAN of the same AC of the same EVPN instance will
have the same End.DX2 SID,
Note that in "AC-aware bundling service interface", the AC-ID inside
that SID_AC1 can help the MAC entry to be installed for the correct
outgoing interface. Such MAC entry is called as the synced MAC entry
of M1.
5.5. C-MAC Flush Notification Procedure
The withdraw of ESI SID Advertisement can be used as C-MAC (which was
learnt against that ESI SID) flush notification like what have been
done by [RFC7623] and [I-D.ietf-bess-pbb-evpn-isid-cmacflush].
Note that even if the EAD/EVI routes of Section 5.2 are not
advertised, the withdraw of those EAD/EVI route can still be used as
a C-MAC flush notification of their <ESI,EVI>.
5.6. E-Tree Support Considerations
E-tree Supprot extensions is similar to [RFC8317] section 5 except
for the following notable differences: The leaf B-MACs are replaced
by leaf ESI-SIDs, the root B-MACs are replaced by root ESI-SIDs. the
PBB encapsulation is replaced by other encapsulations, the
B-component is replaced by an IP-VRF or the underlay GRT. The B-MAC
Advertisement Route is replaced by EAD/EVI route or EAD/ES Route.
5.7. EVPN IRB Support Considerations
The dataplane in this draft is no more complex than typical SRv6
EVPN. So it will work as efficient as we should expect in SRv6 EVPN
IRB usecase.
6. Comparison with Other Solutions
We briefly compared light-weighted SRv6 EVPN with PBB-VPLS, PBB-EVPN
and VXLAN solutions in [Revision-01], further brief comparisions with
VTEP Group (and its transplantation in SRv6 network) were described
in [Revision-02]. So we just add the detailed comparisons between
EVPN-lite SRv6 and PBB EVPN over SRv6 in this revision.
Wang & Chen Expires 9 September 2021 [Page 17]
Internet-Draft EVPN-lite March 2021
6.1. Detailed Comparisons with PBB EVPN over SRv6
The "PBB EVPN over SRv6 underlay" solution will be complex, if we
address too much things. I have some examples in the following:
* The upper-layer header for SRv6 is the PBB-header for B-MACs, not
the ethernet header for C-MACs, so the SID list (SR-Path or
network programming Instructions) in the SRH can't be constructed
for the sake of the I-Component. For example, when a SRv6 SID for
MAC-guarding (or something else, just an example) present in the
SRH for PBB EVPN SRv6, I think it means BMAC-guarding, no C-MAC
guarding.
* The B-MACs for the all-active ESIs can't be aggregated, but the
SRv6 SIDs for ESIs can be aggregated. The underlay can advertise
the ESI-Locators only, so the burden of the underlay network may
not be increased too much. When the underlay routes is
aggregated, the C-MACs can also be learnt against /128 source-IP,
it is the advantage of a light-weighted SRv6 EVPN, which can't be
gained from a PBB header.
* The B-MACs are for overlay protection (the real overlay is the
I-VPLS, but the B-VPLS is also an overlay network from the
viewpoint of the SRv6 network). But the SRv6 SIDs for ESIs will
be for underlay protection, it works like the egress protection.
They are two different types of protecting solutions.
* Although PBB EVPN can be transplanted into SRv6 networks along
with the PBB header (say PBB EVPN over SRv6), It seems to be more
complicated to me. Take the EVPN IRB usecases for example, that
requires seven sequences of header processing, like (SRv6/B-MAC/C-
MAC)(Inner-IP)(C-MAC/B-MAC/SRv6), during the overlay L3
forwarding. I think it will be horrible enough for some ASICs to
implement it. When the processing is simplified as (SRv6/C-
MAC)(Inner-IP)(C-MAC/SRv6), it sounds like a step forward, not
backward, IMHO. We can achieve this goal easily inside the EVPN
framework, only if the data-plane learning can still be considered
as an option after PBB EVPN.
Fortunately, SRv6 is just too young to have a transplantation of PBB
EVPN. So it will waste nothing for the SRv6 nodes to give up the PBB
header that is never used by these SRv6 nodes. Note that the SRv6
functions (End.DT2U and End.DT2M) for L2VPNs have source-IP-based
data-plane learning for a long time already.
In EVPN IRB usecase, [I-D.ietf-bess-evpn-irb-extended-mobility]
defines some optional extensions to support some specific IRB
usecases. In these specific IRB usecases, the <MAC,IP> bindings will
Wang & Chen Expires 9 September 2021 [Page 18]
Internet-Draft EVPN-lite March 2021
change across VM-moves. These extensions can't be applied to PBB
EVPNs, and they can't be applied to light-weighted EVPNs either.
This will not prevent PBB EVPNs and light-weighted EVPNs from
supporting typical IRB use-cases.
6.2. Detailed Comparisons with Anycast Node SID
Note that SRv6 Anycast Node SID is the ultimate aggregation of ESI
SIDs. Such ESI SID aggregation will have some problems as described
in Section 5.1.
7. Security Considerations
Security considerations will be added in future versions.
8. IANA Considerations
8.1. End.DX2AGG SID
IANA is requested to allocate a new code points for the new SRv6
Endpoint Behaviors defined in this document.
+------+-------------+---------------+
| Type | Description | Reference |
+------+-------------+---------------+
| TBD1 | End.DX2AGG | This Document |
+------+-------------+---------------+
Figure 4: End.DX2AGG
9. Acknowledgements
The authors would like to thank the following for their comments and
review of this document:
Ye Shu.
10. Normative References
[I-D.ietf-bess-evpn-unequal-lb]
Malhotra, N., Sajassi, A., Rabadan, J., Drake, J.,
Lingala, A., and S. Thoria, "Weighted Multi-Path
Procedures for EVPN All-Active Multi-Homing", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-unequal-lb-
07, 14 October 2020, <https://tools.ietf.org/html/draft-
ietf-bess-evpn-unequal-lb-07>.
Wang & Chen Expires 9 September 2021 [Page 19]
Internet-Draft EVPN-lite March 2021
[I-D.ietf-bess-srv6-services]
Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R.,
Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based
Overlay services", Work in Progress, Internet-Draft,
draft-ietf-bess-srv6-services-05, 2 November 2020,
<https://tools.ietf.org/html/draft-ietf-bess-srv6-
services-05>.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming",
Work in Progress, Internet-Draft, draft-ietf-spring-srv6-
network-programming-28, 29 December 2020,
<https://tools.ietf.org/html/draft-ietf-spring-srv6-
network-programming-28>.
[I-D.sajassi-bess-evpn-ac-aware-bundling]
Sajassi, A., mishra, m., Thoria, S., Brissette, P.,
Rabadan, J., and J. Drake, "AC-Aware Bundling Service
Interface in EVPN", Work in Progress, Internet-Draft,
draft-sajassi-bess-evpn-ac-aware-bundling-02, 18 August
2020, <https://tools.ietf.org/html/draft-sajassi-bess-
evpn-ac-aware-bundling-02>.
[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>.
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
Henderickx, "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J.,
Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree)
Support in Ethernet VPN (EVPN) and Provider Backbone
Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317,
January 2018, <https://www.rfc-editor.org/info/rfc8317>.
11. Informative References
Wang & Chen Expires 9 September 2021 [Page 20]
Internet-Draft EVPN-lite March 2021
[I-D.ietf-bess-evpn-irb-extended-mobility]
Malhotra, N., Sajassi, A., Pattekar, A., Lingala, A.,
Rabadan, J., and J. Drake, "Extended Mobility Procedures
for EVPN-IRB", Work in Progress, Internet-Draft, draft-
ietf-bess-evpn-irb-extended-mobility-04, 27 October 2020,
<https://tools.ietf.org/html/draft-ietf-bess-evpn-irb-
extended-mobility-04>.
[I-D.ietf-bess-pbb-evpn-isid-cmacflush]
Rabadan, J., Sathappan, S., Nagaraj, K., Miyake, M., and
T. Matsuda, "PBB-EVPN ISID-based CMAC-Flush", Work in
Progress, Internet-Draft, draft-ietf-bess-pbb-evpn-isid-
cmacflush-01, 30 October 2020,
<https://tools.ietf.org/html/draft-ietf-bess-pbb-evpn-
isid-cmacflush-01>.
[I-D.wang-bess-evpn-egress-protection]
Wang, Y. and R. Chen, "EVPN Egress Protection", Work in
Progress, Internet-Draft, draft-wang-bess-evpn-egress-
protection-04, 29 October 2020,
<https://tools.ietf.org/html/draft-wang-bess-evpn-egress-
protection-04>.
[Revision-01]
"Revision-01 of this draft", 1 July 2020,
<https://tools.ietf.org/html/draft-wang-bess-evpn-cmac-
overload-reduction-01#section-6>.
[Revision-02]
"Revision-02 of this draft", 14 November 2020,
<https://tools.ietf.org/html/draft-wang-bess-evpn-cmac-
overload-reduction-02#section-6>.
[RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed.,
"Extensions to the Virtual Private LAN Service (VPLS)
Provider Edge (PE) Model for Provider Backbone Bridging",
RFC 7041, DOI 10.17487/RFC7041, November 2013,
<https://www.rfc-editor.org/info/rfc7041>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
Wang & Chen Expires 9 September 2021 [Page 21]
Internet-Draft EVPN-lite March 2021
[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
Yubao Wang
ZTE Corporation
No.68 of Zijinghua Road, Yuhuatai Distinct
Nanjing
China
Email: wang.yubao2@zte.com.cn
Ran Chen
ZTE Corporation
No. 50 Software Ave, Yuhuatai Distinct
Nanjing
China
Email: chen.ran@zte.com.cn
Wang & Chen Expires 9 September 2021 [Page 22]