Layer-3 Accessible EVPN Services
draft-wang-bess-l3-accessible-evpn-06
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Wei Wang , Aijun Wang , Haibo Wang | ||
| Last updated | 2024-03-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-l3-accessible-evpn-06
BESS Working Group W. Wang
Internet-Draft A. Wang
Intended status: Standards Track China Telecom
Expires: 21 September 2024 H. Wang
Huawei Technologies
20 March 2024
Layer-3 Accessible EVPN Services
draft-wang-bess-l3-accessible-evpn-06
Abstract
This draft describes layer-3 accessible EVPN service interfaces, and
proposes a new solution which can span layer-3 network. This
solution allows each PE in EVPN network to maintain only one MAC-VRF.
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 21 September 2024.
Copyright Notice
Copyright (c) 2024 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Wang, et al. Expires 21 September 2024 [Page 1]
Internet-Draft L3 Accessible EVPN March 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Service Interfaces in layer-3 accessible EVPN . . . . . . . . 5
5. Solutions of LSI-aware bundle service interface . . . . . . . 7
6. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7
6.1. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 7
6.1.1. Extensions to VxLAN . . . . . . . . . . . . . . . . . 7
6.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 7
7. Modification of MAC address storage mode on PE . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
[RFC7432]defines three service interfaces for layer-2 accessible
EVPN: VLAN-Based Service Interface, VLAN-Bundle Service Interface and
VLAN-Aware Bundle Service Interface. These three types of service
interfaces can realize the isolation of layer-2 traffic of customers
in different ways, as shown in Figure 1.
1:1 1:1
+------+ +---------+ +------+
|VID 11+---+ EVI 1 +---+VID 12|
+------+ +---------+ +------+
|VID 21+---+ EVI 2 +---+VID 22|
+------+ +---------+ +------+
|VID 31+---+ EVI 3 +---+VID 32|
+------+ +---------+ +------+
|VID 41+---+ EVI 4 +---+VID 42|
+------+ +---------+ +------+
VLAN-based Service Interface
N:1 1:N
+------+ +---------+ +------+
|VID 11---------+ +--------+VID 12|
+------+ + + +------+
|VID 21+--------+ +--------+VID 22|
+------+ + EVI 1 + +------+
|VID 31+--------+ +--------+VID 32|
+------+ + + +------+
Wang, et al. Expires 21 September 2024 [Page 2]
Internet-Draft L3 Accessible EVPN March 2024
|VID 41+--------+ +--------+VID 42|
+------+ +---------+ +------+
VLAN-bundle Service Interface
N:1 1:N
+----------------------+
+------+ |+--------------------+| +------+
|VID 11+--++ Broadcast Domain 1 ++--+VID 12|
+------+ |+--------------------+| +------+
|VID 21+--++ Broadcast Domain 2 ++--+VID 22|
+------+ |+--------------------+| +------+
|VID 31+--++ Broadcast Domain 3 ++--+VID 32|
+------+ |+--------------------+| +------+
|VID 41+--++ Broadcast Domain 4 ++--+VID 42|
+------+ |+--------------------+| +------+
| |
| EVI 1 |
+----------------------+
VLAN-Aware Bundle Service Interface
Figure 1: EVPN Service Interfaces Overview
For VLAN-based service interface, there is a one to one mapping
between VID and EVI. Each EVI has a single broadcast domain so that
traffic from different customers can be isolated.
For VLAN-bundle service interface, there is a N to one mapping
between VID and EVI. Each EVI has a single broadcast domain, but the
MAC address MUST be unique that can be used for customer traffic
isolation.
For VLAN-aware bundle service interface, there is a N to one mapping
between VID and EVI. Each EVI has multiple broadcast domains while
the MAC address can overlap. One broadcast domain corresponds to one
VID, which can be used to customer traffic isolation.
In the scenarios corresponding to these service interfaces, CE-PE
should be placed in the same Layer-2 network. In most of provider
network, CE-PE need to cross a Layer-3 network, then the above
service interfaces should be extended to adapt to the layer-3
network.
In practical network operations, some users may require the L2--L3--
L2 network connection method, as shown in Figure 2.
Wang, et al. Expires 21 September 2024 [Page 3]
Internet-Draft L3 Accessible EVPN March 2024
+---+
|CE3|
+-+-+
|
+------+------+
| |
| MAN |
+------+------+
|
+--+-+
+-----+ +-----+ PE |------+ +-----+
| | +-+-+ +----+ +-+-+ | |
C-A---+---+ | | | | +---+--C-A
|CE1+--+ MAN +-+PE | Backbone |PE +---+ MAN +--+CE2|
C-B---+---+ | | | | +---+--C-B
| | +-+-+ +-+-+ | |
| | | |
+-----+ +-----------------+ +-----+
Figure 2: LSI-aware bundle service interface scenario
Assuming that the customer is a cross-regional bank, CE3 represents
its headquarter site, while CE1 and CE2 are branch sites of the bank
located in different cities. In this structure, the headquarters
serves as the core of the network, responsible for the management and
control of the overall network; while the branches serve as edge
nodes of the network, responsible for collecting local business data
and uploading it to the headquarters. Each site needs to connect to
the backbone network through the metropolitan area network of its
city for communication. To ensure data security, communication
between branch sites needs to be routed through the headquarters site
first, and end-to-end L2 communication is adopted between the branch
sites and the headquarters site. The backbone is an EVPN domain, and
MANs are L3 domains. The packets should be transmitted from CE to PE
through VxLAN/IPSec tunnel. Due to the EVI cannot be transmitted in
this scenario, we need an EVPN solution that can span the L3 network.
In this draft, we describe three layer-3 accessible interfaces for
EVPN, the above problem can be solved by using these L3 accessible
interfaces.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] .
Wang, et al. Expires 21 September 2024 [Page 4]
Internet-Draft L3 Accessible EVPN March 2024
3. Terminology
The following terms are defined in this draft:
* CE: Client Edge
* EVPN: BGP/MPLS Ethernet VPN, defined in [RFC7432]
* IPSec: Internet Protocol Security, defined in [RFC4301]
* PE: Provider Edge
* SPI: Security Parameters Index, defined in [RFC4301]
* VNI: VXLAN Network Identifier (or VXLAN Segment ID), defined in
[RFC7348]
* VxLAN: Virtual eXtensible Local Area Network, defined in [RFC7348]
4. Service Interfaces in layer-3 accessible EVPN
In most of provider network, CE-PE need to cross a Layer-3 network.
With this scenario, service interfaces defined in [RFC7432] should be
extended to adapt to the layer-3 network. To achieve the traffic
isolation, tunnel encapsulation technologies can be used.
We define Logical Session Identifier(LSI) to distinguish the packets
from different tunnels, which is related to VNI/SPI. The length of
LSI is 16 bits.
The layer-3 accessible interfaces for EVPN are shown in Figure 3,
refer to [RFC7432]
1:1 1:1
+------+ +----------+ +------+
|LSI 11+---+ MAC-VRF1 +---+LSI 12|
+------+ +----------+ +------+
|LSI 21+---+ MAC-VRF2 +---+LSI 22|
+------+ +----------+ +------+
|LSI 31+---+ MAC-VRF3 +---+LSI 32|
+------+ +----------+ +------+
|LSI 41+---+ MAC-VRF4 +---+LSI 42|
+------+ +----------+ +------+
LSI-based Service Interface
Wang, et al. Expires 21 September 2024 [Page 5]
Internet-Draft L3 Accessible EVPN March 2024
N:1 1:N
+------+ +----------+ +------+
|LSI 11---------+ +--------+LSI 12|
+------+ + + +------+
|LSI 21+--------+ +--------+LSI 22|
+------+ + MAC-VRF1 + +------+
|LSI 31+--------+ +--------+LSI 32|
+------+ + + +------+
|LSI 41+--------+ +--------+LSI 42|
+------+ +----------+ +------+
LSI-bundle Service Interface
N:1 1:N
+----------------------+
+------+ |+---------------------+| +------+
|LSI 11+--++ Logical Plane 1 ++--+LSI 12|
+------+ |+---------------------+| +------+
|LSI 21+--++ Logical Plane 2 ++--+LSI 22|
+------+ |+---------------------+| +------+
|LSI 31+--++ Logical Plane 3 ++--+LSI 32|
+------+ |+---------------------+| +------+
|LSI 41+--++ Logical Plane 4 ++--+LSI 42|
+------+ |+---------------------+| +------+
| |
| MAC-VRF 1 |
+-----------------------+
LSI-Aware Bundle Service Interface
Figure 3: Layer-3 accessible EVPN Service Interfaces Overview
For LSI-based service interface, there is a one to one mapping
between LSI and MAC-VRF. Each MAC-VRF has a single logical plane so
that traffic from different customers can be isolated.
For LSI-bundle service interface, there is a N to one mapping between
LSI and MAC-VRF. Each MAC-VRF has a single logical plane, but the
MAC address MUST be unique that can be used for customer traffic
isolation.
For LSI-aware bundle service interface, there is a N to one mapping
between LSI and MAC-VRF. Each MAC-VRF has multiple logical planes
while the MAC address can overlap. One logical plane corresponds to
one LSI, which can be used to customer traffic isolation.
Wang, et al. Expires 21 September 2024 [Page 6]
Internet-Draft L3 Accessible EVPN March 2024
5. Solutions of LSI-aware bundle service interface
For the scenario shown in Figure 2, where Backbone is EVPN domain,
and the MANs are Layer-3 network. There is a 1:1 mapping between LSI
and VNI, LSIs are used for traffic isolation. If customers need end-
to-end L2 data transmission, the use of LSI is similar to VLAN ID.
If each VNI has its own MAC-VRF, each PE and CE maintain an MAC-VRF
for each deployment. The packets should be transmitted from CE to PE
through VxLAN/IPSec tunnel. The EVI cannot be transmitted during
this process, because it cannot be carried in VxLAN or IPSec header.
This problem can be solved by using LSI information to identify
different customer routes / traffic. As described above, LSI can be
generated by VNI/SPI, and there is a one to one mapping between LSI
and VNI/SPI. PEs should maintain the mapping table of LSI and VNI/
SPI, so that they can distinguish different customer routes /
traffic. LSI information can be transmitted by using Ethernet Tag ID
or a newly defined ESI type.
6. Protocol Extensions
6.1. Forwarding Plane
6.1.1. Extensions to VxLAN
When the forwarding plane uses VxLAN tunnel technologies, we should
extend the VxLAN GPE header to carry the LSI information, the
extentions to the VxLAN GPE header is shown in Figure 4:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|Ver|I|P|B|O| LSI |Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The extentions to VxLAN GPE header
We define a S bit. If S is set to 1, it means the field after O bit
contains LSI information.
6.2. Control Plane
We proposed two methods to advertise LSI information in control
plane:
Wang, et al. Expires 21 September 2024 [Page 7]
Internet-Draft L3 Accessible EVPN March 2024
* Reusing the Ethernet Tag ID field. This method requires the
update of [I-D.ietf-bess-evpn-prefix-advertisement] (Etherenet Tag
ID is set to 0 for route type 5), and may arise some confuse with
the original definition of Ethernet Tag ID.
* Using the newly defined ESI type as shown in Figure 5. This
method can preserve the original purpose of ESI definition (multi-
homing).
+---+---+---+---+---+---+---+---+---+---+
| T | Reserved | CE Identifier | LSI |
+---+---+---+---+---+---+---+---+---+---+
Figure 5: The format of new ESI type
Where:
* T (1 octet): specify the ESI Type. The recommended value is 0x06.
* CE Identifier (3 octets): the route ID/IPv4 address of CE.
* LSI (2 octets): the LSI information.
Since the length of LSI is 16 bits, while the length of Ethernet Tag
ID and ESI are 80 bits and 32 bits, respectively. We can only use
the lower 16 bits of Ethernet Tag ID / ESI field to carry LSI
information, the other bits MUST set to 0.
7. Modification of MAC address storage mode on PE
LSI-aware bundle service interface also changes the storage mode of
MAC address on PE, as shown in Figure 6.
Wang, et al. Expires 21 September 2024 [Page 8]
Internet-Draft L3 Accessible EVPN March 2024
+------------------------------+
|MAC-VRF |
| |
| BD-A (LSI <-> VNI/SPI) |
| MAC 1 |
| ...... |
| |
| BD-B (LSI <-> VNISPI) |
| MAC 100 |
| ...... |
+------------------------------+
LSI-Aware Bundle Service
Interface(L2)
Figure 6: Modification of MAC/IP address storage mode on PE
For end-to-end layer-2 data transmission, the storage mode of MAC
address in MAC-VRF is similar to VLAN-aware bundle service, the only
change is that different bridge domains are distinguished by LSI.
8. Security Considerations
TBD
9. IANA Considerations
This draft extends the VxLAN GPE header, S bit of Flag and LSI field
are added:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|Ver|I|P|B|O| LSI |Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This draft also define a new ESI type:
+---+---+---+---+---+---+---+---+---+---+
| T | Reserved | CE Identifier | LSI |
+---+---+---+---+---+---+---+---+---+---+
10. Normative References
Wang, et al. Expires 21 September 2024 [Page 9]
Internet-Draft L3 Accessible EVPN March 2024
[I-D.ietf-bess-evpn-prefix-advertisement]
Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
Sajassi, "IP Prefix Advertisement in Ethernet VPN (EVPN)",
Work in Progress, Internet-Draft, draft-ietf-bess-evpn-
prefix-advertisement-11, 18 May 2018,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-prefix-advertisement-11>.
[I-D.ietf-bess-mvpn-evpn-aggregation-label]
Zhang, Z. J., Rosen, E. C., Lin, W., Li, Z., and I.
Wijnands, "MVPN/EVPN Tunnel Aggregation with Common
Labels", Work in Progress, Internet-Draft, draft-ietf-
bess-mvpn-evpn-aggregation-label-14, 4 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
mvpn-evpn-aggregation-label-14>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000,
<https://www.rfc-editor.org/info/rfc2890>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[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>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
Authors' Addresses
Wang, et al. Expires 21 September 2024 [Page 10]
Internet-Draft L3 Accessible EVPN March 2024
Wei Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: weiwang94@foxmail.com
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: wangaj3@chinatelecom.cn
Haibo Wang
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing
Beijing, 100095
China
Email: rainsword.wang@huawei.com
Wang, et al. Expires 21 September 2024 [Page 11]