One document matched: draft-hertoghs-nvo3-lisp-controlplane-unified-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
docName="draft-hertoghs-nvo3-lisp-controlplane-unified-02"
ipr="trust200902">
<front>
<title abbrev="Unified LISP for NVO3">A Unified LISP Mapping Database for
L2 and L3 Network Virtualization Overlays</title>
<author fullname="Yves Hertoghs" initials="Y." surname="Hertoghs">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>6a De Kleetlaan</street>
<city>Diegem</city>
<code>1831</code>
<region/>
<country>Belgium2</country>
</postal>
<phone>+32-2778-435</phone>
<facsimile>+32-2704-6000</facsimile>
<email>yves@cisco.com</email>
</address>
</author>
<author fullname="Fabio Maino" initials="F" surname="Maino">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city>
<code>95134</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fmaino@cisco.com</email>
</address>
</author>
<author fullname="Victor Moreno" initials="V." surname="Moreno">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city>
<code>95134</code>
<region>California</region>
<country>USA</country>
</postal>
<email>vimoreno@cisco.com</email>
</address>
</author>
<author fullname="Michael Smith" initials="M." surname="Smith">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city>
<code>95134</code>
<region>California</region>
<country>USA</country>
</postal>
<email>michsmit@cisco.com</email>
</address>
</author>
<author fullname="Dino Farinacci" initials="D." surname="Farinacci">
<organization>lispers.net</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<region/>
<country/>
</postal>
<email>farinacci@gmail.com</email>
</address>
</author>
<author fullname="Luigi Iannone" initials="L." surname="Iannone">
<organization>Telecom ParisTech</organization>
<address>
<email>luigi.iannone@telecom-paristech.fr</email>
</address>
</author>
<date day="21" month="July" year="2014"/>
<area>Routing Area</area>
<workgroup>Networking Virtualization Overlays Working Group</workgroup>
<keyword>LISP; deployment; NVO3</keyword>
<abstract>
<t>The purpose of this draft is to document how the Locator/ID
Separation Protocol (LISP) Control Plane can be used to offer a unified
(offering L2 AND L3) Overlay solution that matches the framework and
requirements of Network Virtualization over L3 (NVO3). This information
is provided as input to the NVO3 analysis of the suitability of existing
IETF protocols to the NVO3 requirements.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The purpose of this draft is to provide a mapping between the Network
Virtualization over L3 (NVO3) framework <xref
target="I-D.ietf-nvo3-framework"/> and the Locator/ID Separation
Protocol (LISP) <xref target="RFC6830"/>, and in particular how LISP
components map to the reference models defined therein. This document
extends the scope of<xref target="I-D.maino-nvo3-lisp-cp"> </xref> to
cover the case of a unified overlay that includes L2 and L3
services.</t>
<t>LISP is a flexible map and encap framework that can be used for
overlay network applications, including Data Center Network
Virtualization. The LISP framework provides two main tools for NVO3:</t>
<t><list style="numbers">
<t>A Data Plane that specifies how Endpoint Identifiers (EIDs) are
encapsulated in Routing Locators (RLOCs), and</t>
<t>A Control Plane that specifies the interfaces to the LISP Mapping
System <xref target="RFC6833"/>. The LISP Mapping system provides
the mapping between EIDs and RLOCs.</t>
</list></t>
<t>LISP can be leveraged to offer services to both Physical and Virtual
endpoints, and is architecturally EID address family agnostic. Some
flows will be across an L3 overlay (using IP addresses as EIDs), and
other flows will be across an L2 overlay (using MAC addresses as
EIDs).</t>
<t>If certain requirements are met within the architecture, the choice
of whether a flow is sent across the L2 overlay versus across the L3
overlay is not mapped one to one to the choice between intra subnet
(bridging) and inter subnet (routing) forwarding. This allows the
network administrator to offer infrastructure spanning subnets to its
tenants, while not forcing them to deploy infrastructure-wide broadcast
domains.</t>
<t>This document will focus on how to offer a unified L2 and L3 overlay,
where both L2 and L3 services can be offered to the tenant's traffic
simultaneously.</t>
<t>The draft will elaborate on achieving multi homing of Tenant Systems
(TS), as well as optimal routing and forwarding, including how VM
mobility is achieved and optimal traffic forwarding is achieved.</t>
<t>Although the LISP specification uses a specific data plane, its
control plane can be decoupled fairly easily from the data plane and
thus can support various data plane encapsulations. After describing the
various data plane options, this document also addresses the NVO3 data
plane requirements<xref
target="I-D.ietf-nvo3-dataplane-requirements"/>.</t>
<t>The document continues to lay out how the NVO3 control plane
requirements <xref target="I-D.ietf-nvo3-nve-nva-cp-req"/> are
addressed.</t>
<t>Finally this document will provide security considerations in <xref
target="security"/></t>
</section>
<section anchor="terms" title="Definition of Terms">
<t><list style="empty">
<t>Flood-and-Learn: the use of dynamic (data plane) learning in
VXLAN to discover the location of a given Ethernet/IEEE 802 MAC
address in the underlay network.</t>
<t/>
</list></t>
<t>For definition of NVO3 related terms, notably Tenant System (TS),
Virtual Network (VN), Virtual Network Identifier (VNI), Network
Virtualization Edge (NVE), Network Virtualization Authority (NVA), Data
Center (DC), please consult <xref
target="I-D.ietf-nvo3-framework"/>.</t>
<t>For definitions of LISP related terms, notably Map-Request,
Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR),
Endstation IDentifier (EID), Routing LOCator (RLOC), Map-Server (MS) and
Map-Resolver (MR) please consult the LISP specification <xref
target="RFC6830"/>.</t>
</section>
<section title="NVO3 Framework and LISP">
<t/>
<section title="NVO3 Generic Reference Model">
<t><xref target="I-D.maino-nvo3-lisp-cp"/> provides a mapping of the
NVO3 generic reference model <xref target="I-D.ietf-nvo3-framework"/>
onto the LISP architecture. In this document we will focus on the
unified L2/L3 LISP control plane, and on how it will optimize
forwarding .</t>
</section>
<section title="NVE Reference Model">
<t>The LISP NVE Reference Model is described in <xref
target="I-D.maino-nvo3-lisp-cp"/>. This section will look at the
different types of NVEs: L2-only, L3-only, and unified L2/L3, as well
as looking at VM Mobility, Multi-homing, optimal forwarding and
external connectivity aspects. How TSes connect to the network is
described in <xref target="VN-connect"/>.</t>
<section title="Types of NVE's">
<t><xref target="RFC6830"/> is defined as a L3 NVE, and it can be
enhanced to support L2 NVEs.</t>
<t>The separation of the L2 NVE and L3 NVE functions can be based on
the nature of the packets: bridged packets are assigned to the L2
NVE function, while routed packets are assigned to the L3 NVE
function. Therefore these discrete functions could live on discrete
networking nodes.</t>
<t>However, it is possible to use LISP as an unified control plane,
that combines and co-locates the function of L2/L3 NVE onto a single
node. The network administrator can choose which traffic will be
forwarded across each service type.</t>
<section title="L2 only NVE">
<t><xref target="I-D.smith-lisp-layer2"/> describes an
encapsulation method for carrying Ethernet and IEEE 802 media
access control (MAC) frames within the Locator/ID Separation
Protocol (LISP). As described in <xref
target="I-D.maino-nvo3-lisp-cp"/> MAC addresses are used as EIDs
in an L2 only NVE. As control plane learning is used, only
broadcast and multicast traffic needs mult-destination support
from the underlay.</t>
<t>The frame format defined in <xref
target="I-D.mahalingam-dutt-dcops-vxlan"/>, has a header
compatible with the LISP data path encapsulation header, when MAC
addresses are used as EIDs, as described in section 4.12.2 of
<xref target="I-D.ietf-lisp-lcaf"/>.</t>
<t>The LISP control plane is extensible, and can support non-LISP
data path encapsulations such as NVGRE <xref
target="I-D.sridharan-virtualization-nvgre"/>, or other
encapsulations that provide support for network
virtualization.</t>
</section>
<section title="L3 only NVE">
<t>LISP is defined as a virtualized IP routing and forwarding
service in <xref target="RFC6830"/>, and as such can be used to
provide L3 NVE services.</t>
</section>
<section anchor="L2L3NVE" title="Unified L2/L3 NVE">
<t>When using a unified L2/L3 NVE, IP EIDs are registered to the
LISP mapping system with the MAC Address of the Tenant System (TS)
as an additional RLOC (next to the NVE RLOC), through the methods
defined in <xref target="I-D.ietf-lisp-lcaf"/>, by encoding
Key/Value Pairs. MAC Address based EIDs will also be registered
for TSes that are transmitting non-IP based traffic. TSes that
send out both IP and non-IP traffic will therefore be registered
twice. For the L2 overlay the Virtual Networking Instance
(VNI)/IID denotes a network-wide bridge domain, while for the L3
overlay the VNI/IID denotes a Virtual Routing Forwarding (VRF)
instance.</t>
<t>Implementing an NVE with a unified L2 and L3 overlay support is
beneficial for multiple reasons:</t>
<t>Primarily it allows the network administrator to choose which
traffic traverses the L2 overlay versus the L3 overlay, not only
on the basis of intra-subnet (bridged) versus inter-subnet
(routed) traffic flows. As a matter of fact, it is highly
beneficial to choose a policy where all IP traffic is forwarded
across the L3 overlay (i.e. both intra- and inter-subnet traffic).
Effectively this allows the 'spread' of subnets across the
Datacenter(s) without leading to network wide broadcast and
associated failure domains, while allowing free mobility of the
end-stations.</t>
<t>Secondarily, when all the TS IP and MAC addresses are
registered with the NVA/LISP Mapping system, optimisations in ARP
and ND <xref target="RFC4861"/> forwarding and handling can be
achieved. ARPs and IPv6 NDs for 'unknown' destinations are by
default dropped, although a policy can allow for 'unknown' ARP/ND
packets to be flooded across the underlay if so desired by the
operator (e.g. when there is a desire to support 'silent
hosts').</t>
<t>Finally, as all IP traffic is forwarded across a L3 overlay,
and ARP/ND operations do not need flooding services, the amount of
traffic that needs to traverse the L2 overlay is limited to non-IP
traffic only. This makes the registration of MAC-addresses as EIDs
with the LISP control plane optional. The system in this case
could use ingress replication and Flood-and-Learn to handle the
non-IP traffic. Of course, the use of the LISP control plane for
MAC address based EIDs is another option as well, but the choice
is left to the network administrator.</t>
<t>However, in order to achieve the benefits of this model, there
are some requirements of how TSs can connect to the unified L2/L3
NVE, and there are also requirements on how default gateway MAC/IP
addresses are assigned to the NVE function, and how forwarding is
done on the NVE function:<list style="symbols">
<t>The NVE MUST always do an IP lookup for IP based traffic,
independent of whether the destination is within the same
subnet or not, or whether the destination TS is attached to
the same VLAN or L2 NVI as the source TS.</t>
<t>The unified L2/L3 NVE NVI instance MUST have a uniform
default gateway MAC-address and IP address across the entire
NVO3 network. This is to make sure that a TS can always reach
its default gateway, irrespective of location.</t>
<t>A TS can connect across a L2 switched network to a unified
L2/L3 NVE, but traffic forwarded MUST follow a simple rule,
where all traffic from a TS MUST always be sent upstream to
the unified L2/L3 NVE, regardless of its destination MAC
address, and traffic from locally attached TS's MUST be
switched through the NVE. Directly connecting a TS to a
unified L2/L3 NVE automatically solves that requirement.</t>
</list></t>
<t>There are various options to provide unified L2 and L3 support
for LISP in the data path.</t>
<t><xref target="I-D.smith-lisp-layer2"/> extends LISP to support
MAC addresses as EIDs, and can be used in combination with <xref
target="RFC6830"/>, using the destination UDP port in the outer
LISP header for disambiguation.</t>
<t>Recently extensions to both LISP and VXLAN have been proposed
to offer multiprotocol support across the same outer header format
(i.e. using a single UDP port number), as described in <xref
target="I-D.lewis-lisp-gpe"/>, and <xref
target="I-D.quinn-vxlan-gpe"/> respectively. It is to be noted
that some functionality offered by native LISP is no longer
available when using the <xref
target="I-D.lewis-lisp-gpe"/>extension (namely nonce, echo-nonce,
and map-versioning). These are optional control plane
optimizations implemented in the data plane for <xref
target="RFC6830"/>, and their use is less relevant in DC
applications.</t>
<t>The remainder of this document assumes a unified L2/L3 NVE
deployment model.</t>
</section>
</section>
<section title="Multihoming aspects">
<t>If the TSes are co-located with the xTR/NVE function, no support
for multi-homing is needed.</t>
<t>If the network between the L2 device connecting the TSes and the
LISP xTRs is a simple hub and spoke switched L2 topology using VLANs
(this is a common assumption in DC networks), a multi-chassis Link
Aggregation Group (LAG) solution can be used to offer redundancy,
where both xTRs will be seen by the access device as one logical
entity. xTRs connected to the same L2 switched access network are
part of the same 'LISP site', and both of them can be used to send
traffic to TSes behind them, as both xTRs are registering to the
LISP mapping system for the EIDs behind them. Registrations
performed by the individual xTR (as a result of detection of a new
EID) part of the same site are performed using the RLOCs of all xTRs
connected to that site. How the multi-chassis LAG solution is build
is out of scope of this draft.</t>
</section>
<section title="External connectivity aspects">
<t>External connectivity between a LISP enabled NVO3 DC, as well as
any LISP site, and the external world can be handled through a
gateway device.</t>
<t>In case the gateway device handles connectivity to VPNs or the
Internet, LISP interworking will be employed at the gateway device
as per <xref target="RFC6832"/>.</t>
<t>In case the gateway device is used to interconnect to another DC
part of the same administrative domain (one Mapping System governs
both DCs), the only function needed on this device is routing within
the RLOC address space.</t>
<t>In case separate LISP Mapping systems are used, interworking has
to be established between them, as well as providing routing between
the two administrative domain in between the RLOC address spaces of
both DCs respectively. Today there is no described way of
interworking between DDT based Mapping systems. An external
controller could also insert new RLOC locations into a DDT based
Mapping system when an EID has moved to a location not governed by
this particular Mapping system.</t>
</section>
<section title="Optimal Forwarding aspects">
<t>Implementing a co-located and unified L2 and L3 NVE, and placing
that NVE as close as possible to the TSes, leads to the most optimal
forwarding.</t>
<t>East-to-west traffic (from NVE to NVE) will always be
mapped-and-encapped towards the 'right' NVE, as the NVA function
(the LISP Mapping system) has knowledge about all of the TSes IP and
MAC addresses.</t>
<t>North to South traffic (traffic ingress into the DC) will also be
delivered to the right NVE, without traffic tromboning, as traffic
is switched based on the EID IP address, which will always point to
the correct ETR/RLOC.</t>
<t>Traffic going from TSes to external destinations will also not be
affected by traffic tromboning as all NVE's part of an NVI are seen
as the same default gateway, independent of location.</t>
<t>Traffic tromboning can occur if the last hop router is not in the
same location as the egress NVE, and if only a single L2 NVE is
deployed. In other words, the only way for a L2-only NVE based NVO3
system to avoid traffic tromboning for north-south traffic, is by
centralizing the default gateway for all VNI's in one location (that
in some cases may be suboptimal).</t>
</section>
<section anchor="vm-mobility" title="VM Mobility aspects">
<t>This section shows how the LISP control plane deals with VM
mobility when end systems are migrated from one NVE/DC to
another.</t>
<t>We'll assume that a signaling protocol, as described in <xref
target="I-D.kompella-nvo3-server2nve"/>, signals to the NVE
operations such as creating/terminating/migrating an end system. The
signaling protocol consists of three basic messages: "associate",
"disassociate", and "pre-associate". The signaling protocol for
attach/detach is in addition and orthogonal to the LISP control
plane.</t>
<t>Two approaches are laid out: An approach at L2, where
MAC-addresses are used as EID, and an approach at L3, where both IP
and MAC addresses are used as EIDs.</t>
<section title="VM Mobility at L2">
<t>VM mobility at L2 is described in <xref
target="I-D.maino-nvo3-lisp-cp"/></t>
<t>It is to be noted that the approach of solving VM mobility at
L2 introduces scalability problems in terms of failure domain, NVA
scaling (as MAC addresses are a flat and non de-aggregatable
address space) and BUM containment.</t>
</section>
<section title="VM Mobility at L3">
<t>This approach solves the scaling problems of the L2 approach by
assuming that the majority of traffic is IP based. End Systems are
therefor registered with their IP addresses as EID and xTR IP
address as an RLOC, while their MAC-address is registered as an
additional RLOC for the same EID.</t>
<t><figure align="center" anchor="l2-mobility"
title="End System Mobility">
<artwork align="center"><![CDATA[
,---------.
,' `.
(Mapping System )
`. ,'
`-+------+'
+--+--+ +-+---+
|MS/MR| |MS/MR|
+-+---+ +-----+
| |
.--..--. .--. ..
( ' '.--.
.-.' L3 '
( Underlay )
( '-'
._.'--'._.'.-._.'.-._)
RLOC=IP_A // \\ RLOC=IP_B
+---+--+ +-+--+--+
.--.-.|xTR A |'.-. .| xTR B |.-.
( +---+--+ ) ( +-+--+--+ )
( __. ( '.
..' LISP Site A ) .' LISP Site B )
( .'-' ( .'-'
'--'._.'. )\ '--'._.'. )\
/ '--' \ / '--' \
'--------' '--------' '--------' '--------'
: End : : End : ==> : End : : End :
: Device : : Device : ==> : Device : : Device :
'--------' '--------' '--------' '--------'
EID= EID=<IID1,MAC_W> EID=
<IID2,MAC_X> EID=<IID1,IP_W> <IID1,MAC_Z>
<IID2,IP_X> <IID1,IP_Z>]]></artwork>
</figure></t>
<t>It is assumed that the LISP xTRs have a unified L2 and L3
map-en-encap function, where IP packets, regardless of the fact
they are switched intra- or inter subnet, are mapped-and-encapped
across the L3 overlay. All other traffic (non-routable traffic,
non-IP traffic) is mapped-and-encapped by the L2 overlay. It is
also assumed that all XTRs offer the same default gateway IP and
MAC address across the network, on a per VNI instance.</t>
<t>A unified L2/L3 overlay will lead in the xTRs registering two
sets of EIDs for specific end systems, who deliver a mix of IP and
non-IP traffic:</t>
<t><list style="symbols">
<t>A tuple of EID=<IID, IP> to use for IP traffic across
the L3 overlay, whereby the IID maps to a VRF instance. It
will register the EID to multiple RLOCs, one being the xTR IP
address, and the other one being the TS MAC Address.</t>
<t>A tuple EID= <IID,MAC> to use for non-routable,
non-IP traffic, across the L2 overlay, whereby the IID maps to
a network-wide Bridge Domain.</t>
</list></t>
<t>Assume the scenario described in <xref target="l2-mobility"/>.
Also assume that for the sake of this discussion, the VMs do not
send out traffic that needs treatment by an L2 overlay.</t>
<t>As a result of the end system registration, the Mapping System
contains the EID-to-RLOC mapping for end system W that associates
EID=<IID1, IP_W> with the RLOC(s) associated with LISP site
A (IP_A), as well as the RLOC associated with the MAC Address
MAC_W of the end system W.</t>
<t>The process of migrating end system W from data center A to
data center B is initiated.</t>
<t>ETR B receives a pre-associate message that includes
EID=<IID1, IP_W>. ETR B sends a Map-Register to the mapping
system registering RLOC=IP_B as an additional locator for end
system W with priority set to 255. This means that the RLOC MUST
NOT be used for unicast forwarding, but the mapping system is now
aware of the new location.</t>
<t>During the migration process of end system W, ETR A receives a
dissociate message, and sends a Map-Register with Record TTL=0 to
signal the mapping system that end system W is no longer reachable
at RLOC=IP_A. xTR A will also add an entry in its forwarding table
that marks EID=<IID1, IP_W> as non-local.</t>
<t>When end system W has completed its migration, ETR B receives
an associate message for end system W, and sends a Map-Register to
the mapping system setting a non-255 priority for RLOC=IP_B. Now
the mapping system is updated with the new EID-to-RLOC mapping for
end system W with the desired priority.</t>
<t>The remote ITRs that were corresponding with end system W
during the migration will keep sending packets to ETR A.</t>
<t>ETR A will keep forwarding locally those packets until it
receives a dissociate message, and the entry in the forwarding
table associated with EID=<IID1, IP_W> is marked as
non-local.</t>
<t>Subsequent packets arriving at ETR A from a remote ITR, and
destined to end system W will hit the entry in the forwarding
table that will generate an exception, and will generate a
Solicit-Map-Request (SMR) message that is returned to the remote
ITR.</t>
<t>Upon receiving the SMR the remote ITR will invalidate its local
map-cache entry for EID=<IID1, IP_W> and send a new
Map-Request for that EID. The Map-Request will generate a
Map-Reply that includes the new EID-to-RLOC mapping for end system
W with RLOC=IP_B.</t>
<t>Similarly, unencapsulated packets arriving at ITR A from local
end systems and destined to end system W will hit the entry in the
forwarding table marked as non-local, and will generate an
exception that by sending a Map-Request for EID=<IID1, IP_W>
will populate the map-cache of ITR A with an EID-to-RLOC mapping
for end system W with RLOC=IP_B.</t>
</section>
</section>
</section>
<section anchor="dataplane"
title="LISP dataplane options and NVO3 dataplane requirements">
<t>This section maps the NVO3 data plane requirements <xref
target="I-D.ietf-nvo3-dataplane-requirements"/> to the various options
available.</t>
<section anchor="native-lisp-dp" title="Native LISP Data Plane">
<t><xref target="LISP-header"/>shows the LISP header defined in the
LISP specification <xref target="RFC6830"/>. The UDP and LISP
headers are shown below for reference. For header fields description
see section 5.3 of <xref target="RFC6830"/>.</t>
<t><figure align="center" anchor="LISP-header" title="LISP Header">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 or IPv6 Header (with RLOC addresses) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = (L2-)LISP |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator Status Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>When the headers are used for encapsulating IP Packets, the UDP
Destination Port is set to 4341. When the headers are used for
encapsulating L2 frames, the UDP Destination Port is set to 8472
<xref target="I-D.smith-lisp-layer2"/>.</t>
<t>When used in private DC and Enterprise networks, the 'I'-bit
(Instance bit) is set, indicating the presence of an Instance ID
(IID) inside the header. A Virtual Networking Instance (VNI) is
indicated by the IID, a 24 bit field, which is used as a global
identifier for the tenant in LISP. When used for L3 services, the
IID can be seen as a VRF, when used for L2 services, the IID can be
seen as a L2 Bridge Domain instance.</t>
<t>Virtual Access Point (VAP) identification is naturally supported
by combining LISP and Integrated Routing and Bridging (IRB). IRB
allows local ports or logical ports (ports instantiated on a local
port, where frames are assigned based on some fields in the header
like VLAN IDs (VIDs)), to be added to a NVE-local bridge domain.
That bridge domain instantiates the L2 Specific VNI. The bridge
domain also connects to a virtual routed port, which instantiates
the L3 specific VNI.</t>
<t>A L2 VNI provides an emulated Ethernet Multipoint service through
the use of the LISP control plane, where it registers MAC addresses
as EIDs.</t>
<t>Loop-avoidance is handled by control plane learning, and control
plane enabled registration of all TS EIDs as soon as they send a
first packet. Therefore unicast traffic will never result in loops,
as there is no 'unknown' unicast. multi-destination traffic
forwarding is performed using a multicast enabled underlay and LISP
procedures laid out in <xref target="RFC6831"/> or through ingress
replication to the list of participating NVEs in that NVI, and
therefore is loop-free.</t>
<t>A L3 VNI behaves exactly as an IP VRF and therefore supports
virtualized IP routing and forwarding, through per tenant forwarding
with IP address isolation and L3 tunneling for interconnecting
instances of the same VNI on NVEs.</t>
<t>Note that , within this document, it is assumed that a unified
L2/L3 NVE is deployed and therefore all IP traffic will be forwarded
using the L3 overlay, even intra-subnet traffic.</t>
<t>The LISP header performs the function of the NVO3 overlay
header.</t>
<t>Through using the LISP control plane, the egress NVE can be
looked up.</t>
<t>As the outer LISP header is an IPv4 or IPv6 header,
differentiated forwarding can be supported naturally. Equally, as
LISP uses IP/UDP as a transport, multipath over LAG and ECMP in the
underlay are naturally supported, through the entropy introduced in
the UDP header by selecting per flow source UDP port numbers. A LISP
based NVO3 network can work in both uniform and pipe models <xref
target="RFC2983"/> and fully supports ECN marking as per <xref
target="RFC6040"/> .</t>
<t>As it does for L3 services, the LISP control plane replaces the
use of dynamic data plane learning (Flood-and-Learn) for unicast
traffic for L2 services. Packet replication in the underlay network
to support L2 broadcast, unknown unicast (optional, as all
MAC-address are learned by the control plane) and multicast L2 and
L3 overlay services can be done by:</t>
<t><list style="symbols">
<t>Ingress replication, which reduces the need for multicast in
the NVO3 underlay to zero.</t>
<t>Use of underlay multicast trees. These trees can be
aggregated globally, or per tenant (rather than per VNI).</t>
</list></t>
<t><xref target="RFC6831"/> and <xref
target="I-D.farinacci-lisp-mr-signaling"/>specifies how to map a
multicast flow in the EID space during distribution tree setup and
packet delivery in the underlay network. LISP, being an IP based
map-and-encap protocol, does not require any specific data plane
functionality to make this work.</t>
<t>LISP interworking is described in <xref target="RFC6832"/> and
fully supports connectivity to the internet or VPN gateways through
the use of Proxy xTR's.</t>
<t>LISP, being an IP based protocol, supports ICMP-based MTU Path
Discovery <xref target="RFC1191"/> , <xref target="RFC1981"/>as well
as extended MTU Path Discovery techniques <xref target="RFC4821"/>.
LISP also supports a stateless and stateful way of dealing with
Large Encapsulated packets, see section 5.4 of <xref
target="RFC6830"/>.</t>
<t>Multi-homing is handled in the control plane, by allowing the
LISP mapping system to have multiple RLOC entries for every EID,
allowing the ITR to load balance across both ETR's. xTRs register a
'LISP site id' to the mapping system when they come online. When the
LISP mapping system receives a registration for a given EID from a
certain xTRs, it will install that EID entry pointing to all the
RLOCs/xTR that have the same site-id. By performing LAG across
multiple xTRs, multi-homing can be provided for the access or
virtual switch that connects the TSs.</t>
<t>OAM can be performed across LISP in the same way as OAM is
performed over IP routed, or Ethernet L2 switched environments.</t>
</section>
<section title="LISP with Generic Protocol Extension (LISP-GPE)">
<t><xref target="I-D.lewis-lisp-gpe"/> introduces multiprotocol
support for LISP, by extending the LISP header, as shown in <xref
target="lisp-gpe-header"/> .</t>
<t><figure align="center" anchor="lisp-gpe-header"
title="LISP with Generic Protocol Extension Header">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = xxxx | Dest Port = 4341 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|R|R| Reserved |Nonce/Map-Version/Protocol-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>A Protocol Bit (P-bit) is introduced, that when set, allows the
insertion of a 16-bit Protocol Type. The UDP destination port number
is 4341 for all protocol types.</t>
<t>Although the use of Nonce and Map-versioning are not allowed
simultaneously with Protocol Type with this deployment, all of the
solutions to the requirements described in <xref
target="native-lisp-dp"/> are exactly the same with this data plane
encapsulation in an NVO3 context.</t>
</section>
<section title="VxLAN-GPE">
<t><xref target="I-D.quinn-vxlan-gpe"/> extends the VXLAN
encapsulation with a Protocol Type, by introducing a Protocol Bit
(P-bit) and a 16-bit Protocol Type in the VXLAN header, see <xref
target="vxlan-gpe-header"/>. Note that this data plane encapsulation
is very similar to LISP-GPE, when used in an NVO3 context.</t>
<t><figure align="center" anchor="vxlan-gpe-header"
title="VXLAN with Generic Protocol Extension">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = xxxx | Dest Port = 4789 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R|I|P|R|R| Reserved | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>All of the solutions to the requirements described in <xref
target="native-lisp-dp"/> are exactly the same with this data plane
encapsulation.</t>
</section>
<section title="L2 only solutions such as VxLAN and nvGRE">
<t>The LISP control plane can be leveraged to offer control plane
learning for MAC Addresses for both the VXLAN <xref
target="I-D.mahalingam-dutt-dcops-vxlan"/>, as well as NVGRE <xref
target="I-D.sridharan-virtualization-nvgre"/>. However, this
solution offers sub-optimal support and hence will not be looked
into further.</t>
</section>
</section>
<section title="NVO3 control plane requirements and LISP">
<t>This section maps the NVO3 NVE to NVA control plane <xref
target="I-D.ietf-nvo3-nve-nva-cp-req"/>requirements to the LISP
control plane.</t>
<section title="Inner to Outer Address Mapping">
<t>The LISP control plane, through the use of a Mapping service,
provides inner to outer address mapping.</t>
<t>TS EIDs are registered to the LISP Mapping service by LISP ETRs
within the context of a LISP instance ID, (i.e An NVO3 VNI).</t>
<t>A LISP based NVE will check its local cache if it needs to send a
packet across the overlay. If there is a cache miss, it will request
the EID to RLOC mapping from the LISP Mapping service. If there is a
cache hit, it will use the local EID to RLOC mapping.</t>
<t>Cache entries are aged out when no traffic is being sent to those
EIDs. The LISP control plane has ways of refreshing the local cache
after the destination EID has moved to another RLOC. For more
information, see <xref target="vm-mobility"/> and <xref
target="RFC6830"/></t>
</section>
<section title="Underlying network Multi-Destination Delivery">
<t>LISP supports delivering L2 and L3 multi-destination packets,
independent of the underlying network multicast capabilities.</t>
<t><xref target="RFC6831"/>, <xref
target="I-D.farinacci-lisp-mr-signaling"/> , more specifically
section 6, describes how the LISP Control Plane is used by NVEs/ETRs
to join a given EID multicast group by sending LISP Map-Requests
rather than PIM Joins. Joining can be triggered by the receipt of a
PIM or IGMP join in the EID space. In the case of a L2 overlay
configuration on the NVE, the join is static.</t>
<t>In case the NVE/ETR is not multicast capable the ETR unicast RLOC
will be registered, and will be added to the existing RLOC set for
that given multicast EID, and the Map-Reply will contain the ITR
from which the ETR wants to replicate. LISP ITRs will retrieve this
list of ETRs from the Mapping System upon a Map-Request and will use
this as a replication list.</t>
<t>In case the underlying network is multicast capable the Map-Reply
will contain the multicast RLOC, which will be joined via PIM
subsequently. All this state is stored on the Mapping system, or in
the xTR caches per IID/VNI. In case ingress replication is deemed
unscaleable, <xref target="I-D.farinacci-lisp-te"/> can be used,
allowing a Re-encapsulating Tunnel Router (RTR) to be used as a
distribution server to replicate to all the NVEs.</t>
<t>It is also important to point out that, in a unified L2/L3 NVE
deployment, all IP traffic will get sent across the L3 overlay, and
that ARP and ND packets are not handled using flooding.</t>
<t>In case non-IP traffic needs to be supported, L2 EIDs only need
to use multicast or ingress replication for broadcast and multicast,
as unicast flows are handled by the LISP control plane. This
significantly reduces the multicast or ingress replication load.</t>
</section>
<section anchor="VN-connect" title="VN connect/disconnect">
<t>We assume that a provisioning framework will be responsible for
provisioning end systems (e.g. VMs) in each data center. The
provisioning system configures each end system with an Ethernet/IEEE
802 MAC address and/or IP addresses and provisions the NVE with
other end system specific attributes such as VLAN information, and
TS/VLAN to VNI mapping information. LISP does not introduce new
addressing requirements for end systems.</t>
<t>The provisioning infrastructure is also responsible to provide a
network attach function, that notifies the NVE (the LISP site ETR)
that the end system is attached to a given virtual network
(identified by its VNI/IID) and that the end system is identified,
within that virtual network, by a given Ethernet/IEEE 802 MAC
address.</t>
<t>The LISP framework does not include mechanisms to provision the
local NVE with the appropriate Tenant Instance for each Tenant
Systems. Other protocols, such as VDP (in IEEE P802.1Qbg), should be
used to implement a network attach/detach function, besides using
link-up events for non-virtual end-systems. More-over it is quite
common for devices to be able to 'sense' new tenant end-systems
dynamically by tracking new mac addresses and IP addresses in case a
VDP or link-up event cant be relied upon.</t>
<t>The LISP control plane can take advantage of such a network
attach/detach function or the discovery of new MAC/IP addresses to
trigger the registration of a Tenant System to the Mapping System.
This is particularly helpful to handle mobility across the DC of the
Tenant System.</t>
<t>Upon notification of end system network attach, the ETR sends a
LISP Map-Register to the Mapping System. The Map-Register includes
the EID and RLOCs of the LISP site. The EID-to-RLOC mapping is now
available, via the Mapping System Infrastructure, to other LISP
sites that are hosting end systems that belong to the same
tenant.</t>
<t>For more details on end system registration see <xref
target="RFC6833"/>.</t>
</section>
<section title="VN name to VN ID Mapping">
<t>The LISP Control Plane uses the Instance ID to identify the NVI.
The VN Name to VNI mapping can be performed by the NVE as a result
of local provisioning. Also, using LISP LCAF , it is possible to
store ASCII Names in the Mapping Database, which can allow the
system to resolve a VN Name to an IID/VNI.</t>
</section>
<section title="LISP Control Plane Characteristics in an NVO3 context">
<t>LISP is a Control Plane solution that can scale very well to the
NVO3 requirements:</t>
<t><list style="numbers">
<t>LISP ETRs register destination EIDs into the LISP Mapping
System. LISP ITRs pull destination EIDs from the LISP Mapping
System and cache them for as long as traffic is being sent to
those destinations. Hence a LISP Based NVE is only holding state
for the active TS to TS flows, and only for the NVIs that are
configured on those NVEs.</t>
<t>The LISP Control Plane is fast to acquire the needed state
for a given destination through issuing a single
Map-Request.</t>
<t>When an ETR (lets say ETR1) detects an EID it will also
register this EID to the Mapping system. If that EID has moved
from another ETR (lets say ETR2), it will update the Mapping
system with a Map-Notify saying to no longer forward packets to
it, and will install a 'non-local' entry in the forwarding
table. If an ITR has not updated its map-cache, and therefor
sends a packet to ETR2, ETR will sent a Map-Notify directly to
the ITR, updating its local cache. For further information see
<xref target="vm-mobility"/></t>
<t>As LISP support virtualization, the NVE running the LISP
Control Plane will only be maintaining state for the Tenants
VNIs that are configured on it.</t>
<t>Through leveraging the LISP DDT-based Mapping system <xref
target="I-D.ietf-lisp-ddt"/>, the necessary scaling can be
achieved. The LISP DDT hierarchy can be based on address family,
address family prefix, and IID, and scales in a very similar way
as DNS.</t>
<t>The solution described in this document does not make use of
multiple protocols, and hence is low in complexity.</t>
<t>Through the use of the LISP LCAF <xref
target="I-D.ietf-lisp-lcaf"/> , extensibility is achieved. It is
possible to add new address families (the MAC address family is
the proof point). The LCAF format also allows lookups on a
generic Key. This Key can be an identifier to an ACL or policy.
A combination of multiple keys can be achieved by doing
recursive lookups, where EID attributes are used as keys for a
subsequent lookup. LCAF allows backwards compatibility between
systems that use different LCAF implementations.</t>
<t>As the state is maintained in the LISP Mapping system acting
as an NVA, adding another NVE/xTR to the network does not
require any changes on existing NVEs.</t>
<t>LISP does not rely on Multicast in the underlay, while
preserving the same Control Plane characteristics regardless of
underlay multicast capability.</t>
<t><xref target="I-D.barkai-lisp-nfv"/>documents one
implementation of how the LISP Mapping System (NVA) can be
programmed to create inner to outer address mappings. The LISP
Control Plane will inform the xTR/NVE that hosts have moved, and
if packets are attracted to those NVEs because of stale cache
entries on other ITRs, packets will be routed to the right
location, and the NVE will send a Solicited Map-Reply back to
the ITR, clearing its cache, after which the ITR will request a
new mapping. Obviously NVEs will be able to create inner to
outer address mappings without the use of an orchestration
solution.</t>
<t>See <xref target="security"/></t>
</list></t>
</section>
</section>
<section title="NVO3 OAM Requirements and LISP">
<t>TBD</t>
</section>
<section title="NVO3 Management Plane Requirements and LISP">
<t>TBD</t>
</section>
<section title="Summary">
<t>The LISP Control Plane, makes a very good choice to implement NVO3
services due to the fact that it is agnostic to EID address families,
and the fact that it provides an NVA in the form of the LISP Map
Server with cache optimizations based on the pull-based LISP Map Cache
on the LISP xTRs . The LISP control plane can be deployed across a set
of different dataplane options as well. The usage of a unified L2 and
L3 overlay , with the appropriate set of registrations in the LISP
Mapping system, is recommended because of its optimal forwarding,
scaling and IP centric characteristics, while supporting non-IP
traffic as well.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>The security requirements for a NVO3 Control Plane are defined in
<xref target="I-D.ietf-nvo3-security-requirements"/> . More
specifically, seven requirements are defined (REQ 1 to REQ 7) for
NVE-NVA Control Plane (Network Virtualization Edge to Network
Virtualization Authority Control Plane) and two requirements (REQ 8 and
REQ 9) for NVA-NVA Control Plane (Network Virtualization Authority to
Network Virtualization Authority Control Plane). <xref target="sectab"/>
provides a summary of which document defines LISP Control Plane
mechanisms that allow to satisfy each specific requirement.</t>
<texttable anchor="sectab"
title="NVO3 vs LISP CP Security Requirements">
<ttcol align="left">NVO3 Req.</ttcol>
<ttcol align="left">LISP Control Plane Documents</ttcol>
<c>REQ 1</c>
<c><xref target="RFC6833"/> <xref target="I-D.ietf-lisp-sec"/></c>
<c/>
<c/>
<c>REQ 2</c>
<c><xref target="RFC6833"/> <xref target="I-D.ietf-lisp-sec"/></c>
<c>REQ 3</c>
<c>Not mandatory[1]</c>
<c>REQ 4</c>
<c><xref target="RFC6833"/> <xref target="I-D.ietf-lisp-sec"/></c>
<c>REQ 5</c>
<c><xref target="RFC6833"/> <xref target="I-D.ietf-lisp-sec"/></c>
<c>REQ 6</c>
<c><xref target="RFC6830"/> <xref target="RFC6833"/></c>
<c>REQ 7</c>
<c><xref target="RFC6830"/>[2]</c>
<c>REQ 8</c>
<c><xref target="I-D.ietf-lisp-ddt"/></c>
<c>REQ 9</c>
<c>Does not apply[3]</c>
<postamble>[1] The requirement uses MAY as for <xref
target="RFC2119"/> terminology. [2] Amplification attacks can be
avoided by careful design of the mappings. [3] The existing LISP
Control Planes do not use multicast messages.</postamble>
</texttable>
<t>Security mechanisms to protect the LISP Map-Register messages are
defined in <xref target="RFC6833"/>.</t>
<t><xref target="RFC6830"/> and <xref target="RFC6833"/> describe how to
send control packet with limited frequencies.</t>
<t><xref target="I-D.ietf-lisp-sec"/> defines a set of security
mechanisms that provide origin authentication, integrity and anti-replay
protection to LISP's EID-to-RLOC mapping data conveyed via mapping
lookup process. <xref target="I-D.ietf-lisp-sec"/> also enables
verification of authorization on EID-prefix claims in Map-Reply
messages.</t>
<t>The security of the Mapping System Infrastructure (NVA) depends on
the particular mapping database used. The <xref
target="I-D.ietf-lisp-ddt"/> specification, as an example, defines a
public-key based mechanism that provides origin authentication and
integrity protection to the LISP DDT protocol.</t>
<t/>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t/>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-overlay-problem-statement.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-dataplane-requirements.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-nve-nva-cp-req.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-security-requirements.xml'?>
<?rfc include='reference.RFC.6830'?>
<?rfc include='reference.RFC.6831'?>
<?rfc include='reference.RFC.6832'?>
<?rfc include='reference.RFC.6833'?>
<?rfc include='reference.RFC.6836'?>
<?rfc include='reference.RFC.2983'?>
<?rfc include='reference.RFC.6040'?>
<?rfc include='reference.RFC.1191'?>
<?rfc include='reference.RFC.1981'?>
<?rfc include='reference.RFC.4821'?>
<?rfc include='reference.RFC.4861'?>
<?rfc include='reference.RFC.3971'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.maino-nvo3-lisp-cp.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.smith-lisp-layer2.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mahalingam-dutt-dcops-vxlan.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.sridharan-virtualization-nvgre.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-lcaf.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-framework.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-ddt.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-sec.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lewis-lisp-gpe.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.quinn-vxlan-gpe.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.barkai-lisp-nfv.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.farinacci-lisp-mr-signaling.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.farinacci-lisp-te.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-kompella-nvo3-server2nve-02.xml'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:00:54 |