Internet DRAFT - draft-hertoghs-nvo3-lisp-controlplane-unified
draft-hertoghs-nvo3-lisp-controlplane-unified
Networking Virtualization Overlays Working Group Y. Hertoghs
Internet-Draft F. Maino
Intended status: Informational V. Moreno
Expires: January 20, 2015 M. Smith
Cisco Systems
D. Farinacci
lispers.net
L. Iannone
Telecom ParisTech
July 21, 2014
A Unified LISP Mapping Database for L2 and L3 Network Virtualization
Overlays
draft-hertoghs-nvo3-lisp-controlplane-unified-02
Abstract
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.
Requirements Language
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 RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 20, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
Hertoghs, et al Expires January, 2015 [Page 1]
Internet-Draft Unified LISP for NVO3 July 2014
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. NVO3 Framework and LISP . . . . . . . . . . . . . . . . . . . 4
3.1. NVO3 Generic Reference Model . . . . . . . . . . . . . . . 4
3.2. NVE Reference Model . . . . . . . . . . . . . . . . . . . 4
3.2.1. Types of NVE's . . . . . . . . . . . . . . . . . . . . 4
3.2.1.1. L2 only NVE . . . . . . . . . . . . . . . . . . . 5
3.2.1.2. L3 only NVE . . . . . . . . . . . . . . . . . . . 5
3.2.1.3. Unified L2/L3 NVE . . . . . . . . . . . . . . . . 5
3.2.2. Multihoming aspects . . . . . . . . . . . . . . . . . 7
3.2.3. External connectivity aspects . . . . . . . . . . . . 7
3.2.4. Optimal Forwarding aspects . . . . . . . . . . . . . . 8
3.2.5. VM Mobility aspects . . . . . . . . . . . . . . . . . 8
3.2.5.1. VM Mobility at L2 . . . . . . . . . . . . . . . . 9
3.2.5.2. VM Mobility at L3 . . . . . . . . . . . . . . . . 9
3.3. LISP dataplane options and NVO3 dataplane requirements . . 12
3.3.1. Native LISP Data Plane . . . . . . . . . . . . . . . . 12
3.3.2. LISP with Generic Protocol Extension (LISP-GPE) . . . 14
3.3.3. VxLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 15
3.3.4. L2 only solutions such as VxLAN and nvGRE . . . . . . 15
3.4. NVO3 control plane requirements and LISP . . . . . . . . . 15
3.4.1. Inner to Outer Address Mapping . . . . . . . . . . . . 15
3.4.2. Underlying network Multi-Destination Delivery . . . . 16
3.4.3. VN connect/disconnect . . . . . . . . . . . . . . . . 16
3.4.4. VN name to VN ID Mapping . . . . . . . . . . . . . . . 17
3.4.5. LISP Control Plane Characteristics in an NVO3 context 17
3.5. NVO3 OAM Requirements and LISP . . . . . . . . . . . . . . 19
3.6. NVO3 Management Plane Requirements and LISP . . . . . . . 19
3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 19
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
Hertoghs, et al Expires January, 2015 [Page 2]
Internet-Draft Unified LISP for NVO3 July 2014
The purpose of this draft is to provide a mapping between the Network
Virtualization over L3 (NVO3) framework [I-D.ietf-nvo3-framework] and
the Locator/ID Separation Protocol (LISP) [RFC6830], and in
particular how LISP components map to the reference models defined
therein. This document extends the scope of[I-D.maino-nvo3-lisp-cp]
to cover the case of a unified overlay that includes L2 and L3
services.
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:
1. A Data Plane that specifies how Endpoint Identifiers (EIDs) are
encapsulated in Routing Locators (RLOCs), and
2. A Control Plane that specifies the interfaces to the LISP Mapping
System [RFC6833]. The LISP Mapping system provides the mapping
between EIDs and RLOCs.
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).
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.
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.
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.
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[I-D.ietf-nvo3-dataplane-requirements].
Hertoghs, et al Expires January, 2015 [Page 3]
Internet-Draft Unified LISP for NVO3 July 2014
The document continues to lay out how the NVO3 control plane
requirements [I-D.ietf-nvo3-nve-nva-cp-req] are addressed.
Finally this document will provide security considerations in Section
5
2. Definition of Terms
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.
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 [I-D.ietf-nvo3-framework].
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
[RFC6830].
3. NVO3 Framework and LISP
3.1. NVO3 Generic Reference Model
[I-D.maino-nvo3-lisp-cp] provides a mapping of the NVO3 generic
reference model [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 .
3.2. NVE Reference Model
The LISP NVE Reference Model is described in [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 Section 3.4.3.
3.2.1. Types of NVE's
[RFC6830] is defined as a L3 NVE, and it can be enhanced to support
L2 NVEs.
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.
Hertoghs, et al Expires January, 2015 [Page 4]
Internet-Draft Unified LISP for NVO3 July 2014
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.
3.2.1.1. L2 only NVE
[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
[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.
The frame format defined in [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
[I-D.ietf-lisp-lcaf].
The LISP control plane is extensible, and can support non-LISP data
path encapsulations such as NVGRE [I-D.sridharan-virtualization-
nvgre], or other encapsulations that provide support for network
virtualization.
3.2.1.2. L3 only NVE
LISP is defined as a virtualized IP routing and forwarding service in
[RFC6830], and as such can be used to provide L3 NVE services.
3.2.1.3. Unified L2/L3 NVE
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 [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.
Implementing an NVE with a unified L2 and L3 overlay support is
beneficial for multiple reasons:
Hertoghs, et al Expires January, 2015 [Page 5]
Internet-Draft Unified LISP for NVO3 July 2014
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.
Secondarily, when all the TS IP and MAC addresses are registered with
the NVA/LISP Mapping system, optimisations in ARP and ND [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').
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.
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:
o 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.
o 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.
o 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/
Hertoghs, et al Expires January, 2015 [Page 6]
Internet-Draft Unified LISP for NVO3 July 2014
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.
There are various options to provide unified L2 and L3 support for
LISP in the data path.
[I-D.smith-lisp-layer2] extends LISP to support MAC addresses as
EIDs, and can be used in combination with [RFC6830], using the
destination UDP port in the outer LISP header for disambiguation.
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 [I-D.lewis-lisp-
gpe], and [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 [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 [RFC6830], and their use is less
relevant in DC applications.
The remainder of this document assumes a unified L2/L3 NVE deployment
model.
3.2.2. Multihoming aspects
If the TSes are co-located with the xTR/NVE function, no support for
multi-homing is needed.
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.
3.2.3. External connectivity aspects
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.
In case the gateway device handles connectivity to VPNs or the
Hertoghs, et al Expires January, 2015 [Page 7]
Internet-Draft Unified LISP for NVO3 July 2014
Internet, LISP interworking will be employed at the gateway device as
per [RFC6832].
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.
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.
3.2.4. Optimal Forwarding aspects
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.
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.
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.
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.
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).
3.2.5. VM Mobility aspects
This section shows how the LISP control plane deals with VM mobility
when end systems are migrated from one NVE/DC to another.
Hertoghs, et al Expires January, 2015 [Page 8]
Internet-Draft Unified LISP for NVO3 July 2014
We'll assume that a signaling protocol, as described in [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.
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.
3.2.5.1. VM Mobility at L2
VM mobility at L2 is described in [I-D.maino-nvo3-lisp-cp]
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.
3.2.5.2. VM Mobility at L3
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.
Hertoghs, et al Expires January, 2015 [Page 9]
Internet-Draft Unified LISP for NVO3 July 2014
,---------.
,' `.
(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>
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.
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:
o 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.
o 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.
Hertoghs, et al Expires January, 2015 [Page 10]
Internet-Draft Unified LISP for NVO3 July 2014
Assume the scenario described in Figure 1. Also assume that for the
sake of this discussion, the VMs do not send out traffic that needs
treatment by an L2 overlay.
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.
The process of migrating end system W from data center A to data
center B is initiated.
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.
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.
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.
The remote ITRs that were corresponding with end system W during the
migration will keep sending packets to ETR A.
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.
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.
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.
Hertoghs, et al Expires January, 2015 [Page 11]
Internet-Draft Unified LISP for NVO3 July 2014
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.
3.3. LISP dataplane options and NVO3 dataplane requirements
This section maps the NVO3 data plane requirements [I-D.ietf-nvo3
-dataplane-requirements] to the various options available.
3.3.1. Native LISP Data Plane
Figure 2shows the LISP header defined in the LISP specification
[RFC6830]. The UDP and LISP headers are shown below for reference.
For header fields description see section 5.3 of [RFC6830].
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [I-D
.smith-lisp-layer2].
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.
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
Hertoghs, et al Expires January, 2015 [Page 12]
Internet-Draft Unified LISP for NVO3 July 2014
bridge domain instantiates the L2 Specific VNI. The bridge domain
also connects to a virtual routed port, which instantiates the L3
specific VNI.
A L2 VNI provides an emulated Ethernet Multipoint service through the
use of the LISP control plane, where it registers MAC addresses as
EIDs.
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 [RFC6831] or through ingress replication to
the list of participating NVEs in that NVI, and therefore is loop-
free.
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.
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.
The LISP header performs the function of the NVO3 overlay header.
Through using the LISP control plane, the egress NVE can be looked
up.
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 [RFC2983] and fully
supports ECN marking as per [RFC6040] .
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:
o Ingress replication, which reduces the need for multicast in the
NVO3 underlay to zero.
o Use of underlay multicast trees. These trees can be aggregated
globally, or per tenant (rather than per VNI).
Hertoghs, et al Expires January, 2015 [Page 13]
Internet-Draft Unified LISP for NVO3 July 2014
[RFC6831] and [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.
LISP interworking is described in [RFC6832] and fully supports
connectivity to the internet or VPN gateways through the use of Proxy
xTR's.
LISP, being an IP based protocol, supports ICMP-based MTU Path
Discovery [RFC1191] , [RFC1981]as well as extended MTU Path Discovery
techniques [RFC4821]. LISP also supports a stateless and stateful
way of dealing with Large Encapsulated packets, see section 5.4 of
[RFC6830].
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.
OAM can be performed across LISP in the same way as OAM is performed
over IP routed, or Ethernet L2 switched environments.
3.3.2. LISP with Generic Protocol Extension (LISP-GPE)
[I-D.lewis-lisp-gpe] introduces multiprotocol support for LISP, by
extending the LISP header, as shown in Figure 3 .
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Hertoghs, et al Expires January, 2015 [Page 14]
Internet-Draft Unified LISP for NVO3 July 2014
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 Section 3.3.1 are exactly
the same with this data plane encapsulation in an NVO3 context.
3.3.3. VxLAN-GPE
[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 Figure 4. Note that this data plane
encapsulation is very similar to LISP-GPE, when used in an NVO3
context.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All of the solutions to the requirements described in Section 3.3.1
are exactly the same with this data plane encapsulation.
3.3.4. L2 only solutions such as VxLAN and nvGRE
The LISP control plane can be leveraged to offer control plane
learning for MAC Addresses for both the VXLAN [I-D.mahalingam-dutt-
dcops-vxlan], as well as NVGRE [I-D.sridharan-virtualization-nvgre].
However, this solution offers sub-optimal support and hence will not
be looked into further.
3.4. NVO3 control plane requirements and LISP
This section maps the NVO3 NVE to NVA control plane [I-D.ietf-nvo3
-nve-nva-cp-req]requirements to the LISP control plane.
3.4.1. Inner to Outer Address Mapping
The LISP control plane, through the use of a Mapping service,
Hertoghs, et al Expires January, 2015 [Page 15]
Internet-Draft Unified LISP for NVO3 July 2014
provides inner to outer address mapping.
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).
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.
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 Section 3.2.5 and [RFC6830]
3.4.2. Underlying network Multi-Destination Delivery
LISP supports delivering L2 and L3 multi-destination packets,
independent of the underlying network multicast capabilities.
[RFC6831], [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.
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.
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, [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.
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.
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.
3.4.3. VN connect/disconnect
Hertoghs, et al Expires January, 2015 [Page 16]
Internet-Draft Unified LISP for NVO3 July 2014
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.
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.
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.
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.
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.
For more details on end system registration see [RFC6833].
3.4.4. VN name to VN ID Mapping
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.
3.4.5. LISP Control Plane Characteristics in an NVO3 context
LISP is a Control Plane solution that can scale very well to the NVO3
requirements:
Hertoghs, et al Expires January, 2015 [Page 17]
Internet-Draft Unified LISP for NVO3 July 2014
1. 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.
2. The LISP Control Plane is fast to acquire the needed state for a
given destination through issuing a single Map-Request.
3. 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 Section 3.2.5
4. 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.
5. Through leveraging the LISP DDT-based Mapping system [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.
6. The solution described in this document does not make use of
multiple protocols, and hence is low in complexity.
7. Through the use of the LISP LCAF [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.
8. 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.
9. LISP does not rely on Multicast in the underlay, while preserving
the same Control Plane characteristics regardless of underlay
multicast capability.
Hertoghs, et al Expires January, 2015 [Page 18]
Internet-Draft Unified LISP for NVO3 July 2014
10. [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.
11. See Section 5
3.5. NVO3 OAM Requirements and LISP
TBD
3.6. NVO3 Management Plane Requirements and LISP
TBD
3.7. Summary
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.
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
The security requirements for a NVO3 Control Plane are defined in
[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). Table 1 provides a summary
of which document defines LISP Control Plane mechanisms that allow to
satisfy each specific requirement.
Hertoghs, et al Expires January, 2015 [Page 19]
Internet-Draft Unified LISP for NVO3 July 2014
+-----------+-------------------------------+
| NVO3 Req. | LISP Control Plane Documents |
+-----------+-------------------------------+
| REQ 1 | [RFC6833] [I-D.ietf-lisp-sec] |
| REQ 2 | [RFC6833] [I-D.ietf-lisp-sec] |
| REQ 3 | Not mandatory[1] |
| REQ 4 | [RFC6833] [I-D.ietf-lisp-sec] |
| REQ 5 | [RFC6833] [I-D.ietf-lisp-sec] |
| REQ 6 | [RFC6830] [RFC6833] |
| REQ 7 | [RFC6830][2] |
| REQ 8 | [I-D.ietf-lisp-ddt] |
| REQ 9 | Does not apply[3] |
+-----------+-------------------------------+
[1] The requirement uses MAY as for [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.
Security mechanisms to protect the LISP Map-Register messages are
defined in [RFC6833].
[RFC6830] and [RFC6833] describe how to send control packet with
limited frequencies.
[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. [I-D
.ietf-lisp-sec] also enables verification of authorization on EID-
prefix claims in Map-Reply messages.
The security of the Mapping System Infrastructure (NVA) depends on
the particular mapping database used. The [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.
6. Acknowledgements
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[I-D.barkai-lisp-nfv]
sbarkai@gmail.com, s., Farinacci, D., Meyer, D., Maino,
F., Ermagan, V., Rodriguez-Natal, A. and A. Cabellos-
Aparicio, "LISP Based FlowMapping for Scaling NFV",
Internet-Draft draft-barkai-lisp-nfv-04, February 2014.
Hertoghs, et al Expires January, 2015 [Page 20]
Internet-Draft Unified LISP for NVO3 July 2014
[I-D.farinacci-lisp-mr-signaling]
Farinacci, D. and M. Napierala, "LISP Control-Plane
Multicast Signaling", Internet-Draft draft-farinacci-lisp-
mr-signaling-04, March 2014.
[I-D.farinacci-lisp-te]
Farinacci, D., Kowal, M. and P. Lahiri, "LISP Traffic
Engineering Use-Cases", Internet-Draft draft-farinacci-
lisp-te-06, March 2014.
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V. and A. Jain, "LISP
Delegated Database Tree", Internet-Draft draft-ietf-lisp-
ddt-01, March 2013.
[I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D. and J. Snijders, "LISP Canonical
Address Format (LCAF)", Internet-Draft draft-ietf-lisp-
lcaf-05, May 2014.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A. and D.
Saucez, "LISP-Security (LISP-SEC)", Internet-Draft draft-
ietf-lisp-sec-06, April 2014.
[I-D.ietf-nvo3-dataplane-requirements]
Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L. and
B. Khasnabish, "NVO3 Data Plane Requirements", Internet-
Draft draft-ietf-nvo3-dataplane-requirements-03, April
2014.
[I-D.ietf-nvo3-framework]
Lasserre, M., Balus, F., Morin, T., Bitar, N. and Y.
Rekhter, "Framework for DC Network Virtualization",
Internet-Draft draft-ietf-nvo3-framework-09, July 2014.
[I-D.ietf-nvo3-nve-nva-cp-req]
Kreeger, L., Dutt, D., Narten, T. and D. Black, "Network
Virtualization NVE to NVA Control Protocol Requirements",
Internet-Draft draft-ietf-nvo3-nve-nva-cp-req-02, April
2014.
[I-D.ietf-nvo3-overlay-problem-statement]
Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L. and
M. Napierala, "Problem Statement: Overlays for Network
Virtualization", Internet-Draft draft-ietf-nvo3-overlay-
problem-statement-04, July 2013.
[I-D.ietf-nvo3-security-requirements]
Hartman, S., Zhang, D. and M. Wasserman, "Security
Requirements of NVO3", Internet-Draft draft-ietf-nvo3
-security-requirements-02, January 2014.
Hertoghs, et al Expires January, 2015 [Page 21]
Internet-Draft Unified LISP for NVO3 July 2014
[I-D.kompella-nvo3-server2nve]
Kompella, K., Rekhter, Y., Morin, T. and D. Black,
"Signaling Virtual Machine Activity to the Network
Virtualization Edge", Internet-Draft draft-kompella-
nvo3-server2nve-02, April 2013.
[I-D.lewis-lisp-gpe]
Lewis, D., Agarwal, P., Kreeger, L., Maino, F., Quinn, P.,
Smith, M. and N. Yadav, "LISP Generic Protocol Extension",
Internet-Draft draft-lewis-lisp-gpe-02, July 2014.
[I-D.mahalingam-dutt-dcops-vxlan]
Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M. and C. Wright, "VXLAN: A
Framework for Overlaying Virtualized Layer 2 Networks over
Layer 3 Networks", Internet-Draft draft-mahalingam-dutt-
dcops-vxlan-09, April 2014.
[I-D.maino-nvo3-lisp-cp]
Maino, F., Ermagan, V., Hertoghs, Y., Farinacci, D. and M.
Smith, "LISP Control Plane for Network Virtualization
Overlays", Internet-Draft draft-maino-nvo3-lisp-cp-03,
October 2013.
[I-D.quinn-vxlan-gpe]
Quinn, P., Agarwal, P., Fernando, R., Lewis, D., Kreeger,
L., Smith, M., Yadav, N., Yong, L., Xu, X., Elzur, U. and
P. Garg, "Generic Protocol Extension for VXLAN", Internet-
Draft draft-quinn-vxlan-gpe-03, July 2014.
[I-D.smith-lisp-layer2]
Smith, M., Dutt, D., Farinacci, D. and F. Maino, "Layer 2
(L2) LISP Encapsulation Format", Internet-Draft draft-
smith-lisp-layer2-03, September 2013.
[I-D.sridharan-virtualization-nvgre]
Sridharan, M., Greenberg, A., Wang, Y., Garg, P.,
Venkataramiah, N., Duda, K., Ganga, I., Lin, G., Pearson,
M., Thaler, P. and C. Tumuluri, "NVGRE: Network
Virtualization using Generic Routing Encapsulation",
Internet-Draft draft-sridharan-virtualization-nvgre-04,
February 2014.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
Hertoghs, et al Expires January, 2015 [Page 22]
Internet-Draft Unified LISP for NVO3 July 2014
[RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January
2013.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J. and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, January 2013.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D. and V. Fuller,
"Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, January
2013.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D. and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013.
Authors' Addresses
Yves Hertoghs
Cisco Systems
6a De Kleetlaan
Diegem, 1831
Belgium2
Phone: +32-2778-435
Email: yves@cisco.com
Fabio Maino
Cisco Systems
170 Tasman Drive
San Jose, California 95134
USA
Email: fmaino@cisco.com
Hertoghs, et al Expires January, 2015 [Page 23]
Internet-Draft Unified LISP for NVO3 July 2014
Victor Moreno
Cisco Systems
170 Tasman Drive
San Jose, California 95134
USA
Email: vimoreno@cisco.com
Michael Smith
Cisco Systems
170 Tasman Drive
San Jose, California 95134
USA
Email: michsmit@cisco.com
Dino Farinacci
lispers.net
Email: farinacci@gmail.com
Luigi Iannone
Telecom ParisTech
Email: luigi.iannone@telecom-paristech.fr
Hertoghs, et al Expires January, 2015 [Page 24]
