Internet DRAFT - draft-moreno-lisp-datacenter-deployment
draft-moreno-lisp-datacenter-deployment
Network Working Group V. Moreno
Internet-Draft F. Maino
Intended status: Experimental D. Lewis
Expires: August 18, 2014 M. Smith
S. Sinha
Cisco Systems
February 14, 2014
LISP Deployment Considerations in Data Center Networks
draft-moreno-lisp-datacenter-deployment-00
Abstract
This document discusses scenarios and implications of LISP based
overlay deployment in the Data Center. The alternatives for
topological location of the different LISP functions are analyzed in
the context of the most prevalent Data Center topologies. The role
and deployment of LISP in the Wide Area Network and Data Center
Interconnection are also discussed.
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 [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 August 18, 2014.
Moreno, et al. Expires August 18, 2014 [Page 1]
Internet-Draft LISP Data Center Deployment February 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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. LISP in the Data Center . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Data Center Network Reference Topologies . . . . . . . . . . 4
4. LISP Deployment in Data Center Fabric Topologies . . . . . . 6
4.1. xTR Topological Placement . . . . . . . . . . . . . . . . 7
4.1.1. vLeaf nodes as xTRs . . . . . . . . . . . . . . . . . 7
4.1.2. Disjoint xTR function: vLeaf to Leaf-proxy function
separation . . . . . . . . . . . . . . . . . . . . . 7
4.1.3. Full LISP xTR function at Leaf node . . . . . . . . . 8
4.2. Mapping System topological placement . . . . . . . . . . 9
4.2.1. Map-Server/Resolver out of band . . . . . . . . . . . 9
4.2.2. Map-Server/Resolver in-line . . . . . . . . . . . . . 10
5. LISP deployment in the DC WAN and Data Center Interconnect . 12
5.1. Fabric-WAN handoff: topology, peering and administrative
delineation . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Two-tier Fabric-WAN normalized handoff . . . . . . . 13
5.1.2. Single-tier Fabric-WAN handoff . . . . . . . . . . . 14
5.2. Fabric to WAN interoperability scenarios . . . . . . . . 14
5.2.1. LISP Fabric to LISP WAN interoperability with common
RLOC space . . . . . . . . . . . . . . . . . . . . . 14
5.2.2. LISP Fabric to LISP WAN interoperability with
disjoint RLOC spaces . . . . . . . . . . . . . . . . 15
5.2.3. Non-LISP Fabric to LISP WAN interoperability . . . . 15
5.2.4. LISP Fabric to Non-LISP WAN interoperability . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Moreno, et al. Expires August 18, 2014 [Page 2]
Internet-Draft LISP Data Center Deployment February 2014
1. LISP in the Data Center
Data Center Networks require support for segmentation, mobility and
scale as described in [I-D.ietf-nvo3-overlay-problem-statement].
These requirements can be addressed with the use of overlay networks.
The LISP [RFC6830] control plane can be used for the creation of
network overlays that support mobility and segmentation at large
scale in Layer 2, Layer 3 and combined Layer2/Layer3 overlays as
described in [I-D.maino-nvo3-lisp-cp] and
[I-D.hertoghs-nvo3-lisp-controlplane-unified].
The needs for overlay provided services are typically different
within and across Data Centers versus the needs for Data Center Wide
Area Network connectivity. LISP is relevant in both of these areas.
The use of LISP as a control protocol for the creation of overlays
can be optimized for the specific topologies that are relevant in the
context of Data Center Networks within and across Data Centers. This
document discusses different deployment options for LISP in the
context of different data center topologies, the implications of the
use of the different deployment options are part of the discussion.
Data Center Networks include an intra-Data-Center fabric topology as
well as inter-Data-Center and Wide Area Network components. The
topologies found inside the Data Center Network fabric are designed
in a deterministic manner with a very high degree of symmetry. This
high degree of symmetry assures that a multitude of paths exist
between any two end-points in the data center and that these paths
are of equal cost and deterministic latency. As a result of such
designs, traffic patterns within or across the data center are
guaranteed to traverse specific tiers of the network. A reference
Data Center Network inclusive of an intra-Data-Center fabric topology
as well as inter-Data-Center and Wide Area Network components is
described in Section 3.
The predictability of the different possible data paths in the Data
Center Network opens opportunities for optimizations in the
deployment of demand based control plane models such as LISP. In the
specific case of LISP, some of the interesting deployment options are
centered around the topological location of the mapping-system and
xTRs, equally interesting is the option of separating the LISP
control-plane from the encapsulation/decapsulation functions in an
xTR. Different deployment scenarios are discussed in Section 4 and
Section 5.
Moreno, et al. Expires August 18, 2014 [Page 3]
Internet-Draft LISP Data Center Deployment February 2014
2. Definition of Terms
Proxy Reply Mode: Map Servers may reply to a map-request directly,
rather than forwarding the map-request to the registering ETR
Fabric Manager: Orchestration tool in charge of provisioning and
monitoring Fabric Network nodes.
WAN Manager: Orchestration tool in charge of provisioning and
monitoring WAN/DCI Network nodes.
For definition of NVO3 related terms, notably Virtual Network (VN),
Virtual Network Identifier (VNI), Network Virtualization Edge (NVE),
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), Map-
Server (MS) and Map-Resolver (MR) please consult the LISP
specification [RFC6830].
3. Data Center Network Reference Topologies
The reference topology that will be used for our discussion is a
folded clos topology. The folded clos is considered to be the
prevalent topology in large-scale data centers requiring the use of
overlays. Although other topologies may be utilized within the data
center, most of such topologies may be modeled as a folded clos or
collection of clos topologies.
The reference clos topology is illustrated in Figure 1. The
connectivity depicted in the diagram is not exhaustive; every Leaf
node has at least one connection to every Spine node, effectively
providing at least N equal cost paths between any two Leaf nodes,
where N is the number of spine nodes.
Moreno, et al. Expires August 18, 2014 [Page 4]
Internet-Draft LISP Data Center Deployment February 2014
+-----+ +-----+ +-----+
Spine | | | | | |
| | | | | |
+--+--+ +--+--+ +--+--+
/|\ /|\ /|\
/ | \ / | \ / | \
/ | \ / | \ / | \
/ | \/ | \/ | \
/ | /\ | /\ | \
/ | / \ | / \ | \
/ | / \ | / \ | \
/ |/ \|/ \| \
+-----+ +-----+ +-----+ +-----+ +-----+
Leaf | | | | | | | | | |
| | | | | | | | | X | bLeaf(s)
+-----+ +-----+ +-----+ +-----+ +-----+
^ ^ | ^
| | | |
+--+--+ +--+--+ | --+--
vLeaf | | | | . . .... | | X | WAN/DCI Router(s)
+-----+ +-----+ | -----
| | |
| | |
end-points V V . . .... P
Figure 1: Folded Clos Data Center Topology
The clos topology is a multi-stage topology. In the folded clos
instantiation, there is an ingress stage, a middle stage and an
egress stage. The elements of the topology are described as:
o Spine Nodes: Nodes that make the middle stage of the clos. In the
absence of failures, each Spine Node is connected to every Leaf
Node.
o Leaf Nodes: Nodes that make the ingress and egress stage of the
clos. Each Leaf Node is connected to every Spine Node. In the
case of a link or Spine Node failure, a Leaf Node will remain
connected to the surviving Spine Nodes over the remaining healthy
links. The fabric will continue to operate under such condition
of partial connectivity.
o vLeaf Nodes: Virtual Leaf Nodes are those network nodes that
connect to the Leaf Nodes. vLeaf Nodes are usually in the form of
Moreno, et al. Expires August 18, 2014 [Page 5]
Internet-Draft LISP Data Center Deployment February 2014
virtual switches/routers running on the physical compute end-
points hosts. Many vLeaf nodes may connect to a single Leaf node.
Likewise, a vLeaf node may connect to multiple Leaf nodes for
redundancy purposes.
o WAN Routers: Routers attached to leaf nodes in the clos topology
to provide connectivity outside the clos over a WAN or Data Center
Interconnect (DCI). WAN Routers are usually deployed in pairs for
resiliency and they are also usually attached to at least two Leaf
nodes in a redundant topology. WAN routers participate in a Wide
Area Network (WAN) or Data Center Interconnect (DCI).
o bLeaf: Border Leaf nodes are Leaf nodes that attach to the WAN
routers.
o WAN: The Wide Area Network is the network over which client sites
as well as Disaster Recovery sites connect to the data center.
o DCI: Data Center Interconnect is a Metropolitan Area Network over
which multiple Data Centers connect to each other. There is an
assumption of bound latency over the DCI.
o end-points: Hosts that connect to the Data Center Fabric. End-
points can be physical (P) or virtual (V)
o V: Virtual end-points such as Virtual Machines.
o P: Physical end-points such as non-virtualized servers.
4. LISP Deployment in Data Center Fabric Topologies
The main LISP functions to be deployed in the Data Center fabric
topology are:
o xTRs
o Map-Servers
o Map-Resolvers
The Map-Server and Map-Resolver functions will generally be co-
located on the same network nodes, we will refer to the co-located
function as Map-Server/Resolver.
Moreno, et al. Expires August 18, 2014 [Page 6]
Internet-Draft LISP Data Center Deployment February 2014
4.1. xTR Topological Placement
LISP xTRs perform both Data Plane as well as Control Plane tasks.
From the Data Plane perspective the xTRs are tasked with
encapsulating (ITRs) or decapsulating (ETRs) traffic. From the
Control Plane perspective the tasks of registering mappings and
requesting/caching mappings are handled by the ETRs and ITRs
respectively.
It is possible to split the roles of ETR and ITR to different network
nodes. The most prevalent deployment model combines the roles of ETR
and ITR onto a single device. We will focus our discussion on the
combined ETR/ITR model. A device that serves as both ETR and ITR is
generally referred to as an xTR.
It is also possible to split the Data Plane and Control Plane
responsibilities and distribute them across different network nodes.
Some of the deployment options enabled by this separation are
discussed in the following sections:
4.1.1. vLeaf nodes as xTRs
The full xTR function including both Control and Data Plane can be
deployed at the vLeaf nodes. The entire clos including Leaf nodes
and Spine nodes simply serves as an underlay transport to the LISP
overlay.
The advantage of distributing the xTR role to the vLeaf is mainly
that the map-cache state at each xTR is minimized by virtue of it
being distributed to a larger number of nodes.
Amongst the challenges are:
o Operational implications of managing a larger number of overlay
end-points.
o Large number of xTRs sending requests and registrations to the
mapping system has implications on the scale requirements and
limits of the mapping system (servers and resolvers)
o vLeaves do not service non-virtualized Physical end-points
4.1.2. Disjoint xTR function: vLeaf to Leaf-proxy function separation
The control and data plane tasks can be separated and distributed
amongst Leaf and vLeaf. In this approach the vLeaf can retain the
Data Plane encap/decap function while the LISP signaling is done by
Moreno, et al. Expires August 18, 2014 [Page 7]
Internet-Draft LISP Data Center Deployment February 2014
the Leaf. Thus, the Leaf will proxy the signaling for the vLeaf
nodes connected to it as follows
o Map-register messages will be issued by the Leaf with the
corresponding RLOC addresses of the vLeaf nodes.
o Map-request messages will be sent by the ITR vLeaf to its upstream
Leaf and then relayed by the Leaf to the Map-resolver on behalf of
the vLeaf.
o The mapping system, when not in proxy reply mode, will forward the
map-request directly to the RLOC of the vLeaf node with which the
EID being requested was registered.
o Map-reply messages will be sent to the requesting Leaf and then
relayed to the corresponding vLeaf where the mapping is cached.
This scheme allows the caching of state to remain fully distributed
and also enables more granular distribution of the mappings amongst a
larger number of ETRs. The scheme also allows the consolidation of
the signaling at the Leaf nodes where map-registers and map-requests
can be batched. The scheme does however present the challenge of
maintaining mappings in the mapping system for an increased number of
xTRs since it will track the larger number of xTRs at the vLeaf level
rather than the smaller number of xTRs at the Leaf level, this can be
alleviated by fully proxying the vLeaf LISP functions at the Leaf as
discussed in Section 4.1.3.
4.1.3. Full LISP xTR function at Leaf node
Both the data plane and control plane xTR function may reside on the
Leaf nodes. This deployment model leverages the LISP control plane
without any changes and enables interworking of different hypervisor
overlays across a normalized LISP fabric.
vLeaf nodes may encapsulate traffic into the Fabric in different ways
(802.1Q, VXLAN, NVGRE, etc) depending on the hypervisor they may use.
It is the role of the Leaf node, in this model, to terminate any
encapsulation being used by the vLeaf nodes, extract any metadata
information, such as the VNID [I-D.ietf-nvo3-framework], from the
headers imposed at the vLeaf nodes and normalize the different
encapsulations received from different vLeaf nodes to a common LISP
encapsulation amongst Leaf nodes. The LISP encapsulation at the Leaf
nodes will encode the VNIDs extracted from the encapsulated vLeaf
traffic as instance-ids in the LISP overlay.
The mapping of the VNIDs imposed by the vLeaf nodes to LISP instance-
ids is provisioned at each Leaf/xTR node either manually or by an
Moreno, et al. Expires August 18, 2014 [Page 8]
Internet-Draft LISP Data Center Deployment February 2014
automated provisioning system linked to an orchestration system with
visibility into the different hypervisor overlays and the LISP
overlay.
The ability to normalize different hypervisor overlays is predicated
on the use and exchange of Universally Unique Identifiers (UUIDs) as
the constant parameter identifying a common segment across different
overlay administrative domains that may use a variety of VNIDs to
encapsulate traffic for the same segment. The assignment and
administration of tenant UUIDs is an important orchestration task and
outside the scope of this document.
4.2. Mapping System topological placement
Within the data center, we will assume that the functions of map-
server and map-resolver are co-located on the same nodes. We will
refer to such nodes as Map-Server/Resolver.
Resiliency is important in the deployment of Map-Server/Resolvers for
the Data Center. Multiple Map-Server/Resolvers must be deployed for
redundancy. Depending on the topological location of the Map-Server/
Resolver nodes, there may be different deployment requirements to
achieve appropriate reachability to the multiple Map-Server/Resolvers
involved.
4.2.1. Map-Server/Resolver out of band
The Map-Server/Resolver function can be deployed out of band on one
or more network nodes that are either reachable in the WAN or
attached to a leaf as end-points but are not part of the clos
topology. Out of band Map-Server/Resolvers will only be exposed to
control plane traffic.
Clusters of Map-Server/Resolver nodes can be deployed by having ETRs
register to multiple Map-Server addresses and ITRs issue map-requests
to an anycast address that is shared by the map-resolver function of
the Map-Server/Resolver nodes in the cluster. Thus, the map-resolver
function can use a common anycast IP address across all Map-Server/
Resolver nodes, separate unicast IP addresses will be assigned the
map-server component in each node. ETRs registering to the map-
servers should be configured to send map-registers to all map-server
IP addresses. ITRs should issue map-requests to the shared anycast
IP address of the map-resolver component of the cluster.
Alternatively, clusters of Map-Server/Resolver nodes can be deployed
by having ETRs register to one Map-Server and use an alternate
mechanism to allow the synchronization of this registration across
all Map-Servers in the cluster. In this case ETRs will be configured
Moreno, et al. Expires August 18, 2014 [Page 9]
Internet-Draft LISP Data Center Deployment February 2014
to register to a single IP address, this would likely be a shared
anycast IP address amongst the Map-Servers in order to ensure
resiliency. ITRs will continue to issue requests to a Map-Resolver
shared anycast IP.
The creation of Map-Server/Resolver resiliency clusters based on IP
addressing is a topologically agnostic deployment model which fits
the out of band model well and gives a high degree of flexibility for
the deployment of the necessary mapping system nodes.
4.2.2. Map-Server/Resolver in-line
The Map-Server/Resolver function can be deployed in-line on one or
more network nodes that participate in the clos topology either as
Spine nodes or Leaf nodes. In-line Map-Server/Resolvers will receive
both Control Plane and Data Plane traffic.
4.2.2.1. Map-Server/Resolver at the Spine
The Map-Server/Resolver function can be deployed on Spine nodes. In
order to guarantee resiliency, Map-Server/Resolvers are deployed on
at least two Spine nodes, but preferably on all Spine nodes.
Any map-register messages must be sent to all Map-Server/Resolver
enabled Spine nodes in order to ensure synchronization of the mapping
system. Therefore in a system where all Spine nodes host the Map-
Server/Resolver functionality, all Spine nodes will have complete
mapping state for all EIDs in the fabric. Alternatively, map-
register messages can be sent to a single Map-Server and the state
may be relayed by other methods to other Map-Servers in the Spine.
When all Spine nodes host the Map-Server/Resolver functionality, all
data plane traffic that cuts across different leaf nodes will
traverse a Spine node that has the full LISP mapping state for the
fabric. In this deterministic topology it is possible to implement
avoid transient drops that may occur when looking up destinations
that have not been previously cached at the ITRs.
In order to avoid transient drops during Mapping System lookups, ITRs
(Leaf or vLeaf nodes) without a pre-existing cache entry for a
particular destination must encapsulate and forward the traffic with
the unknown destination to the Spine. Since the Spine has full
location information, it knows which ETR to send the traffic to, so
it encapsulates and forwards the traffic accordingly.
Simultaneously, the ITR may send a map-request to the anycast address
for the map-resolvers that are present across the spine. The ITR
will continue to send the traffic for the unknown destination towards
the Spine until a mapping for the destination is received in a map-
Moreno, et al. Expires August 18, 2014 [Page 10]
Internet-Draft LISP Data Center Deployment February 2014
reply and cached at the ITR, at which point the ITR will start
encapsulating traffic directly to the appropriate ETR.
In order to forward traffic for unknown destinations to the Spine,
the ITR must LISP encapsulate the unknown destination traffic towards
the anycast IP address configured for the map-resolver function on
the Spine nodes or it may hash the traffic to select a discrete RLOC
for a specific Spine node. It is important that traffic be LISP
encapsulated in order to preserve the semantics of instance-id and
other parameters that may be encoded in the LISP header.
An alternative implementation could leverage the data plane traffic
in order to reduce the amount of control plane messages that are
exchanged. For instance, when traffic with unknown destinations is
sent to the spine, rather than waiting to receive a map-request for
the unknown destination, the spine could react to the reception of
the unknown destination data plane traffic by sending a map-reply to
the source ITR with the mappings for the corresponding unknown
destination. This effectively replaces the map-request messaging
with data plane events. Either way this is implemented, the main
benefit of the deployment model is the ability to avoid packet drops
while mapping system lookups are completed.
4.2.2.2. Map-Server/Resolver at Leaf nodes
The Map-Server/Resolver function could be deployed at Leaf nodes. In
this scenario it may be beneficial to make the different Leaf hosted
Map-Server/Resolvers authoritative for specific prefixes or instance-
ids (VNIs) and allow the distribution of the mapping state across the
different Leaf nodes.
One mechanism to achieve the distribution of the mapping state across
the different leaf nodes is to have different Leaf nodes be the
authority for a particular prefix or instance-id in a Delegated
Database Tree (DDT)[I-D.ietf-lisp-ddt]. The Leaf nodes can be
arranged in pairs for redundancy and the association of a particular
prefix or instance-id to specific Leaf nodes is achieved by
configuration of the Leaf nodes and the DDT.
This type of in-line deployment of the Map-Server/Resolver could, in
theory, also provide a no-drop LISP lookup service at the expense of
maintaining all LISP mapping state at all Leaf nodes. In the case of
a no-drop LISP lookup service, the Map-Server/Resolver function would
be deployed in the same way as explained for deployment in the Spine
and the system would therefore not benefit from the distribution of
state at the Leaf nodes.
Moreno, et al. Expires August 18, 2014 [Page 11]
Internet-Draft LISP Data Center Deployment February 2014
5. LISP deployment in the DC WAN and Data Center Interconnect
The placement of IP workloads within and across Data Centers has a
high degree of entropy, which renders existing topology congruent
routing summarization methods ineffective in containing the explosion
of routing state in the Data Center WAN and Data Center Interconnect.
The problem of entropy in the placement of workloads across Data
Centers is analogous to the challenge of prefix disaggregation found
on the Internet. The seminal motivation behind the development of
LISP was the mitigation of the scale issues caused by the
disaggregation of user prefixes in the Internet, the multi-Data
Center problem is of similar nature, hence LISP is a very good fit to
address such scale problem.
In the WAN, LISP will be in charge of handling reachability
information between Branch sites and IP workloads that are
distributed across different Data Centers. The use of LISP allows
the scalable handling of very granular location information as IP
workloads are deployed in diverse Data Centers. The management
domain is usually a single one for the LISP WAN environment and the
diverse Data Centers involved may be managed independently. The
diversity of management domains is a key deployment consideration
which is found in the WAN and DCI connectivity scenarios and requires
a certain level of federation between the different domains as will
be discussed in the next few sections.
In the Data Center Interconnect (DCI), LISP provides reachability and
policies (such as inbound load-balancing) between Data Centers for
those cases in which IP workloads must communicate with each other
across Data Centers. The communication may happen between Data
Centers in independent administrative domains, with a single
administrative domain being a more specific instantiation of the
general case.
In the WAN and DCI, as inside the Data Center, the main LISP
functions to deploy are:
o xTRs
o Map-Servers
o Map-Resolvers
o PxTRs
Map-Servers/Map-Resolvers will be distributed across Data Centers and
over the WAN following the DDT model. DDT prefix delegation provides
Moreno, et al. Expires August 18, 2014 [Page 12]
Internet-Draft LISP Data Center Deployment February 2014
a way to parition different administrative domains, providing a very
basic form of federation.
xTRs will normally be deployed at the edge of the Data Center on the
WAN/DCI routers.
PxTR location may vary, but in general will be placed as close as
possible to Internet gateways, or other non LISP-speaking sources.
See [RFC6832] for considerations on Interworking with non-LISP sites.
Particularly interesting in the deployment of LISP is the type of
handoff between the Data Center Fabric and the devices providing the
WAN/DCI services. Different handoff options are discussed in
Section 5.1.
Of further relevance is the careful evaluation of the different
interoperability scenarios between the Data Center Fabric and the WAN
/DCI that are discussed in Section 5.2.
5.1. Fabric-WAN handoff: topology, peering and administrative
delineation
There are a couple of approaches to realizing the handoff between the
Fabric and the WAN:
o Two-tier: Border-Leaf to WAN-router peering
o Single-tier: Consolidated border-Leaf/WAN-router function
5.1.1. Two-tier Fabric-WAN normalized handoff
In the two-tier approach the border-Leaf and WAN-router peer over a
normalized handoff. There is clear administrative delineation at the
handoff between Fabric and WAN where the Fabric Manager is
authoritative solely over the border-Leaf and the WAN Manager is
authoritative solely over the WAN-router. The border-Leaf and WAN
router may enter a peering relationship and exchange routes and other
attributes of their respective overlay services. Segments (VNs) in
the Fabric overlay will map at the border-Leaf to a normalized
segment over the handoff that can be realized by use of VRFs or VLANs
interconnected over an 802.1Q trunked set of links or over an overlay
encapsulation such as VXLAN, GRE, NVGRE, MPLS, LISP or other. These
segments will in turn be mapped at the WAN-router to their
corresponding segments in the WAN service (for example, a VRF in an
IP MPLS VPN or a VRF/instance-id segment in LISP). Reachability and
other information can be exchanged between the border-Leaf nodes and
the WAN routers over the normalized handoff using an extensible
routing protocol such as MP-BGP or IS-IS.
Moreno, et al. Expires August 18, 2014 [Page 13]
Internet-Draft LISP Data Center Deployment February 2014
5.1.2. Single-tier Fabric-WAN handoff
In the single tier approach, the border-Leaf and the WAN-router are
the same device. Mapping of segments (VNs) in one domain to segments
in the other domain is achieved by sharing certain components between
the two domains. One good example is a VRF that routes traffic
between the Fabric overlay domain and the WAN overlay domain at the
consolidated border-Leaf/WAN-router device.
The device that consolidates the border-Leaf and WAN-router roles is
managed by two entities: the Fabric manager and the WAN manager.
Delineation of management authority must be established carefully and
precisely to separate WAN relevant elements within the device from
Fabric relevant elements and their corresponding administration.
There will be a series of common components where the mapping between
the domains happens (e.g. VRFs). Policy to resolve any conflicts
related to the administration of common components in the handoff
must be in place.
5.2. Fabric to WAN interoperability scenarios
5.2.1. LISP Fabric to LISP WAN interoperability with common RLOC space
To integrate a LISP based Fabric with the LISP WAN it is possible to
merge the Fabric LISP domain with the WAN LISP domain. To achieve
this, the Map-Servers/Resolvers for the Fabric can join the DDT
structure in the WAN.
The merging of the domains assumes that the Fabric ITR/Leaf nodes are
reachable in the underlay (RLOC space) from the WAN. In this model
the xTRs are the Fabric Leaf nodes as well as the Branch Routers at
the different WAN sites and an end-to-end overlay is realized between
xTRs cutting across WAN and Fabric.
Although the domains are merged into one, the hierarchical structure
of the DDT provides some isolation of the control plane and failure
isolation. The granular state for the Fabric is maintained solely on
the Fabric Map-Server/Resolvers and LISP signaling for the Fabric
xTRs will be scoped and serviced by the Fabric Map-Server/Resolvers.
The domain isolation achieved with this model may not be sufficient
for specific deployments, it is possible to follow the model
described for a disjoint RLOC space in Section 5.2.2 even if the RLOC
space is contiguous.
Moreno, et al. Expires August 18, 2014 [Page 14]
Internet-Draft LISP Data Center Deployment February 2014
5.2.2. LISP Fabric to LISP WAN interoperability with disjoint RLOC
spaces
There are scenarios in which the RLOC space in the Fabric is not part
of the WAN routing space. In these scenarios the LISP overlay
realized inside the Fabric must terminate at the border of the Fabric
and should be mapped to a WAN overlay that terminates at the border
of the WAN.
The handoff between the two domains may be a single-tier handoff. In
this case, the WAN/DCI device and bLeaf are the same device. The WAN
/DCI device will be an xTR in two domains: Fabric and WAN/DCI. In
one deployment model the xTR may receive Map-Notifications from the
WAN Mapping System and these may trigger registrations into the
Fabric Mapping System and vice versa. This model basically uses the
xTR as an exchange point between the two LISP control plane
instances. From the data plane perspective the xTR acts as an RTR
(Re-encapsulating Tunnel Router). A different deployment model may
rely heavily on Mapping System intelligence and may assume that the
mapping systems are federated and that the location of the requesting
ITR gives the mapping system enough context to provide map-replies
that will steer traffic to the appropriate RTRs as packets progress
through the different Data Center edges.
In the disjoint RLOC scenario, the handoff between the two domains
may alternatively be a two-tier handoff with separate border-Leaf and
WAN-router devices. The exchange of routing information between the
bLeaf and WAN-router may be achieved by dynamic routing protocols
such as MP-BGP or IS-IS. The routes received by either device must
be registered into the respective mapping system. Similarly, any
mappings in one domain must be advertised as routes on the handoff to
the other domain.
When the LISP implementation does not support redistribution of
routes into LISP and the converse redistribution of Mappings into
routing protocols, the use of static routes and static mappings can
help the interoperability of the two domains.
5.2.3. Non-LISP Fabric to LISP WAN interoperability
In order to support mobility, Data Center Fabrics are either built as
pure Layer 2 Fabrics or, when built as Layer 3 networks, they rely on
host routing to achieve mobility in the routed Fabric. The
implication of the use of Layer 3 in the Fabric is that every Leaf
will advertise host routes for the devices that are directly
connected to the Leaf and all Leaf nodes will hold complete state for
all end-points that attach to the fabric.
Moreno, et al. Expires August 18, 2014 [Page 15]
Internet-Draft LISP Data Center Deployment February 2014
When multiple Fabrics are interconnected with a DCI/WAN service, end-
points that are reachable outside the fabric can be represented
inside the fabric by a default route advertised by the bLeaves into
the Fabric. The routing is thus made of specific host routes for
end-points attached to the local Fabric and any end-points attached
to other Fabrics will not be known specifically, but would be assumed
to be reachable via the default route that points to the bLeaf.
Another way of describing this model is to simply state that all
local end-points are explicitly known and that traffic destined to
any unknown destinations will be default forwarded to the bLeaf. The
bLeaf can be a LISP xTR (in the single-tier model) and it would
receive default routed traffic for which it can issue map-requests
and encapsulate to the appropriate destination as the traffic is
received. Altenatively, the bLeaf may handoff the traffic to a WAN/
DCI router that provides the required xTR functionality.
The advantages of this model are several:
o Remote state is kept out of the local fabric by using default
routing
o xTRs in the LISP WAN/DCI only resolve and cache mappings for
active flows as expected of an on-demand control plane
o Host routes terminate at the bLeaf and are kept outside of the
routing tables in the WAN/DCI as they are handled by LISP instead
5.2.4. LISP Fabric to Non-LISP WAN interoperability
In this scenario, the prefixes handled by LISP inside the Fabric must
be advertised to the Non-LISP WAN/DCI. In order to do so, the bLeaf
must be able to pull all EIDs that are registered with the Fabric's
mapping system and advertise these EIDs in a routing protocol. If
the EIDs are easily summarizable, it may be sufficient to simply add
a static route at the bLeaf. More generally, the EIDs may not be
easily summarizable and may even change dynamically. When the EIDs
are not summarizable or static, a mechanism for the bLeaf to
subscribe to the mapping system and download all EIDs dynamically is
required. Since LISP does not provide such subscription service, one
option is to run a push protocol such as BGP between the mapping
system and the bLeaf, since all registered EIDs are known at the Map-
Server/Resolver, the Map-Server/Resolver may redistribute these EIDs
into BGP and the required information may be advertised over BGP to
the xTRs on the bLeaves. Another option is for the Map-Server-
Resolver to be located at the bLeaves and have the EIDs be
redistributed from LISP into a routing protocol on the same device.
Moreno, et al. Expires August 18, 2014 [Page 16]
Internet-Draft LISP Data Center Deployment February 2014
6. Security Considerations
[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. LISP-
SEC also enables verification of authorization on EID-prefix claims
in Map-Reply messages.
Additional security mechanisms to protect the LISP Map-Register
messages are defined in [RFC6833].
The security of the Mapping System Infrastructure 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.
7. IANA Considerations
This document has no IANA implications
8. Acknowledgements
The authors want to thank Yves Hertoghs for the early review,
insightful comments and suggestions.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.farinacci-lisp-mr-signaling]
Farinacci, D. and M. Napierala, "LISP Control-Plane
Multicast Signaling", draft-farinacci-lisp-mr-signaling-03
(work in progress), September 2013.
[I-D.hertoghs-nvo3-lisp-controlplane-unified]
Hertoghs, Y., Maino, F., Moreno, V., Smith, M., Farinacci,
D., and L. Iannone, "A Unified LISP Mapping Database for
L2 and L3 Network Virtualization Overlays", draft-
hertoghs-nvo3-lisp-controlplane-unified-01 (work in
progress), February 2014.
Moreno, et al. Expires August 18, 2014 [Page 17]
Internet-Draft LISP Data Center Deployment February 2014
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
progress), March 2013.
[I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-04 (work in
progress), January 2014.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-
ietf-lisp-sec-05 (work in progress), October 2013.
[I-D.ietf-nvo3-dataplane-requirements]
Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L.,
and B. Khasnabish, "NVO3 Data Plane Requirements", draft-
ietf-nvo3-dataplane-requirements-02 (work in progress),
November 2013.
[I-D.ietf-nvo3-framework]
Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for DC Network Virtualization", draft-
ietf-nvo3-framework-05 (work in progress), January 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",
draft-ietf-nvo3-nve-nva-cp-req-01 (work in progress),
October 2013.
[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", draft-ietf-nvo3-overlay-problem-
statement-04 (work in progress), July 2013.
[I-D.maino-nvo3-lisp-cp]
Maino, F., Ermagan, V., Hertoghs, Y., Farinacci, D., and
M. Smith, "LISP Control Plane for Network Virtualization
Overlays", draft-maino-nvo3-lisp-cp-03 (work in progress),
October 2013.
[I-D.smith-lisp-layer2]
Smith, M., Dutt, D., Farinacci, D., and F. Maino, "Layer 2
(L2) LISP Encapsulation Format", draft-smith-lisp-
layer2-03 (work in progress), September 2013.
Moreno, et al. Expires August 18, 2014 [Page 18]
Internet-Draft LISP Data Center Deployment February 2014
[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
Victor Moreno
Cisco Systems
170 Tasman Drive
San Jose, California 95134
USA
Email: vimoreno@cisco.com
Fabio Maino
Cisco Systems
170 Tasman Drive
San Jose, California 95134
USA
Email: fmaino@cisco.com
Darrel Lewis
Cisco Systems
170 West Tasman Dr.
San Jose, California 95134
USA
Email: darlewis@cisco.com
Moreno, et al. Expires August 18, 2014 [Page 19]
Internet-Draft LISP Data Center Deployment February 2014
Michael Smith
Cisco Systems
170 West Tasman Dr.
San Jose, California 95134
USA
Email: michsmit@cisco.com
Satyam Sinha
Cisco Systems
170 West Tasman Dr.
San Jose, California 95134
USA
Email: satysinh@cisco.com
Moreno, et al. Expires August 18, 2014 [Page 20]
