Internet DRAFT - draft-wang-bess-evpn-cmac-overload-reduction
draft-wang-bess-evpn-cmac-overload-reduction
BESS WG Y. Wang
Internet-Draft R. Chen
Intended status: Standards Track ZTE Corporation
Expires: 3 March 2022 30 August 2021
Light Weighted EVPN
draft-wang-bess-evpn-cmac-overload-reduction-07
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 [RFC8986], 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 3 March 2022.
Wang & Chen Expires 3 March 2022 [Page 1]
Internet-Draft EVPN-lite August 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. No C-MAC Awareness in the Backbone . . . . . . . . . . . 6
2.2. Flexible Multi-homing Remains Supported . . . . . . . . . 6
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 . . . . 7
2.6. Independent Convergency per <ESI, EVI> . . . . . . . . . 7
2.7. ESI Route Aggregation in Backbone . . . . . . . . . . . . 7
2.8. Unequal load-balance . . . . . . . . . . . . . . . . . . 7
2.9. AC-aware Service Interface . . . . . . . . . . . . . . . 8
2.10. Ingress Filtering for Unicast Flows of E-Tree Services . 8
2.11. AC-Influenced DF Election . . . . . . . . . . . . . . . . 8
2.12. Synchronous MAC Entries in All-Active Mode . . . . . . . 8
3. Light-Weighted SRv6 EVPN Overview . . . . . . . . . . . . . . 8
3.1. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Solution Overview . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Aggregatable End.DX2 SID . . . . . . . . . . . . . . 10
3.2.2. The Advertisement of ESI-Prefixes . . . . . . . . . . 10
3.3. Packet Walkthrough . . . . . . . . . . . . . . . . . . . 11
3.3.1. PE1 forward ARP Request to PE2/PE3 . . . . . . . . . 11
3.3.2. PE2/PE3's Dataplane MAC Learning . . . . . . . . . . 12
3.3.3. PE2 Discard ARP Request to H1 . . . . . . . . . . . . 12
3.3.4. PE3 Forward ARP Replay to PE1/PE2 . . . . . . . . . . 13
3.3.5. PE1 Forward ARP Replay to H1 . . . . . . . . . . . . 13
4. Decapsulation Optimizations . . . . . . . . . . . . . . . . . 13
4.1. Decapsulation Aggregation . . . . . . . . . . . . . . . . 13
4.2. End.DX2AGG Function and Arg.ACI . . . . . . . . . . . . . 14
5. Advanced Considerations . . . . . . . . . . . . . . . . . . . 15
Wang & Chen Expires 3 March 2022 [Page 2]
Internet-Draft EVPN-lite August 2021
5.1. ESI SID Aggregation . . . . . . . . . . . . . . . . . . . 15
5.2. ESI/AC SID Advertisement Optimization . . . . . . . . . . 16
5.2.1. Advertise ESI-Locators in Underlay Network . . . . . 16
5.2.2. Using EAD/EVI Route to Advertise AC SIDs . . . . . . 16
5.2.3. Using EAD/ES Route to Advertise ESI SIDs . . . . . . 16
5.2.4. The Reduction of EAD/EVI Routes . . . . . . . . . . . 17
5.2.4.1. AC-DF per EVI Mode for Light-Weighted EVPNs . . . 17
5.2.4.2. On Receiving Reverse EAD/EVI Routes . . . . . . . 18
5.3. Unequal LB Advertisement . . . . . . . . . . . . . . . . 18
5.4. AC-aware Bundling Service Interface . . . . . . . . . . . 19
5.5. C-MAC Flush Notification Procedure . . . . . . . . . . . 19
5.6. E-Tree Support Considerations . . . . . . . . . . . . . . 19
5.7. MAC-Synchronization in All-Active Mode . . . . . . . . . 20
5.8. EVPN IRB Support Considerations . . . . . . . . . . . . . 21
5.8.1. EVPN IRB Extended Mobility . . . . . . . . . . . . . 21
5.8.2. Anycast IRB interfaces . . . . . . . . . . . . . . . 21
5.8.2.1. Constructing GW-list . . . . . . . . . . . . . . 21
5.8.2.2. Flooding over GW-list . . . . . . . . . . . . . . 21
6. Comparison with Other Solutions . . . . . . . . . . . . . . . 22
6.1. Detailed Comparisons with PBB EVPN over SRv6 . . . . . . 22
6.2. Detailed Comparisons with Anycast Node SID . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. End.DX2AGG SID . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
10. Normative References . . . . . . . . . . . . . . . . . . . . 23
11. Informative References . . . . . . . . . . . . . . . . . . . 25
Appendix A. Explanation for Physical Links of the Use-cases . . 26
A.1. Failure Detections for P1.2 (or P2.1) . . . . . . . . . . 27
A.2. Protection Approaches for N1 (or N2) . . . . . . . . . . 27
A.2.1. CCC-Approaches . . . . . . . . . . . . . . . . . . . 28
A.2.1.1. CCC Active-Active Protection . . . . . . . . . . 28
A.2.1.2. CCC Active-Standby Protection . . . . . . . . . . 28
A.2.2. VSI-Approaches . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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.
Wang & Chen Expires 3 March 2022 [Page 3]
Internet-Draft EVPN-lite August 2021
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.
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.
Wang & Chen Expires 3 March 2022 [Page 4]
Internet-Draft EVPN-lite August 2021
* GDV: Global Discreminating Value. An identifier with global
uniqueness.
* EGD: EVI-GDV, an EVI's Global Discreminator, it is a GDV for an
EVPN MAC-VRF. A EGD is used to idenfify an EVPN MAC-VRF in data
plane. The EGD is a Global Discreminating Value (GDV) of that
EVPN MAC-VRF, so it is also the abbreviation of EVPN-GDV. e.g.
The EGD of [RFC7348] is a global VNI. In this draft, the EGD of
an EVI is that MAC-VRF'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.ACI.
* ESI IP: The End.DX2AGG SID of a specified ESI, but with an empty
Arg.ACI.
* ESI Prefix: The IPv6 Prefix that covers all AC-SIDs of the
specified ESI.
* Ingress AC SID: The End.DX2 SID of the ingress-AC on ingress-PE.
Note that the Ingress AC SID are typically encapsulated as SRv6
Source IP in data plane.
* 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.ACI: The argument part of a SID of the End.DX2AGG function is
called as Arg.ACI, because the value of that argument will be an
AC-ID.
* RT-2: MAC/IP Advertise Route.
* MAC Entry: An entry in the EVPN MAC table in data-plane.
* GRT: Global Routing Table.
2. Requirements
Light-weighted SRv6 EVPNs should be provided together with the
following requirements:
Wang & Chen Expires 3 March 2022 [Page 5]
Internet-Draft EVPN-lite August 2021
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, ES101's location-set is {PE1}, ES102's location-set is
{PE2, PE3}, ES103's location-set is {PE1, PE3}, and ES104's location-
set is {PE2,PE4}.
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.
Wang & Chen Expires 3 March 2022 [Page 6]
Internet-Draft EVPN-lite August 2021
Note that when an ES fails on one PE, it may still works well on
another PE, 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 (illustrated as the 'X' flag
in Figure 1) on PE1, 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.
If PE1 is the last active link for that <ESI, ETI> before that
failure, C-MAC flush should be triggered on the remote PEs. If that
ESI is single-active, C-MAC flush should be triggered on the remote
PEs too.
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].
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].
Wang & Chen Expires 3 March 2022 [Page 7]
Internet-Draft EVPN-lite August 2021
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. Ingress Filtering for Unicast Flows of E-Tree Services
The filtering needed by an E-Tree service for known unicast traffic
should be performed at the ingress PE, thus providing very efficient
filtering and avoiding sending known unicast traffic over the PSN to
be filtered at the egress PE, as is done in traditional E-Tree
solutions (i.e., E-Tree for VPLS [RFC7796]).
2.11. AC-Influenced DF Election
When the EAD/EVI route is not advertised before the corresponding ESI
sub-interface fails, The AC-influenced DF Election procedures should
elect the right DF before and after that failure.
Note that according to [RFC8584], the AC-influenced DF Election will
be incorrect when no EAD/EVI route is advertised, even if no ESI sub-
interface has failed at all.
The AC-influenced DF Election should support "service carving" like
what [RFC7432] section 8.5 have done.
2.12. Synchronous MAC Entries in All-Active Mode
When a C-MAC Mx is learnt on an attachment circuit AC1 of an all-
active Ethernet Segment ES21 on PE1, Mx should not be in unknown
unicast state on PE2, which is also adjacent with ES21. And the
outgoing interface of PE2's MAC entry of Mx should be AC2, which is
an AC of ES21 and has the same VLAN as AC1.
3. Light-Weighted SRv6 EVPN Overview
3.1. Use Case
The physical links of these use cases are described in Appendix A.
Here we discribe the ACs and broadcast domains. Note that the VN-10/
VN-20/VUN1 in Figure 1 is the VPNx/VPNy/NIz in Figure 5.
The ethernet segment ES21's ESI is ESI21, the ES21 is attached to
MAC-VRF VN-10 via attachment circuit AC1 on PE1, the ES21 is attached
to MAC-VRF VN-10 via attachment circuit AC2 on PE2, We assign an
Wang & Chen Expires 3 March 2022 [Page 8]
Internet-Draft EVPN-lite August 2021
End.DX2 SID DX2_AC1 to AC1, and we assign an End.DX2 SID DX2_AC2 to
AC2. The ethernet segment ES3's ESI is ESI3, the ES3 is attached to
MAC-VRF VN-10 via attachment circuit AC3 on PE3, We assign an End.DX2
SID DX2_AC3 to AC3.
Note that network instance VUN1 is the (virtual) underlay network of
VN-10 and VN-20. Because that VN-10 and VN-20 are SRv6 EVPN MAC-
VRFs, their underlay network will be the SRv6 network of the GRT.
+------------------------+
PE1 | |
+-------+-------+ ------------> |
V1P1 | ___(VN-10) | VUN1: DX2AGG:: |
EVC1(V1) V2P1 | /DX2_AC1 \ | through IGP or |
SN1--O=------=========< (VUN1) | RT-1 per ES | PE3
\ / ESI21 | \___ / | +----+-----+
| | + | X (VN-20) | | |
X X | +----------+----+ | |
|P3| | | | (VN-10)--+H3
| | | | | RT2(VN:C-MAC)| / |
V1 | | V2 | DX2AGG::/96 | | EVI-RT | (VUN1) |
| | | | V ES-Import RT | \ |
| | | | | (VN-20)--+H4
| | | +----------+----+ | |
\/ + | X___(VN-10) | | |
/\ ESI21 | /DX2_AC2 \ | +----+-----+
SN2--O===--===========< (VUN1) | |
EVC2(V2) V1P2 | \___ / | |
V2P2 | (VN-20) | |
+-------+-------+ |
PE2 | |
+------------------------+
Figure 1: EVPN-lite SRv6 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
Wang & Chen Expires 3 March 2022 [Page 9]
Internet-Draft EVPN-lite August 2021
3.2.1. Aggregatable End.DX2 SID
When an Ethernet Segment ES21 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
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 MAC-VRF.
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 ESI21 is single-active mode, DX2_AC1 is different from
DX2_AC2, but if ESI21 is all-active mode, DX2_AC1 is the same as
DX2_AC2, we can call them DX2_SID21 in such case.
3.2.2. The Advertisement of ESI-Prefixes
The ESI-prefixes of DX2_AC1 and DX2_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.
Wang & Chen Expires 3 March 2022 [Page 10]
Internet-Draft EVPN-lite August 2021
Note that the SRv6 SID in IMET route is an End.DT2M SID but with a
zero argument length.
Note that if ESI21 is single-active mode, ESI_Prefix1 is different
from ESI_Prefix2, but if ESI21 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
DX2_SID21(=DX2_AC2=DX2_AC1). This will bring out fast network
convergency.
Note that when the PE-CE link of ESI21 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
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
3.3.1. PE1 forward ARP Request to PE2/PE3
* When H1 (of SN1) requests H3's ARP, PE1 will receive the ARP
Request BUM1 from AC1 of ESI21. PE1 will forward the ARP Request
following the broadcast-list of AC1's MAC-VRF VN-10. The
broadcast-list is constructed by the IMET routes from PE2 and PE3.
The End.DX2 SID of AC1 is named as DX2_AC1.
PE1 will forward the ARP Request to PE2 and PE3. The inner SMAC
of the ARP request is M1 which is H1'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 (DX2_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.
Wang & Chen Expires 3 March 2022 [Page 11]
Internet-Draft EVPN-lite August 2021
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.
3.3.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 DX2_AC1.
Note that when PE2 learns that M1 is behind DX2_AC1, it will
assume that M1 is behind the local AC (AC2) whose End.DX2 SID
(DX2_AC2) is the same as DX2_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 H3.
3.3.3. PE2 Discard ARP Request to H1
* On receiving BUM1 from PE1, PE2 use the ingress ESI information
(DX2_AC1) in BUM1 to determine its ingress ESI-Prefix, When ESI21
is all-active mode and PE2 is about to forward the ARP request to
H1, PE2 will find that the AC SID (DX2_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 DX2_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 ESI21 is single-active mode, the outgoing AC may be in
blocking state, otherwise its corresponding sub-interface on H1
will take charge of packet-drop behavior instead. So although the
AC-SID (DX2_AC2) for the outgoing AC is not the same as DX2_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.
Wang & Chen Expires 3 March 2022 [Page 12]
Internet-Draft EVPN-lite August 2021
3.3.4. PE3 Forward ARP Replay to PE1/PE2
* When H3 replies to H1 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
DX2_AC1's SRv6 locator's IGP route.
When ESI21 is all-active mode, DX2_AC1 will be the same as
DX2_AC2, in such case, we call both of them DX2_SID21 instead.
The traffics to M1 will be load-balanced between PE1 and PE2.
Because that DX2_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 (DX2_AC1) on PE1 for AC1 according to the MAC entry
M1.
Note that if the DIP is just the anycast node SID of PE1 and PE2,
when the PE-CE link of ESI21 fails, the traffic will be steadily
bypassed untill that link recovers again. That's why MAC-entries
should be learnt against AC-SIDs.
3.3.5. PE1 Forward ARP Replay to H1
* When PE1 receives the ARP reply packet U1 from PE3, PE1 first
match the packet to its MAC-VRF VN-10 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 MAC-VRF VN-10.
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.
Wang & Chen Expires 3 March 2022 [Page 13]
Internet-Draft EVPN-lite August 2021
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.ACI -------->|
+------------+------------+-----------+-----------------------+-+
| Block | Node | ESI.LDV | EGD |L|
+------------+------------+-----------+-----------------------+-+
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
ESI.LDV works like the function part of an End.DX2 SID. The argument
part of an ESI SID is called as Arg.ACI in this document.
Note that the Arg.ACI comprises EGD (EVPN Global Discreminator) and L
bit. The EGD identifies the EVI of that AC. When that AC is a leaf
AC, the L bit is 1, otherwise the L bit is 0.
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.ACI
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.ACI". 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 .
Wang & Chen Expires 3 March 2022 [Page 14]
Internet-Draft EVPN-lite August 2021
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.ACI.
S04. Learn the exposed MAC Source Address in L2 Table T.
S05. Find out the OIF, Forward the Ethernet frame to the OIF.
S06. } Else {
S07. Process as per Section 4.1.1 of [RFC8986].
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
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.
Wang & Chen Expires 3 March 2022 [Page 15]
Internet-Draft EVPN-lite August 2021
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.
Note that in such case the ESI/AC SID typically don't have to be
advertised by EVPN routes in overlay network, unless some special
features (i.e. unequal load-balance) should be providered together.
5.2.2. 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.
In all-active mode, when an AC of a <ESI, EVI> fails on one PE, all
other PEs of that <ESI, EVI> should use EAD/EVI route to advertise
its AC SID.
5.2.3. Using EAD/ES Route to Advertise ESI SIDs
In section 6.1.1 of [I-D.ietf-bess-srv6-services], the SRv6 L2
Service TLVs of EAD ES routes just carry the Arg.FE2 infomations.
Here the SRv6 L2 Service TLVs of EAD ES routes carry the ESI SIDs.
Wang & Chen Expires 3 March 2022 [Page 16]
Internet-Draft EVPN-lite August 2021
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 are 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.
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.4. 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.2.4.1. AC-DF per EVI Mode for Light-Weighted EVPNs
When the EAD/EVI routes are not advertised, the AC-influenced DF-
Election per [RFC8584] can't work. So the AC-DF per EVI procedures
are required. The AC-DF per EVI procedures includes two steps. The
first step is the AC-DF per EVI capability negotiation procedure, and
the second step is the AC-DF per EVI DF-election procedure.
Wang & Chen Expires 3 March 2022 [Page 17]
Internet-Draft EVPN-lite August 2021
The Capability negotiation procedures and the DF-Election procedures
follow [I-D.wang-bess-evpn-ac-df-per-evi].
5.2.4.2. On Receiving Reverse EAD/EVI Routes
In all-active mode, when a PE X receives a reverse EAD/EVI route
([I-D.wang-bess-evpn-ac-df-per-evi]), that PE x can use nomal EAD/EVI
route to advertise its local AC SID of that <ESI,EVI>.
Note that no EAD/EVI route have to be advertised before receiving the
corresponding reverse EAD/EVI routes. This can greatly reduce the
amount of EAD/EVI routes.
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])
along with the ESI SIDs using EAD/ES 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.
Note that the association between an ESI SID and its corresponding
Node SID is also advertised by EAD/ES routes. 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 EAD/ES routes of
overlay network. So the ESI SIDs must be advertised in overlay
network in such case.
Although these ESI SIDs (that are used as destination IP addresses to
PE X) won't be exposed untill data packets reached the egress PE X,
the ESI-Locator of them should also be advertised in underlay network
because that their corresponding AC SIDs will be encapsulated as
source IPs for some other data packets whose ingress PE is PE X. and
these source IPs may be checked by underlay URPF (Unicast Reverse
Path Forwarding) procedures.
Wang & Chen Expires 3 March 2022 [Page 18]
Internet-Draft EVPN-lite August 2021
5.4. AC-aware Bundling Service Interface
In AC-aware bundling service interface, Attachment Circuit ID
extended community ([I-D.sajassi-bess-evpn-ac-aware-bundling]) or
ACI-specific SOI extended community
([I-D.wang-bess-evpn-ether-tag-id-usage]) should be used in ARP/ND
synchronization.
Note that each VLAN of the same AC of the same MAC-VRF will have the
same End.DX2 SID,
Note that in "AC-aware bundling service interface", the AC-ID inside
that DX2_AC1 can help the MAC entry to be installed for the correct
outgoing interface. Such MAC entry is called as the synced MAC
entry.
Note that the MAC enties which are learnt against a DX2-SID should
have low preference than which are received over a RT-2 route, when
they are installed to the MAC table.
5.5. C-MAC Flush Notification Procedure
The withdraw of an ESI/AC SID Advertisement (as an overlay route) can
(if it is the only advertisement of that ESI/AC SID at that time) be
used as C-MAC (which was learnt against that ESI/AC SID) flush
notification.
Note that in single active mode, the ESI-Prefixes of DX2_AC1 and
DX2_AC2 are different, so each withdraw of DX2_AC1 or DX2_AC2 will be
for the single advertisement of that SID.
When "AC-DF per EVI" (Section 5.2.4.1) is used, the reverse EAD/EVI
routes can be used to trigger C-MAC flush for specified AC SIDs. In
such case, these reverse EAD/EVI routes should not use EVI-RT format
to carry their EVI's route-target. Because that EVI-RT format is not
visible to RT constraints mechanism.
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 SRv6 encapsulation, the B-component
is replaced by the underlay GRT. The B-MAC Advertisement Route is
replaced by EAD/EVI route or EAD/ES Route.
Wang & Chen Expires 3 March 2022 [Page 19]
Internet-Draft EVPN-lite August 2021
As illustrated in Figure 3, the root AC-SID and leaf AC-SID of the
same AC can be considered as the same ESI-SID with different Arg.ACI.
Even the EGD part of their Arg.ACIs are the same EGD, only the L bit
of their Arg.ACIs are different. The L bit of the leaf AC-SID is set
to 1. The L bit of the root AC-SID is set to 0.
On the ingress PE, when the L bit of the destination SID for the DMAC
of a data packet is 1, and that data packet's ingress AC is a leaf
AC, that data packet should be dropped.
5.7. MAC-Synchronization in All-Active Mode
When a host H1 of subnet SN1 sends an ARP Request REQ_P1, then REQ_P1
will be forwarded by EVC1 to either PE1 or PE2, not to the both. But
when H3 send an ARP Reply REP_P2 to H1, then PE3 may load-balance
REP_P2 to either PE1 or PE2, not to the both.
When REQ_P1 is load-balanced (see Appendix A.2.1.1) by EVC1 to PE1,
not to PE2, but PE3 load-balance REP_P2 to PE2, The MAC entry of H1
would not have been prepared on PE2 for REP_P2. So the fowarding of
REP_P2 will follow the unknown-unicast procedures.
PE1 MUST use RT-2 route RT2S (RT-2 for Synchronization only) to
advertise the MAC/IP entry of H1 to other PEs (e.g. PE2) on ES21.
These RT-2 routes should be advertised along with an EVI-RT
([I-D.ietf-bess-evpn-igmp-mld-proxy]) and an ES-Import RT.
When PE2 receives RT2S, the MAC entry Mx should be installed with AC2
as its actual outgoing-interface. When PE3 receives RT2S, RT2S MUST
not be imported into VN-10 because that the ES-Import RT of RT2S can
be resolved to a local ES of PE3.
As a result of that, the synchronized MAC entries will not be
imported by their external remote PEs, they are imported just by
their internal remote PEs.
The IP address field of NLRI of RT2S can be set to H1's IP address,
which is obtained through ARP snooping. This IP address can be used
to trigger ARP probing when PE1 fails.
When C-MAC Mx is aged out by PE1, the RT2S MUST be withdrawn, thus
PE2's MAC entry of Mx will be deleted. In such case, ARP probing for
Mx should not be triggered in order not to hold a MAC entry for Mx
when Mx will not connect to others for a long time.
Wang & Chen Expires 3 March 2022 [Page 20]
Internet-Draft EVPN-lite August 2021
Note that in other light-weighted EVPNs, the VUN1 may be a backbone-
VPLS (B-VPLS), in such case, the IP address field of NLRI can be used
to distinguish the RT-2 routes of C-MACs from the RT-2 routes of
B-MACs.
5.8. 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.
5.8.1. EVPN IRB Extended Mobility
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
change across VM-moves. These extensions can't be applied to light-
weighted EVPNs, just like they can't be applied to PBB EVPNs either.
5.8.2. Anycast IRB interfaces
When an EVPN IRB interface (on PE1) ping a host H1, the corresponding
ICMP Echo Request will be delivered to host H1, whether host H1 is
PE1's local host or not . but if that IRB interface is an anycast IRB
interface, and host H1 is a local host of PE2 (not of PE1), naturally
the Echo Reply for that Echo Request will be delivered to the nearest
anycast IRB interface on PE2 (not on PE1) only.
5.8.2.1. Constructing GW-list
The MAC/IP of an anycast IRB interface should be advertised along
with a Default Gateway Extended Community.
The PEs in which resides the anycast IRB interface of a subnet forms
the "GW-list" of that subnet. The "GW-list" of a BD can be
constructed from such MAC/IP routes (with Default Gateway extended
community of corresponding subnet).
5.8.2.2. Flooding over GW-list
Echo Replies received by any of the anycast IRB interfaces MUST be
flooded over the GW-list of that BD. So that the PE which originated
the previous Echo Request can receive the synced Echo Replies.
Note that the Echo Replies between two hosts of that BD will not be
flooded, because that they will not be received by any of the anycast
IRB interfaces.
Wang & Chen Expires 3 March 2022 [Page 21]
Internet-Draft EVPN-lite August 2021
6. Comparison with Other Solutions
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 to it. 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.
* Light-weighted SRv6 EVPN can support AC-influenced DF Election,
but PBB EVPN over SRv6 can't.
* 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.
Wang & Chen Expires 3 March 2022 [Page 22]
Internet-Draft EVPN-lite August 2021
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.
Although the extensions in [I-D.ietf-bess-evpn-irb-extended-mobility]
can't be applied to PBB EVPNs or light-weighted EVPNs. This will not
prevent PBB EVPNs and light-weighted EVPNs from supporting typical
IRB use-cases. Note that these extensions are optional.
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
Wang & Chen Expires 3 March 2022 [Page 23]
Internet-Draft EVPN-lite August 2021
[I-D.ietf-bess-evpn-igmp-mld-proxy]
Sajassi, A., Thoria, S., Mishra, M. P., Drake, J., and W.
Lin, "IGMP and MLD Proxy for EVPN", Work in Progress,
Internet-Draft, draft-ietf-bess-evpn-igmp-mld-proxy-12, 23
August 2021, <https://datatracker.ietf.org/doc/html/draft-
ietf-bess-evpn-igmp-mld-proxy-12>.
[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 Multi-Homing", Work in Progress,
Internet-Draft, draft-ietf-bess-evpn-unequal-lb-14, 14 May
2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
bess-evpn-unequal-lb-14>.
[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-07, 11 April 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
srv6-services-07>.
[I-D.sajassi-bess-evpn-ac-aware-bundling]
Sajassi, A., Brissette, P., Mishra, M., Thoria, S.,
Rabadan, J., and J. Drake, "AC-Aware Bundling Service
Interface in EVPN", Work in Progress, Internet-Draft,
draft-sajassi-bess-evpn-ac-aware-bundling-04, 11 July
2021, <https://datatracker.ietf.org/doc/html/draft-
sajassi-bess-evpn-ac-aware-bundling-04>.
[I-D.wang-bess-evpn-ac-df-per-evi]
Wang, Y., "AC-Influenced DF Election per EVI", Work in
Progress, Internet-Draft, draft-wang-bess-evpn-ac-df-per-
evi-00, 7 May 2021,
<https://datatracker.ietf.org/doc/html/draft-wang-bess-
evpn-ac-df-per-evi-00>.
[I-D.wang-bess-evpn-ether-tag-id-usage]
Wang, Y., "Ethernet Tag ID Usage Update for Ethernet A-D
per EVI Route", Work in Progress, Internet-Draft, draft-
wang-bess-evpn-ether-tag-id-usage-03, 26 August 2021,
<https://datatracker.ietf.org/doc/html/draft-wang-bess-
evpn-ether-tag-id-usage-03>.
Wang & Chen Expires 3 March 2022 [Page 24]
Internet-Draft EVPN-lite August 2021
[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>.
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
VPN Designated Forwarder Election Extensibility",
RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
11. Informative References
[I-D.ietf-bess-evpn-irb-extended-mobility]
Malhotra, N., Sajassi, A., Pattekar, A., Rabadan, J.,
Lingala, A., and J. Drake, "Extended Mobility Procedures
for EVPN-IRB", Work in Progress, Internet-Draft, draft-
ietf-bess-evpn-irb-extended-mobility-05, 15 March 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-irb-extended-mobility-05>.
[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://datatracker.ietf.org/doc/html/draft-wang-bess-
evpn-egress-protection-04>.
Wang & Chen Expires 3 March 2022 [Page 25]
Internet-Draft EVPN-lite August 2021
[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>.
[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>.
Appendix A. Explanation for Physical Links of the Use-cases
+------------------+
PE1 | P6 |
L2NE1 +----------+---------+ |
+----------+ | __(P1.1)__(VPNx) | |
+---+ P4 | | P1 | / \ | |
|N1 |-----O==------=======< (NIz) | P6 | PE3
+---+ | \ / | | \__ __ / | +----+-------+
| | | | | (P1.2) (VPNy) | | |
+----|P3|--+ +-----------+--------+ | (VPNx)--+N3
| | | | / |
P3.1 | | P3.2 | P7 | (NIz)--------+N4
| | PE2 | | \ |
+----|P3|--+ +-----------+--------+ | (VPNy)--+N5
| \/ | | __(P2.2)__(VPNy) | | |
+---+ | /\ | | / \ | +----+-------+
|N2 |-----O====--=========< (NIz) | P8 |
+---+ P5 | | P2 | \__ __ / | |
+----------+ | (P2.1) (VPNx) | |
L2NE2 +----------+---------+ |
| P8 |
+------------------+
Figure 5: Physical Links Illustrated
Wang & Chen Expires 3 March 2022 [Page 26]
Internet-Draft EVPN-lite August 2021
There are three PEs, two L2NEs (Layer 2 Network Elements) and five
L3NEs (Layer 3 Network Elements) in abobe network. The PEs are PE1,
PE2 and PE3. The L2NEs are L2NE1 and L2NE2. The L3NEs are
N1/N2/N3/N4/N5. They are all illustrated in Figure 5.
There are 9 physical links among these 10 physical devices as
illustrated in Figure 5. These physical links are called as PLi
(i=1,2...8). The two physical ports of the same physical link PLi
are both called as Pi (i=1,2...8).
As illustrated in Figure 5, some of these physical ports may have
subinterfaces. When a subinterface's VLAN ID is j and it is physical
port Pi's subinterface, that subinterface is called as Pi.j. For
example, P1.2 is a subinterface of physical port P1 and its VLAN ID
is 2.
There are three NIs (Network Instances) among PE1, PE2 and PE3. They
are VPNx, VPNy and NIz. Two subinterfaces are attached to VPNx, they
are P1.1 and P2.1. Other two subinterfaces are attached to VPNy,
they are P1.2 and P2.2. N3 is also attched to VPNx, while N5 is also
attached to VPNy.
There are two EVCs (Ethernet Virtual Connections) between L2NE1 and
L2NE2, they are EVC1 and EVC2. The L2NE1's EVC1 instance (which is
illustrated as the "O" on L2NE1) have three member interfaces, they
are P4, P1.1 and P3.1, where P3.1 and P1.1 are of the same
protection-group. The L2NE2's EVC1 instance have two member
interfaces, they are P3.1 and P2.1. The L2NE2's EVC2 instance (which
is illustrated as the "O" on L2NE2) have three member interfaces,
they are P5, P2.2 and P3.2, where P3.1 and P1.1 are of the same
protection-group. The L2NE1's EVC2 instance have two member
interfaces, they are P3.2 and P1.2. The L2NE2's EVC1 instance and
L2NE1's EVC2 instance are both CCC (Circuit Cross Connection) local
connections.
VPNx and VPNy are associated to NIz on each PE.
A.1. Failure Detections for P1.2 (or P2.1)
There is a CFM session CFM1 between P1.2 of PE1 and L2NE2's P3.2,
when physical port P3 fails, the CFM session CFM1 will go down.
There is a CFM session CFM2 between P2.1 of PE2 and L2NE1's P3.1,
when physical port P3 fails, the CFM session CFM2 will go down.
A.2. Protection Approaches for N1 (or N2)
Wang & Chen Expires 3 March 2022 [Page 27]
Internet-Draft EVPN-lite August 2021
A.2.1. CCC-Approaches
The L2NE1's EVC1 instance and L2NE2's EVC2 instance are both CCC
local connections too. In L2NE1's EVC1 instance, P1.1 and P3.1 are
of the same protection-group PG1. In L2NE2's EVC2 instance, P2.2 and
P3.2 are of the same protection-group PG2. In PG1, both P1.1 and
P3.1 will receive data packets. In PG2, both P2.2 and P3.2 will
receive data packets.
A.2.1.1. CCC Active-Active Protection
L2NE1 (or L2NE2) will load-balance N1's (N2's) data packets between
P1.1 and P3.1 (or P2.2 and P3.2).
A.2.1.2. CCC Active-Standby Protection
In PG1, P1.1 is the active path, P3.1 is the backup path. In PG2,
P2.2 is the active path, P3.2 is the backup path.
That's saying that L2NE1 (or L2NE2) will not send N1's (or N2's) data
packets over P3.1 (or P3.2), unless P1.1 (or P2.2) or P1 (or P2) has
been in failure before that data forwarding.
A.2.2. VSI-Approaches
L2NE1's EVC2 instance and L2NE2's EVC1 instance are both VSI
instances in this case. P1.1, P3.1, P2.2 and P3.2 are all individual
ACs in these VSIs.
Note that L2NE2's EVC1 instance and L2NE1's EVC2 instance are still
both CCC local connections in this case, and there is no PG1 or PG2
in this case, and there are no PWs in this case.
Authors' Addresses
Yubao Wang
ZTE Corporation
No.68 of Zijinghua Road, Yuhuatai Distinct
Nanjing
China
Email: wang.yubao2@zte.com.cn
Wang & Chen Expires 3 March 2022 [Page 28]
Internet-Draft EVPN-lite August 2021
Ran Chen
ZTE Corporation
No. 50 Software Ave, Yuhuatai Distinct
Nanjing
China
Email: chen.ran@zte.com.cn
Wang & Chen Expires 3 March 2022 [Page 29]
