rfc9469xml2.original.xml   rfc9469.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7432.xml">
<!ENTITY RFC7365 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7365.xml">
<!ENTITY RFC7364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7364.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8365 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8365.xml">
<!ENTITY I-D.ietf-nvo3-encap SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3
/reference.I-D.ietf-nvo3-encap.xml">
<!ENTITY I-D.ietf-bess-evpn-lsp-ping SYSTEM "https://xml2rfc.ietf.org/public/rfc
/bibxml3/reference.I-D.ietf-bess-evpn-lsp-ping.xml">
<!ENTITY I-D.skr-bess-evpn-pim-proxy SYSTEM "https://xml2rfc.ietf.org/public/rfc
/bibxml3/reference.I-D.skr-bess-evpn-pim-proxy.xml">
<!ENTITY I-D.ietf-bess-evpn-optimized-ir SYSTEM "https://xml2rfc.ietf.org/public
/rfc/bibxml3/reference.I-D.ietf-bess-evpn-optimized-ir.xml">
<!ENTITY RFC8584 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8584.xml">
<!ENTITY I-D.ietf-bess-evpn-pref-df SYSTEM "https://xml2rfc.ietf.org/public/rfc/
bibxml3/reference.I-D.ietf-bess-evpn-pref-df.xml">
<!ENTITY I-D.ietf-bess-evpn-irb-mcast SYSTEM "https://xml2rfc.ietf.org/public/rf
c/bibxml3/reference.I-D.ietf-bess-evpn-irb-mcast.xml">
<!ENTITY I-D.ietf-bess-evpn-ipvpn-interworking SYSTEM "https://xml2rfc.ietf.org/
public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-ipvpn-interworking.xml">
<!ENTITY RFC7348 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7348.xml">
<!ENTITY RFC7510 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7510.xml">
<!ENTITY RFC4364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4364.xml">
<!ENTITY I-D.ietf-bess-evpn-geneve SYSTEM "https://xml2rfc.ietf.org/public/rfc/b
ibxml3/reference.I-D.ietf-bess-evpn-geneve.xml">
<!ENTITY I-D.ietf-bess-evpn-mvpn-seamless-interop SYSTEM "https://xml2rfc.ietf.o
rg/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-mvpn-seamless-interop.xml">
<!ENTITY I-D.sajassi-bess-secure-evpn SYSTEM "https://xml2rfc.ietf.org/public/rf
c/bibxml3/reference.I-D.sajassi-bess-secure-evpn.xml">
<!ENTITY I-D.ietf-bess-rfc7432bis SYSTEM "https://xml2rfc.ietf.org/public/rfc/bi
bxml3/reference.I-D.ietf-bess-rfc7432bis.xml">
<!ENTITY I-D.ietf-rtgwg-bgp-pic SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibx
ml3/reference.I-D.ietf-rtgwg-bgp-pic.xml">
<!ENTITY RFC5925 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5925.xml">
<!ENTITY RFC4271 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4271.xml">
<!ENTITY RFC4272 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4272.xml">
<!ENTITY RFC6952 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6952.xml">
<!ENTITY RFC8926 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8926.xml">
<!ENTITY RFC9135 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9135.xml">
<!ENTITY RFC9136 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9136.xml">
<!ENTITY RFC9012 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9012.xml">
<!ENTITY RFC9161 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9161.xml">
<!ENTITY RFC9014 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9014.xml">
<!ENTITY RFC4760 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4760.xml">
<!ENTITY RFC9251 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9251.xml">
]>
<rfc category="info" docName="draft-ietf-nvo3-evpn-applicability-06"
ipr="trust200902" submissionType="IETF">
<!-- Generated by id2xml 1.5.0 on 2020-11-02T10:45:47Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc text-list-symbols="o-*+"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" info" consensus="true" docName="draft-ietf-nvo3-evpn-applicability-06" number="9 469" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sort Refs="true" tocInclude="true" version="3">
<?rfc toc="yes"?> <!-- xml2rfc v2v3 conversion 3.17.1 -->
<!-- Generated by id2xml 1.5.0 on 2020-11-02T10:45:47Z -->
<front> <front>
<title abbrev="EVPN Applicability for NVO3">Applicability of EVPN to NVO3 <title abbrev="EVPN Applicability for NVO3">Applicability of Ethernet Virtua
Networks</title> l Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks<
/title>
<author fullname="Jorge Rabadan" initials="J." role="editor" <seriesInfo name="RFC" value="9469"/>
surname="Rabadan"> <author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabada
n">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>520 Almanor Ave</street> <street>520 Almanor Ave</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94085</code> <code>94085</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>jorge.rabadan@nokia.com</email> <email>jorge.rabadan@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Matthew Bocci" initials="M." surname="Bocci"> <author fullname="Matthew Bocci" initials="M." surname="Bocci">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>matthew.bocci@nokia.com</email> <email>matthew.bocci@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Sami Boutros" initials="S." surname="Boutros"> <author fullname="Sami Boutros" initials="S." surname="Boutros">
<organization>Ciena</organization> <organization>Ciena</organization>
<address> <address>
<email>sboutros@ciena.com</email> <email>sboutros@ciena.com</email>
</address> </address>
</author> </author>
<author fullname="Ali Sajassi" initials="A." surname="Sajassi"> <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization> <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address> <address>
<email>sajassi@cisco.com</email> <email>sajassi@cisco.com</email>
</address> </address>
</author> </author>
<date month="September" year="2023"/>
<date day="28" month="April" year="2023"/> <area>rtg</area>
<workgroup>nvo3</workgroup>
<workgroup>NVO3 Workgroup</workgroup>
<abstract> <abstract>
<t>Ethernet Virtual Private Network (EVPN) provides a unified <t>An Ethernet Virtual Private Network (EVPN) provides a unified
control-plane that solves the Network Virtualization Edge (NVE) control plane that solves the issues of Network Virtualization Edge (NVE)
auto-discovery, tenant MAC/IP dissemination and advanced features auto-discovery, tenant Media Access Control (MAC) / IP dissemination, and
required by Network Virtualization Over Layer-3 (NVO3) networks. EVPN is advanced features in a scablable way as
required by Network Virtualization over Layer 3 (NVO3) networks.
EVPN is
a scalable solution for NVO3 networks and keeps the independence of the a scalable solution for NVO3 networks and keeps the independence of the
underlay IP Fabric, i.e. there is no need to enable PIM in the underlay underlay IP Fabric, i.e., there is no need to enable Protocol Independent
network and maintain multicast states for tenant Broadcast Domains. This Multicast (PIM) in the underlay
document describes the use of EVPN for NVO3 networks, discusses its network and maintain multicast states for tenant Broadcast Domains.
applicability to basic Layer-2 and Layer-3 connectivity requirements, as This document describes the use of EVPN for NVO3 networks and discusses it
well as advanced features such as MAC-mobility, MAC Protection and Loop s
Protection, multi-homing, Data Center Interconnect (DCI) and much more. applicability to basic Layer 2 and Layer 3 connectivity requirements and t
No new EVPN procedures are introduced. </t> o
advanced features such as MAC Mobility, MAC Protection and Loop
Protection, multihoming, Data Center Interconnect (DCI), and much more.
No new EVPN procedures are introduced.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" title="Introduction"> <section anchor="sect-1" numbered="true" toc="default">
<t>In Network Virtualization Over Layer-3 (NVO3) networks, Network <name>Introduction</name>
Virtualization Edge devices (NVEs) sit at the edge of the underlay
network and provide Layer-2 and Layer-3 connectivity among Tenant <t>In Network Virtualization over Layer 3 (NVO3) networks, Network
Virtualization Edge (NVE) devices sit at the edge of the underlay
network and provide Layer 2 and Layer 3 connectivity among Tenant
Systems (TSes) of the same tenant. The NVEs need to build and maintain Systems (TSes) of the same tenant. The NVEs need to build and maintain
mapping tables so that they can deliver encapsulated packets to their mapping tables so they can deliver encapsulated packets to their
intended destination NVE(s). While there are different options to create intended destination NVE(s). While there are different options to create
and disseminate the mapping table entries, NVEs may exchange that and disseminate the mapping table entries, NVEs may exchange that
information directly among themselves via a control-plane protocol, such information directly among themselves via a control plane protocol, such
as Ethernet Virtual Private Network (EVPN). EVPN provides an efficient, as Ethernet Virtual Private Network (EVPN). EVPN provides an efficient,
flexible and unified control-plane option that can be used for Layer-2 flexible, and unified control plane option that can be used for Layer 2
and Layer-3 Virtual Network (VN) service connectivity. This document and Layer 3 Virtual Network (VN) service connectivity. This document
does not introduce any new procedures in EVPN.</t> does not introduce any new procedures in EVPN.</t>
<t>In this document, we assume that the EVPN control plane module
<t>In this document, we assume that the EVPN control-plane module
resides in the NVEs. The NVEs can be virtual switches in hypervisors, resides in the NVEs. The NVEs can be virtual switches in hypervisors,
Top Of Rack (TOR) switches or Leaf switches or Data Center Gateways. As Top-of-Rack (ToR) switches or Leaf switches, or Data Center Gateways. As
described in <xref target="RFC7365"/>, Network Virtualization described in <xref target="RFC7365" format="default"/>, Network Virtualiza
tion
Authorities (NVAs) may be used to provide the forwarding information to Authorities (NVAs) may be used to provide the forwarding information to
the NVEs, and in that case, EVPN could be used to disseminate the the NVEs, and in that case, EVPN could be used to disseminate the
information across multiple federated NVAs. The applicability of EVPN information across multiple federated NVAs. The applicability of EVPN
would then be similar to the one described in this document. However, would then be similar to the one described in this document. However,
for simplicity, the description assumes control-plane communication for simplicity, the description assumes control plane communication
among NVE(s).</t> among NVE(s).</t>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
<section anchor="sect-2" title="EVPN and NVO3 Terminology"> <name>EVPN and NVO3 Terminology</name>
<t>This document uses the terminology of <xref target="RFC7365"/>, in <t>This document uses the terminology of <xref target="RFC7365" format="de
addition to the terms that follow. <list style="symbols"> fault"/> in
<t>AC: Attachment Circuit or logical interface associated to a given addition to the terms that follow. </t>
<dl spacing="normal" newline="false">
<dt>AC:</dt><dd>Attachment Circuit or logical interface associated with
a given
BT. To determine the AC on which a packet arrived, the NVE will BT. To determine the AC on which a packet arrived, the NVE will
examine the physical/logical port and/or VLAN tags (where the VLAN examine the physical/logical port and/or VLAN tags (where the VLAN
tags can be individual c-tags, s-tags or ranges of both).</t> tags can be individual c-tags, s-tags, or ranges of both).</dd>
<dt>ARP and NDP:</dt><dd>Address Resolution Protocol (IPv4) and Neighbor
<t>ARP and ND: Address Resolution Protocol (IPv4) and Neighbor Discovery Protocol (IPv6), respectively.</dd>
Discovery protocol (IPv6).</t> <dt>BD:</dt><dd>Broadcast Domain that corresponds to a tenant IP subnet.
If
<t>BD: or Broadcast Domain, it corresponds to a tenant IP subnet. If
no suppression techniques are used, a BUM frame that is injected in no suppression techniques are used, a BUM frame that is injected in
a Broadcast Domain will reach all the NVEs that are attached to that a Broadcast Domain will reach all the NVEs that are attached to that
Broadcast Domain. An EVI may contain one or multiple Broadcast Broadcast Domain. An EVI may contain one or multiple Broadcast
Domains depending on the service model <xref target="RFC7432"/>. Domains depending on the service model <xref target="RFC7432" format=" default"/>.
This document will use the term Broadcast Domain to refer to a This document will use the term Broadcast Domain to refer to a
tenant subnet.</t> tenant subnet.</dd>
<dt>BT:</dt><dd>Bridge Table, as defined in <xref target="RFC7432" forma
<t>BT: a Bridge Table, as defined in <xref target="RFC7432"/>. A BT t="default"/>. A BT
is the instantiation of a Broadcast Domain in an NVE. When there is is the instantiation of a Broadcast Domain in an NVE. When there is
a single Broadcast Domain on a given EVI, the MAC-VRF is equivalent a single Broadcast Domain on a given EVI, the MAC-VRF is equivalent
to the BT on that NVE. Although a Broadcast Domain spans multiple to the BT on that NVE. Although a Broadcast Domain spans multiple
NVEs, and a BT is really the instantiation of a Broadcast Domain in NVEs and a BT is really the instantiation of a Broadcast Domain in
an NVE, this document uses BT and Broadcast Domain an NVE, this document uses BT and Broadcast Domain
interchangeably.</t> interchangeably.</dd>
<dt>BUM:</dt><dd>Broadcast, Unknown Unicast, and Multicast frames</dd>
<t>BUM: Broadcast, Unknown unicast and Multicast frames.</t> <dt>Clos:</dt><dd>A multistage network topology described in <xref targe
t="CLOS1953" format="default"/>, where all the edge switches (or Leafs) are
<t>Clos: a multistage network topology described in <xref
target="CLOS1953"/>, where all the edge switches (or Leafs) are
connected to all the core switches (or Spines). Typically used in connected to all the core switches (or Spines). Typically used in
Data Centers.</t> Data Centers.</dd>
<dt>DF and NDF:</dt><dd>Designated Forwarder and Non-Designated
<t>DF and NDF: they refer to Designated Forwarder and Non-Designated Forwarder, respectively. These are the roles that a given PE can have
Forwarder, which are the roles that a given PE can have in a given in a given
ES.</t> ES.</dd>
<dt>ECMP:</dt><dd>Equal-Cost Multipath</dd>
<t>ECMP: Equal Cost Multi-Path.</t> <dt>ES:</dt><dd>Ethernet Segment. When a Tenant System (TS) is connected
to
<t>ES: Ethernet Segment. When a Tenant System (TS) is connected to one or more NVEs via a set of Ethernet links, that set of links
one or more NVEs via a set of Ethernet links, then that set of links is referred to as an "Ethernet Segment". Each ES is represented by a
is referred to as an 'Ethernet segment'. Each ES is represented by a unique Ethernet Segment Identifier (ESI) in the NVO3 network, and the
unique Ethernet Segment Identifier (ESI) in the NVO3 network and the ESI is used in EVPN routes that are specific to that ES.</dd>
ESI is used in EVPN routes that are specific to that ES.</t>
<t>Ethernet Tag: Used to represent a Broadcast Domain that is <dt>Ethernet Tag:</dt><dd>Used to represent a Broadcast Domain that is
configured on a given ES for the purpose of Designated Forwarder configured on a given ES for the purpose of Designated Forwarder
election. Note that any of the following may be used to represent a election. Note that any of the following may be used to represent a
Broadcast Domain: VIDs (including Q-in-Q tags), configured IDs, VNIs Broadcast Domain: VIDs (including Q-in-Q tags), configured IDs, VNIs,
(Virtual Extensible Local Area Network (VXLAN) Network Identifiers), normalized VIDs, Service Instance Identifiers (I-SIDs), etc., as
normalized VIDs, I-SIDs (Service Instance Identifiers), etc., as
long as the representation of the Broadcast Domains is configured long as the representation of the Broadcast Domains is configured
consistently across the multihomed PEs attached to that ES.</t> consistently across the multihomed PEs attached to that ES.</dd>
<dt>EVI or EVPN Instance:</dt><dd>A Layer 2 Virtual Network that uses
<t>EVI: or EVPN Instance. It is a Layer-2 Virtual Network that uses an EVPN control plane to exchange reachability information among the
an EVPN control-plane to exchange reachability information among the
member NVEs. It corresponds to a set of MAC-VRFs of the same tenant. member NVEs. It corresponds to a set of MAC-VRFs of the same tenant.
See MAC-VRF in this section.</t> See MAC-VRF in this section.</dd>
<t>EVPN: Ethernet Virtual Private Networks, as described in <xref
target="RFC7432"/>.</t>
<t>EVPN VLAN-aware bundle service model: similar to the VLAN-bundle <dt>EVPN:</dt><dd>Ethernet Virtual Private Network, as described in <xref target
model but each individual VLAN value is mapped to a different ="RFC7432" format="default"/>.</dd>
Broadcast Domain. In this model there are multiple Broadcast Domains
per EVI for a given tenant. Each Broadcast Domain is identified by
an "Ethernet Tag", that is a control-plane value that identifies the
routes for the Broadcast Domain within the EVI.</t>
<t>EVPN VLAN-based service model: one of the three service models <dt>EVPN VLAN-Aware Bundle Service Interface:</dt><dd>Similar to the VLAN-bundle
defined in <xref target="RFC7432"/>. It is characterized as a interface but each individual VLAN value is mapped to a different Broadcast
Domain. In this interface, there are multiple Broadcast Domains per EVI for a gi
ven
tenant. Each Broadcast Domain is identified by an "Ethernet Tag", which is a
control plane value that identifies the routes for the Broadcast Domain within
the EVI.</dd>
<dt>EVPN VLAN-Based Service Interface:</dt><dd>One of the three service
interfaces
defined in <xref target="RFC7432" format="default"/>. It is characteri
zed as a
Broadcast Domain that uses a single VLAN per physical access port to Broadcast Domain that uses a single VLAN per physical access port to
attach tenant traffic to the Broadcast Domain. In this service attach tenant traffic to the Broadcast Domain. In this service
model, there is only one Broadcast Domain per EVI.</t> interface, there is only one Broadcast Domain per EVI.</dd>
<dt>EVPN VLAN-Bundle Service Interface:</dt><dd>Similar to the VLAN-base
<t>EVPN VLAN-bundle service model: similar to VLAN-based but uses a d interface but uses a
bundle of VLANs per physical port to attach tenant traffic to the bundle of VLANs per physical port to attach tenant traffic to the
Broadcast Domain. As in VLAN-based, in this model there is a single Broadcast Domain. Like the VLAN-based interface, there is only one
Broadcast Domain per EVI.</t> Broadcast Domain per EVI.</dd>
<dt>Geneve:</dt><dd>Generic Network Virtualization Encapsulation. An NVO
<t>GENEVE: Generic Network Virtualization Encapsulation, an NVO3 3
encapsulation defined in <xref target="RFC8926"/>.</t> encapsulation defined in <xref target="RFC8926" format="default"/>.</d
d>
<t>IP-VRF: an IP Virtual Routing and Forwarding table, as defined in <dt>IP-VRF:</dt><dd>IP Virtual Routing and Forwarding table, as defined
<xref target="RFC4364"/>. It stores IP Prefixes that are part of the in
tenant's IP space, and are distributed among NVEs of the same tenant <xref target="RFC4364" format="default"/>. It stores IP Prefixes that
by EVPN. Route Distinguisher (RD) and Route Target(s) (RTs) are are part of the
tenant's IP space and are distributed among NVEs of the same tenant
by EVPN. A Route Distinguisher (RD) and one or more Route Targets (RTs
) are
required properties of an IP-VRF. An IP-VRF is instantiated in an required properties of an IP-VRF. An IP-VRF is instantiated in an
NVE for a given tenant, if the NVE is attached to multiple subnets NVE for a given tenant if the NVE is attached to multiple subnets
of the tenant and local inter-subnet-forwarding is required across of the tenant and local inter-subnet forwarding is required across
those subnets.</t> those subnets.</dd>
<t>IRB: Integrated Routing and Bridging interface. It refers to the <dt>IRB:</dt><dd>Integrated Routing and Bridging.
It refers to the
logical interface that connects a Broadcast Domain instance (or a logical interface that connects a Broadcast Domain instance (or a
BT) to an IP- VRF and allows to forward packets with destination in BT) to an IP-VRF and forwards packets with a destination in
a different subnet.</t> a different subnet.</dd>
<dt>MAC-VRF:</dt><dd>A MAC Virtual Routing and Forwarding table, as defi
<t>MAC-VRF: a MAC Virtual Routing and Forwarding table, as defined ned
in <xref target="RFC7432"/>. The instantiation of an EVI (EVPN in <xref target="RFC7432" format="default"/>. The instantiation of an
Instance) in an NVE. Route Distinguisher (RD) and Route Target(s) EVI (EVPN
(RTs) are required properties of a MAC-VRF and they are normally Instance) in an NVE. A Route Distinguisher (RD) and one or more RTs
are required properties of a MAC-VRF, and they are normally
different from the ones defined in the associated IP-VRF (if the different from the ones defined in the associated IP-VRF (if the
MAC-VRF has an IRB interface).</t> MAC-VRF has an IRB interface).</dd>
<t>NVE: Network Virtualization Edge device, a network entity that <dt>NVE:</dt><dd>Network Virtualization Edge. A network entity that
sits at the edge of an underlay network and implements Layer-2 sits at the edge of an underlay network and implements Layer 2
and/or Layer-3 network virtualization functions. The network-facing and/or Layer 3 network virtualization functions. The network-facing
side of the NVE uses the underlying Layer-3 network to tunnel tenant side of the NVE uses the underlying Layer 3 network to tunnel tenant
frames to and from other NVEs. The tenant-facing side of the NVE frames to and from other NVEs. The tenant-facing side of the NVE
sends and receives Ethernet frames to and from individual Tenant sends and receives Ethernet frames to and from individual Tenant
Systems. In this document, an NVE could be implemented as a virtual Systems.
switch within a hypervisor, a switch or a router, and runs EVPN in In this document, an NVE could be implemented as a virtual
the control-plane.</t> switch within a hypervisor, a switch, or a router, and it runs EVPN in
the control plane.</dd>
<t>NVO3 tunnels: Network Virtualization Over Layer-3 tunnels. In <dt>NVO3 tunnels:</dt><dd>Network Virtualization over Layer 3 tunnels.
In
this document, NVO3 tunnels refer to a way to encapsulate tenant this document, NVO3 tunnels refer to a way to encapsulate tenant
frames or packets into IP packets whose IP Source Addresses (SA) or frames or packets into IP packets, whose IP Source Addresses (SAs) or
Destination Addresses (DA) belong to the underlay IP address space, Destination Addresses (DAs) belong to the underlay IP address space,
and identify NVEs connected to the same underlay network. Examples and identify NVEs connected to the same underlay network. Examples
of NVO3 tunnel encapsulations are VXLAN <xref target="RFC7348"/>, of NVO3 tunnel encapsulations are VXLAN <xref target="RFC7348" format=
GENEVE <xref target="RFC8926"/> or MPLSoUDP <xref "default"/>,
target="RFC7510"/>.</t> Geneve <xref target="RFC8926" format="default"/>, or MPLSoUDP <xref ta
rget="RFC7510" format="default"/>.</dd>
<t>PE: Provider Edge router.</t> <dt>PE:</dt><dd>Provider Edge</dd>
<dt>PMSI:</dt><dd>Provider Multicast Service Interface</dd>
<t>PMSI: Provider Multicast Service Interface.</t> <dt>PTA:</dt><dd>PMSI Tunnel Attribute</dd>
<dt>RT and RD:</dt><dd>Route Target and Route Distinguisher, respectivel
<t>PTA: Provider Multicast Service Interface Tunnel Attribute.</t> y.</dd>
<dt>RT-1, RT-2, RT-3, etc.:</dt><dd>These refer to the Route Types follo
<t>RT and RD: Route Target and Route Distinguisher.</t> wed by the
type numbers as defined in the "EVPN Route Types" IANA registry (see <
<t>RT-1, RT-2, RT-3, etc.: they refer to Route Type followed by the eref target="https://www.iana.org/assignments/evpn/" brackets="angle"/>).</dd>
type number as defined in the IANA registry for EVPN route <dt>SA and DA:</dt><dd>Source Address and Destination Address, respectiv
types.</t> ely. They are used
along with MAC or IP, e.g., IP SA or MAC DA.</dd>
<t>SA and DA: Source Address and Destination Address. They are used <dt>SBD:</dt><dd>Supplementary Broadcast Domain, as defined in <xref target="RFC
along with MAC or IP, e.g. IP SA or MAC DA.</t> 9136" format="default"/>. It is a Broadcast Domain that does not have any
Attachment Circuits, only has IRB interfaces, and provides connectivit
<t>SBD: Supplementary Broadcast Domain. Defined in <xref y
target="RFC9136"/>, it is a Broadcast Domain that does not have any
Attachment Circuits, only IRB interfaces, and provides connectivity
among all the IP-VRFs of a tenant in the Interface-ful among all the IP-VRFs of a tenant in the Interface-ful
IP-VRF-to-IP-VRF models.</t> IP-VRF-to-IP-VRF models.</dd>
<dt>TS:</dt><dd>Tenant System. A physical or virtual system that can pla
<t>TS: Tenant System. A physical or virtual system that can play the y the
role of a host or a forwarding element such as a router, switch, role of a host or a forwarding element, such as a router, switch,
firewall, etc. It belongs to a single tenant and connects to one or firewall, etc. It belongs to a single tenant and connects to one or
more Broadcast Domains of that tenant.</t> more Broadcast Domains of that tenant.</dd>
<dt>VID:</dt><dd>Virtual Local Area Network Identifier</dd>
<t>VIDs: Virtual Local Area Network Identifiers.</t> <dt>VNI:</dt><dd>Virtual Network Identifier. Irrespective of the NVO3
<t>VNI: Virtual Network Identifier. Irrespective of the NVO3
encapsulation, the tunnel header always includes a VNI that is added encapsulation, the tunnel header always includes a VNI that is added
at the ingress NVE (based on the mapping table lookup) and at the ingress NVE (based on the mapping table lookup) and
identifies the BT at the egress NVE. This VNI is called VNI in VXLAN identifies the BT at the egress NVE.
or GENEVE, VSID in nvGRE or Label in MPLSoGRE or MPLSoUDP. This This VNI is called VNI in VXLAN
document will refer to VNI as a generic Virtual Network Identifier or Geneve, Virtual Subnet ID (VSID) in nvGRE, or Label in MPLSoGRE or
for any NVO3 encapsulation.</t> MPLSoUDP. This
document refers to VNI as a generic VNI
<t>VXLAN: Virtual eXtensible Local Area Network, an NVO3 for any NVO3 encapsulation.</dd>
encapsulation defined in <xref target="RFC7348"/>.</t> <dt>VXLAN:</dt><dd>Virtual eXtensible Local Area Network. An NVO3
</list></t> encapsulation defined in <xref target="RFC7348" format="default"/>.</d
d>
</dl>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default">
<section anchor="sect-3" title="Why is EVPN Needed in NVO3 Networks?"> <name>Why is EVPN Needed in NVO3 Networks?</name>
<t>Data Centers have adopted NVO3 architectures mostly due to the issues <t>Data Centers have adopted NVO3 architectures mostly due to the issues
discussed in <xref target="RFC7364"/>. The architecture of a Data Center discussed in <xref target="RFC7364" format="default"/>. The architecture o f a Data Center
is nowadays based on a Clos design, where every Leaf is connected to a is nowadays based on a Clos design, where every Leaf is connected to a
layer of Spines, and there is a number of Equal Cost Multi-Paths between layer of Spines and there is a number of ECMPs between
any two leaf nodes. All the links between Leaf and Spine nodes are any two Leaf nodes. All the links between Leaf and Spine nodes are
routed links, forming what we also know as an underlay IP Fabric. The routed links, forming what we also know as an underlay IP Fabric. The
underlay IP Fabric does not have issues with loops or flooding (like old underlay IP Fabric does not have issues with loops or flooding (like old
Spanning Tree Data Center designs did), convergence is fast and Equal Spanning Tree Data Center designs did), convergence is fast, and ECMP gene
Cost Multi-Path generally distributes utilization well across all the rally distributes utilization well across all the
links.</t> links.</t>
<t>On this architecture, and as discussed by <xref target="RFC7364" format
<t>On this architecture, and as discussed by <xref target="RFC7364"/>, ="default"/>,
multi-tenant intra-subnet and inter-subnet connectivity services are multi-tenant intra-subnet and inter-subnet connectivity services are
provided by NVO3 tunnels. VXLAN <xref target="RFC7348"/> or GENEVE <xref provided by NVO3 tunnels. VXLAN <xref target="RFC7348" format="default"/>
target="RFC8926"/> are two examples of such NVO3 tunnels.</t> and Geneve <xref target="RFC8926" format="default"/> are two examples of such NV
O3 tunnels.</t>
<t>Why is a control-plane protocol along with NVO3 tunnels helpful? <t>Why is a control plane protocol along with NVO3 tunnels helpful?
There are three main reasons:</t> There are three main reasons:</t>
<ol spacing="normal" type="a">
<li>Auto-discovery of the remote NVEs that are attached to the same VPN
instance (Layer 2 and/or Layer 3) as the ingress NVE is.</li>
<li>Dissemination of the MAC/IP host information so that mapping
tables can be populated on the remote NVEs.</li>
<t><list style="letters"> <li>Advanced features such as MAC Mobility, MAC Protection, BUM and
<t>Auto-discovery of the remote NVEs that are attached to the same ARP/ND traffic reduction/suppression, multihoming, functionality simil
VPN instance (Layer-2 and/or Layer-3) as the ingress NVE is.</t> ar to Prefix
Independent Convergence (PIC) <xref target="I-D.ietf-rtgwg-bgp-pic" fo
<t>Dissemination of the MAC/IP host information so that mapping rmat="default"/>, fast convergence, etc.</li>
tables can be populated on the remote NVEs.</t> </ol>
<t>"Flood and learn" is a possible approach to achieve points (a) and (b)
<t>Advanced features such as MAC Mobility, MAC Protection, BUM and above for
ARP/ND traffic reduction/suppression, Multi-homing, Prefix multipoint Ethernet services. "Flood and learn"
Independent Convergence (PIC) like functionality <xref refers to "flooding" BUM traffic from the ingress NVE to all the egress NV
target="I-D.ietf-rtgwg-bgp-pic"/>, Fast Convergence, etc.</t> Es attached
</list></t> to the same Broadcast Domain instead of using a specific control plane on
the NVEs. The egress NVEs may then use data path
<t>A possible approach to achieve points (a) and (b) above for
multipoint Ethernet services, is "flood and learn". "Flood and learn"
refers to not using a specific control-plane on the NVEs, but rather
"flood" BUM traffic from the ingress NVE to all the egress NVEs attached
to the same Broadcast Domain. The egress NVEs may then use data path
source MAC address "learning" on the frames received over the NVO3 source MAC address "learning" on the frames received over the NVO3
tunnels. When the destination host replies and the frames arrive at the tunnels. When the destination host replies and the frames arrive at the
NVE that initially flooded BUM frames, the NVE will also "learn" the NVE that initially flooded BUM frames, the NVE will also "learn" the
source MAC address of the frame encapsulated on the NVO3 tunnel. This source MAC address of the frame encapsulated on the NVO3 tunnel. This
approach has the following drawbacks:</t> approach has the following drawbacks:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>In order to flood a given BUM frame, the ingress NVE must know <t>In order to flood a given BUM frame, the ingress NVE must know
the IP addresses of the remote NVEs attached to the same Broadcast the IP addresses of the remote NVEs attached to the same Broadcast
Domain. This may be done as follows:<list style="symbols"> Domain. This may be done as follows:</t>
<t>The remote tunnel IP addresses can be statically provisioned <ul spacing="normal">
<li>The remote tunnel IP addresses can be statically provisioned
on the ingress NVE. If the ingress NVE receives a BUM frame for on the ingress NVE. If the ingress NVE receives a BUM frame for
the Broadcast Domain on an ingress Attachment Circuit, it will the Broadcast Domain on an ingress Attachment Circuit, it will
do ingress replication and will send the frame to all the do ingress replication and will send the frame to all the
configured egress NVE destination IP addresses in the Broadcast configured egress NVE destination IP addresses in the Broadcast
Domain.</t> Domain.</li>
<li>All the NVEs attached to the same Broadcast Domain can
<t>All the NVEs attached to the same Broadcast Domain can subscribe to an underlay IP multicast group that is dedicated to
subscribe to an underlay IP Multicast Group that is dedicated to that Broadcast Domain.
that Broadcast Domain. When an ingress NVE receives a BUM frame When an ingress NVE receives a BUM frame
on an ingress Attachment Circuit, it will send a single copy of on an ingress Attachment Circuit, it will send a single copy of
the frame encapsulated into an NVO3 tunnel, using the multicast the frame encapsulated into an NVO3 tunnel using the multicast
address as destination IP address of the tunnel. This solution address as the destination IP address of the tunnel. This solution
requires Protocol Independent Multicast (PIM) in the underlay requires PIM in the underlay
network and the association of individual Broadcast Domains to network and the association of individual Broadcast Domains to
underlay IP multicast groups.</t> underlay IP multicast groups.</li>
</list></t> </ul>
</li>
<t>"Flood and learn" solves the issues of auto-discovery and <li>"Flood and learn" solves the issues of auto-discovery and
learning of the MAC to VNI/tunnel IP mapping on the NVEs for a given the learning of the MAC to VNI/tunnel IP mapping on the NVEs for a giv
en
Broadcast Domain. However, it does not provide a solution for Broadcast Domain. However, it does not provide a solution for
advanced features and it does not scale well (mostly due to the need advanced features, and it does not scale well (mostly due to the need
for constant flooding and the underlay PIM states that must be for constant flooding and the underlay PIM states that must be
maintained).</t> maintained).</li>
</list></t> </ul>
<t>EVPN provides a unified control plane that solves the issues of NVE
<t>EVPN provides a unified control-plane that solves the NVE auto-discovery, tenant MAC/IP dissemination, and advanced features in a
auto-discovery, tenant MAC/IP dissemination and advanced features in a scalable way and keeps the independence of the underlay IP Fabric;
scalable way and keeping the independence of the underlay IP Fabric,
i.e., there is no need to enable PIM in the underlay network and i.e., there is no need to enable PIM in the underlay network and
maintain multicast states for tenant Broadcast Domains.</t> maintain multicast states for tenant Broadcast Domains.</t>
<t><xref target="sect-4" format="default"/> describes how EVPN can be used
<t><xref target="sect-4"/> describes how EVPN can be used to meet the to meet the
control-plane requirements in an NVO3 network.</t> control plane requirements in an NVO3 network.</t>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default">
<section anchor="sect-4" title="Applicability of EVPN to NVO3 Networks"> <name>Applicability of EVPN to NVO3 Networks</name>
<t>This section discusses the applicability of EVPN to NVO3 networks. <t>This section discusses the applicability of EVPN to NVO3 networks.
The intent is not to provide a comprehensive explanation of the protocol The intent is not to provide a comprehensive explanation of the protocol
itself but give an introduction and point at the corresponding reference itself, but to give an introduction and point at the corresponding referen
document, so that the reader can easily find more details if needed.</t> ce
document so the reader can easily find more details if needed.</t>
<section anchor="sect-4.1" <section anchor="sect-4.1" numbered="true" toc="default">
title="EVPN Route Types Used in NVO3 Networks"> <name>EVPN Route Types Used in NVO3 Networks</name>
<t>EVPN supports multiple Route Types and each type has a different <t>EVPN supports multiple Route Types, and each type has a different
function. For convenience, <xref target="tab-evpn-route-types"/> shows function. For convenience, <xref target="tab-evpn-route-types" format="d
a summary of all the existing EVPN route types and its usage. In this efault"/> shows
document we may refer to these route types as RT-x routes, where x is a summary of all the existing EVPN Route Types and their usages. In this
the type number included in the first column of <xref document, we may refer to these route types as RT-x routes, where x is
target="tab-evpn-route-types"/>.</t> the type number included in the first column of <xref target="tab-evpn-r
oute-types" format="default"/>.</t>
<texttable anchor="tab-evpn-route-types" style="all" <table anchor="tab-evpn-route-types" align="center">
title="EVPN route types"> <name>EVPN Route Types</name>
<ttcol>Type</ttcol> <thead>
<tr>
<ttcol>Description</ttcol> <th align="left">Type</th>
<th align="left">Description</th>
<ttcol>Usage</ttcol> <th align="left">Usage</th>
</tr>
<c>1</c> </thead>
<tbody>
<c>Ethernet Auto-Discovery</c> <tr>
<td align="left">1</td>
<c>Multi-homing: used for MAC mass-withdraw when advertised per <td align="left">Ethernet Auto-Discovery</td>
Ethernet Segment, and used for aliasing/backup functions when <td align="left">Multihoming: Used for MAC mass-withdraw when adve
advertised per EVI</c> rtised per
Ethernet Segment and for aliasing/backup functions when
<c>2</c> advertised per EVI.</td>
</tr>
<c>MAC/IP Advertisement</c> <tr>
<td align="left">2</td>
<c>Host MAC/IP dissemination, supports MAC mobility and <td align="left">MAC/IP Advertisement</td>
protection</c> <td align="left">Host MAC/IP dissemination; supports MAC Mobility
and
<c>3</c> protection.</td>
</tr>
<c>Inclusive Multicast Ethernet Tag</c> <tr>
<td align="left">3</td>
<c>NVE discovery and BUM flooding tree setup</c> <td align="left">Inclusive Multicast Ethernet Tag</td>
<td align="left">NVE discovery and BUM flooding tree setup.</td>
<c>4</c> </tr>
<tr>
<c>Ethernet Segment</c> <td align="left">4</td>
<td align="left">Ethernet Segment</td>
<c>Multi-homing: ES auto-discovery and DF Election</c> <td align="left">Multihoming: ES auto-discovery and DF election.</
td>
<c>5</c> </tr>
<tr>
<c>IP Prefix</c> <td align="left">5</td>
<td align="left">IP Prefix</td>
<c>IP Prefix dissemination</c> <td align="left">IP Prefix dissemination.</td>
</tr>
<c>6</c> <tr>
<td align="left">6</td>
<c>Selective Multicast Ethernet Tag</c> <td align="left">Selective Multicast Ethernet Tag</td>
<td align="left">Indicate interest for a multicast S,G or *,G.</td
<c>Indicate interest for a multicast S,G or *,G</c> >
</tr>
<c>7</c> <tr>
<td align="left">7</td>
<c>Multicast Join Synch</c> <td align="left">Multicast Join Synch</td>
<td align="left">Multihoming: S,G or *,G state synch.</td>
<c>Multi-homing: S,G or *,G state synch</c> </tr>
<tr>
<c>8</c> <td align="left">8</td>
<td align="left">Multicast Leave Synch</td>
<c>Multicast Leave Synch</c> <td align="left">Multihoming: S,G or *,G leave synch.</td>
</tr>
<c>Multi-homing: S,G or *,G leave synch</c> <tr>
<td align="left">9</td>
<c>9</c> <td align="left">Per-Region I-PMSI A-D</td>
<td align="left">BUM tree creation across regions.</td>
<c>Per-Region I-PMSI A-D</c> </tr>
<tr>
<c>BUM tree creation across regions</c> <td align="left">10</td>
<td align="left">S-PMSI A-D</td>
<c>10</c> <td align="left">Multicast tree for S,G or *,G states.</td>
</tr>
<c>S-PMSI A-D</c> <tr>
<td align="left">11</td>
<c>Multicast tree for S,G or *,G states</c> <td align="left">Leaf A-D</td>
<td align="left">Used for responses to explicit tracking.</td>
<c>11</c> </tr>
</tbody>
<c>Leaf A-D</c> </table>
<c>Used for responses to explicit tracking</c>
</texttable>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default">
<section anchor="sect-4.2" <name>EVPN Basic Applicability for Layer 2 Services</name>
title="EVPN Basic Applicability for Layer-2 Services">
<t>Although the applicability of EVPN to NVO3 networks spans multiple <t>Although the applicability of EVPN to NVO3 networks spans multiple
documents, EVPN's baseline specification is <xref target="RFC7432"/>. documents, EVPN's baseline specification is <xref target="RFC7432" forma
<xref target="RFC7432"/> allows multipoint layer-2 VPNs to be operated t="default"/>.
as <xref target="RFC4364"/> IP-VPNs, where MACs and the information to <xref target="RFC7432" format="default"/> allows multipoint Layer 2 VPNs
set up flooding trees are distributed by MP-BGP <xref to be operated
target="RFC4760"/>. Based on <xref target="RFC7432"/>, <xref as IP VPNs <xref target="RFC4364" format="default"/>, where MACs and the
target="RFC8365"/> describes how to use EVPN to deliver Layer-2 information to
services specifically in NVO3 Networks.</t> set up flooding trees are distributed by Multiprotocol BGP (MP-BGP) <xre
f target="RFC4760" format="default"/>. Based on <xref target="RFC7432" format="d
<t><xref target="ure-evpn-for-l2-in-an-nvo3-network-example"/> efault"/>, <xref target="RFC8365" format="default"/> describes how to use EVPN t
represents a Layer-2 service deployed with an EVPN Broadcast Domain in o deliver Layer 2
services specifically in NVO3 networks.</t>
<t><xref target="ure-evpn-for-l2-in-an-nvo3-network-example" format="def
ault"/>
represents a Layer 2 service deployed with an EVPN Broadcast Domain in
an NVO3 network.</t> an NVO3 network.</t>
<figure anchor="ure-evpn-for-l2-in-an-nvo3-network-example">
<figure anchor="ure-evpn-for-l2-in-an-nvo3-network-example" <name>EVPN for L2 in an NVO3 Network - Example</name>
title="EVPN for L2 in an NVO3 Network - example"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ +--TS2---+
+--TS2---+ * | Single-Active
* | Single-Active * | ESI-1
* | ESI-1 +----+ +----+
+----+ +----+ |BD1 | |BD1 |
|BD1 | |BD1 | +-------------| |--| |-----------+
+-------------| |--| |-----------+ | +----+ +----+ |
| +----+ +----+ | | NVE2 NVE3 NVE4
| NVE2 NVE3 NVE4 | EVPN NVO3 Network +----+
| EVPN NVO3 Network +----+ NVE1(IP-A) | BD1|-----+
NVE1(IP-A) | BD1|-----+ +-------------+ RT-2 | | |
+-------------+ RT-2 | | | | | +-------+ +----+ |
| | +-------+ +----+ | | +----+ | |MAC1 | NVE5 TS3
| +----+ | |MAC1 | NVE5 TS3 TS1--------|BD1 | | |IP1 | +----+ |
TS1--------|BD1 | | |IP1 | +----+ | MAC1 | +----+ | |Label L|---> | BD1|-----+
MAC1 | +----+ | |Label L|---> | BD1|-----+ IP1 | | |NH IP-A| | | All-Active
IP1 | | |NH IP-A| | | All-Active | Hypervisor | +-------+ +----+ ESI-2
| Hypervisor | +-------+ +----+ ESI-2 +-------------+ |
+-------------+ | +--------------------------------------+
+--------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>In a simple NVO3 network, such as the example of <xref target="ure-ev
<t>In a simple NVO3 network, such as the example of <xref pn-for-l2-in-an-nvo3-network-example" format="default"/>, these are the
target="ure-evpn-for-l2-in-an-nvo3-network-example"/>, these are the basic constructs that EVPN uses for Layer 2 services (or Layer 2
basic constructs that EVPN uses for Layer-2 services (or Layer-2
Virtual Networks):</t> Virtual Networks):</t>
<ul spacing="normal">
<t><list style="symbols"> <li>BD1 is an EVPN Broadcast Domain for a given tenant and TS1, TS2,
<t>BD1 is an EVPN Broadcast Domain for a given tenant and TS1, TS2
and TS3 are connected to it. The five represented NVEs are and TS3 are connected to it. The five represented NVEs are
attached to BD1 and are connected to the same underlay IP network. attached to BD1 and are connected to the same underlay IP network.
That is, each NVE learns the remote NVEs' loopback addresses via That is, each NVE learns the remote NVEs' loopback addresses via
underlay routing protocol.</t> underlay routing protocol.</li>
<li>NVE1 is deployed as a virtual switch in a hypervisor with IP-A
<t>NVE1 is deployed as a virtual switch in a Hypervisor with IP-A as underlay loopback IP address. The rest of the NVEs in <xref targe
as underlay loopback IP address. The rest of the NVEs in <xref t="ure-evpn-for-l2-in-an-nvo3-network-example" format="default"/> are physical
target="ure-evpn-for-l2-in-an-nvo3-network-example"/> are physical switches and TS2/TS3 are multihomed to them. TS1 is a virtual
switches and TS2/TS3 are multi-homed to them. TS1 is a virtual
machine, identified by MAC1 and IP1. TS2 and TS3 are physically machine, identified by MAC1 and IP1. TS2 and TS3 are physically
dual-connected to NVEs, hence they are normally not considered dual-connected to NVEs; hence, they are normally not considered
virtual machines.</t> virtual machines.</li>
<li>The terms Single-Active and All-Active in <xref target="ure-evpn-f
<t>The terms Single-Active and All-Active in <xref or-l2-in-an-nvo3-network-example" format="default"/> refer to the
target="ure-evpn-for-l2-in-an-nvo3-network-example"/> refer to the mode in which the TS2 and TS3 are multihomed to the NVEs in BD1.
mode in which the TS2 and TS3 are multi-homed to the NVEs in BD1. In All-Active mode, all the multihoming links are active and can
In All-Active mode, all the multi-homing links are active and can
send or receive traffic. In Single-Active mode, only one link (of send or receive traffic. In Single-Active mode, only one link (of
the set of links connected to the NVEs) is active.</t> the set of links connected to the NVEs) is active.</li>
</list></t> </ul>
<section anchor="sect-4.2.1" numbered="true" toc="default">
<section anchor="sect-4.2.1" <name>Auto-Discovery and Auto-Provisioning</name>
title="Auto-Discovery and Auto-Provisioning">
<t>Auto-discovery is one of the basic capabilities of EVPN. The <t>Auto-discovery is one of the basic capabilities of EVPN. The
provisioning of EVPN components in NVEs is significantly automated, provisioning of EVPN components in NVEs is significantly automated,
simplifying the deployment of services and minimizing manual simplifying the deployment of services and minimizing manual
operations that are prone to human error.</t> operations that are prone to human error.</t>
<t>These are some of the auto-discovery and auto-provisioning
<t>These are some of the Auto-Discovery and Auto-Provisioning
capabilities available in EVPN:</t> capabilities available in EVPN:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Automation on Ethernet Segments (ES): an Ethernet Segment is <t>Automation on Ethernet Segments (ESes): An Ethernet Segment is
defined as a group of NVEs that are attached to the same Tenant defined as a group of NVEs that are attached to the same Tenant
System or network. An Ethernet Segment is identified by an System or network. An Ethernet Segment is identified by an
Ethernet Segment Identifier (ESI) in the control plane, but Ethernet Segment Identifier (ESI) in the control plane, but
neither the ESI nor the NVEs that share the same Ethernet neither the ESI nor the NVEs that share the same Ethernet
Segment are required to be manually provisioned in the local Segment are required to be manually provisioned in the local
NVE:<list style="symbols"> NVE.</t>
<t>If the multi-homed Tenant System or network are running <ul spacing="normal">
protocols such as LACP (Link Aggregation Control Protocol)
<xref target="IEEE.802.1AX_2014"/>, MSTP (Multiple-instance <li>If the multihomed Tenant System or network is running
Spanning Tree Protocol), G.8032, etc. and all the NVEs in protocols, such as the Link Aggregation Control Protocol (LACP
)
<xref target="IEEE.802.1AX_2014" format="default"/>, the Multi
ple
Spanning Tree Protocol (MSTP), G.8032, etc., and all the NVEs
in
the Ethernet Segment can listen to the protocol PDUs to the Ethernet Segment can listen to the protocol PDUs to
uniquely identify the multi-homed Tenant System/network, uniquely identify the multihomed Tenant System/network,
then the ESI can be "auto-sensed" or "auto-provisioned" then the ESI can be "auto-sensed" or "auto-provisioned"
following the guidelines in <xref target="RFC7432"/> section following the guidelines in <xref target="RFC7432" sectionForm
5. The ESI can also be auto-derived out of other parameters at="of" section="5"/>.
The ESI can also be auto-derived out of other parameters
that are common to all NVEs attached to the same Ethernet that are common to all NVEs attached to the same Ethernet
Segment.</t> Segment.</li>
<li>As described in <xref target="RFC7432" format="default"/>, E
<t>As described in <xref target="RFC7432"/>, EVPN can also VPN can also
auto-derive the BGP parameters required to advertise the auto-derive the BGP parameters required to advertise the
presence of a local Ethernet Segment in the control plane presence of a local Ethernet Segment in the control plane
(RT and RD). Local Ethernet Segments are advertised using (RT and RD). Local Ethernet Segments are advertised using
Ethernet Segment routes and the ESI-import Route-Target used Ethernet Segment routes, and the ESI-import Route Target used
by Ethernet Segment routes can be auto-derived based on the by Ethernet Segment routes can be auto-derived based on the
procedures of <xref target="RFC7432"/>, section 7.6.</t> procedures of <xref target="RFC7432" sectionFormat="of" sectio
n="7.6"/>.</li>
<t>By listening to other Ethernet Segment routes that match <li>By listening to other Ethernet Segment routes that match
the local ESI and import Route Target, an NVE can also the local ESI and import Route Target, an NVE can also
auto-discover the other NVEs participating in the auto-discover the other NVEs participating in the
multi-homing for the Ethernet Segment.</t> multihoming for the Ethernet Segment.</li>
<li>Once the NVE has auto-discovered all the NVEs attached to
<t>Once the NVE has auto-discovered all the NVEs attached to
the same Ethernet Segment, the NVE can automatically perform the same Ethernet Segment, the NVE can automatically perform
the Designated Forwarder Election algorithm (which the Designated Forwarder election algorithm (which
determines the NVE that will forward traffic to the determines the NVE that will forward traffic to the
multi-homed Tenant System/network). EVPN guarantees that all multihomed Tenant System/network). EVPN guarantees that all
the NVEs in the Ethernet Segment have a consistent the NVEs in the Ethernet Segment have a consistent
Designated Forwarder Election.</t> Designated Forwarder election.</li>
</list></t> </ul>
</li>
<t>Auto-provisioning of services: when deploying a Layer-2 <li>Auto-provisioning of services: When deploying a Layer 2
Service for a tenant in an NVO3 network, all the NVEs attached service for a tenant in an NVO3 network, all the NVEs attached
to the same subnet must be configured with a MAC-VRF and the to the same subnet must be configured with a MAC-VRF and the
Broadcast Domain for the subnet, as well as certain parameters Broadcast Domain for the subnet, as well as certain parameters
for them. Note that, if the EVPN service model is VLAN-based or for them. Note that if the EVPN service interfaces are VLAN-based or
VLAN-bundle, implementations do not normally have a specific VLAN-bundle, implementations do not normally have a specific
provisioning for the Broadcast Domain (since it is in that case provisioning for the Broadcast Domain since, in this case, it is
the same construct as the MAC-VRF). EVPN allows auto-deriving as the same construct as the MAC-VRF. EVPN allows auto-deriving as
many MAC-VRF parameters as possible. As an example, the many MAC-VRF parameters as possible. As an example, the
MAC-VRF's Route Target and Route Distinguisher for the EVPN MAC-VRF's Route Target and Route Distinguisher for the EVPN
routes may be auto-derived. Section 5.1.2.1 in <xref routes may be auto-derived. <xref target="RFC8365" sectionFormat="
target="RFC8365"/> specifies how to auto-derive a MAC-VRF's of" section="5.1.2.1"/> specifies how to auto-derive a MAC-VRF's
Route Target as long as VLAN-based service model is implemented. Route Target as long as a VLAN-based service interface is implemen
<xref target="RFC7432"/> specifies how to auto-derive the Route ted.
Distinguisher.</t> <xref target="RFC7432" format="default"/> specifies how to auto-de
</list></t> rive the Route
Distinguisher.</li>
</ul>
</section> </section>
<section anchor="sect-4.2.2" numbered="true" toc="default">
<section anchor="sect-4.2.2" title="Remote NVE Auto-Discovery"> <name>Remote NVE Auto-Discovery</name>
<t>Auto-discovery via MP-BGP <xref target="RFC4760"/> is used to <t>Auto-discovery via MP-BGP <xref target="RFC4760" format="default"/>
is used to
discover the remote NVEs attached to a given Broadcast Domain, the discover the remote NVEs attached to a given Broadcast Domain, the
NVEs participating in a given redundancy group, the tunnel NVEs participating in a given redundancy group, the tunnel
encapsulation types supported by an NVE, etc.</t> encapsulation types supported by an NVE, etc.</t>
<t>In particular, when a new MAC-VRF and Broadcast Domain are <t>In particular, when a new MAC-VRF and Broadcast Domain are
enabled, the NVE will advertise a new Inclusive Multicast Ethernet enabled, the NVE will advertise a new Inclusive Multicast Ethernet
Tag route. Besides other fields, the Inclusive Multicast Ethernet Tag route. Besides other fields, the Inclusive Multicast Ethernet
Tag route will encode the IP address of the advertising NVE, the Tag route will encode the IP address of the advertising NVE, the
Ethernet Tag (which is zero in case of VLAN-based and VLAN-bundle Ethernet Tag (which is zero in the case of VLAN-based and VLAN-bundle
models) and also a PMSI Tunnel Attribute (PTA) that indicates the interfaces), and a PMSI Tunnel Attribute (PTA) that indicates the
information about the intended way to deliver BUM traffic for the information about the intended way to deliver BUM traffic for the
Broadcast Domain.</t> Broadcast Domain.</t>
<t>When BD1 is enabled in the example of <xref target="ure-evpn-for-l2
<t>In the example of <xref -in-an-nvo3-network-example" format="default"/>, NVE1 will send an Inclusive Mul
target="ure-evpn-for-l2-in-an-nvo3-network-example"/>, when BD1 is ticast Ethernet Tag route
enabled, NVE1 will send an Inclusive Multicast Ethernet Tag route including its own IP address, an Ethernet-Tag for BD1, and the PMSI
including its own IP address, Ethernet-Tag for BD1 and the PMSI
Tunnel Attribute to the remote NVEs. Assuming Ingress Replication Tunnel Attribute to the remote NVEs. Assuming Ingress Replication
(IR) is used, the Inclusive Multicast Ethernet Tag route will (IR) is used, the Inclusive Multicast Ethernet Tag route will
include an identification for Ingress Replication in the PMSI Tunnel include an identification for Ingress Replication in the PMSI Tunnel
Attribute and the Virtual Network Identifier that the other NVEs in Attribute and the VNI that the other NVEs in
the Broadcast Domain must use to send BUM traffic to the advertising the Broadcast Domain must use to send BUM traffic to the advertising
NVE. The other NVEs in the Broadcast Domain will import the NVE. The other NVEs in the Broadcast Domain will import the
Inclusive Multicast Ethernet Tag route and will add NVE1's IP Inclusive Multicast Ethernet Tag route and will add NVE1's IP
address to the flooding list for BD1. Note that the Inclusive address to the flooding list for BD1. Note that the Inclusive
Multicast Ethernet Tag route is also sent with a BGP encapsulation Multicast Ethernet Tag route is also sent with a BGP encapsulation
attribute <xref target="RFC9012"/> that indicates what NVO3 attribute <xref target="RFC9012" format="default"/> that indicates wha t NVO3
encapsulation the remote NVEs should use when sending BUM traffic to encapsulation the remote NVEs should use when sending BUM traffic to
NVE1.</t> NVE1.</t>
<t>Refer to <xref target="RFC7432" format="default"/> for more informa
<t>Refer to <xref target="RFC7432"/> for more information about the tion about the
Inclusive Multicast Ethernet Tag route and forwarding of BUM Inclusive Multicast Ethernet Tag route and forwarding of BUM
traffic, and to <xref target="RFC8365"/> for its considerations on traffic. See <xref target="RFC8365" format="default"/> for its conside rations on
NVO3 networks.</t> NVO3 networks.</t>
</section> </section>
<section anchor="sect-4.2.3" numbered="true" toc="default">
<section anchor="sect-4.2.3" <name>Distribution of Tenant MAC and IP Information</name>
title="Distribution of Tenant MAC and IP Information">
<t>Tenant MAC/IP information is advertised to remote NVEs using <t>Tenant MAC/IP information is advertised to remote NVEs using
MAC/IP Advertisement routes. Following the example of <xref MAC/IP Advertisement routes. Following the example of <xref target="ur
target="ure-evpn-for-l2-in-an-nvo3-network-example"/>:</t> e-evpn-for-l2-in-an-nvo3-network-example" format="default"/>:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>In a given EVPN Broadcast Domain, the MAC addresses of TSes are first learne
<t>In a given EVPN Broadcast Domain, Tenant Systems' MAC d at the NVE they are attached to via
addresses are first learned at the NVE they are attached to, via data path or management plane learning. In <xref target="ure-evpn-
data path or management plane learning. In <xref for-l2-in-an-nvo3-network-example" format="default"/>, we assume
target="ure-evpn-for-l2-in-an-nvo3-network-example"/> we assume
NVE1 learns MAC1/IP1 in the management plane (for instance, via NVE1 learns MAC1/IP1 in the management plane (for instance, via
Cloud Management System) since the NVE is a virtual switch. Cloud Management System) since the NVE is a virtual switch.
NVE2, NVE3, NVE4 and NVE5 are TOR/Leaf switches and they NVE2, NVE3, NVE4, and NVE5 are ToR/Leaf switches, and they
normally learn MAC addresses via data path.</t> normally learn MAC addresses via data path.</li>
<li>Once NVE1's BD1 learns MAC1/IP1, NVE1 advertises that
<t>Once NVE1's BD1 learns MAC1/IP1, NVE1 advertises that information along with a VNI and Next-Hop
information along with a Virtual Network Identifier and Next Hop IP-A in a MAC/IP Advertisement route. The EVPN routes are
IP-A in an MAC/IP Advertisement route. The EVPN routes are advertised using the Route Distinguisher / Route Targets of the
advertised using the Route Distinguisher/Route Targets of the
MAC-VRF where the Broadcast Domain belongs. Similarly, all the MAC-VRF where the Broadcast Domain belongs. Similarly, all the
NVEs in BD1 learn local MAC/IP addresses and advertise them in NVEs in BD1 learn local MAC/IP addresses and advertise them in
MAC/IP Advertisement routes.</t> MAC/IP Advertisement routes.</li>
<li>The remote NVEs can then add MAC1 to their mapping table for
<t>The remote NVEs can then add MAC1 to their mapping table for BD1 (BT). For instance, when TS3 sends frames to NVE4 with the
BD1 (BT). For instance, when TS3 sends frames to NVE4 with
destination MAC address = MAC1, NVE4 does a MAC lookup on the destination MAC address = MAC1, NVE4 does a MAC lookup on the
Bridge Table that yields IP-A and Label L. NVE4 can then Bridge Table that yields IP-A and Label L. NVE4 can then
encapsulate the frame into an NVO3 tunnel with IP-A as the encapsulate the frame into an NVO3 tunnel with IP-A as the
tunnel destination IP address and L as the Virtual Network tunnel destination IP address and L as the VNI.
Identifier. Note that the MAC/IP Advertisement route may also Note that the MAC/IP Advertisement route may also
contain the host's IP address (as in the example of <xref contain the host's IP address (as shown in the example of <xref ta
target="ure-evpn-for-l2-in-an-nvo3-network-example"/>). While rget="ure-evpn-for-l2-in-an-nvo3-network-example" format="default"/>). While
the MAC of the received MAC/IP Advertisement route is installed the MAC of the received MAC/IP Advertisement route is installed
in the Bridge Table, the IP address may be installed in the in the Bridge Table, the IP address may be installed in the
Proxy-ARP/ND table (if enabled) or in the ARP/IP-VRF tables if Proxy ARP/ND table (if enabled) or in the ARP/IP-VRF tables if
the Broadcast Domain has an IRB. See <xref target="sect-4.7.3"/> the Broadcast Domain has an IRB. See <xref target="sect-4.7.3" for
to see more information about Proxy-ARP/ND and <xref mat="default"/>
target="sect-4.3"/>. for more details about IRB and Layer-3 for more information about Proxy ARP/ND and <xref target="sect-4.3
services.</t> " format="default"/> for more details about IRB and Layer 3
</list></t> services.</li>
</ul>
<t>Refer to <xref target="RFC7432"/> and <xref target="RFC8365"/> <t>Refer to <xref target="RFC7432" format="default"/> and <xref target
="RFC8365" format="default"/>
for more information about the MAC/IP Advertisement route and for more information about the MAC/IP Advertisement route and
forwarding of known unicast traffic.</t> the forwarding of known unicast traffic.</t>
</section> </section>
</section> </section>
<section anchor="sect-4.3" numbered="true" toc="default">
<section anchor="sect-4.3" <name>EVPN Basic Applicability for Layer 3 Services</name>
title="EVPN Basic Applicability for Layer-3 Services"> <t><xref target="RFC9136" format="default"/> and <xref target="RFC9135"
<t><xref target="RFC9136"/> and <xref target="RFC9135"/> are the format="default"/> are the
reference documents that describe how EVPN can be used for Layer-3 reference documents that describe how EVPN can be used for Layer 3
services. Inter Subnet Forwarding in EVPN networks is implemented via services. Inter-subnet forwarding in EVPN networks is implemented via
IRB interfaces between Broadcast Domains and IP-VRFs. An EVPN IRB interfaces between Broadcast Domains and IP-VRFs. An EVPN
Broadcast Domain corresponds to an IP subnet. When IP packets Broadcast Domain corresponds to an IP subnet. When IP packets
generated in a Broadcast Domain are destined to a different subnet generated in a Broadcast Domain are destined to a different subnet
(different Broadcast Domain) of the same tenant, the packets are sent (different Broadcast Domain) of the same tenant, the packets are sent
to the IRB attached to the local Broadcast Domain in the source NVE. to the IRB attached to the local Broadcast Domain in the source NVE.
As discussed in <xref target="RFC9135"/>, depending on how the IP As discussed in <xref target="RFC9135" format="default"/>, depending on how the IP
packets are forwarded between the ingress NVE and the egress NVE, packets are forwarded between the ingress NVE and the egress NVE,
there are two forwarding models: Asymmetric and Symmetric model.</t> there are two forwarding models: Asymmetric and Symmetric.</t>
<t>The Asymmetric model is illustrated in the example of <xref target="u
<t>The Asymmetric model is illustrated in the example of <xref re-evpn-for-l3-in-an-nvo3-network-asymmetric-model" format="default"/>, and it
target="ure-evpn-for-l3-in-an-nvo3-network-asymmetric-model"/> and it
requires the configuration of all the Broadcast Domains of the tenant requires the configuration of all the Broadcast Domains of the tenant
in all the NVEs attached to the same tenant. In that way, there is no in all the NVEs attached to the same tenant. That way, there is no
need to advertise IP Prefixes between NVEs since all the NVEs are need to advertise IP Prefixes between NVEs since all the NVEs are
attached to all the subnets. It is called Asymmetric because the attached to all the subnets. It is called "Asymmetric" because the
ingress and egress NVEs do not perform the same number of lookups in ingress and egress NVEs do not perform the same number of lookups in
the data plane. In <xref the data plane.
target="ure-evpn-for-l3-in-an-nvo3-network-asymmetric-model"/>, if TS1 In <xref target="ure-evpn-for-l3-in-an-nvo3-network-asymmetric-model" format="de
and TS2 are in different subnets, and TS1 sends IP packets to TS2, the fault"/>, if TS1
following lookups are required in the data path: a MAC lookup (on and TS2 are in different subnets and TS1 sends IP packets to TS2, the
BD1's table), an IP lookup (on the IP-VRF) and a MAC lookup (on BD2's following lookups are required in the data path: a MAC lookup at
table) at the ingress NVE1 and then only a MAC lookup at the egress BD1's table, an IP lookup at the IP-VRF, a MAC lookup at BD2's
NVE. The two IP-VRFs in <xref table at the ingress NVE1, and only a MAC lookup at the egress
target="ure-evpn-for-l3-in-an-nvo3-network-asymmetric-model"/> are not NVE. The two IP-VRFs in <xref target="ure-evpn-for-l3-in-an-nvo3-network
connected by tunnels and all the connectivity between the NVEs is done -asymmetric-model" format="default"/> are not
connected by tunnels, and all the connectivity between the NVEs is done
based on tunnels between the Broadcast Domains.</t> based on tunnels between the Broadcast Domains.</t>
<figure anchor="ure-evpn-for-l3-in-an-nvo3-network-asymmetric-model">
<figure anchor="ure-evpn-for-l3-in-an-nvo3-network-asymmetric-model" <name>EVPN for L3 in an NVO3 Network - Asymmetric Model</name>
title="EVPN for L3 in an NVO3 Network - Asymmetric model"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ +-------------------------------------+
+-------------------------------------+ | EVPN NVO3 |
| EVPN NVO3 | | |
| | NVE1 NVE2
NVE1 NVE2 +--------------------+ +--------------------+
+--------------------+ +--------------------+ | +---+IRB +------+ | | +------+IRB +---+ |
| +---+IRB +------+ | | +------+IRB +---+ | TS1-----|BD1|----|IP-VRF| | | |IP-VRF|----|BD1| |
TS1-----|BD1|----|IP-VRF| | | |IP-VRF|----|BD1| | | +---+ | | | | | | +---+ |
| +---+ | | | | | | +---+ | | +---+ | | | | | | +---+ |
| +---+ | | | | | | +---+ | | |BD2|----| | | | | |----|BD2|----TS2
| |BD2|----| | | | | |----|BD2|----TS2 | +---+IRB +------+ | | +------+IRB +---+ |
| +---+IRB +------+ | | +------+IRB +---+ | +--------------------+ +--------------------+
+--------------------+ +--------------------+ | |
| | +-------------------------------------+
+-------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>In the Symmetric model, depicted in <xref target="ure-evpn-for-l3-in-
<t>In the Symmetric model, depicted in <xref an-nvo3-network-symmetric-model" format="default"/>, the
target="ure-evpn-for-l3-in-an-nvo3-network-symmetric-model"/>, the
same number of data path lookups is needed at the ingress and egress same number of data path lookups is needed at the ingress and egress
NVEs. For example, if TS1 sends IP packets to TS3, the following data NVEs. For example, if TS1 sends IP packets to TS3, the following data
path lookups are required: a MAC lookup at NVE1's BD1 table, an IP path lookups are required: a MAC lookup at NVE1's BD1 table, an IP
lookup at NVE1's IP-VRF and then IP lookup and MAC lookup at NVE2's lookup at NVE1's IP-VRF, and an IP lookup and MAC lookup at NVE2's
IP-VRF and BD3 respectively. In the Symmetric model, the Inter Subnet IP-VRF and BD3, respectively. In the Symmetric model, the inter-subnet
connectivity between NVEs is done based on tunnels between the connectivity between NVEs is done based on tunnels between the
IP-VRFs.</t> IP-VRFs.</t>
<figure anchor="ure-evpn-for-l3-in-an-nvo3-network-symmetric-model">
<figure anchor="ure-evpn-for-l3-in-an-nvo3-network-symmetric-model" <name>EVPN for L3 in an NVO3 Network - Symmetric Model</name>
title="EVPN for L3 in an NVO3 Network - Symmetric model"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ +-------------------------------------+
+-------------------------------------+ | EVPN NVO3 |
| EVPN NVO3 | | |
| | NVE1 NVE2
NVE1 NVE2 +--------------------+ +--------------------+
+--------------------+ +--------------------+ | +---+IRB +------+ | | +------+IRB +---+ |
| +---+IRB +------+ | | +------+IRB +---+ | TS1-----|BD1|----|IP-VRF| | | |IP-VRF|----|BD3|-----TS3
TS1-----|BD1|----|IP-VRF| | | |IP-VRF|----|BD3|-----TS3 | +---+ | | | | | | +---+ |
| +---+ | | | | | | +---+ | | +---+IRB | | | | +------+ |
| +---+IRB | | | | +------+ | TS2-----|BD2|----| | | +--------------------+
TS2-----|BD2|----| | | +--------------------+ | +---+ +------+ | |
| +---+ +------+ | | +--------------------+ |
+--------------------+ | | |
| | +-------------------------------------+
+-------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The Symmetric model scales better than the Asymmetric model because <t>The Symmetric model scales better than the Asymmetric model because
it does not require the NVEs to be attached to all the tenant's it does not require the NVEs to be attached to all the tenant's
subnets. However, it requires the use of NVO3 tunnels on the IP-VRFs subnets. However, it requires the use of NVO3 tunnels on the IP-VRFs
and the exchange of IP Prefixes between the NVEs in the control plane. and the exchange of IP Prefixes between the NVEs in the control plane.
EVPN uses MAC/IP Advertisement routes for the exchange of host IP EVPN uses MAC/IP Advertisement routes for the exchange of host IP
routes and IP Prefixes routes for the exchange of prefixes of any routes and IP Prefix routes for the exchange of prefixes of any
length (including host routes too). As an example, in <xref length, including host routes. As an example, in <xref target="ure-evpn-
target="ure-evpn-for-l3-in-an-nvo3-network-symmetric-model"/>, NVE2 for-l3-in-an-nvo3-network-symmetric-model" format="default"/>, NVE2
needs to advertise TS3's host route and/or TS3's subnet, so that the needs to advertise TS3's host route and/or TS3's subnet so that the
IP lookup on NVE1's IP-VRF succeeds.</t> IP lookup on NVE1's IP-VRF succeeds.</t>
<t><xref target="RFC9135" format="default"/> specifies the use of MAC/IP
<t><xref target="RFC9135"/> specifies the use of MAC/IP Advertisement Advertisement
routes for the advertisement of host routes. Section 4.4.1 in <xref routes for the advertisement of host routes. <xref target="RFC9136" sect
target="RFC9136"/> specifies the use of IP Prefix routes for the ionFormat="of" section="4.4.1"/> specifies the use of IP Prefix routes for the
advertisement of IP Prefixes in an "Interface-less IP-VRF-to-IP-VRF advertisement of IP Prefixes in an "Interface-less IP-VRF-to-IP-VRF
Model". The Symmetric model for host routes can be implemented Model". The Symmetric model for host routes can be implemented
following either approach:</t> following either approach:</t>
<ol spacing="normal" type="a"><li>
<t><list style="letters"> <xref target="RFC9135" format="default"/> uses MAC/IP Advertisement
<t><xref target="RFC9135"/> uses MAC/IP Advertisement routes to routes to
convey the information to populate Layer-2, ARP/ND and Layer-3 convey the information to populate Layer 2, ARP/ND, and Layer 3
Forwarding Information Base tables in the remote NVE. For Forwarding Information Base tables in the remote NVE. For
instance, in <xref instance, in <xref target="ure-evpn-for-l3-in-an-nvo3-network-symmet
target="ure-evpn-for-l3-in-an-nvo3-network-symmetric-model"/>, ric-model" format="default"/>,
NVE2 would advertise a MAC/IP Advertisement route with TS3's IP NVE2 would advertise a MAC/IP Advertisement route with TS3's IP
and MAC addresses, and including two labels/Virtual Network and MAC addresses and include two labels / VNIs: a label-3/VNI-3 tha
Identifiers: a label-3/VNI-3 that identifies BD3 for MAC lookup t identifies BD3 for MAC lookup
(that would be used for Layer-2 traffic in case NVE1 was attached (that would be used for Layer 2 traffic in case NVE1 was attached
to BD3 too) and a label-1/VNI-1 that identifies the IP-VRF for IP to BD3 too) and a label-1/VNI-1 that identifies the IP-VRF for IP
lookup (and will be used for Layer-3 traffic). NVE1 imports the lookup (that would be used for Layer 3 traffic). NVE1 imports the
MAC/IP Advertisement route and installs TS3's IP in the IP-VRF MAC/IP Advertisement route and installs TS3's IP in the IP-VRF
route table with label-1/VNI-1. Traffic from e.g., TS2 to TS3, route table with label-1/VNI-1. Traffic, e.g., from TS2 to TS3,
will be encapsulated with label-1/VNI-1 and forwarded to NVE2.</t> would be encapsulated with label-1/VNI-1 and forwarded to NVE2.</li>
<li>
<t><xref target="RFC9136"/> uses MAC/IP Advertisement routes to <xref target="RFC9136" format="default"/> uses MAC/IP Advertisement
convey the information to populate the Layer-2 Forwarding routes to
Information Base and ARP/ND tables, and IP Prefix routes to convey the information to populate the Layer 2 Forwarding
populate the IP-VRF Layer-3 Forwarding Information Base table. For Information Base, ARP/ND tables, and IP Prefix routes to
instance, in <xref populate the IP-VRF Layer 3 Forwarding Information Base table. For
target="ure-evpn-for-l3-in-an-nvo3-network-symmetric-model"/>, instance, in <xref target="ure-evpn-for-l3-in-an-nvo3-network-symmet
ric-model" format="default"/>,
NVE2 would advertise a MAC/IP Advertisement route including TS3's NVE2 would advertise a MAC/IP Advertisement route including TS3's
MAC and IP addresses with a single label-3/VNI-3. In this example, MAC and IP addresses with a single label-3/VNI-3. In this example,
this MAC/IP Advertisement route wouldn't be imported by NVE1 this MAC/IP Advertisement route wouldn't be imported by NVE1
because NVE1 is not attached to BD3. In addition, NVE2 would because NVE1 is not attached to BD3. In addition, NVE2 would
advertise an IP Prefix route with TS3's IP address and advertise an IP Prefix route with TS3's IP address and
label-1/VNI-1. This IP Prefix route would be imported by NVE1's label-1/VNI-1. This IP Prefix route would be imported by NVE1's
IP-VRF and the host route installed in the Layer-3 Forwarding IP-VRF and the host route installed in the Layer 3 Forwarding
Information Base associated to label-1/VNI-1. Traffic from TS2 to Information Base associated with label-1/VNI-1. Traffic from TS2 to
TS3 would be encapsulated with label-1/VNI-1.</t> TS3 would be encapsulated with label-1/VNI-1.</li>
</list></t> </ol>
</section> </section>
<section anchor="sect-4.4" numbered="true" toc="default">
<section anchor="sect-4.4" <name>EVPN as Control Plane for NVO3 Encapsulations and Geneve</name>
title="EVPN as Control Plane for NVO3 Encapsulations and GENEVE"> <t><xref target="RFC8365" format="default"/> describes how to use EVPN f
<t><xref target="RFC8365"/> describes how to use EVPN for NVO3 or NVO3
encapsulations, such us VXLAN, nvGRE or MPLSoGRE. The procedures can encapsulations, such us VXLAN, nvGRE, or MPLSoGRE. The procedures can
be easily applicable to any other NVO3 encapsulation, in particular be easily applicable to any other NVO3 encapsulation, particularly Genev
GENEVE.</t> e.</t>
<t>Geneve <xref target="RFC8926" format="default"/> is the proposed stan
<t>The Generic Network Virtualization Encapsulation <xref dard encapsulation specified in
target="RFC8926"/> is the proposed standard encapsulation specified in
the IETF Network Virtualization Overlays Working Group. The EVPN the IETF Network Virtualization Overlays Working Group. The EVPN
control plane can signal the GENEVE encapsulation type in the BGP control plane can signal the Geneve encapsulation type in the BGP
Tunnel Encapsulation Extended Community (see <xref Tunnel Encapsulation Extended Community (see <xref target="RFC9012" form
target="RFC9012"/>).</t> at="default"/>).</t>
<t>Geneve requires a control plane <xref target="I-D.ietf-nvo3-encap" fo
<t>GENEVE requires a control plane <xref rmat="default"/> to:</t>
target="I-D.ietf-nvo3-encap"/> to:</t> <ul spacing="normal"><li>Negotiate a subset of Geneve option TLVs that c
an be carried on
<t><list style="numbers"> a Geneve tunnel,</li>
<t>Negotiate a subset of GENEVE option TLVs that can be carried on <li>Enforce an order for Geneve option TLVs, and</li>
a GENEVE tunnel</t> <li>Limit the total number of options that could be carried on a
Geneve tunnel.</li>
<t>Enforce an order for GENEVE option TLVs and</t> </ul>
<t>Limit the total number of options that could be carried on a
GENEVE tunnel.</t>
</list></t>
<t>The EVPN control plane can easily extend the BGP Tunnel <t>The EVPN control plane can easily extend the BGP Tunnel
Encapsulation Attribute sub-TLV <xref target="RFC9012"/> to specify Encapsulation attribute sub-TLV <xref target="RFC9012" format="default"/
the GENEVE tunnel options that can be received or transmitted over a > to specify
GENEVE tunnels by a given NVE. <xref the Geneve tunnel options that can be received or transmitted over a
target="I-D.ietf-bess-evpn-geneve"/> describes the EVPN control plane Geneve tunnel by a given NVE. <xref target="I-D.ietf-bess-evpn-geneve" f
extensions to support GENEVE.</t> ormat="default"/> describes the EVPN control plane
extensions to support Geneve.</t>
</section> </section>
<section anchor="sect-4.5" numbered="true" toc="default">
<section anchor="sect-4.5" title="EVPN OAM and Application to NVO3"> <name>EVPN OAM and Application to NVO3</name>
<t>EVPN OAM (as in <xref target="I-D.ietf-bess-evpn-lsp-ping"/>) <t>EVPN Operations, Administration, and Maintenance (OAM), as described
in <xref target="I-D.ietf-bess-evpn-lsp-ping" format="default"/>,
defines mechanisms to detect data plane failures in an EVPN deployment defines mechanisms to detect data plane failures in an EVPN deployment
over an MPLS network. These mechanisms detect failures related to P2P over an MPLS network. These mechanisms detect failures related to point-
and P2MP connectivity, for multi-tenant unicast and multicast Layer-2 to-point (P2P)
and Point-to-Multipoint (P2MP) connectivity, for multi-tenant unicast an
d multicast Layer 2
traffic, between multi-tenant access nodes connected to EVPN PE(s), traffic, between multi-tenant access nodes connected to EVPN PE(s),
and in a single-homed, single-active or all-active redundancy and in a single-homed, Single-Active, or All-Active redundancy
model.</t> model.</t>
<t>In general, EVPN OAM mechanisms defined for EVPN deployed in MPLS <t>In general, EVPN OAM mechanisms defined for EVPN deployed in MPLS
networks are equally applicable for EVPN in NVO3 networks.</t> networks are equally applicable for EVPN in NVO3 networks.</t>
</section> </section>
<section anchor="sect-4.6" numbered="true" toc="default">
<section anchor="sect-4.6" <name>EVPN as the Control Plane for NVO3 Security</name>
title="EVPN as the Control Plane for NVO3 Security">
<t>EVPN can be used to signal the security protection capabilities of <t>EVPN can be used to signal the security protection capabilities of
a sender NVE, as well as what portion of an NVO3 packet (taking a a sender NVE, as well as what portion of an NVO3 packet (taking a
GENEVE packet as an example) can be protected by the sender NVE, to Geneve packet as an example) can be protected by the sender NVE, to
ensure the privacy and integrity of tenant traffic carried over the ensure the privacy and integrity of tenant traffic carried over the
NVO3 tunnels <xref target="I-D.sajassi-bess-secure-evpn"/>.</t> NVO3 tunnels <xref target="I-D.ietf-bess-secure-evpn" format="default"/> .</t>
</section> </section>
<section anchor="sect-4.7" numbered="true" toc="default">
<section anchor="sect-4.7" <name>Advanced EVPN Features for NVO3 Networks</name>
title="Advanced EVPN Features for NVO3 Networks">
<t>This section describes how EVPN can be used to deliver advanced <t>This section describes how EVPN can be used to deliver advanced
capabilities in NVO3 networks.</t> capabilities in NVO3 networks.</t>
<section anchor="sect-4.7.1" numbered="true" toc="default">
<section anchor="sect-4.7.1" title="Virtual Machine (VM) Mobility"> <name>Virtual Machine (VM) Mobility</name>
<t><xref target="RFC7432"/> replaces the classic Ethernet <t><xref target="RFC7432" format="default"/> replaces the classic Ethe
Flood-and-Learn behavior among NVEs with BGP-based MAC learning, rnet
which in return provides more control over the location of MAC "flood and learn" behavior among NVEs with BGP-based MAC learning.
In return, this provides more control over the location of MAC
addresses in the Broadcast Domain and consequently advanced addresses in the Broadcast Domain and consequently advanced
features, such as MAC Mobility. If we assume that VM Mobility means features, such as MAC Mobility. If we assume that Virtual Machine (VM) Mobility means
the VM's MAC and IP addresses move with the VM, EVPN's MAC Mobility the VM's MAC and IP addresses move with the VM, EVPN's MAC Mobility
is the required procedure that facilitates VM Mobility. According to is the required procedure that facilitates VM Mobility. According to
<xref target="RFC7432"/> section 15, when a MAC is advertised for <xref target="RFC7432" sectionFormat="of" section="15"/>, when a MAC i s advertised for
the first time in a Broadcast Domain, all the NVEs attached to the the first time in a Broadcast Domain, all the NVEs attached to the
Broadcast Domain will store Sequence Number zero for that MAC. When Broadcast Domain will store Sequence Number zero for that MAC. When
the MAC "moves" within the same Broadcast Domain but to a remote the MAC "moves" to a remote NVE within the same Broadcast Domain,
NVE, the NVE that just learned locally the MAC, increases the the NVE that just learned the MAC locally increases the
Sequence Number in the MAC/IP Advertisement route's MAC Mobility Sequence Number in the MAC/IP Advertisement route's MAC Mobility
extended community to indicate that it owns the MAC now. That makes extended community to indicate that it owns the MAC now. That makes
all the NVE in the Broadcast Domain change their tables immediately all the NVEs in the Broadcast Domain change their tables immediately
with no need to wait for any aging timer. EVPN guarantees a fast MAC with no need to wait for any aging timer. EVPN guarantees a fast MAC
Mobility without flooding or black-holes in the Broadcast Mobility without flooding or packet drops in the Broadcast
Domain.</t> Domain.</t>
</section> </section>
<section anchor="sect-4.7.2" numbered="true" toc="default">
<section anchor="sect-4.7.2" <name>MAC Protection, Duplication Detection, and Loop Protection</name
title="MAC Protection, Duplication Detection and Loop Protectio >
n"> <t>The advertisement of MACs in the control plane allows advanced
<t>The advertisement of MACs in the control plane, allows advanced features such as MAC Protection, Duplication Detection, and Loop
features such as MAC protection, Duplication Detection and Loop
Protection.</t> Protection.</t>
<t>In a MAC/IP Advertisement route, MAC Protection refers to EVPN's ab
<t><xref target="RFC7432"/> MAC Protection refers to EVPN's ability ility
to indicate - in a MAC/IP Advertisement route - that a MAC must be to indicate that a MAC must be
protected by the NVE receiving the route. The Protection is protected by the NVE receiving the route <xref target="RFC7432" format
="default"/>. The Protection is
indicated in the "Sticky bit" of the MAC Mobility extended community indicated in the "Sticky bit" of the MAC Mobility extended community
sent along the MAC/IP Advertisement route for a MAC. NVEs' sent along the MAC/IP Advertisement route for a MAC. NVEs'
Attachment Circuits that are connected to subject-to-be-protected Attachment Circuits that are connected to subject-to-be-protected
servers or VMs, may set the Sticky bit on the MAC/IP Advertisement servers or VMs may set the Sticky bit on the MAC/IP Advertisement
routes sent for the MACs associated to the Attachment Circuits. routes sent for the MACs associated with the Attachment Circuits.
Also, statically configured MAC addresses should be advertised as Also, statically configured MAC addresses should be advertised as
Protected MAC addresses, since they are not subject to MAC Mobility Protected MAC addresses since they are not subject to MAC Mobility
procedures.</t> procedures.</t>
<t>MAC Duplication Detection refers to
<t><xref target="RFC7432"/> MAC Duplication Detection refers to EVPN's ability to detect duplicate MAC addresses <xref target="RFC7432
EVPN's ability to detect duplicate MAC addresses. A "MAC move" is a " format="default"/>. A "MAC move" is a
relearn event that happens at an access Attachment Circuit or relearn event that happens at an access Attachment Circuit or
through a MAC/IP Advertisement route with a Sequence Number that is through a MAC/IP Advertisement route with a Sequence Number that is
higher than the stored one for the MAC. When a MAC moves a number of higher than the stored one for the MAC.
times N within an M-second window between two NVEs, the MAC is When a MAC moves a number of
declared as Duplicate and the detecting NVE does not re-advertise times (N) within an M-second window between two NVEs, the MAC is
declared as a duplicate and the detecting NVE does not re-advertise
the MAC anymore.</t> the MAC anymore.</t>
<t><xref target="RFC7432" format="default"/> provides MAC Duplication
<t><xref target="RFC7432"/> provides MAC Duplication Detection, and Detection, and
with an extension it can protect the Broadcast Domain against loops with an extension, it can protect the Broadcast Domain against loops
created by backdoor links between NVEs. The same principle (based on created by backdoor links between NVEs. The same principle (based on
the Sequence Number) may be extended to protect the Broadcast Domain the Sequence Number) may be extended to protect the Broadcast Domain
against loops. When a MAC is detected as duplicate, the NVE may against loops.
When a MAC is detected as a duplicate, the NVE may
install it as a drop-MAC and discard received frames with source MAC install it as a drop-MAC and discard received frames with source MAC
address or destination MAC address matching that duplicate MAC. The address or the destination MAC address matching that duplicate MAC. Th e
MAC Duplication extension to support Loop Protection is described in MAC Duplication extension to support Loop Protection is described in
<xref target="I-D.ietf-bess-rfc7432bis"/>, section 15.3.</t> <xref target="I-D.ietf-bess-rfc7432bis" sectionFormat="of" section="15 .3"/>.</t>
</section> </section>
<section anchor="sect-4.7.3" numbered="true" toc="default">
<section anchor="sect-4.7.3" <name>Reduction/Optimization of BUM Traffic in Layer 2 Services</name>
title="Reduction/Optimization of BUM Traffic in Layer-2 Service
s">
<t>In Broadcast Domains with a significant amount of flooding due to <t>In Broadcast Domains with a significant amount of flooding due to
Unknown unicast and Broadcast frames, EVPN may help reduce and Unknown Unicast and broadcast frames, EVPN may help reduce and
sometimes even suppress the flooding.</t> sometimes even suppress the flooding.</t>
<t>In Broadcast Domains where most of the broadcast traffic is
<t>In Broadcast Domains where most of the Broadcast traffic is caused by the Address Resolution Protocol (ARP) and the Neighbor
caused by ARP (Address Resolution Protocol) and ND (Neighbor Discovery Protocol (NDP) on the Tenant Systems, EVPN's Proxy ARP and
Discovery) protocols on the Tenant Systems, EVPN's Proxy-ARP and Proxy ND capabilities may reduce the flooding drastically. The use
Proxy-ND capabilities may reduce the flooding drastically. The use of Proxy ARP/ND is specified in <xref target="RFC9161" format="default
of Proxy-ARP/ND is specified in <xref target="RFC9161"/>.</t> "/>.</t>
<t>Proxy ARP/ND procedures, along with the assumption that Tenant
<t>Proxy-ARP/ND procedures along with the assumption that Tenant Systems always issue a Gratuitous ARP (GARP) or an unsolicited
Systems always issue a GARP (Gratuitous ARP) or an unsolicited
Neighbor Advertisement message when they come up in the Broadcast Neighbor Advertisement message when they come up in the Broadcast
Domain, may drastically reduce the unknown unicast flooding in the Domain, may drastically reduce the Unknown Unicast flooding in the
Broadcast Domain.</t> Broadcast Domain.</t>
<t>The flooding caused by Tenant Systems' IGMP / Multicast Listener Di
<t>The flooding caused by Tenant Systems' IGMP/MLD or PIM messages scovery (MLD) or PIM messages
in the Broadcast Domain may also be suppressed by the use of in the Broadcast Domain may also be suppressed by the use of
IGMP/MLD and PIM Proxy functions, as specified in <xref IGMP/MLD and PIM Proxy functions, as specified in <xref target="RFC925
target="RFC9251"/> and <xref target="I-D.skr-bess-evpn-pim-proxy"/>. 1" format="default"/> and <xref target="I-D.skr-bess-evpn-pim-proxy" format="def
ault"/>.
These two documents also specify how to forward IP multicast traffic These two documents also specify how to forward IP multicast traffic
efficiently within the same Broadcast Domain, translate soft state efficiently within the same Broadcast Domain, translate soft state
IGMP/MLD/PIM messages into hard state BGP routes and provide IGMP/MLD/PIM messages into hard state BGP routes, and provide
fast-convergence redundancy for IP Multicast on multi-homed Ethernet fast convergence redundancy for IP multicast on multihomed ESes.</t>
Segments (ESes).</t>
</section> </section>
<section anchor="sect-4.7.4" numbered="true" toc="default">
<section anchor="sect-4.7.4" <name>Ingress Replication (IR) Optimization for BUM Traffic</name>
title="Ingress Replication (IR) Optimization for BUM Traffic">
<t>When an NVE attached to a given Broadcast Domain needs to send <t>When an NVE attached to a given Broadcast Domain needs to send
BUM traffic for the Broadcast Domain to the remote NVEs attached to BUM traffic for the Broadcast Domain to the remote NVEs attached to
the same Broadcast Domain, Ingress Replication is a very common the same Broadcast Domain, Ingress Replication is a very common
option in NVO3 networks, since it is completely independent of the option in NVO3 networks since it is completely independent of the
multicast capabilities of the underlay network. Also, if the multicast capabilities of the underlay network. Also, if the
optimization procedures to reduce/suppress the flooding in the optimization procedures to reduce/suppress the flooding in the
Broadcast Domain are enabled (<xref target="sect-4.7.3"/>), in spite Broadcast Domain are enabled (<xref target="sect-4.7.3" format="defaul t"/>) in spite
of creating multiple copies of the same frame at the ingress NVE, of creating multiple copies of the same frame at the ingress NVE,
Ingress Replication may be good enough. However, in Broadcast Ingress Replication may be good enough. However, in Broadcast
Domains where Multicast (or Broadcast) traffic is significant, Domains where Multicast (or Broadcast) traffic is significant,
Ingress Replication may be very inefficient and cause performance Ingress Replication may be very inefficient and cause performance
issues on virtual-switch-based NVEs.</t> issues on virtual switch-based NVEs.</t>
<t><xref target="I-D.ietf-bess-evpn-optimized-ir" format="default"/> s
<t><xref target="I-D.ietf-bess-evpn-optimized-ir"/> specifies the pecifies the
use of AR (Assisted Replication) NVO3 tunnels in EVPN Broadcast use of Assisted Replication (AR) NVO3 tunnels in EVPN Broadcast
Domains. AR retains the independence of the underlay network while Domains. AR retains the independence of the underlay network while
providing a way to forward Broadcast and Multicast traffic providing a way to forward Broadcast and multicast traffic
efficiently. AR uses AR-REPLICATORs that can replicate the efficiently. AR uses AR-REPLICATORs that can replicate the
Broadcast/Multicast traffic on behalf of the AR-LEAF NVEs. The broadcast/multicast traffic on behalf of the AR-LEAF NVEs. The
AR-LEAF NVEs are typically virtual-switches or NVEs with limited AR-LEAF NVEs are typically virtual switches or NVEs with limited
replication capabilities. AR can work in a single-stage replication replication capabilities. AR can work in a single-stage replication
mode (Non-Selective Mode) or in a dual-stage replication mode mode (Non-Selective Mode) or in a dual-stage replication mode
(Selective Mode). Both modes are detailed in <xref (Selective Mode). Both modes are detailed in <xref target="I-D.ietf-be
target="I-D.ietf-bess-evpn-optimized-ir"/>.</t> ss-evpn-optimized-ir" format="default"/>.</t>
<t>In addition, <xref target="I-D.ietf-bess-evpn-optimized-ir"/> <t>In addition, <xref target="I-D.ietf-bess-evpn-optimized-ir" format=
also describes a procedure to avoid sending Broadcast, Multicast or "default"/>
Unknown unicast to certain NVEs that do not need that type of describes a procedure to avoid sending BUM to certain NVEs that do not
traffic. This is done by enabling PFL (Pruned Flood Lists) on a need that type of
given Broadcast Domain. For instance, a virtual-switch NVE that traffic. This is done by enabling Pruned Flood Lists (PFLs) on a
learns all its local MAC addresses for a Broadcast Domain via Cloud given Broadcast Domain. For instance, a virtual switch NVE that
Management System, does not need to receive the Broadcast Domain's learns all its local MAC addresses for a Broadcast Domain via a Cloud
Unknown unicast traffic. Pruned Flood Lists help optimize the BUM Management System does not need to receive the Broadcast Domain's
Unknown Unicast traffic. PFLs help optimize the BUM
flooding in the Broadcast Domain.</t> flooding in the Broadcast Domain.</t>
</section> </section>
<section anchor="sect-4.7.5" numbered="true" toc="default">
<section anchor="sect-4.7.5" title="EVPN Multi-Homing"> <name>EVPN Multihoming</name>
<t>Another fundamental concept in EVPN is multi-homing. A given <t>Another fundamental concept in EVPN is multihoming. A given
Tenant System can be multi-homed to two or more NVEs for a given Tenant System can be multihomed to two or more NVEs for a given
Broadcast Domain, and the set of links connected to the same Tenant Broadcast Domain, and the set of links connected to the same Tenant
System is defined as Ethernet Segment (ES). EVPN supports System is defined as an ES. EVPN supports
single-active and all-active multi-homing. In single-active Single-Active and All-Active multihoming. In Single-Active
multi-homing only one link in the Ethernet Segment is active. In multihoming, only one link in the Ethernet Segment is active. In
all-active multi-homing all the links in the Ethernet Segment are All-Active multihoming, all the links in the Ethernet Segment are
active for unicast traffic. Both modes support load-balancing:</t> active for unicast traffic. Both modes support load-balancing:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Single-Active multihoming means per-service load-balancing
<t>Single-active multi-homing means per-service load-balancing to/from the Tenant System. For example, in <xref target="ure-evpn-
to/from the Tenant System. For example, in <xref for-l2-in-an-nvo3-network-example" format="default"/> for BD1,
target="ure-evpn-for-l2-in-an-nvo3-network-example"/>, for BD1,
only one of the NVEs can forward traffic from/to TS2. For a only one of the NVEs can forward traffic from/to TS2. For a
different Broadcast Domain, the other NVE may forward different Broadcast Domain, the other NVE may forward
traffic.</t> traffic.</li>
<li>All-active multihoming means per-flow load-balancing for
<t>All-active multi-homing means per-flow load-balanding for unicast frames to/from the Tenant System. That is, in <xref target
unicast frames to/from the Tenant System. That is, in <xref ="ure-evpn-for-l2-in-an-nvo3-network-example" format="default"/> and for
target="ure-evpn-for-l2-in-an-nvo3-network-example"/> and for
BD1, both NVE4 and NVE5 can forward known unicast traffic BD1, both NVE4 and NVE5 can forward known unicast traffic
to/from TS3. For BUM traffic only one of the two NVEs can to/from TS3. For BUM traffic, only one of the two NVEs can
forward traffic to TS3, and both can forward traffic from forward traffic to TS3, and both can forward traffic from
TS3.</t> TS3.</li>
</list>There are two key aspects in the EVPN multi-homing </ul>
<t>There are two key aspects in the EVPN multihoming
procedures:</t> procedures:</t>
<dl spacing="normal" newline="true">
<t><list style="symbols"> <dt>Designated Forwarder (DF) election:</dt><dd>The Designated Forwa
<t>DF (Designated Forwarder) election: the Designated Forwarder rder
is the NVE that forwards the traffic to the Ethernet Segment in is the NVE that forwards the traffic to the Ethernet Segment in
single-active mode. In case of all-active, the Designated Single-Active mode.
In the case of All-Active mode, the Designated
Forwarder is the NVE that forwards the BUM traffic to the Forwarder is the NVE that forwards the BUM traffic to the
Ethernet Segment.</t> Ethernet Segment.</dd>
<dt>Split-horizon function:</dt><dd>Prevents the Tenant System from
<t>Split-horizon function: prevents the Tenant System from
receiving echoed BUM frames that the Tenant System itself sent receiving echoed BUM frames that the Tenant System itself sent
to the Ethernet Segment. This is especially relevant in to the Ethernet Segment. This is especially relevant in
all-active Ethernet Segments, where the Tenant System may All-Active ESes where the TS may
forward BUM frames to a non-Designated Forwarder NVE that can forward BUM frames to a Non-Designated Forwarder NVE that can
flood the BUM frames back to the Designated Forwarder NVE and flood the BUM frames back to the Designated Forwarder NVE and
then the Tenant System. As an example, in <xref then back to the TS. As an example, assuming
target="ure-evpn-for-l2-in-an-nvo3-network-example"/>, assuming NVE4 is the Designated Forwarder for ESI-2 in BD1, <xref
NVE4 is the Designated Forwarder for ESI-2 in BD1, BUM frames target="ure-evpn-for-l2-in-an-nvo3-network-example" format="default"/> shows tha
sent from TS3 to NVE5 will be received at NVE4 and, since NVE4 t BUM frames
is the Designated Forwarder for BD1, it will forward them back sent from TS3 to NVE5 will be received at NVE4. NVE4 will forward
to TS3. Split-horizon allows NVE4 (and any multi-homed NVE for them back to TS3 since NVE4 is the Designated Forwarder for BD1. Split-horizon a
llows NVE4 (and any multihomed NVE for
that matter) to identify if an EVPN BUM frame is coming from the that matter) to identify if an EVPN BUM frame is coming from the
same Ethernet Segment or different, and if the frame belongs to same Ethernet Segment or a different one. If the frame belongs to
the same ESI-2, NVE4 will not forward the BUM frame to TS3, in the same ESI-2, NVE4 will not forward the BUM frame to TS3 in
spite of being the Designated Forwarder.</t> spite of being the Designated Forwarder.</dd>
</list></t> </dl>
<t>While <xref target="RFC7432" format="default"/> describes the defau
<t>While <xref target="RFC7432"/> describes the default algorithm lt algorithm
for the Designated Forwarder Election, <xref target="RFC8584"/> and for the Designated Forwarder election, <xref target="RFC8584" format="
<xref target="I-D.ietf-bess-evpn-pref-df"/> specify other algorithms default"/> and
and procedures that optimize the Designated Forwarder Election.</t> <xref target="I-D.ietf-bess-evpn-pref-df" format="default"/> specify o
ther algorithms
<t>The Split-horizon function is specified in <xref and procedures that optimize the Designated Forwarder election.</t>
target="RFC7432"/> and it is carried out by using a special <t>The split-horizon function is specified in <xref target="RFC7432" f
ESI-label that it identifies in the data path, all the BUM frames ormat="default"/>, and it is carried out by using a special
being originated from a given NVE and Ethernet Segment. Since the ESI-label that it identifies in the data path with all the BUM frames
originating from a given NVE and Ethernet Segment. Since the
ESI-label is an MPLS label, it cannot be used in all the non-MPLS ESI-label is an MPLS label, it cannot be used in all the non-MPLS
NVO3 encapsulations, therefore <xref target="RFC8365"/> defines a NVO3 encapsulations. Therefore, <xref target="RFC8365" format="default
modified Split-horizon procedure that is based on the source IP "/> defines a
address of the NVO3 tunnel, and it is known as "Local-Bias". It is modified split-horizon procedure that is based on the source IP
worth noting that Local-Bias only works for all-active multi-homing, address of the NVO3 tunnel; it is known as "Local-Bias". It is
and not for single-active multi-homing.</t> worth noting that Local-Bias only works for All-Active multihoming,
and not for Single-Active multihoming.</t>
</section> </section>
<section anchor="sect-4.7.6" numbered="true" toc="default">
<section anchor="sect-4.7.6" <name>EVPN Recursive Resolution for Inter-subnet Unicast Forwarding</n
title="EVPN Recursive Resolution for Inter-Subnet Unicast Forwa ame>
rding"> <t><xref target="sect-4.3" format="default"/> describes how EVPN can b
<t><xref target="sect-4.3"/> describes how EVPN can be used for e used for
Inter Subnet Forwarding among subnets of the same tenant. MAC/IP inter-subnet forwarding among subnets of the same tenant. MAC/IP
Advertisement routes and IP Prefix routes allow the advertisement of Advertisement routes and IP Prefix routes allow the advertisement of
host routes and IP Prefixes (IP Prefix route) of any length. The host routes and IP Prefixes (IP Prefix route) of any length. The
procedures outlined by <xref target="sect-4.3"/> are similar to the procedures outlined by <xref target="sect-4.3" format="default"/> are
ones in <xref target="RFC4364"/>, only for NVO3 tunnels. However, similar to the
<xref target="RFC9136"/> also defines advanced Inter Subnet ones in <xref target="RFC4364" format="default"/>, but they are only f
Forwarding procedures that allow the resolution of IP Prefix routes or NVO3 tunnels. However,
to not only BGP next-hops but also "overlay indexes" that can be a <xref target="RFC9136" format="default"/> also defines advanced inter-
MAC, a Gateway IP (GW-IP) or an ESI, all of them in the tenant subnet
forwarding procedures that allow the resolution of IP Prefix routes
not only to BGP next hops but also to "overlay indexes" that can be a
MAC, a Gateway IP (GW-IP), or an ESI, all of them in the tenant
space.</t> space.</t>
<t><xref target="ure-evpn-for-l3-recursive-resolution-example" format=
<t><xref target="ure-evpn-for-l3-recursive-resolution-example"/> "default"/>
illustrates an example that uses Recursive Resolution to a GW-IP as illustrates an example that uses Recursive Resolution to a GW-IP as
per <xref target="RFC9136"/> section 4.4.2. In this example, IP-VRFs per <xref target="RFC9136" sectionFormat="of" section="4.4.2"/>. In th
in NVE1 and NVE2 are connected by an SBD (Supplementary Broadcast is example, IP-VRFs
Domain). An SBD is a Broadcast Domain that connects all the IP-VRFs in NVE1 and NVE2 are connected by a Supplementary Broadcast
of the same tenant, via IRB, and has no Attachment Circuits. NVE1 Domain (SBD). An SBD is a Broadcast Domain that connects all the IP-VR
Fs
of the same tenant via IRB and has no Attachment Circuits. NVE1
advertises the host route TS2-IP/L (IP address and Prefix Length of advertises the host route TS2-IP/L (IP address and Prefix Length of
TS2) in an IP Prefix route with overlay index GW-IP=IP1. Also, IP1 TS2) in an IP Prefix route with overlay index GW-IP=IP1. Also, IP1
is advertised in an MAC/IP Advertisement route associated to M1, is advertised in a MAC/IP Advertisement route associated with M1,
VNI-S and BGP next-hop NVE1. Upon importing the two routes, NVE2 VNI-S, and BGP next-hop NVE1. Upon importing the two routes, NVE2
installs TS2-IP/L in the IP-VRF with a next-hop that is the GW-IP installs TS2-IP/L in the IP-VRF with a next hop that is the GW-IP
IP1. NVE2 also installs M1 in the Supplementary Broadcast Domain, IP1. NVE2 also installs M1 in the Supplementary Broadcast Domain,
with VNI-S and NVE1 as next-hop. If TS3 sends a packet with IP with VNI-S and NVE1 as next hop. If TS3 sends a packet with IP
DA=TS2, NVE2 will perform a Recursive Resolution of the IP Prefix DA=TS2, NVE2 will perform a Recursive Resolution of the IP Prefix
route prefix information to the forwarding information of the route prefix information to the forwarding information of the
correlated MAC/IP Advertisement route. The IP Prefix route's correlated MAC/IP Advertisement route. The IP Prefix route's
Recursive Resolution has several advantages such as better Recursive Resolution has several advantages, such as better
convergence in scaled networks (since multiple IP Prefix routes can convergence in scaled networks (since multiple IP Prefix routes can
be invalidated with a single withdrawal of the overlay index route) be invalidated with a single withdrawal of the overlay index route)
or the ability to advertise multiple IP Prefix routes from an or the ability to advertise multiple IP Prefix routes from an
overlay index that can move or change dynamically. <xref overlay index that can move or change dynamically. <xref target="RFC91
target="RFC9136"/> describes a few use-cases.</t> 36" format="default"/> describes a few use cases.</t>
<figure anchor="ure-evpn-for-l3-recursive-resolution-example">
<figure anchor="ure-evpn-for-l3-recursive-resolution-example" <name>EVPN for L3 - Recursive Resolution Example</name>
title="EVPN for L3 - Recursive Resolution example"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ +-------------------------------------+
+-------------------------------------+ | EVPN NVO3 |
| EVPN NVO3 | | +
| + NVE1 NVE2
NVE1 NVE2 +--------------------+ +--------------------+
+--------------------+ +--------------------+ | +---+IRB +------+ | | +------+IRB +---+ |
| +---+IRB +------+ | | +------+IRB +---+ | TS1-----|BD1|----|IP-VRF| | | |IP-VRF|----|BD3|-----TS3
TS1-----|BD1|----|IP-VRF| | | |IP-VRF|----|BD3|-----TS3 | +---+ | |-(SBD)------(SBD)-| | +---+ |
| +---+ | |-(SBD)------(SBD)-| | +---+ | | +---+IRB | |IRB(IP1/M1) IRB+------+ |
| +---+IRB | |IRB(IP1/M1) IRB+------+ | TS2-----|BD2|----| | | +-----------+--------+
TS2-----|BD2|----| | | +-----------+--------+ | +---+ +------+ | |
| +---+ +------+ | | +--------------------+ |
+--------------------+ | | RT-2(M1,IP1,VNI-S,NVE1)--> |
| RT-2(M1,IP1,VNI-S,NVE1)--> | | RT-5(TS2-IP/L,GW-IP=IP1)--> |
| RT-5(TS2-IP/L,GW-IP=IP1)--> | +-------------------------------------+
+-------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="sect-4.7.7" numbered="true" toc="default">
<section anchor="sect-4.7.7" <name>EVPN Optimized Inter-subnet Multicast Forwarding</name>
title="EVPN Optimized Inter-Subnet Multicast Forwarding">
<t>The concept of the Supplementary Broadcast Domain described in <t>The concept of the Supplementary Broadcast Domain described in
<xref target="sect-4.7.6"/> is also used in <xref <xref target="sect-4.7.6" format="default"/> is also used in <xref tar
target="I-D.ietf-bess-evpn-irb-mcast"/> for the procedures related get="I-D.ietf-bess-evpn-irb-mcast" format="default"/> for the procedures related
to Inter Subnet Multicast Forwarding across Broadcast Domains of the to inter-subnet multicast forwarding across Broadcast Domains of the
same tenant. For instance, <xref same tenant. For instance, <xref target="I-D.ietf-bess-evpn-irb-mcast"
target="I-D.ietf-bess-evpn-irb-mcast"/> allows the efficient format="default"/> allows the efficient
forwarding of IP multicast traffic from any Broadcast Domain to any forwarding of IP multicast traffic from any Broadcast Domain to any
other Broadcast Domain (or even to the same Broadcast Domain where other Broadcast Domain (or even to the same Broadcast Domain where
the Source resides). The <xref the source resides). The <xref target="I-D.ietf-bess-evpn-irb-mcast" f
target="I-D.ietf-bess-evpn-irb-mcast"/> procedures are supported ormat="default"/> procedures are supported
along with EVPN multi-homing, and for any tree allowed on NVO3 along with EVPN multihoming and for any tree allowed on NVO3
networks, including IR or AR. <xref networks, including IR or AR. <xref target="I-D.ietf-bess-evpn-irb-mca
target="I-D.ietf-bess-evpn-irb-mcast"/> also describes the st" format="default"/> also describes the
interoperability between EVPN and other multicast technologies such interoperability between EVPN and other multicast technologies such
as MVPN (Multicast VPN) and PIM for inter-subnet multicast.</t> as Multicast VPN (MVPN) and PIM for inter-subnet multicast.</t>
<t><xref target="I-D.ietf-bess-evpn-mvpn-seamless-interop" format="def
<t><xref target="I-D.ietf-bess-evpn-mvpn-seamless-interop"/> ault"/>
describes another potential solution to support EVPN to MVPN describes another potential solution to support EVPN to MVPN
interoperability.</t> interoperability.</t>
</section> </section>
<section anchor="sect-4.7.8" numbered="true" toc="default">
<section anchor="sect-4.7.8" title="Data Center Interconnect (DCI)"> <name>Data Center Interconnect (DCI)</name>
<t>Tenant Layer-2 and Layer-3 services deployed on NVO3 networks <t>Tenant Layer 2 and Layer 3 services deployed on NVO3 networks
must often be extended to remote NVO3 networks that are connected must often be extended to remote NVO3 networks that are connected
via non-NOV3 Wide Area Networks (mostly MPLS based Wide Area via non-NOV3 Wide Area Networks (WANs) (mostly MPLS-based WANs). <xref
Networks). <xref target="RFC9014"/> defines some architectural target="RFC9014" format="default"/> defines some architectural
models that can be used to interconnect NVO3 networks via MPLS Wide models that can be used to interconnect NVO3 networks via MPLS WANs.
Area Networks.</t> </t>
<t>When NVO3 networks are connected by MPLS WANs,
<t>When NVO3 networks are connected by MPLS Wide Area Networks, <xref target="RFC9014" format="default"/> specifies how EVPN can be us
<xref target="RFC9014"/> specifies how EVPN can be used end-to-end, ed end to end
in spite of using a different encapsulation in the Wide Area in spite of using a different encapsulation in the WAN.
Network. <xref target="RFC9014"/> also supports the use of NVO3 or <xref target="RFC9014" format="default"/> also supports the use of NVO3
or
Segment Routing (encoding 32-bit or 128-bit Segment Identifiers into Segment Routing (encoding 32-bit or 128-bit Segment Identifiers into
labels or IPv6 addresses respectively) transport tunnels in the Wide labels or IPv6 addresses, respectively) transport tunnels in the WAN.<
Area Network.</t> /t>
<t>Even if EVPN can also be used in the WAN for
<t>Even if EVPN can also be used in the Wide Area Network for Layer 2 and Layer 3 services, there may be a need to provide a
Layer-2 and Layer-3 services, there may be a need to provide a Gateway function between EVPN for NVO3 encapsulations and IP VPN for
Gateway function between EVPN for NVO3 encapsulations and IPVPN for MPLS tunnels if the operator uses IP VPN in the WAN.
MPLS tunnels, if the operator uses IPVPN in the Wide Area Network. <xref target="I-D.ietf-bess-evpn-ipvpn-interworking" format="default"/
<xref target="I-D.ietf-bess-evpn-ipvpn-interworking"/> specifies the > specifies the
interworking function between EVPN and IPVPN for unicast Inter interworking function between EVPN and IP VPN for unicast inter-subnet
Subnet Forwarding. If Inter Subnet Multicast Forwarding is also forwarding. If inter-subnet multicast forwarding is also
needed across an IPVPN Wide Area Network, <xref needed across an IP VPN WAN, <xref target="I-D.ietf-bess-evpn-irb-mcas
target="I-D.ietf-bess-evpn-irb-mcast"/> describes the required t" format="default"/> describes the required
interworking between EVPN and MVPN (Multicast Virtual Private interworking between EVPN and MVPNs.</t>
Networks).</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default">
<section anchor="sect-5" title="Security Considerations"> <name>Security Considerations</name>
<t>This document does not introduce any new procedure or additional <t>This document does not introduce any new procedure or additional
signaling in EVPN, and relies on the security considerations of the signaling in EVPN and relies on the security considerations of the
individual specifications used as a reference throughout the document. individual specifications used as a reference throughout the document.
In particular, and as mentioned in <xref target="RFC7432"/>, control In particular, and as mentioned in <xref target="RFC7432" format="default" />, control
plane and forwarding path protection are aspects to secure in any EVPN plane and forwarding path protection are aspects to secure in any EVPN
domain, when applied to NVO3 networks.</t> domain when applied to NVO3 networks.</t>
<t><xref target="RFC7432" format="default"/> mentions security techniques
<t><xref target="RFC7432"/> mentions security techniques such as those such as those
discussed in <xref target="RFC5925"/> to authenticate BGP messages, and discussed in <xref target="RFC5925" format="default"/> to authenticate BGP
those included in <xref target="RFC4271"/>, <xref target="RFC4272"/> and messages, and
<xref target="RFC6952"/> to secure BGP are relevant for EVPN in NVO3 those included in <xref target="RFC4271" format="default"/>, <xref target=
"RFC4272" format="default"/>, and
<xref target="RFC6952" format="default"/> to secure BGP are relevant for E
VPN in NVO3
networks as well.</t> networks as well.</t>
</section> </section>
<section anchor="sect-6" numbered="true" toc="default">
<section anchor="sect-6" title="IANA Considerations"> <name>IANA Considerations</name>
<t>None.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
&RFC7432;
&RFC7365; <displayreference target="I-D.ietf-nvo3-encap" to="NVO3-ENCAP"/>
<displayreference target="I-D.ietf-bess-evpn-lsp-ping" to="BESS-EVPN-LSP-PING"/>
&RFC7364; <displayreference target="I-D.skr-bess-evpn-pim-proxy" to="BESS-EVPN-PIM-PROXY"/
</references> >
<displayreference target="I-D.ietf-bess-evpn-pref-df" to="BESS-EVPN-PREF-DF"/>
<references title="Informative References"> <displayreference target="I-D.ietf-bess-evpn-irb-mcast" to="BESS-EVPN-IRB-MCAST"
&RFC9136; />
<displayreference target="I-D.ietf-bess-evpn-ipvpn-interworking" to="BESS-EVPN-I
&RFC9135; PVPN-INTERWORKING"/>
<displayreference target="I-D.ietf-bess-evpn-geneve" to="BESS-EVPN-GENEVE"/>
&RFC8365; <displayreference target="I-D.ietf-bess-evpn-mvpn-seamless-interop" to="BESS-EVP
N-MVPN-SEAMLESS-INTEROP"/>
&RFC8926; <displayreference target="I-D.ietf-bess-secure-evpn" to="BESS-SECURE-EVPN"/>
<displayreference target="I-D.ietf-bess-rfc7432bis" to="BESS-RFC7432BIS"/>
&I-D.ietf-nvo3-encap; <displayreference target="I-D.ietf-rtgwg-bgp-pic" to="RTGWG-BGP-PIC"/>
<displayreference target="I-D.ietf-bess-evpn-optimized-ir" to="BESS-EVPN-OPTIMIZ
&RFC9012; ED-IR"/>
<references>
&I-D.ietf-bess-evpn-lsp-ping; <name>References</name>
<references>
&RFC9161; <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
&RFC9251; 432.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
&I-D.skr-bess-evpn-pim-proxy; 365.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
&I-D.ietf-bess-evpn-optimized-ir; 364.xml"/>
</references>
&RFC8584; <references>
<name>Informative References</name>
&I-D.ietf-bess-evpn-pref-df; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
136.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
135.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
365.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
926.xml"/>
&I-D.ietf-bess-evpn-irb-mcast; <!-- [I-D.ietf-nvo3-encap] IESG state Publication Requested; added the long way
to include Editor roles -->
<reference anchor="I-D.ietf-nvo3-encap" target="https://datatracker.ietf.org/doc
/html/draft-ietf-nvo3-encap-09">
<front>
<title>
Network Virtualization Overlays (NVO3) Encapsulation Considerations
</title>
<author role="editor" initials="S." surname="Boutros" fullname="Sami Boutros">
<organization>Ciena Corporation</organization>
</author>
<author role="editor" initials="D." surname="Eastlake 3rd" fullname="D. Eastlake
3rd">
</author>
<date month="October" day="7" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-nvo3-encap-09"/>
</reference>
&RFC9014; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 012.xml"/>;
&I-D.ietf-bess-evpn-ipvpn-interworking; <!-- [I-D.ietf-bess-evpn-lsp-ping] in RFC Ed queue as of 9/18/23 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-bess-evpn-lsp-ping.xml"/>
&RFC7348; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
161.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
251.xml"/>
&RFC7510; <!-- [I-D.skr-bess-evpn-pim-proxy] IESG state Expired -->
<reference anchor="I-D.skr-bess-evpn-pim-proxy" target="https://datatracker.ietf
.org/doc/html/draft-skr-bess-evpn-pim-proxy-01">
<front>
<title>PIM Proxy in EVPN Networks</title>
<author role="editor" initials="J." surname="Rabadan" fullname="Jorge Rabadan">
<organization>Nokia</organization>
</author>
<author initials="J." surname="Kotalwar" fullname="Jayant Kotalwar">
<organization>Nokia</organization>
</author>
<author initials="S." surname="Sathappan" fullname="Senthil Sathappan">
<organization>Nokia</organization>
</author>
<author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang">
<organization>Juniper</organization>
</author>
<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
<organization>Cisco</organization>
</author>
<date month="October" day="30" year="2017"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-skr-bess-evpn-pim-proxy-01"/>
</reference>
&RFC4364; <!-- [I-D.ietf-bess-evpn-optimized-ir] in RFC Ed queue / MISSREF*R as of 9/18/23
-->
<reference anchor="I-D.ietf-bess-evpn-optimized-ir" target="https://datatracker.
ietf.org/doc/html/draft-ietf-bess-evpn-optimized-ir-12">
<front>
<title>
Optimized Ingress Replication Solution for Ethernet VPN (EVPN)
</title>
<author role="editor" initials="J." surname="Rabadan" fullname="Jorge Rabadan">
<organization>Nokia</organization>
</author>
<author initials="S." surname="Sathappan" fullname="Senthil Sathappan">
<organization>Nokia</organization>
</author>
<author initials="W." surname="Lin" fullname="Wen Lin">
<organization>Juniper Networks</organization>
</author>
<author initials="M." surname="Katiyar" fullname="Mukul Katiyar">
<organization>Versa Networks</organization>
</author>
<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
<organization>Cisco Systems</organization>
</author>
<date month="January" day="25" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-optimized-ir-12"/>
</reference>
<reference anchor="CLOS1953"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 584.xml"/>
<title>A Study of Non-Blocking Switching Networks</title>
<author fullname="C. Clos" initials="C." surname="Clos"> <!-- [I-D.ietf-bess-evpn-pref-df] IESG state AD Evaluation -->
<organization>The Bell System Technical Journal, Vol. 32(2), DOI <reference anchor="I-D.ietf-bess-evpn-pref-df" target="https://datatracker.ietf.
10.1002/j.1538- 7305.1953.tb01433.x</organization> org/doc/html/draft-ietf-bess-evpn-pref-df-11">
</author> <front>
<title>Preference-based EVPN DF Election</title>
<author role="editor" initials="J." surname="Rabadan" fullname="Jorge Rabadan">
<organization>Nokia</organization>
</author>
<author initials="S." surname="Sathappan" fullname="Senthil Sathappan">
<organization>Nokia</organization>
</author>
<author initials="W." surname="Lin" fullname="Wen Lin">
<organization>Juniper Networks</organization>
</author>
<author initials="J." surname="Drake" fullname="John Drake">
<organization>Juniper Networks</organization>
</author>
<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
<organization>Cisco Systems</organization>
</author>
<date month="July" day="6" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-pref-df-11"/>
</reference>
<date month="March" year="1953"/> <!-- [I-D.ietf-bess-evpn-irb-mcast] IESG state AD Evaluation -->
</front> <reference anchor="I-D.ietf-bess-evpn-irb-mcast" target="https://datatracker.iet
</reference> f.org/doc/html/draft-ietf-bess-evpn-irb-mcast-09">
<front>
<title>
EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding
</title>
<author initials="W." surname="Lin" fullname="Wen Lin">
<organization>Juniper Networks</organization>
</author>
<author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang">
<organization>Juniper Networks</organization>
</author>
<author initials="J." surname="Drake" fullname="John Drake">
<organization>Juniper Networks</organization>
</author>
<author role="editor" initials="E." surname="Rosen" fullname="Eric C. Rosen">
<organization>Juniper Networks</organization>
</author>
<author initials="J." surname="Rabadan" fullname="Jorge Rabadan">
<organization>Nokia</organization>
</author>
<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
<organization>Cisco Systems</organization>
</author>
<date month="February" day="21" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-irb-mcast-09"/>
</reference>
&I-D.ietf-bess-evpn-geneve; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 014.xml"/>;
&I-D.ietf-bess-evpn-mvpn-seamless-interop; <!-- [I-D.ietf-bess-evpn-ipvpn-interworking] I-D exists -->
<reference anchor="I-D.ietf-bess-evpn-ipvpn-interworking" target="https://datatr
acker.ietf.org/doc/html/draft-ietf-bess-evpn-ipvpn-interworking-08">
<front>
<title>EVPN Interworking with IPVPN</title>
<author role="editor" initials="J." surname="Rabadan" fullname="Jorge Rabadan">
<organization>Nokia</organization>
</author>
<author role="editor" initials="A." surname="Sajassi" fullname="Ali Sajassi">
<organization>Cisco</organization>
</author>
<author initials="E." surname="Rosen" fullname="Eric C. Rosen">
<organization>Individual</organization>
</author>
<author initials="J." surname="Drake" fullname="John Drake">
<organization>Juniper</organization>
</author>
<author initials="W." surname="Lin" fullname="Wen Lin">
<organization>Juniper</organization>
</author>
<author initials="J." surname="Uttaro" fullname="Jim Uttaro">
<organization>AT&amp;T</organization>
</author>
<author initials="A." surname="Simpson" fullname="Adam Simpson">
<organization>Nokia</organization>
</author>
<date month="July" day="5" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-ipvpn-interworking
-08"/>
</reference>
&I-D.sajassi-bess-secure-evpn; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
348.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
510.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
364.xml"/>
&RFC5925; <reference anchor="CLOS1953" target="https://ieeexplore.ieee.org/documen
t/6770468">
<front>
<title>A study of non-blocking switching networks</title>
<author fullname="Charles Clos" initials="C." surname="Clos">
</author>
<date month="March" year="1953"/>
</front>
<seriesInfo name="DOI" value="10.1002/j.1538-7305.1953.tb01433.x"/>
<refcontent>The Bell System Technical Journal, Vol. 32, Issue 2</refcon
tent>
</reference>
&RFC4271; <!-- [I-D.ietf-bess-evpn-geneve] IESG state I-D Exists -->
<reference anchor="I-D.ietf-bess-evpn-geneve" target="https://datatracker.ietf.o
rg/doc/html/draft-ietf-bess-evpn-geneve-06">
<front>
<title>EVPN control plane for Geneve</title>
<author role="editor" initials="S." surname="Boutros" fullname="Sami Boutros">
<organization>Ciena</organization>
</author>
<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
<organization>Cisco Systems</organization>
</author>
<author initials="J." surname="Drake" fullname="John Drake">
<organization>Juniper Networks</organization>
</author>
<author initials="J." surname="Rabadan" fullname="Jorge Rabadan">
<organization>Nokia</organization>
</author>
<author initials="S." surname="Aldrin" fullname="Sam Aldrin">
<organization>Google</organization>
</author>
<date month="May" day="26" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-geneve-06"/>
</reference>
&RFC4272; <!-- [I-D.ietf-bess-evpn-mvpn-seamless-interop] IESG state I-D Exists -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-be
ss-evpn-mvpn-seamless-interop.xml"/>
&RFC6952; <!-- [I-D.sajassi-bess-secure-evpn] draft-sajassi-bess-secure-evpn-06 is expired
and was replaced by draft-ietf-bess-secure-evpn-00 (I-D Exists). Entered the lo
ng way as the date was wrong -->
<reference anchor="I-D.ietf-bess-secure-evpn" target="https://datatracker.ietf.o
rg/doc/html/draft-ietf-bess-secure-evpn-00">
<front>
<title>Secure EVPN</title>
<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
<organization>Cisco</organization>
</author>
<author initials="A." surname="Banerjee" fullname="Ayan Banerjee">
<organization>Cisco</organization>
</author>
<author initials="S." surname="Thoria" fullname="Samir Thoria">
<organization>Cisco</organization>
</author>
<author initials="D." surname="Carrel" fullname="David Carrel">
<organization>Graphiant</organization>
</author>
<author initials="B." surname="Weis" fullname="Brian Weis">
<organization>Independent</organization>
</author>
<author initials="J." surname="Drake" fullname="John Drake">
<organization>Juniper Networks</organization>
</author>
<date month="June" day="20" year="2023" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bess-secure-evpn-00" />
</reference>
&RFC4760; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
925.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
272.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
952.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
760.xml"/>
&I-D.ietf-bess-rfc7432bis; <!-- [I-D.ietf-bess-rfc7432bis] Expired -->
<reference anchor="I-D.ietf-bess-rfc7432bis" target="https://datatracker.ietf.or
g/doc/html/draft-ietf-bess-rfc7432bis-07">
<front>
<title>BGP MPLS-Based Ethernet VPN</title>
<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
<organization>Cisco</organization>
</author>
<author initials="L." surname="Burdet" fullname="Luc André Burdet">
<organization>Cisco</organization>
</author>
<author initials="J." surname="Drake" fullname="John Drake">
<organization>Juniper</organization>
</author>
<author initials="J." surname="Rabadan" fullname="Jorge Rabadan">
<organization>Nokia</organization>
</author>
<date month="March" day="13" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bess-rfc7432bis-07"/>
</reference>
&I-D.ietf-rtgwg-bgp-pic; <!-- [I-D.ietf-rtgwg-bgp-pic] IESG state I-D Exists -->
<reference anchor="I-D.ietf-rtgwg-bgp-pic" target="https://datatracker.ietf.org/
doc/html/draft-ietf-rtgwg-bgp-pic-19">
<front>
<title>BGP Prefix Independent Convergence</title>
<author role="editor" initials="A." surname="Bashandy" fullname="Ahmed Bashandy"
>
<organization>Cisco Systems</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
</author>
<author initials="P." surname="Mohapatra" fullname="Prodosh Mohapatra">
<organization>Sproute Networks</organization>
</author>
<date month="April" day="1" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-bgp-pic-19"/>
</reference>
<reference anchor="IEEE.802.1AX_2014"> <reference anchor="IEEE.802.1AX_2014">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks -- <title>IEEE Standard for Local and metropolitan area networks --
Link Aggregation</title> Link Aggregation</title>
<author>
<author fullname="IEEE"> <organization>IEEE</organization>
<organization>IEEE 802.1AX-2014, DOI </author>
10.1109/IEEESTD.2014.7055197</organization> <date month="December" year="2014"/>
</author> </front>
<seriesInfo name="IEEE Std" value="802.1AX-2014"/>
<date day="24" month="December" year="2014"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2014.7055197"/>
</front> </reference>
</reference> </references>
</references> </references>
<section anchor="acknowledgments" numbered="false" toc="default">
<section anchor="sect-A" title="Acknowledgments"> <name>Acknowledgments</name>
<t>The authors want to thank Aldrin Isaac for his comments.</t> <t>The authors thank <contact fullname="Aldrin Isaac"/> for his comments.<
/t>
</section> </section>
<section anchor="sect-B" title="Contributors"/>
<section anchor="sect-C" title="Authors' Addresses"/>
</back> </back>
</rfc> </rfc>
 End of changes. 230 change blocks. 
1017 lines changed or deleted 1199 lines changed or added

This html diff was produced by rfcdiff 1.48.