draft-ietf-bess-evpn-geneve-00.txt   draft-ietf-bess-evpn-geneve-01.txt 
INTERNET-DRAFT Sami Boutros BESS Workgroup S. Boutros, Ed.
Intended Status: Standard Track VMware Internet-Draft Ciena
Ali Sajassi Intended status: Informational A. Sajassi
Cisco Systems Expires: December 14, 2020 Cisco Systems
John Drake J. Drake
J. Rabadan
S. Aldrin
Juniper Networks Juniper Networks
Jorge Rabadan June 12, 2020
Nokia
Sam Aldrin
Google
Expires: February 8, 2020 August 7, 2019
EVPN control plane for Geneve EVPN control plane for Geneve
draft-ietf-bess-evpn-geneve-00.txt draft-ietf-bess-evpn-geneve-01.txt
Abstract Abstract
This document describes how Ethernet VPN (EVPN) control plane can be This document describes how Ethernet VPN (EVPN) control plane can be
used with Network Virtualization Overlay over Layer 3 (NVO3) Generic used with Network Virtualization Overlay over Layer 3 (NVO3) Generic
Network Virtualization Encapsulation (Geneve) encapsulation for NVO3 Network Virtualization Encapsulation (Geneve) encapsulation for NVO3
solutions. EVPN control plane can also be used by a Network solutions.
Virtualization Endpoints (NVEs) to express Geneve tunnel option
TLV(s)supported in transmission and/or reception of Geneve
encapsulated data packets.
Status of this Memo EVPN control plane can also be used by a Network Virtualization
Endpoints (NVEs) to express Geneve tunnel option TLV(s)supported in
transmission and/or reception of Geneve encapsulated data packets.
This Internet-Draft is submitted to IETF in full conformance with the Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as working documents as Internet-Drafts. The list of current Internet-
Internet-Drafts. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 14, 2020.
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. GENEVE extensions . . . . . . . . . . . . . . . . . . . . . . . 4 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Ethernet option TLV . . . . . . . . . . . . . . . . . . . . 4 4. GENEVE extensions . . . . . . . . . . . . . . . . . . . . . . 4
3. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Ethernet option TLV . . . . . . . . . . . . . . . . . . . 4
3.1 Geneve Tunnel Option Types sub-TLV . . . . . . . . . . . . . 6 5. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Geneve Tunnel Option Types sub-TLV . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.2 Informative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1 Introduction 1. Introduction
The Network Virtualization over Layer 3 (NVO3) solutions for network The Network Virtualization over Layer 3 (NVO3) solutions for network
virtualization in data center (DC) environment are based on an IP- virtualization in data center (DC) environment are based on an IP-
based underlay. An NVO3 solution provides layer 2 and/or layer 3 based underlay. An NVO3 solution provides layer 2 and/or layer 3
overlay services for virtual networks enabling multi-tenancy and overlay services for virtual networks enabling multi-tenancy and
workload mobility. The NVO3 working group have been working on workload mobility. The NVO3 working group have been working on
different dataplane encapsulations. The Generic Network different dataplane encapsulations. The Generic Network
Virtualization Encapsulation [GENEVE] have been recently recommended Virtualizationi Encapsulation [I-D.ietf-nvo3-geneve] have been
to be the proposed standard for network virtualization overlay recently recommended to be the proposed standard for network
encapsulation. virtualization overlay encapsulation.
This document describes how the EVPN control plane can signal Geneve This document describes how the EVPN control plane can signal Geneve
encapsulation type in the BGP Tunnel Encapsulation Extended Community encapsulation type in the BGP Tunnel Encapsulation Extended Community
defined in [TUNNEL-ENCAP]. In addition, this document defines how to defined in [I-D.ietf-idr-tunnel-encaps]. In addition, this document
communicate the Geneve tunnel option types in a new BGP Tunnel defines how to communicate the Geneve tunnel option types in a new
Encapsulation Attribute sub-TLV. The Geneve tunnel options are BGP Tunnel Encapsulation Attribute sub-TLV. The Geneve tunnel
encapsulated as TLVs after the Geneve base header in the Geneve options are encapsulated as TLVs after the Geneve base header in the
packet as described in [GENEVE]. Geneve packet as described in [I-D.ietf-nvo3-geneve].
[DT-ENCAP] recommends that a control plane determines how Network [I-D.ietf-nvo3-encap] recommends that a control plane determines how
Virtualization Edge devices (NVEs) use the GENEVE option TLVs when Network Virtualization Edge devices (NVEs) use the GENEVE option TLVs
sending/receiving packets. In particular, the control plane when sending/receiving packets. In particular, the control plane
negotiates the subset of option TLVs supported, their order and the negotiates the subset of option TLVs supported, their order and the
total number of option TLVs allowed in the packets. This negotiation total number of option TLVs allowed in the packets. This negotiation
capability allows, for example, interoperability with hardware-based capability allows, for example, interoperability with hardware-based
NVEs that can process fewer options than software-based NVEs. NVEs that can process fewer options than software-based NVEs.
This EVPN control plane extension will allow a Network Virtualization This EVPN control plane extension will allow a Network Virtualization
Edge (NVE) to express what Geneve option TLV types it is capable to Edge (NVE) to express what Geneve option TLV types it is capable to
receive or to send over the Geneve tunnel to its peers. receive or to send over the Geneve tunnel to its peers.
In the datapath, a transmitting NVE MUST NOT encapsulate a packet In the datapath, a transmitting NVE MUST NOT encapsulate a packet
destined to another NVE with any option TLV(s) the receiving NVE is destined to another NVE with any option TLV(s) the receiving NVE is
not capable of processing. not capable of processing.
1.1 Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described in BCP document are to be interpreted as described in [RFC2119].
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Most of the terminology used in this documents comes from [RFC7432] 3. Abbreviations
and [NVO3-FRWK].
NVO3: Network Virtualization Overlay over Layer 3 NVO3 Network Virtualization Overlays over Layer 3
GENEVE: Generic Network Virtualization Encapsulation.
NVE: Network Virtualization Edge. GENEVE: Generic Network Virtualization Encapsulation.
VNI: Virtual Network Identifier. NVE: Network Virtualization Edge.
MAC: Media Access Control. VNI: Virtual Network Identifier.
OAM: Operations, Administration and Maintenance. MAC: Media Access Control.
PE: Provide Edge Node. OAM: Operations, Administration and Maintenance.
CE: Customer Edge device e.g., host or router or switch. PE: Provide Edge Node.
EVPN: Ethernet VPN. CE: Customer Edge device e.g., host or router or switch.
EVI: An EVPN instance spanning the Provider Edge (PE) devices EVPN: Ethernet VPN.
participating in that EVPN.
MAC-VRF: A Virtual Routing and Forwarding table for Media Access EVI: An EVPN instance spanning the Provider Edge (PE) devices
Control (MAC) addresses on a PE. participating in that EVPN.
2. GENEVE extensions MAC-VRF: A Virtual Routing and Forwarding table for Media Access
Control (MAC) addresses on a PE.
This document adds some extensions to the [GENEVE] encapsulation that 4. GENEVE extensions
are relevant to the operation of EVPN.
2.1 Ethernet option TLV This document adds some extensions to the [I-D.ietf-nvo3-geneve]
encapsulation that are relevant to the operation of EVPN.
[EVPN-OVERLAY] describes when an ingress NVE uses ingress replication 4.1. Ethernet option TLV
to flood unknown unicast traffic to the egress NVEs, the ingress NVE
needs to indicate to the egress NVE that the Encapsulated packet is a [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses
BUM traffic type. This is required to avoid transient packet ingress replication to flood unknown unicast traffic to the egress
duplication in all-active multi-homing scenarios. For GENVE NVEs, the ingress NVE needs to indicate to the egress NVE that the
encapsulation we need a bit to for this purpose. Encapsulated packet is a BUM traffic type. This is required to avoid
transient packet duplication in all-active multi-homing scenarios.
For GENVE encapsulation we need a bit to for this purpose.
[RFC8317] uses MPLS label for leaf indication of BUM traffic [RFC8317] uses MPLS label for leaf indication of BUM traffic
originated from a leaf AC in an ingress NVE so that the egress NVEs originated from a leaf AC in an ingress NVE so that the egress NVEs
can filter BUM traffic toward their leaf ACs. For GENVE encapsulation can filter BUM traffic toward their leaf ACs. For GENVE
we need a bit for this purpose. encapsulation we need a bit for this purpose.
Although the default mechanism for split-horizon filtering of BUM Although the default mechanism for split-horizon filtering of BUM
traffic on an Ethernet segment for IP-based ecnapsulations such as traffic on an Ethernet segment for IP-based ecnapsulations such as
VxLAN, GPE, NVGRE, and GENVE, is local-bias as defined in section VxLAN, GPE, NVGRE, and GENVE, is local-bias as defined in section
8.3.1 of [EVPN-OVERLAY], there can be an incentive to leverage the 8.3.1 of [I-D.ietf-bess-evpn-overlay], there can be an incentive to
same split-horizon filtering mechanism of [RFC7432] that uses a 20- leverage the same split-horizon filtering mechanism of [RFC7432] that
bit MPLS label so that a) the a single filtering mechanism is used uses a 20- bit MPLS label so that a) the a single filtering mechanism
for all encapsulation types and b) the same PE can participate in a is used for all encapsulation types and b) the same PE can
mix of MPLS and IP encapsulations. For this purpose a 20-bit label participate in a mix of MPLS and IP encapsulations. For this purpose
field MAY be defined for GENVE encapsulation. The support for this a 20-bit label field MAY be defined for GENVE encapsulation. The
label is optional. support for this label is optional.
If an NVE wants to use local-bias procedure, then it sends the new If an NVE wants to use local-bias procedure, then it sends the new
option TLV without ESI-label (e.g., length=4): option TLV without ESI-label (e.g., length=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 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
| Option Class=Ethernet |Type=0 |B|L|R| Len=0x1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Class=Ethernet |Type=0 |B|L|R| Len=0x1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If an NVE wants to use ESI-label, then it sends the new option TLV If an NVE wants to use ESI-label, then it sends the new option TLV
with ESI-label (e.g., length=8) with ESI-label (e.g., length=8)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Class=Ethernet |Typ=EVPN-OPTION|B|L|R| Len=0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | Source-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 Where: - Option Class is set to Ethernet (new Option Class requested
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 to IANA) - Type is set to EVPN-OPTION (new type requested to IANA)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and C bit must be set. - B bit is set to 1 for BUM traffic. - L bit
| Option Class=Ethernet |Typ=EVPN-OPTION|B|L|R| Len=0x2 | is set to 1 for Leaf-Indication. - Source-ID is a 24-bit value that
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ encodes the ESI-label value signaled on the EVPN Autodiscovery per-ES
| Rsvd | Source-ID | routes, as described in [RFC7432] for multi-homing and [RFC8317] for
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ leaf-to-leaf BUM filtering. The ESI-label value is encoded in the
high-order 20 bits of the Source-ESI field.
Where:
- Option Class is set to Ethernet (new Option Class requested
to IANA)
- Type is set to EVPN-OPTION (new type requested to IANA) and
C bit must be set.
- B bit is set to 1 for BUM traffic.
- L bit is set to 1 for Leaf-Indication.
- Source-ID is a 24-bit value that encodes the ESI-label value
signaled on the EVPN Autodiscovery per-ES routes, as described
in [RFC7432] for multi-homing and [RFC8317] for leaf-to-leaf
BUM filtering. The ESI-label value is encoded in the high-order
20 bits of the Source-ESI field.
The egress NVEs that make use of ESIs in the data path (because they The egress NVEs that make use of ESIs in the data path (because they
have a local multi-homed ES or support [RFC8317]) SHOULD advertise have a local multi-homed ES or support [RFC8317] SHOULD advertise
their Ethernet A-D per-ES routes along with the Geneve tunnel sub-TLV their Ethernet A-D per-ES routes along with the Geneve tunnel sub-TLV
and in addition to the ESI-label Extended Community. The ingress NVE and in addition to the ESI-label Extended Community. The ingress NVE
can then use the Ethernet option-TLV when sending GENEVE packets can then use the Ethernet option-TLV when sending GENEVE packets
based on the [RFC7432] and [RFC8317] procedures. The egress NVE will based on the [RFC7432] and [RFC8317] procedures. The egress NVE will
use the Source-ID field in the received packets to make filtering use the Source-ID field in the received packets to make filtering
decisions. decisions.
Note that [EVPN-OVERLAY] modifies the [RFC7432] split-horizon Note that [I-D.ietf-bess-evpn-overlay] modifies the [RFC7432] split-
procedures for NVO3 tunnels using the "local-bias" procedure. "Local- horizon procedures for NVO3 tunnels using the "local-bias" procedure.
bias" relies on tunnel IP source address checks (instead of ESI- "Local- bias" relies on tunnel IP source address checks (instead of
labels) to determine whether a packet can be forwarded to a local ES. ESI- labels) to determine whether a packet can be forwarded to a
local ES.
While "local-bias" MUST be supported along with GENEVE encapsulation, While "local-bias" MUST be supported along with GENEVE encapsulation,
the use of the Ethernet option-TLV is RECOMMENDED to follow the same the use of the Ethernet option-TLV is RECOMMENDED to follow the same
procedures used by EVPN MPLS. procedures used by EVPN MPLS.
An ingress NVE using ingress replication to flood BUM traffic MUST An ingress NVE using ingress replication to flood BUM traffic MUST
send B=1 in all the GENEVE packets that encapsulate BUM frames. An send B=1 in all the GENEVE packets that encapsulate BUM frames. An
egress NVE SHOULD determine whether a received packet encapsulates a egress NVE SHOULD determine whether a received packet encapsulates a
BUM frame based on the B bit. The use of the B bit is only relevant BUM frame based on the B bit. The use of the B bit is only relevant
to GENEVE packets with Protocol Type 0x6558 (Bridged Ethernet). to GENEVE packets with Protocol Type 0x6558 (Bridged Ethernet).
3. BGP Extensions 5. BGP Extensions
As per [EVPN-OVERLAY] the BGP Encapsulation extended community As per [I-D.ietf-bess-evpn-overlay] the BGP Encapsulation extended
defined in [TUNNEL-ENCAP] is included with all EVPN routes advertised community defined in [I-D.ietf-idr-tunnel-encaps] is included with
by an egress NVE. all EVPN routes advertised by an egress NVE.
This document specifies a new BGP Tunnel Encapsulation Type for This document specifies a new BGP Tunnel Encapsulation Type for
Geneve and a new Geneve tunnel option types sub-TLV as described Geneve and a new Geneve tunnel option types sub-TLV as described
below. below.
3.1 Geneve Tunnel Option Types sub-TLV 5.1. Geneve Tunnel Option Types sub-TLV
The Geneve tunnel option types is a new BGP Tunnel Encapsulation The Geneve tunnel option types is a new BGP Tunnel Encapsulation
Attribute Sub-TLV. Attribute Sub-TLV.
+-----------------------------------+ +-----------------------------------+
| Sub-TLV Type (1 Octet) | | Sub-TLV Type (1 Octet) |
+-----------------------------------+ +-----------------------------------+
| Sub-TLV Length (1 or 2 Octets)| | Sub-TLV Length (1 or 2 Octets)|
+-----------------------------------+ +-----------------------------------+
| Sub-TLV Value (Variable) | | Sub-TLV Value (Variable) |
| | | |
+-----------------------------------+ +-----------------------------------+
Figure 1: Geneve tunnel option types sub-TLV Figure 1: Geneve tunnel option types sub-TLV
The Sub-TLV Type field contains a value in the range from 192-252. The Sub-TLV Type field contains a value in the range from 192-252.
To be allocated by IANA. To be allocated by IANA.
Sub-TLV value MUST match exactly the first 4-octets of the option TLV Sub-TLV value MUST match exactly the first 4-octets of the option TLV
format. For instance, if we need to signal support for two option format. For instance, if we need to signal support for two option
TLVs: TLVs:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Class | Type |R|R|R| Length | | Option Class | Type |R|R|R| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Class | Type |R|R|R| Length | | Option Class | Type |R|R|R| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where, an NVE receiving the above sub-TLV, will send GENEVE packets Where, an NVE receiving the above sub-TLV, will send GENEVE packets
to the originator NVE with with only the option TLVs the receiver NVE to the originator NVE with with only the option TLVs the receiver NVE
is capable of receiving, and following the same order. Also the high is capable of receiving, and following the same order. Also the high
order bit in the type, is the critical bit, MUST be set accordingly. order bit in the type, is the critical bit, MUST be set accordingly.
The above sub-TLV(s) MAY be included with only Ethernet A-D per-ES The above sub-TLV(s) MAY be included with only Ethernet A-D per-ES
routes. routes.
4. Operation 6. Operation
The following figure shows an example of an NVO3 deployment with The following figure shows an example of an NVO3 deployment with
EVPN. EVPN.
+--------------+ +--------------+
| | | |
+---------+ | WAN | +---------+ +---------+ | WAN | +---------+
+----+ | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | | +----+
|NVE1|--| | |ASBR| |ASBR| | |--|NVE3| |NVE1|--| | |ASBR| |ASBR| | |--|NVE3|
+----+ |IP Fabric|---| 1 | | 2 |--|IP Fabric| +----+ +----+ |IP Fabric|---| 1 | | 2 |--|IP Fabric| +----+
+----+ | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | | +----+
|NVE2|--| | | | | |--|NVE4| |NVE2|--| | | | | |--|NVE4|
+----+ +---------+ +--------------+ +---------+ +----+ +----+ +---------+ +--------------+ +---------+ +----+
|<------ DC 1 -----> <---- DC2 ------>| |<------ DC 1 -----> <---- DC2 ------>|
Figure 2: Data Center Interconnect with ASBR Figure 2: Data Center Interconnect with ASBR
iBGP sessions are established between NVE1, NVE2, ASBR1, possibly via iBGP sessions are established between NVE1, NVE2, ASBR1, possibly via
a BGP route-reflector. Similarly, iBGP sessions are established a BGP route-reflector. Similarly, iBGP sessions are established
between NVE3, NVE4, ASBR2. between NVE3, NVE4, ASBR2.
eBGP sessions are established among ASBR1 and ASBR2. eBGP sessions are established among ASBR1 and ASBR2.
All NVEs and ASBRs are enabled for the EVPN SAFI and exchange EVPN All NVEs and ASBRs are enabled for the EVPN SAFI and exchange EVPN
routes. For inter-AS option B, the ASBRs re-advertise these routes routes. For inter-AS option B, the ASBRs re-advertise these routes
with NEXT_HOP attribute set to their IP addresses as per [RFC4271]. with NEXT_HOP attribute set to their IP addresses as per [RFC4271].
NVE1 sets the BGP Encapsulation extended community defined in all NVE1 sets the BGP Encapsulation extended community defined in all
EVPN routes advertised. NVE1 sets the BGP Tunnel Encapsulation EVPN routes advertised. NVE1 sets the BGP Tunnel Encapsulation
Attribute Tunnel Type to Geneve tunnel encapsulation, and sets the Attribute Tunnel Type to Geneve tunnel encapsulation, and sets the
Tunnel Encapsulation Attribute Tunnel sub-TLV for the Geneve tunnel Tunnel Encapsulation Attribute Tunnel sub-TLV for the Geneve tunnel
option types with all the Geneve option types it can transmit and option types with all the Geneve option types it can transmit and
receive. receive.
All other NVE(s) learn what Geneve option types are supported by NVE1 All other NVE(s) learn what Geneve option types are supported by NVE1
through the EVPN control plane. In the datapath, NVE2, NVE3 and NVE4 through the EVPN control plane. In the datapath, NVE2, NVE3 and NVE4
only encapsulate overlay packets with the Geneve option TLV(s) that only encapsulate overlay packets with the Geneve option TLV(s) that
NVE1 is capable of receiving. NVE1 is capable of receiving.
A PE advertises the BGP Encapsulation extended community defined in A PE advertises the BGP Encapsulation extended community defined in
[RFC5512] if it supports any of the encapsulations defined in [EVPN- [RFC5512] if it supports any of the encapsulations defined in
OVERLAY]. A PE advertises the BGP Tunnel Encapsulation Attribute [I-D.ietf-bess-evpn-overlay]. A PE advertises the BGP Tunnel
defined in [TUNNEL-ENCAP] if it supports Geneve encapsulation. Encapsulation Attribute defined in [I-D.ietf-idr-tunnel-encaps] if it
supports Geneve encapsulation.
5. Security Considerations 7. Security Considerations
The mechanisms in this document use EVPN control plane as defined in The mechanisms in this document use EVPN control plane as defined in
[RFC7432]. Security considerations described in [RFC7432] are equally [RFC7432]. Security considerations described in [RFC7432] are
applicable. equally applicable.
This document uses IP-based tunnel technologies to support data plane This document uses IP-based tunnel technologies to support data plane
transport. Security considerations described in [RFC7432] and in transport. Security considerations described in [RFC7432] and in
[EVPN-OVERLAY] are equally applicable. [I-D.ietf-bess-evpn-overlay] are equally applicable.
6. IANA Considerations 8. IANA Considerations
IANA is requested to allocate the following: IANA is requested to allocate the following:
BGP Tunnel Encapsulation Attribute BGP Tunnel Encapsulation Attribute
Tunnel Type: Tunnel Type:
XX Geneve Encapsulation XX Geneve Encapsulation
BGP Tunnel Encapsulation Attribute Sub-TLVs a Code point from the BGP Tunnel Encapsulation Attribute Sub-TLVs a Code point from the
range of 192-252 for Geneve tunnel option types sub-TLV. range of 192-252 for Geneve tunnel option types sub-TLV.
IANA is requested to assign a new option class from the "Geneve IANA is requested to assign a new option class from the "Geneve
Option Class" registry for the Ethernet option TLV. Option Class" registry for the Ethernet option TLV.
Option Class Description Option Class Description
------------ --------------- ------------ ---------------
XXXX Ethernet option XXXX Ethernet option
7. Acknowledgements 9. Acknowledgements
The authors wish to thank T. Sridhar, for his input, feedback, and The authors wish to thank T. Sridhar, for his input, feedback, and
helpful suggestions. helpful suggestions.
8. References 10. References
8.1 Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [I-D.ietf-bess-evpn-overlay]
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March Sajassi, A., Drake, J., Bitar, N., Shekhar, R., Uttaro,
1997, <http://www.rfc-editor.org/info/rfc2119>. J., and W. Henderickx, "A Network Virtualization Overlay
Solution using EVPN", draft-ietf-bess-evpn-overlay-12
(work in progress), February 2018.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [I-D.ietf-idr-tunnel-encaps]
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc- Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15
editor.org/info/rfc7432>. (work in progress), December 2019.
[RFC8317] Sajassi, et al. "Ethernet-Tree (E-Tree) Support in Ethernet [I-D.ietf-nvo3-encap]
VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)", RFC 8317, Boutros, S., "NVO3 Encapsulation Considerations", draft-
January 2018, <http://www.rfc-editor.org/info/rfc8317>. ietf-nvo3-encap-05 (work in progress), February 2020.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border [I-D.ietf-nvo3-geneve]
Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, <http://www.rfc- Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
editor.org/info/rfc4271>. Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-16 (work in progress), March 2020.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, Requirement Levels", BCP 14, RFC 2119,
<http://www.rfc-editor.org/info/rfc5226>. DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[GENEVE] Gross, et al. "Geneve: Generic Network Virtualization [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Encapsulation", draft-ietf-nvo3-geneve-05, work in progress, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
September, 2017. DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[DT-ENCAP] Boutros, et al. "NVO3 Encapsulation Considerations", [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
draft-ietf-nvo3-encap-01, work in progress, October, 2017. Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512,
DOI 10.17487/RFC5512, April 2009,
<https://www.rfc-editor.org/info/rfc5512>.
[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Attribute", draft-ietf-idr-tunnel-encaps-07, work in progress, July, Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
2017. Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[EVPN-OVERLAY] Sajassi-Drake et al., "A Network Virtualization [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J.,
Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-10.txt, Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree)
work in progress, December, 2017 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>.
8.2 Informative References 10.2. Informative References
[NVO3-FRWK] Lasserre et al., "Framework for DC Network [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Virtualization", RFC 7365, October 2014. Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
2014, <https://www.rfc-editor.org/info/rfc7365>.
Authors' Addresses Authors' Addresses
Sami Boutros Sami Boutros (editor)
VMware, Inc. Ciena
Email: boutross@vmware.com USA
Email: sboutros@ciena.com
Ali Sajassi Ali Sajassi
Cisco Cisco Systems
USA
Email: sajassi@cisco.com Email: sajassi@cisco.com
John Drake John Drake
Juniper Networks Juniper Networks
USA
Email: jdrake@juniper.net Email: jdrake@juniper.net
Jorge Rabadan Jorge Rabadan
Nokia Juniper Networks
USA
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Sam Aldrin Sam Aldrin
Google Juniper Networks
USA
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
 End of changes. 90 change blocks. 
222 lines changed or deleted 237 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/