draft-ietf-lisp-deployment-12.txt   rfc7215.txt 
Network Working Group L. Jakab Internet Engineering Task Force (IETF) L. Jakab
Internet-Draft Cisco Systems Request for Comments: 7215 Cisco Systems
Intended status: Experimental A. Cabellos-Aparicio Category: Experimental A. Cabellos-Aparicio
Expires: July 21, 2014 F. Coras ISSN: 2070-1721 F. Coras
J. Domingo-Pascual J. Domingo-Pascual
Technical University of Technical University of Catalonia
Catalonia
D. Lewis D. Lewis
Cisco Systems Cisco Systems
January 17, 2014 April 2014
LISP Network Element Deployment Considerations Locator/Identifier Separation Protocol (LISP)
draft-ietf-lisp-deployment-12.txt Network Element Deployment Considerations
Abstract Abstract
This document is a snapshot of different Locator/Identifier This document is a snapshot of different Locator/Identifier
Separation Protocol (LISP) deployment scenarios. It discusses the Separation Protocol (LISP) deployment scenarios. It discusses the
placement of new network elements introduced by the protocol, placement of new network elements introduced by the protocol,
representing the thinking of the LISP working group as of Summer representing the thinking of the LISP working group as of Summer
2013. LISP deployment scenarios may have evolved since. This memo 2013. LISP deployment scenarios may have evolved since then. This
represents one stable point in that evolution of understanding. memo represents one stable point in that evolution of understanding.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for examination, experimental implementation, and
working documents as Internet-Drafts. The list of current Internet- evaluation.
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on July 21, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7215.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Tunnel Routers ..................................................5
2.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 4 2.1. Deployment Scenarios .......................................5
2.1.1. Customer Edge . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Customer Edge (CE) ..................................5
2.1.2. Provider Edge . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Provider Edge (PE) ..................................6
2.1.3. Tunnel Routers Behind NAT . . . . . . . . . . . . . . 7 2.1.3. Tunnel Routers behind NAT ...........................8
2.1.3.1. ITR . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.3.1. ITR ........................................8
2.1.3.2. ETR . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.3.2. ETR ........................................9
2.1.3.3. Additional Notes . . . . . . . . . . . . . . . . . 8 2.1.3.3. Additional Notes ...........................9
2.2. Functional Models with Tunnel Routers . . . . . . . . . . 8 2.2. Functional Models with Tunnel Routers ......................9
2.2.1. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . 8 2.2.1. Split ITR/ETR .......................................9
2.2.2. Inter-Service Provider Traffic Engineering . . . . . . 10 2.2.2. Inter-Service-Provider Traffic Engineering .........11
2.3. Summary and Feature Matrix . . . . . . . . . . . . . . . . 12 2.3. Summary and Feature Matrix ................................13
3. Map Resolvers and Map Servers . . . . . . . . . . . . . . . . 13 3. Map-Servers and Map-Resolvers ..................................14
3.1. Map Servers . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Map-Servers ...............................................14
3.2. Map Resolvers . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Map-Resolvers .............................................16
4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 16 4. Proxy Tunnel Routers ...........................................17
4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. PITRs .....................................................17
4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. PETRs .....................................................18
5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 18 5. Migration to LISP ..............................................19
5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. LISP+BGP ..................................................19
5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 19 5.2. Mapping Service Provider (MSP) PITR Service ...............20
5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 19 5.3. Proxy-ITR Route Distribution (PITR-RD) ....................20
5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 22 5.4. Migration Summary .........................................23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations ........................................24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgements ...............................................24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. References .....................................................24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References ......................................24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 8.2. Informative References ....................................24
9.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Step-by-Step Example BGP-to-LISP Migration Procedure ..26
Appendix A. Step-by-Step Example BGP to LISP Migration A.1. Customer Pre-Install and Pre-Turn-Up Checklist .............26
Procedure . . . . . . . . . . . . . . . . . . . . . . 24 A.2. Customer Activating LISP Service ...........................28
A.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 24 A.3. Cut-Over Provider Preparation and Changes ..................29
A.2. Customer Activating LISP Service . . . . . . . . . . . . . 26
A.3. Cut-Over Provider Preparation and Changes . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The Locator/Identifier Separation Protocol (LISP) is designed to The Locator/Identifier Separation Protocol (LISP) is designed to
address the scaling issues of the global Internet routing system address the scaling issues of the global Internet routing system
identified in [RFC4984] by separating the current addressing scheme identified in [RFC4984] by separating the current addressing scheme
into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs). The into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs). The
main protocol specification [RFC6830] describes how the separation is main protocol specification [RFC6830] describes how the separation is
achieved, which new network elements are introduced, and details the achieved and which new network elements are introduced, and it
packet formats for the data and control planes. details the packet formats for the data and control planes.
LISP assumes that such separation is between the edge and core and LISP assumes that such separation is between the edge and core and
uses mapping and encapsulation for forwarding. While the boundary uses mapping and encapsulation for forwarding. While the boundary
between both is not strictly defined, one widely accepted definition between both is not strictly defined, one widely accepted definition
places it at the border routers of stub autonomous systems, which may places it at the border routers of stub autonomous systems, which may
carry a partial or complete default-free zone (DFZ) routing table. carry a partial or complete default-free zone (DFZ) routing table.
The initial design of LISP took this location as a baseline for The initial design of LISP took this location as a baseline for
protocol development. However, the applications of LISP go beyond protocol development. However, the applications of LISP go beyond
just decreasing the size of the DFZ routing table, and include just decreasing the size of the DFZ routing table and include
improved multihoming and ingress traffic engineering (TE) support for improved multihoming and ingress traffic engineering (TE) support for
edge networks, and even individual hosts. Throughout the document we edge networks, and even individual hosts. Throughout this document,
will use the term LISP site to refer to these networks/hosts behind a we will use the term "LISP site" to refer to these networks/hosts
LISP Tunnel Router. We formally define the following two terms: behind a LISP Tunnel Router. We formally define the following
two terms:
Network element: Facility or equipment used in the provision of a Network element: Facility or equipment used in the provision of a
communications service over the Internet [TELCO96]. communications service over the Internet [TELCO96].
LISP site: A single host or a set of network elements in an edge LISP site: A single host or a set of network elements in an edge
network under the administrative control of a single organization, network under the administrative control of a single organization,
delimited from other networks by LISP Tunnel Router(s). delimited from other networks by LISP Tunnel Router(s).
Since LISP is a protocol which can be used for different purposes, it Since LISP is a protocol that can be used for different purposes, it
is important to identify possible deployment scenarios and the is important to identify possible deployment scenarios and the
additional requirements they may impose on the protocol specification additional requirements they may impose on the protocol specification
and other protocols. Additionally, this document is intended as a and other protocols. Additionally, this document is intended as a
guide for the operational community for LISP deployments in their guide for the operational community for LISP deployments in their
networks. It is expected to evolve as LISP deployment progresses, networks. It is expected to evolve as LISP deployment progresses,
and the described scenarios are better understood or new scenarios and the described scenarios are better understood or new scenarios
are discovered. are discovered.
Each subsection considers an element type, discussing the impact of Each subsection considers an element type and discusses the impact of
deployment scenarios on the protocol specification. For definition deployment scenarios on the protocol specification. For definitions
of terms, please refer to the appropriate documents (as cited in the of terms, please refer to the appropriate documents (as cited in the
respective sections). respective sections).
This experimental document describing deployment considerations and This experimental document describes deployment considerations.
the LISP specifications have areas that require additional experience These considerations and the LISP specifications have areas that
and measurement. LISP is not recommended for deployment beyond require additional experience and measurement. LISP is not
experimental situations. Results of experimentation may lead to recommended for deployment beyond experimental situations. Results
modifications and enhancements of the LISP protocol mechanisms. of experimentation may lead to modifications and enhancements of LISP
Additionally, at the time of this writing there is no standardized mechanisms. Additionally, at the time of this writing there is no
security to implement. Beware that there are no counter measures for standardized security to implement. Beware that there are no
any of the threads identified in [I-D.ietf-lisp-threats]. See countermeasures for any of the threats identified in [LISP-THREATS].
Section 15 [of RFC 6830] for specific, known issues that are in need See Section 15 of [RFC6830] for specific known issues that are in
of further work during development, implementation, and need of further work during development, implementation, and
experimentation, and [I-D.ietf-lisp-threats] for recommendations to experimentation, and see [LISP-THREATS] for recommendations to
ameliorate the above-mentioned security threats. ameliorate the above-mentioned security threats.
2. Tunnel Routers 2. Tunnel Routers
The device that is the gateway between the edge and the core is The device that is the gateway between the edge and the core is
called a Tunnel Router (xTR), performing one or both of two separate called a Tunnel Router (xTR); it performs one or both of two separate
functions: functions:
1. Encapsulating packets originating from an end host to be 1. Encapsulating packets originating from an end host to be
transported over intermediary (transit) networks towards the transported over intermediary (transit) networks towards the
other end-point of the communication other endpoint of the communication.
2. Decapsulating packets entering from intermediary (transit) 2. Decapsulating packets entering from intermediary (transit)
networks, originated at a remote end host. networks, originated at a remote end host.
The first function is performed by an Ingress Tunnel Router (ITR), The first function is performed by an Ingress Tunnel Router (ITR) and
the second by an Egress Tunnel Router (ETR). the second by an Egress Tunnel Router (ETR).
Section 8 of the main LISP specification [RFC6830] has a short Section 8 of the main LISP specification [RFC6830] has a short
discussion of where Tunnel Routers can be deployed and some of the discussion of where Tunnel Routers can be deployed and some of the
associated advantages and disadvantages. This section adds more associated advantages and disadvantages. This section adds more
detail to the scenarios presented there, and provides additional detail to the scenarios presented there and provides additional
scenarios as well. Furthermore this section discusses functional scenarios as well. Furthermore, this section discusses functional
models, that is, network functions that can be achieved by deploying models, that is, network functions that can be achieved by deploying
Tunnel Routers in specific ways. Tunnel Routers in specific ways.
2.1. Deployment Scenarios 2.1. Deployment Scenarios
2.1.1. Customer Edge 2.1.1. Customer Edge (CE)
The first scenario we discuss is customer edge, when xTR The first scenario we discuss is the customer edge, when xTR
functionality is placed on the router(s) that connect the LISP site functionality is placed on the router(s) that connects the LISP site
to its upstream(s), but are under its control. As such, this is the to its upstream(s) but is under its control. As such, this is the
most common expected scenario for xTRs, and this document considers most common expected scenario for xTRs, and this document considers
it the reference location, comparing the other scenarios to this one. it the reference location, comparing the other scenarios to this one.
ISP1 ISP2 ISP1 ISP2
| | | |
| | | |
+----+ +----+ +----+ +----+
+--|xTR1|--|xTR2|--+ +--|xTR1|--|xTR2|--+
| +----+ +----+ | | +----+ +----+ |
| | | |
| LISP site | | LISP site |
+------------------+ +------------------+
Figure 1: xTRs at the customer edge Figure 1: xTRs at the Customer Edge
From the LISP site perspective the main advantage of this type of From the LISP site's perspective, the main advantage of this type of
deployment (compared to the one described in the next section) is deployment (compared to the one described in the next section) is
having direct control over its ingress traffic engineering. This having direct control over its ingress traffic engineering. This
makes it easy to set up and maintain active/active, active/backup, or makes it easy to set up and maintain active/active, active/backup, or
more complex TE policies, adding ISPs and additional xTRs at will, more complex TE policies, adding ISPs and additional xTRs at will,
without involving third parties. without involving third parties.
Being under the same administrative control, reachability information Being under the same administrative control, reachability information
of all ETRs is easier to synchronize, because the necessary control of all ETRs is easier to synchronize, because the necessary control
traffic can be allowed between the locators of the ETRs. A correct traffic can be allowed between the locators of the ETRs. A correct
synchronous global view of the reachability status is thus available, synchronous global view of the reachability status is thus available,
and the Locator Status Bits (Loc-Status-Bits, defined in [RFC6830]) and the Locator-Status-Bits can be set correctly in the LISP data
can be set correctly in the LISP data header of outgoing packets. header of outgoing packets.
By placing the tunnel router at the edge of the site, existing By placing the Tunnel Router at the edge of the site, existing
internal network configuration does not need to be modified. internal network configuration does not need to be modified.
Firewall rules, router configurations and address assignments inside Firewall rules, router configurations, and address assignments inside
the LISP site remain unchanged. This helps with incremental the LISP site remain unchanged. This helps with incremental
deployment and allows a quick upgrade path to LISP. For larger sites deployment and allows a quick upgrade path to LISP. For larger sites
with many external connections, distributed in geographically diverse distributed in geographically diverse points of presence (PoPs) and
points of presence (PoPs), and complex internal topology, it may having many external connections and complex internal topology, it
however make more sense to both encapsulate and decapsulate as soon may, however, make more sense to both encapsulate and decapsulate as
as possible, to benefit from the information in the IGP to choose the soon as possible, to benefit from the information in the IGP to
best path (see Section 2.2.1 for a discussion of this scenario). choose the best path. See Section 2.2.1 for a discussion of this
scenario.
Another thing to consider when placing tunnel routers is MTU issues. Another thing to consider when placing Tunnel Routers is MTU issues.
Encapsulation increases the amount of overhead associated with each Encapsulation increases the amount of overhead associated with each
packet. This added overhead decreases the effective end-to-end path packet. This added overhead decreases the effective end-to-end path
MTU (unless fragmentation and reassembly is used). Some transit MTU (unless fragmentation and reassembly are used). Some transit
networks are known to provide larger MTU than the typical value of networks are known to provide larger MTU values than the typical
1500 bytes of popular access technologies used at end hosts (e.g., value of 1500 bytes for popular access technologies used at end hosts
IEEE 802.3 and 802.11). However, placing the LISP router connecting (e.g., IEEE 802.3 and 802.11). However, placing the LISP router
to such a network at the customer edge could possibly bring up MTU connecting to such a network at the customer edge could possibly
issues, depending on the link type to the provider as opposed to the bring up MTU issues, depending on the link type to the provider as
following scenario. See [RFC4459] for MTU considerations of opposed to the following scenario. See [RFC4459] for MTU
tunneling protocols on how to mitigate potential issues. Still, even considerations of tunneling protocols and how to mitigate potential
with these mitigations, path MTU issues are still possible. issues. Still, even with these mitigations, path MTU issues are
still possible.
2.1.2. Provider Edge 2.1.2. Provider Edge (PE)
The other location at the core-edge boundary for deploying LISP The other location at the core-edge boundary for deploying LISP
routers is at the Internet service provider edge. The main incentive routers is at the Internet service provider edge. The main incentive
for this case is that the customer does not have to upgrade the CE for this case is that the customer does not have to upgrade the CE
router(s), or change the configuration of any equipment. router(s) or change the configuration of any equipment.
Encapsulation/decapsulation happens in the provider's network, which Encapsulation/decapsulation happens in the provider's network, which
may be able to serve several customers with a single device. For may be able to serve several customers with a single device. For
large ISPs with many residential/business customers asking for LISP large ISPs with many residential/business customers asking for LISP,
this can lead to important savings, since there is no need to upgrade this can lead to important savings, since there is no need to upgrade
the software (or hardware, if it's the case) at each client's the software (or hardware, if that's the case) at each client's
location. Instead, they can upgrade the software (or hardware) on a location. Instead, they can upgrade the software (or hardware) on a
few PE routers serving the customers. This scenario is depicted in few PE routers serving the customers. This scenario is depicted in
Figure 2. Figure 2.
+----------+ +------------------+ +----------+ +------------------+
| ISP1 | | ISP2 | | ISP1 | | ISP2 |
| | | | | | | |
| +----+ | | +----+ +----+ | | +----+ | | +----+ +----+ |
+--|xTR1|--+ +--|xTR2|--|xTR3|--+ +--|xTR1|--+ +--|xTR2|--|xTR3|--+
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | |
| | | | | |
+--<[LISP site]>---+-------+ +--<[LISP site]>---+-------+
Figure 2: xTR at the PE Figure 2: xTRs at the Provider Edge
While this approach can make transition easy for customers and may be While this approach can make transition easy for customers and may be
cheaper for providers, the LISP site loses one of the main benefits cheaper for providers, the LISP site loses one of the main benefits
of LISP: ingress traffic engineering. Since the provider controls of LISP: ingress traffic engineering. Since the provider controls
the ETRs, additional complexity would be needed to allow customers to the ETRs, additional complexity would be needed to allow customers to
modify their mapping entries. modify their mapping entries.
The problem is aggravated when the LISP site is multihomed. Consider The problem is aggravated when the LISP site is multihomed. Consider
the scenario in Figure 2: whenever a change to TE policies is the scenario in Figure 2: whenever a change to TE policies is
required, the customer contacts both ISP1 and ISP2 to make the required, the customer contacts both ISP1 and ISP2 to make the
necessary changes on the routers (if they provide this possibility). necessary changes on the routers (if they provide this possibility).
It is however unlikely, that both ISPs will apply changes It is, however, unlikely that both ISPs will apply changes
simultaneously, which may lead to inconsistent state for the mappings simultaneously, which may lead to inconsistent state for the mappings
of the LISP site. Since the different upstream ISPs are usually of the LISP site. Since the different upstream ISPs are usually
competing business entities, the ETRs may even be configured to competing business entities, the ETRs may even be configured to
compete, either to attract all the traffic or to get no traffic. The compete, to either attract all the traffic or get no traffic. The
former will happen if the customer pays per volume, the latter if the former will happen if the customer pays per volume, the latter if the
connectivity has a fixed price. A solution could be to configure the connectivity has a fixed price. A solution could be to configure the
Map Server(s) to do proxy-replying and have the Mapping Service Map-Server(s) to do proxy-replying and have the Mapping Service
Provider (MSP) apply policies. Provider (MSP) apply policies.
Additionally, since xTR1, xTR2, and xTR3 are in different Additionally, since xTR1, xTR2, and xTR3 are in different
administrative domains, locator reachability information is unlikely administrative domains, locator reachability information is unlikely
to be exchanged among them, making it difficult to set Loc-Status- to be exchanged among them, making it difficult to set the
Bits (LSB) correctly on encapsulated packets. Because of this, and Locator-Status-Bits (LSBs) correctly on encapsulated packets.
due to the security concerns about LSB described in Because of this, and due to the security concerns about LSBs as
[I-D.ietf-lisp-threats] their use is discouraged (set the L-bit to described in [LISP-THREATS], their use is discouraged (set the L-bit
0). Mapping versioning is another alternative [RFC6834]. to 0). Map-Versioning is another alternative [RFC6834].
Compared to the customer edge scenario, deploying LISP at the Compared to the customer edge scenario, deploying LISP at the
provider edge might have the advantage of diminishing potential MTU provider edge might have the advantage of diminishing potential MTU
issues, because the tunnel router is closer to the core, where links issues, because the Tunnel Router is closer to the core, where links
typically have higher MTUs than edge network links. typically have higher MTUs than edge network links.
2.1.3. Tunnel Routers Behind NAT 2.1.3. Tunnel Routers behind NAT
NAT in this section refers to IPv4 network address and port "NAT" in this section refers to IPv4 network address and port
translation. translation.
2.1.3.1. ITR 2.1.3.1. ITR
_.--. _.--. _.--. _.--.
,-'' `--. +-------+ ,-'' `--. ,-'' `--. +-------+ ,-'' `--.
' EID ` (Private) | NAT | (Public) ,' RLOC `. ' EID ` (Private) | NAT | (Public) ,' RLOC `.
( )---[ITR]---| |---------( ) ( )---[ITR]---| |---------( )
. space ,' (Address) | Box |(Address) . space ,' . space ,' (Address) | Box |(Address) . space ,'
`--. _.-' +-------+ `--. _.-' `--. _.-' +-------+ `--. _.-'
`--'' `--'' `--'' `--''
Figure 3: ITR behind NAT Figure 3: ITR behind NAT
Packets encapsulated by an ITR are just UDP packets from a NAT Packets encapsulated by an ITR are just UDP packets from a NAT
device's point of view, and they are handled like any UDP packet, device's point of view, and they are handled like any UDP packet;
there are no additional requirements for LISP data packets. there are no additional requirements for LISP data packets.
Map-Requests sent by an ITR, which create the state in the NAT table, Map-Requests sent by an ITR, which create the state in the NAT table,
have a different 5-tuple in the IP header than the Map-Reply have a different 5-tuple in the IP header than the Map-Reply
generated by the authoritative ETR. Since the source address of this generated by the authoritative ETR. Since the source address of this
packet is different from the destination address of the request packet is different from the destination address of the request
packet, no state will be matched in the NAT table and the packet will packet, no state will be matched in the NAT table and the packet will
be dropped. To avoid this, the NAT device has to do the following: be dropped. To avoid this, the NAT device has to do the following:
o Send all UDP packets with source port 4342, regardless of the o Send all UDP packets with source port 4342, regardless of the
destination port, to the RLOC of the ITR. The most simple way to destination port, to the RLOC of the ITR. The simplest way to
achieve this is configuring 1:1 NAT mode from the external RLOC of achieve this is configuring 1:1 NAT mode from the external RLOC of
the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer the NAT device to the ITR's RLOC (called "DMZ" mode in consumer
broadband routers). broadband routers).
o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in
the payload. the payload.
This setup supports only a single ITR behind the NAT device. This setup supports only a single ITR behind the NAT device.
2.1.3.2. ETR 2.1.3.2. ETR
An ETR placed behind NAT is reachable from the outside by the An ETR placed behind NAT is reachable from the outside by the
Internet-facing locator of the NAT device. It needs to know this Internet-facing locator of the NAT device. It needs to know this
locator (and configure a loopback interface with it), so that it can locator (and configure a loopback interface with it), so that it can
use it in Map-Reply and Map-Register messages. Thus support for use it in Map-Reply and Map-Register messages. Thus, support for
dynamic locators for the mapping database is needed in LISP dynamic locators for the mapping database is needed in LISP
equipment. equipment.
Again, only one ETR behind the NAT device is supported. Again, only one ETR behind the NAT device is supported.
_.--. _.--. _.--. _.--.
,-'' `--. +-------+ ,-'' `--. ,-'' `--. +-------+ ,-'' `--.
' EID ` (Private) | NAT | (Public) ,' RLOC `. ' EID ` (Private) | NAT | (Public) ,' RLOC `.
( )---[ETR]---| |---------( ) ( )---[ETR]---| |---------( )
. space ,' (Address) | Box |(Address) . space ,' . space ,' (Address) | Box |(Address) . space ,'
`--. _.-' +-------+ `--. _.-' `--. _.-' +-------+ `--. _.-'
`--'' `--'' `--'' `--''
Figure 4: ETR behind NAT Figure 4: ETR behind NAT
2.1.3.3. Additional Notes 2.1.3.3. Additional Notes
An implication of the issues described above is that LISP sites with An implication of the issues described above is that LISP sites with
xTRs can not be behind carrier based NATs, since two different sites xTRs cannot be behind carrier-based NATs, since two different sites
would collide on the port forwarding. An alternative to static hole- would collide on the same forwarded UDP port. An alternative to
punching to explore is the use of the Port Control Protocol (PCP) static hole-punching to explore is the use of the Port Control
[RFC6887]. Protocol (PCP) [RFC6887].
We only include this scenario due to completeness, to show that a We only include this scenario due to completeness, to show that a
LISP site can be deployed behind NAT, should it become necessary. LISP site can be deployed behind NAT should it become necessary.
However, LISP deployments behind NAT should be avoided, if possible. However, LISP deployments behind NAT should be avoided, if possible.
2.2. Functional Models with Tunnel Routers 2.2. Functional Models with Tunnel Routers
This section describes how certain LISP deployments can provide This section describes how certain LISP deployments can provide
network functions. network functions.
2.2.1. Split ITR/ETR 2.2.1. Split ITR/ETR
In a simple LISP deployment, xTRs are located at the border of the In a simple LISP deployment, xTRs are located at the border of the
LISP site (see Section 2.1.1). In this scenario packets are routed LISP site (see Section 2.1.1). In this scenario, packets are routed
inside the domain according to the EID. However, more complex inside the domain according to the EID. However, more complex
networks may want to route packets according to the destination RLOC. networks may want to route packets according to the destination RLOC.
This would enable them to choose the best egress point. This would enable them to choose the best egress point.
The LISP specification separates the ITR and ETR functionality and The LISP specification separates the ITR and ETR functionality and
allows both entities to be deployed in separated network equipment. allows both entities to be deployed in separated network equipment.
ITRs can be deployed closer to the host (i.e., access routers). This ITRs can be deployed closer to the host (i.e., access routers). This
way packets are encapsulated as soon as possible, and egress point way, packets are encapsulated as soon as possible, and egress point
selection is driven by operational policy. In turn, ETRs can be selection is driven by operational policy. In turn, ETRs can be
deployed at the border routers of the network, and packets are deployed at the border routers of the network, and packets are
decapsulated as soon as possible. Once decapsulated, packets are decapsulated as soon as possible. Once decapsulated, packets are
routed based on destination EID, according to internal routing routed based on the destination EID according to internal routing
policy. policy.
In the following figure we can see an example. The Source (S) We can see an example in Figure 5. The Source (S) transmits packets
transmits packets using its EID and in this particular case packets using its EID, and in this particular case packets are encapsulated
are encapsulated at ITR_1. The encapsulated packets are routed at ITR_1. The encapsulated packets are routed inside the domain
inside the domain according to the destination RLOC, and can egress according to the destination RLOC and can egress the network through
the network through the best point (i.e., closer to the RLOC's AS). the best point (i.e., closer to the RLOC's Autonomous System (AS)).
On the other hand, inbound packets are received by ETR_1 which On the other hand, inbound packets are received by ETR_1, which
decapsulates them. Then packets are routed towards S according to decapsulates them. Then, packets are routed towards S according to
the EID, again following the best path. the EID, again following the best path.
+---------------------------------------+ +---------------------------------------+
| | | |
| +-------+ +-------+ +-------+ | +-------+ +-------+ +-------+
| | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A | | | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A |
| +-------+ | +-------+ +-------+ | +-------+ | +-------+ +-------+
| +-+ | | | | +-+ | | |
| |S| | IGP | | | |S| | IGP | |
| +-+ | | | | +-+ | | |
| +-------+ | +-------+ +-------+ | +-------+ | +-------+ +-------+
| | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B |
| +-------+ +-------+ +-------+ | +-------+ +-------+ +-------+
| | | |
+---------------------------------------+ +---------------------------------------+
Figure 5: Split ITR/ETR Scenario Figure 5: Split ITR/ETR Scenario
This scenario has a set of implications: This scenario has a set of implications:
o The site must carry more specific routes in order to choose the o The site must carry more-specific routes in order to choose the
best egress point, and typically BGP is used for this, increasing best egress point, and typically BGP is used for this, increasing
the complexity of the network. However, this is usually already the complexity of the network. However, this is usually already
the case for LISP sites that would benefit from this scenario. the case for LISP sites that would benefit from this scenario.
o If the site is multihomed to different ISPs and any of the o If the site is multihomed to different ISPs and any of the
upstream ISPs are doing uRPF filtering, this scenario may become upstream ISPs are doing unicast reverse path forwarding (uRPF)
impractical. ITRs need to determine the exit ETR, for setting the filtering, this scenario may become impractical. To set the
correct source RLOC in the encapsulation header. This adds correct source RLOC in the encapsulation header, ITRs need to
complexity and reliability concerns. first determine which ETR will be used by the outgoing packet.
This adds complexity and reliability concerns.
o In LISP, ITRs set the reachability bits when encapsulating data o In LISP, ITRs set the reachability bits when encapsulating data
packets. Hence, ITRs need a mechanism to be aware of the liveness packets. Hence, ITRs need a mechanism to be aware of the liveness
of all ETRs serving their site. of all ETRs serving their site.
o MTU within the site network must be large enough to accommodate o The MTU within the site network must be large enough to
encapsulated packets. accommodate encapsulated packets.
o In this scenario, each ITR is serving fewer hosts than in the case o In this scenario, each ITR is serving fewer hosts than in the case
when it is deployed at the border of the network. It has been when it is deployed at the border of the network. It has been
shown that cache hit ratio grows logarithmically with the amount shown that the cache hit rate grows logarithmically with the
of users [CACHE]. Taking this into account, when ITRs are amount of users [CACHE]. Taking this into account, when ITRs are
deployed closer to the host the effectiveness of the mapping cache deployed closer to the host the effectiveness of the mapping cache
may be lower (i.e., the miss ratio is higher). Another may be lower (i.e., the miss rate is higher). Another consequence
consequence of this is that the site may transmit a higher amount of this is that the site may transmit a higher amount of
of Map-Requests, increasing the load on the distributed mapping Map-Requests, increasing the load on the distributed mapping
database. database.
o By placing the ITRs inside the site, they will still need global o By placing the ITRs inside the site, they will still need global
RLOCs, and this may add complexity to intra-site routing RLOCs. This may add complexity to intra-site routing
configuration, and further intra-site issues when there is a configurations and more intra-site issues when there is a change
change of providers. of providers.
2.2.2. Inter-Service Provider Traffic Engineering 2.2.2. Inter-Service-Provider Traffic Engineering
At the time of this writing, if two ISPs want to control their At the time of this writing, if two ISPs want to control their
ingress TE policies for transit traffic between them, they need to ingress TE policies for transit traffic between them, they need to
rely on existing BGP mechanisms. This typically means deaggregating rely on existing BGP mechanisms. This typically means deaggregating
prefixes to choose on which upstream link packets should enter. This prefixes to choose on which upstream link packets should enter. This
is either not feasible (if fine-grained per-customer control is either is not feasible (if fine-grained per-customer control is
required, the very specific prefixes may not be propagated) or required, the very-specific prefixes may not be propagated) or
increases DFZ table size. increases DFZ table size.
Typically, LISP is seen applicable only to stub networks, however the Typically, LISP is seen as applicable only to stub networks; however,
LISP protocol can be also applied in a recursive manner, providing LISP can also be applied in a recursive manner, providing service
service provider ingress/egress TE capabilities without impacting the provider ingress/egress TE capabilities without impacting the DFZ
DFZ table size. table size.
In order to implement this functionality with LISP consider the In order to implement this functionality with LISP, consider the
scenario depicted in Figure 6. The two ISPs willing to achieve scenario depicted in Figure 6. The two ISPs willing to achieve
ingress/egress TE are labeled as ISP_A and ISP_B, they are servicing ingress/egress TE are labeled as ISP_A and ISP_B. They are servicing
Stub1 and Stub2 respectively, both are required to be LISP sites with Stub1 and Stub2, respectively. Both are required to be LISP sites
their own xTRs. In this scenario we assume that Stub1 and Stub2 are with their own xTRs. In this scenario, we assume that Stub1 and
communicating with each other and thus, ISP_A and ISP_B offer transit Stub2 are communicating with each other; thus, ISP_A and ISP_B offer
for such communications. ISP_A has RLOC_A1 and RLOC_A2 as upstream transit for such communications. ISP_A has RLOC_A1 and RLOC_A2 as
IP addresses while ISP_B has RLOC_B1 and RLOC_B2. The shared goal upstream IP addresses, while ISP_B has RLOC_B1 and RLOC_B2. The
among ISP_A and ISP_B is to control the transit traffic flow between shared goal among ISP_A and ISP_B is to control the transit traffic
RLOC_A1/A2 and RLOC_B1/B2. flow between RLOC_A1/A2 and RLOC_B1/B2.
_.--. _.--.
Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub2 Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub2
\ | R_A1|----,' `. ---|R_B1 | / \ | R_A1|----,' `. ---|R_B1 | /
--| | ( Transit ) | |-- --| | ( Transit ) | |--
... .../ | R_A2|-----. ,' ---|R_B2 | \... ... ... .../ | R_A2|-----. ,' ---|R_B2 | \... ...
+-------+ `--. _.-' +-------+ +-------+ `--. _.-' +-------+
... ... ISP_A `--'' ISP_B ... ... ... ... ISP_A `--'' ISP_B ... ...
Figure 6: Inter-Service provider TE scenario Figure 6: Inter-Service-Provider TE Scenario
Both ISPs deploy xTRs on on RLOC_A1/A2 and RLOC_B1/B2 respectively Both ISPs deploy xTRs on RLOC_A1/A2 and RLOC_B1/B2, respectively and
and reach a bilateral agreement to deploy their own private mapping reach a bilateral agreement to deploy their own private mapping
system. This mapping system contains bindings between the RLOCs of system. This mapping system contains bindings between the RLOCs of
Stub1 and Stub2 (owned by ISP_A and ISP_B respectively) and Stub1 and Stub2 (owned by ISP_A and ISP_B, respectively) and RLOC_A1/
RLOC_A1/A2 and RLOC_B1/B2. Such bindings are in fact the TE policies A2 and RLOC_B1/B2. Such bindings are in fact the TE policies between
between both ISPs and the convergence time is expected to be fast, both ISPs, and the convergence time is expected to be fast, since
since ISPs only have to update/query a mapping to/from the database. ISPs only have to update/query a mapping to/from the database.
The packet flow is as follows. First, a packet originated at Stub1 The packet flow is as follows. First, a packet originated at Stub1
towards Stub2 is LISP encapsulated by Stub1's xTR. The xTR of ISP_A towards Stub2 is LISP encapsulated by Stub1's xTR. The xTR of ISP_A
recursively encapsulates it and, according to the TE policies stored recursively encapsulates it, and according to the TE policies stored
in the private mapping system, the ISP_A xTR chooses RLOC_B1 or in the private mapping system the ISP_A xTR chooses RLOC_B1 or
RLOC_B2 as the outer encapsulation destination. Note that the packet RLOC_B2 as the outer encapsulation destination. Note that the packet
transits between ISP_A and ISP_B double-encapsulated. Upon reception transits between ISP_A and ISP_B double-encapsulated. Upon reception
at the xTR of ISP_B the packet is decapsulated and sent towards Stub2 at the xTR of ISP_B, the packet is decapsulated and sent towards
which performs the last decapsulation. Stub2, which performs the last decapsulation.
This deployment scenario, which uses recursive LISP, includes three This deployment scenario, which uses recursive LISP, includes three
important caveats. First, it is intended to be deployed between only important caveats. First, it is intended to be deployed between only
two ISPs. If more than two ISPs use this approach, then the xTRs two ISPs. If more than two ISPs use this approach, then either the
deployed at the participating ISPs must either query multiple mapping xTRs deployed at the participating ISPs must query multiple mapping
systems, or the ISPs must agree on a common shared mapping system. systems, or the ISPs must agree on a common shared mapping system.
Furthermore, keeping this deployment scenario restricted to only two Furthermore, keeping this deployment scenario restricted to only two
ISPs maintains the solution scalable, given that only two entities ISPs maintains a scalable solution, given that only two entities need
need to agree on using recursive LISP, and only one private mapping to agree on using recursive LISP and only one private mapping system
system is involved. is involved.
Second, the scenario is only recommended for ISPs providing Second, the scenario is only recommended for ISPs providing
connectivity to LISP sites, such that source RLOCs of packets to be connectivity to LISP sites, such that source RLOCs of packets to be
recursively encapsulated belong to said ISP. Otherwise the recursively encapsulated belong to said ISP. Otherwise, the
participating ISPs must register prefixes they do not own in the participating ISPs must register prefixes they do not own in the
above mentioned private mapping system. This results in either above-mentioned private mapping system. This results in either
requiring complex authentication mechanisms or enabling simple requiring complex authentication mechanisms or enabling simple
traffic redirection attacks. Failure to follow these recommendations traffic redirection attacks. Failure to follow these recommendations
may lead to operational security issues when deploying this scenario. may lead to operational security issues when deploying this scenario.
And third, recursive encapsulation models are typically complex to And third, recursive encapsulation models are typically complex to
troubleshoot and debug. troubleshoot and debug.
Besides these recommendations, the main disadvantages of this Besides these recommendations, the main disadvantages of this
deployment case are: deployment case are:
o Extra LISP header is needed. This increases the packet size and o An extra LISP header is needed. This increases the packet size
requires that the MTU between both ISPs accommodates double- and requires that the MTU between both ISPs accommodate double-
encapsulated packets. encapsulated packets.
o The ISP ITR must encapsulate packets and therefore must know the o The ISP ITR must encapsulate packets and therefore must know the
RLOC-to-RLOC binding. These bindings are stored in a mapping RLOC-to-RLOC bindings. These bindings are stored in a mapping
database and may be cached in the ITR's mapping cache. Cache database and may be cached in the ITR's mapping cache. Cache
misses lead to an additional lookup latency, unless a push based misses lead to an additional lookup latency, unless a push-based
mapping system is used for the private mapping system. mapping system is used for the private mapping system.
o The operational overhead of maintaining the shared mapping o Maintaining the shared mapping database involves operational
database. overhead.
2.3. Summary and Feature Matrix 2.3. Summary and Feature Matrix
When looking at the deployment scenarios and functional models above, When looking at the deployment scenarios and functional models above,
there are several things to consider when choosing the approprate there are several things to consider when choosing an appropriate
one, depending on the type of the organization doing the deployment. model, depending on the type of the organization doing the
deployment.
For home users and small site who wish to multihome and have control For home users and small sites that wish to multihome and have
over their ISP options, the "CE" scenario offers the most advantages: control over their ISP options, the "CE" scenario offers the most
it's simple to deploy, in some cases it only requires a software advantages: it's simple to deploy, and in some cases it only requires
upgrade of the CPE, getting mapping serice, and configuring the a software upgrade of the Customer Premises Equipment (CPE), getting
router. It ratains control of TE and choosing upstreams by the user. mapping service, and configuring the router. It retains control of
It doesn't provide too many advantages to ISPs, due to the lessened TE and choosing upstreams by the user. It doesn't provide too many
dependence on their services in case of multihomed clients. It is advantages to ISPs, due to the lessened dependence on their services
also unlikely that ISP wiching to offer LISP to their customers will in cases of multihomed clients. It is also unlikely that ISPs
choose the "CE" placement: they need to send a technician to each wishing to offer LISP to their customers will choose the "CE" model,
customer, and potentially a new CPE. Even if they have remote as they would need to send a technician to each customer and,
control over the router, and a software upgrade could add LISP potentially, a new CPE device. Even if they have remote control over
support, the operation is too risky. the router and a software upgrade could add LISP support, the
operation is too risky.
For a network operator a good option to deploy is the "PE" scenario, For a network operator, a good option to deploy is the "PE" scenario,
unless a hardware upgrade is required for its edge routers to support unless a hardware upgrade is required for its edge routers to support
LISP (in which case upgrading CPEs may be simpler). It retains LISP (in which case upgrading CPEs may be simpler). It retains
control of TE, choice of PETR, and MS/MR. It also lowers potential control of TE as well as the choice of Proxy Egress Tunnel Router
MTU issues, as dicussed above. Network operators should also explore (PETR) and Map-Server/Map-Resolver. It also lowers potential MTU
the "Inter-SP TE" (recursive) functional model for their TE needs. issues, as discussed above. Network operators should also explore
the "inter-service-provider TE" (recursive) functional model for
their TE needs.
Large organizations can benefit the most from the "Split ITR/ETR" To optimize their traffic flow, large organizations can benefit the
functional model, to optimize their traffic flow. most from the "split ITR/ETR" functional model.
The following table gives a quick overview of the features supported The following table gives a quick overview of the features supported
by each of the deployment scenarios discussed above (marked with an by each of the deployment scenarios discussed above (marked with an
"x") in the appropriate column: "CE" for customer edge, "PE" for "x" in the appropriate column): "CE" for customer edge, "PE" for
provider edge, "Split" for split ITR/ETR, and "Recursive" for inter- provider edge, "Split" for split ITR/ETR, and "Recursive" for
service provider traffic engineering. The discussed features inter-service-provider traffic engineering. The discussed features
include: include:
Control of ingress TE: The scenario allows the LISP site to easily Control of ingress TE: This scenario allows the LISP site to easily
control LISP ingress traffic engineering policies. control LISP ingress traffic engineering policies.
No modifcations to existing int. network infrastruncture: The No modifications to existing int. network infrastructure: This
scenario doesn't require the LISP site to modify internal network scenario doesn't require the LISP site to modify internal network
configurations. configurations.
Loc-Status-Bits sync: The scenario allows easy synchronization of Locator-Status-Bits sync: This scenario allows easy synchronization
the Locator Status Bits. of the Locator Status Bits.
MTU/PMTUD issues minimized: The scenario minimizes potential MTU and MTU/PMTUD issues minimized: The scenario minimizes potential MTU and
Path MTU Discovery issues. Path MTU Discovery (PMTUD) issues.
Feature CE PE Split Recursive NAT Feature CE PE Split Recursive NAT
-------------------------------------------------------------------- --------------------------------------------------------------------
Control of ingress TE x - x x x Control of ingress TE x - x x x
No modifications to existing No modifications to existing
int. network infrastructure x x - - x int. network infrastructure x x - - x
Loc-Status-Bits sync x - x x - Locator-Status-Bits sync x - x x -
MTU/PMTUD issues minimized - x - - - MTU/PMTUD issues minimized - x - - -
3. Map Resolvers and Map Servers 3. Map-Servers and Map-Resolvers
Map Resolvers and Map Servers make up the LISP mapping system and Map-Servers and Map-Resolvers make up the LISP mapping system and
provide a means to find authoritative EID-to-RLOC mapping provide a means to find authoritative EID-to-RLOC mapping
information, conforming to [RFC6833]. They are meant to be deployed information, conforming to [RFC6833]. They are meant to be deployed
in RLOC space, and their operation behind NAT is not supported. in RLOC space, and their operation behind NAT is not supported.
3.1. Map Servers 3.1. Map-Servers
The Map Server learns EID-to-RLOC mapping entries from an The Map-Server learns EID-to-RLOC mapping entries from an
authoritative source and publishes them in the distributed mapping authoritative source and publishes them in the distributed mapping
database. These entries are learned through authenticated Map- database. These entries are learned through authenticated
Register messages sent by authoritative ETRs. Also, upon reception Map-Register messages sent by authoritative ETRs. Also, upon
of a Map-Request, the Map Server verifies that the destination EID reception of a Map-Request, the Map-Server verifies that the
matches an EID-prefix for which it is authoritative for, and then re- destination EID matches an EID-Prefix for which it is authoritative
encapsulates and forwards it to a matching ETR. Map Server and then re-encapsulates and forwards it to a matching ETR.
functionality is described in detail in [RFC6833]. Map-Server functionality is described in detail in [RFC6833].
The Map Server is provided by a Mapping Service Provider (MSP). The The Map-Server is provided by a Mapping Service Provider (MSP). The
MSP participates in the global distributed mapping database MSP participates in the global distributed mapping database
infrastructure, by setting up connections to other participants, infrastructure by setting up connections to other participants
according to the specific mapping system that is employed (e.g., ALT according to the specific mapping system that is employed (e.g.,
[RFC6836], DDT [I-D.ietf-lisp-ddt]). Participation in the mapping Alternative Logical Topology (ALT) [RFC6836], Delegated Database Tree
database, and the storing of EID-to-RLOC mapping data is subject to (DDT) [LISP-DDT]). Participation in the mapping database and the
the policies of the "root" operators, who should check ownership storing of EID-to-RLOC mapping data are subject to the policies of
rights for the EID prefixes stored in the database by participants. the "root" operators, who should check ownership rights for the
These policies are out of the scope of this document. EID-Prefixes stored in the database by participants. These policies
are out of scope for this document.
The LISP DDT protocol is used by LISP Mapping Service providers to The LISP DDT protocol is used by LISP MSPs to provide reachability
provide reachability between those providers' Map-Resolvers and Map- between those providers' Map-Resolvers and Map-Servers. The DDT root
Servers. The DDT Root is currently operated by a collection of is currently operated by a collection of organizations on an open
organizations on an open basis. See [DDT-ROOT] for more details. basis. See [DDT-ROOT] for more details. Similarly to the DNS root,
Similarly to the DNS root, it has several different server instances it has several different server instances using names of the letters
using names of the letters of the Greek alphabet (alpha, delta, of the Greek alphabet (alpha, delta, etc.), operated by independent
etc.), operated by independent organizations. When this document was organizations. When this document was published, there were 6 such
published, there were 5 such instances, one of them being anycasted. instances, with one of them being anycasted. [DDT-ROOT] provides the
The Root provides the list of server instances on their web site and list of server instances on its web site and configuration files for
configuration files for several map server implementations. The DDT several Map-Server implementations. The DDT root and LISP Mapping
Root, and LISP Mapping Providers both rely on and abide by existing Providers both rely on and abide by existing allocation policies as
allocation policies by Regional Internet Registries to determine defined by Regional Internet Registries (RIRs) to determine prefix
prefix ownership for use as EIDs. ownership for use as EIDs.
It is expected that the DDT root organizations will continue to It is expected that the DDT root organizations will continue to
evolve in response to experimentation with LISP deployments for evolve in response to experimentation with LISP deployments for
Internet edge multi-homing and VPN use cases. Internet edge multihoming and VPN use cases.
In all cases, the MSP configures its Map Server(s) to publish the In all cases, the MSP configures its Map-Server(s) to publish the
prefixes of its clients in the distributed mapping database and start prefixes of its clients in the distributed mapping database and start
encapsulating and forwarding Map-Requests to the ETRs of the AS. encapsulating and forwarding Map-Requests to the ETRs of the AS.
These ETRs register their prefix(es) with the Map Server(s) through These ETRs register their prefix(es) with the Map-Server(s) through
periodic authenticated Map-Register messages. In this context, for periodic authenticated Map-Register messages. In this context, for
some LISP sites, there is a need for mechanisms to: some LISP sites, there is a need for mechanisms to:
o Automatically distribute EID prefix(es) shared keys between the o Automatically distribute EID-Prefix(es) shared keys between the
ETRs and the EID-registrar Map Server. ETRs and the EID-registrar Map-Server.
o Dynamically obtain the address of the Map Server in the ETR of the o Dynamically obtain the address of the Map-Server in the ETR of
AS. the AS.
The Map Server plays a key role in the reachability of the EID- The Map-Server plays a key role in the reachability of the
prefixes it is serving. On the one hand it is publishing these EID-Prefixes it is serving. On one hand, it is publishing these
prefixes into the distributed mapping database and on the other hand prefixes into the distributed mapping database, and on the other
it is encapsulating and forwarding Map-Requests to the authoritative hand, it is encapsulating and forwarding Map-Requests to the
ETRs of these prefixes. ITRs encapsulating towards EIDs under the authoritative ETRs of these prefixes. ITRs encapsulating towards
responsibility of a failed Map Server will be unable to look up any EIDs for which a failed Map-Server is responsible will be unable to
of their covering prefixes. The only exception are the ITRs that look up any of their covering prefixes. The only exceptions are the
already contain the mappings in their local cache. In this case ITRs ITRs that already contain the mappings in their local caches. In
can reach ETRs until the entry expires (typically 24 hours). For this case, ITRs can reach ETRs until the entry expires (typically
this reason, redundant Map Server deployments are desirable. A set 24 hours). For this reason, redundant Map-Server deployments are
of Map Servers providing high-availability service to the same set of desirable. A set of Map-Servers providing high-availability service
prefixes is called a redundancy group. ETRs are configured to send to the same set of prefixes is called a redundancy group. ETRs are
Map-Register messages to all Map Servers in the redundancy group. configured to send Map-Register messages to all Map-Servers in the
The configuration for fail-over (or load-balancing, if desired) among redundancy group. The configuration for fail-over (or
the members of the group depends on the technology behind the mapping load-balancing, if desired) among the members of the group depends on
system being deployed. Since ALT is based on BGP and DDT was the technology behind the mapping system being deployed. Since ALT
inspired from the Domain Name System (DNS), deployments can leverage is based on BGP and DDT takes its inspiration from the Domain Name
current industry best practices for redundancy in BGP and DNS. These System (DNS), deployments can leverage current industry best
best practices are out of the scope of this document. practices for redundancy in BGP and DNS. These best practices are
out of scope for this document.
Additionally, if a Map Server has no reachability for any ETR serving Additionally, if a Map-Server has no reachability for any ETR serving
a given EID block, it should not originate that block into the a given EID block, it should not originate that block into the
mapping system. mapping system.
3.2. Map Resolvers 3.2. Map-Resolvers
A Map Resolver is a network infrastructure component which accepts A Map-Resolver is a network infrastructure component that accepts
LISP encapsulated Map-Requests, typically from an ITR, and finds the LISP-encapsulated Map-Requests, typically from an ITR, and finds the
appropriate EID-to-RLOC mapping by consulting the distributed mapping appropriate EID-to-RLOC mapping by consulting the distributed mapping
database. Map Resolver functionality is described in detail in database. Map-Resolver functionality is described in detail in
[RFC6833]. [RFC6833].
Anyone with access to the distributed mapping database can set up a Anyone with access to the distributed mapping database can set up a
Map Resolver and provide EID-to-RLOC mapping lookup service. Map-Resolver and provide EID-to-RLOC mapping lookup service.
Database access setup is mapping system specific. Database access setup is mapping system specific.
For performance reasons, it is recommended that LISP sites use Map For performance reasons, it is recommended that LISP sites use
Resolvers that are topologically close to their ITRs. ISPs Map-Resolvers that are topologically close to their ITRs. ISPs
supporting LISP will provide this service to their customers, supporting LISP will provide this service to their customers,
possibly restricting access to their user base. LISP sites not in possibly restricting access to their user base. LISP sites not in
this position can use open access Map Resolvers, if available. this position can use open access Map-Resolvers, if available.
However, regardless of the availability of open access resolvers, the However, regardless of the availability of open access resolvers, the
MSP providing the Map Server(s) for a LISP site should also make MSP providing the Map-Server(s) for a LISP site should also make
available Map Resolver(s) for the use of that site. available Map-Resolver(s) for the use of that site.
In medium to large-size ASes, ITRs must be configured with the RLOC In medium- to large-size ASes, ITRs must be configured with the RLOC
of a Map Resolver, operation which can be done manually. However, in of a Map-Resolver; this type of operation can be done manually.
Small Office Home Office (SOHO) scenarios a mechanism for However, in Small Office/Home Office (SOHO) scenarios, a mechanism
autoconfiguration should be provided. for autoconfiguration should be provided.
One solution to avoid manual configuration in LISP sites of any size One solution to avoid manual configuration in LISP sites of any size
is the use of anycast RLOCs [RFC4786] for Map Resolvers similar to is the use of anycast [RFC4786] RLOCs for Map-Resolvers, similar to
the DNS root server infrastructure. Since LISP uses UDP the DNS root server infrastructure. Since LISP uses UDP
encapsulation, the use of anycast would not affect reliability. LISP encapsulation, the use of anycast would not affect reliability. LISP
routers are then shipped with a preconfigured list of well know Map routers are then shipped with a preconfigured list of well-known
Resolver RLOCs, which can be edited by the network administrator, if Map-Resolver RLOCs, which can be edited by the network administrator,
needed. if needed.
The use of anycast also helps improve mapping lookup performance. The use of anycast also helps improve mapping lookup performance.
Large MSPs can increase the number and geographical diversity of Large MSPs can increase the number and geographical diversity of
their Map Resolver infrastructure, using a single anycasted RLOC. their Map-Resolver infrastructure, using a single anycasted RLOC.
Once LISP deployment is advanced enough, very large content providers Once LISP deployment is advanced enough, very large content providers
may also be interested running this kind of setup, to ensure minimal may also be interested in running this kind of setup, to ensure
connection setup latency for those connecting to their network from minimal connection setup latency for those connecting to their
LISP sites. network from LISP sites.
While Map Servers and Map Resolvers implement different While Map-Servers and Map-Resolvers implement different
functionalities within the LISP mapping system, they can coexist on functionalities within the LISP mapping system, they can coexist on
the same device. For example, MSPs offering both services, can the same device. For example, MSPs offering both services can deploy
deploy a single Map Resolver/Map Server in each PoP where they have a a single Map-Resolver/Map-Server in each PoP where they have a
presence. presence.
4. Proxy Tunnel Routers 4. Proxy Tunnel Routers
4.1. P-ITR 4.1. PITRs
Proxy Ingress Tunnel Routers (P-ITRs) are part of the non-LISP/LISP Proxy Ingress Tunnel Routers (PITRs) are part of the non-LISP/LISP
transition mechanism, allowing non-LISP sites to reach LISP sites. transition mechanism, allowing non-LISP sites to reach LISP sites.
They announce via BGP certain EID prefixes (aggregated, whenever They announce via BGP certain EID-Prefixes (aggregated, whenever
possible) to attract traffic from non-LISP sites towards EIDs in the possible) to attract traffic from non-LISP sites towards EIDs in the
covered range. They do the mapping system lookup, and encapsulate covered range. They do the mapping system lookup and encapsulate
received packets towards the appropriate ETR. Note that for the received packets towards the appropriate ETR. Note that for the
reverse path LISP sites can reach non-LISP sites simply by not reverse path, LISP sites can reach non-LISP sites by simply not
encapsulating traffic. See [RFC6832] for a detailed description of encapsulating traffic. See [RFC6832] for a detailed description of
P-ITR functionality. PITR functionality.
The success of new protocols depends greatly on their ability to The success of new protocols depends greatly on their ability to
maintain backwards compatibility and inter-operate with the maintain backwards compatibility and interoperate with the
protocol(s) they intend to enhance or replace, and on the incentives protocol(s) they intend to enhance or replace, and on the incentives
to deploy the necessary new software or equipment. A LISP site needs to deploy the necessary new software or equipment. A LISP site needs
an interworking mechanism to be reachable from non-LISP sites. A an interworking mechanism to be reachable from non-LISP sites. A
P-ITR can fulfill this role, enabling early adopters to see the PITR can fulfill this role, enabling early adopters to see the
benefits of LISP, similar to tunnel brokers helping the transition benefits of LISP, similar to tunnel brokers helping the transition
from IPv4 to IPv6. A site benefits from new LISP functionality from IPv4 to IPv6. A site benefits from new LISP functionality
(proportionally with existing global LISP deployment) when going (proportionally with existing global LISP deployment) when migrating
LISP, so it has the incentives to deploy the necessary tunnel to LISP, so it has the incentives to deploy the necessary Tunnel
routers. In order to be reachable from non-LISP sites it has two Routers. In order to be reachable from non-LISP sites, it has two
options: keep announcing its prefix(es) with BGP, or have a P-ITR options: keep announcing its prefix(es) with BGP, or have a PITR
announce prefix(es) covering them. announce prefix(es) covering them.
If the goal of reducing the DFZ routing table size is to be reached, If the goal of reducing the DFZ routing table size is to be reached,
the second option is preferred. Moreover, the second option allows the second option is preferred. Moreover, the second option allows
LISP-based ingress traffic engineering from all sites. However, the LISP-based ingress traffic engineering from all sites. However, the
placement of P-ITRs significantly influences performance and placement of PITRs significantly influences performance and
deployment incentives. Section 5 is dedicated to the migration to a deployment incentives. Section 5 is dedicated to the migration to a
LISP-enabled Internet, and includes deployment scenarios for P-ITRs. LISP-enabled Internet and includes deployment scenarios for PITRs.
4.2. P-ETR 4.2. PETRs
In contrast to P-ITRs, P-ETRs are not required for the correct In contrast to PITRs, PETRs are not required for the correct
functioning of all LISP sites. There are two cases, where they can functioning of all LISP sites. There are two cases where they can be
be of great help: of great help:
o LISP sites with unicast reverse path forwarding (uRPF) o LISP sites with unicast reverse path forwarding (uRPF)
restrictions, and restrictions, and
o Communication between sites using different address family RLOCs. o Communication between sites using different address family RLOCs.
In the first case, uRPF filtering is applied at their upstream PE In the first case, uRPF filtering is applied at the LISP site's
router. When forwarding traffic to non-LISP sites, an ITR does not upstream provider's PE router. When forwarding traffic to non-LISP
encapsulate packets, leaving the original IP headers intact. As a sites, an ITR does not encapsulate packets, leaving the original IP
result, packets will have EIDs in their source address. Since we are headers intact. As a result, packets will have EIDs in their source
discussing the transition period, we can assume that a prefix address. Since we are discussing the transition period, we can
covering the EIDs belonging to the LISP site is advertised to the assume that a prefix covering the EIDs belonging to the LISP site is
global routing tables by a P-ITR, and the PE router has a route advertised to the global routing tables by a PITR, and the PE router
towards it. However, the next hop will not be on the interface has a route towards it. However, the next hop will not be on the
towards the CE router, so non-encapsulated packets will fail uRPF interface towards the CE router, so non-encapsulated packets will
checks. fail uRPF checks.
To avoid this filtering, the affected ITR encapsulates packets To avoid this filtering, the affected ITR encapsulates packets
towards the locator of the P-ETR for non-LISP destinations. Now the towards the locator of the PETR for non-LISP destinations. Now the
source address of the packets, as seen by the PE router is the ITR's source address of the packets, as seen by the PE router, is the ITR's
locator, which will not fail the uRPF check. The P-ETR then locator, which will not fail the uRPF check. The PETR then
decapsulates and forwards the packets. decapsulates and forwards the packets.
The second use case is IPv4-to-IPv6 transition. Service providers The second use case is IPv4-to-IPv6 transition. Service providers
using older access network hardware, which only supports IPv4 can using older access network hardware that only supports IPv4 can still
still offer IPv6 to their clients, by providing a CPE device running offer IPv6 to their clients by providing a CPE device running LISP,
LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP and PETR(s) for accessing IPv6-only non-LISP sites and LISP sites,
sites, with IPv6-only locators. Packets originating from the client with IPv6-only locators. Packets originating from the client LISP
LISP site for these destinations would be encapsulated towards the site for these destinations would be encapsulated towards the PETR's
P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network, IPv4 locator. The PETR is in a native IPv6 network, decapsulating
decapsulating and forwarding packets. For non-LISP destination, the and forwarding packets. For non-LISP destinations, the packet
packet travels natively from the P-ETR. For LISP destinations with travels natively from the PETR. For LISP destinations with IPv6-only
IPv6-only locators, the packet will go through a P-ITR, in order to locators, the packet will go through a PITR in order to reach its
reach its destination. destination.
For more details on P-ETRs see [RFC6832]. For more details on PETRs, see [RFC6832].
P-ETRs can be deployed by ISPs wishing to offer value-added services PETRs can be deployed by ISPs wishing to offer value-added services
to their customers. As is the case with P-ITRs, P-ETRs too may to their customers. As is the case with PITRs, PETRs too may
introduce path stretch (the ratio between the cost of the selected introduce path stretch (the ratio between the cost of the selected
path and that of the optimal path). Because of this the ISP needs to path and that of the optimal path). Because of this, the ISP needs
consider the tradeoff of using several devices, close to the to consider the tradeoff of using several devices close to the
customers, to minimize it, or few devices, farther away from the customers to minimize it, or fewer devices farther away from the
customers, minimizing cost instead. customers to minimize cost instead.
Since the deployment incentives for P-ITRs and P-ETRs are different, Since the deployment incentives for PITRs and PETRs are different, it
it is likely they will be deployed in separate devices, except for is likely that they will be deployed in separate devices, except for
the CDN case, which may deploy both in a single device. the Content Delivery Network (CDN) case, which may deploy both in a
single device.
In all cases, the existence of a P-ETR involves another step in the In all cases, the existence of a PETR involves another step in the
configuration of a LISP router. CPE routers, which are typically configuration of a LISP router. CPE routers, which are typically
configured by DHCP, stand to benefit most from P-ETRs. configured by DHCP, stand to benefit most from PETRs.
Autoconfiguration of the P-ETR locator could be achieved by a DHCP Autoconfiguration of the PETR locator could be achieved by a DHCP
option, or adding a P-ETR field to either Map-Notifys or Map-Replies. option or by adding a PETR field to either Map-Notify or Map-Reply
messages.
5. Migration to LISP 5. Migration to LISP
This section discusses a deployment architecture to support the This section discusses a deployment architecture to support the
migration to a LISP-enabled Internet. The loosely defined terms of migration to a LISP-enabled Internet. The loosely defined terms
"early transition phase", "late transition phase", and "LISP Internet "early transition phase", "late transition phase", and "LISP Internet
phase" refer to time periods when LISP sites are a minority, a phase" refer to time periods when LISP sites are a minority, a
majority, or represent all edge networks respectively. majority, or represent all edge networks, respectively.
5.1. LISP+BGP 5.1. LISP+BGP
For sites wishing to go LISP with their PI prefix the least For sites wishing to migrate to LISP with their Provider-Independent
disruptive way is to upgrade their border routers to support LISP, (PI) prefix, the least disruptive way is to upgrade their border
register the prefix into the LISP mapping system, but keep announcing routers to support LISP and register the prefix into the LISP mapping
it with BGP as well. This way LISP sites will reach them over LISP, system, but to keep announcing it with BGP as well. This way, LISP
while legacy sites will be unaffected by the change. The main sites will reach them over LISP, while legacy sites will be
disadvantage of this approach is that no decrease in the DFZ routing unaffected by the change. The main disadvantage of this approach is
table size is achieved. Still, just increasing the number of LISP that no decrease in the DFZ routing table size is achieved. Still,
sites is an important gain, as an increasing LISP/non-LISP site ratio just increasing the number of LISP sites is an important gain, as an
may decrease the need for BGP-based traffic engineering that leads to increasing LISP/non-LISP site ratio may decrease the need for
prefix deaggregation. That, in turn, may lead to a decrease in the BGP-based traffic engineering that leads to prefix deaggregation.
DFZ size and churn in the late transition phase. That, in turn, may lead to a decrease in the DFZ size and churn in
the late transition phase.
This scenario is not limited to sites that already have their This scenario is not limited to sites that already have their
prefixes announced with BGP. Newly allocated EID blocks could follow prefixes announced with BGP. Newly allocated EID blocks could follow
this strategy as well during the early LISP deployment phase, this strategy as well during the early LISP deployment phase,
depending on the cost/benefit analysis of the individual networks. depending on the cost/benefit analysis of the individual networks.
Since this leads to an increase in the DFZ size, the following Since this leads to an increase in the DFZ size, the following
architecture should be preferred for new allocations. architecture should be preferred for new allocations.
5.2. Mapping Service Provider (MSP) P-ITR Service 5.2. Mapping Service Provider (MSP) PITR Service
In addition to publishing their clients' registered prefixes in the In addition to publishing their clients' registered prefixes in the
mapping system, MSPs with enough transit capacity can offer them mapping system, MSPs with enough transit capacity can offer PITR
P-ITR service as a separate service. This service is especially service to them as a separate service. This service is especially
useful for new PI allocations, to sites without existing BGP useful for new PI allocations to sites without existing BGP
infrastructure, that wish to avoid BGP altogether. The MSP announces infrastructure wishing to avoid BGP altogether. The MSP announces
the prefix into the DFZ, and the client benefits from ingress traffic the prefix into the DFZ, and the client benefits from ingress traffic
engineering without prefix deaggregation. The downside of this engineering without prefix deaggregation. The downside of this
scenario is adding path stretch. scenario is added path stretch.
Routing all non-LISP ingress traffic through a third party which is Routing all non-LISP ingress traffic through a third party that is
not one of its ISPs is only feasible for sites with modest amounts of not one of its ISPs is only feasible for sites with modest amounts of
traffic (like those using the IPv6 tunnel broker services today), traffic (like those using the IPv6 tunnel broker services today),
especially in the first stage of the transition to LISP, with a especially in the first stage of the transition to LISP, with a
significant number of legacy sites. This is because the handling of significant number of legacy sites. This is because the handling of
said traffic is likely to result in additional costs, which would be said traffic is likely to result in additional costs, which would be
passed down to the client. When the LISP/non-LISP site ratio becomes passed down to the client. When the LISP/non-LISP site ratio becomes
high enough, this approach can prove increasingly attractive. high enough, this approach can prove increasingly attractive.
Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix
deaggregation for traffic engineering purposes, resulting in slower deaggregation for traffic engineering purposes, resulting in slower
routing table increase in the case of new allocations and potential routing table increase in the case of new allocations and potential
decrease for existing ones. Moreover, MSPs serving different clients decrease for existing ones. Moreover, MSPs serving different clients
with adjacent aggregatable prefixes may lead to additional decrease, with adjacent aggregatable prefixes may lead to additional decrease,
but quantifying this decrease is subject to future research study. but quantifying this decrease is subject to future research study.
5.3. Proxy-ITR Route Distribution (PITR-RD) 5.3. Proxy-ITR Route Distribution (PITR-RD)
Instead of a LISP site, or the MSP, announcing their EIDs with BGP to Instead of a LISP site or the MSP announcing its EIDs with BGP to the
the DFZ, this function can be outsourced to a third party, a P-ITR DFZ, this function can be outsourced to a third party, a PITR Service
Service Provider (PSP). This will result in a decrease of the Provider (PSP). This will result in a decrease in operational
operational complexity both at the site and at the MSP. complexity at both the site and the MSP.
The PSP manages a set of distributed P-ITR(s) that will advertise the The PSP manages a set of distributed PITR(s) that will advertise the
corresponding EID prefixes through BGP to the DFZ. These P-ITR(s) corresponding EID-Prefixes through BGP to the DFZ. These PITRs will
will then encapsulate the traffic they receive for those EIDs towards then encapsulate the traffic they receive for those EIDs towards the
the RLOCs of the LISP site, ensuring their reachability from non-LISP RLOCs of the LISP site, ensuring their reachability from non-LISP
sites. sites.
While it is possible for a PSP to manually configure each client's While it is possible for a PSP to manually configure each client's
EID routes to be announced, this approach offers little flexibility EID-Routes to be announced, this approach offers little flexibility
and is not scalable. This section presents a scalable architecture and is not scalable. This section presents a scalable architecture
that offers automatic distribution of EID routes to LISP sites and that offers automatic distribution of EID-Routes to LISP sites and
service providers. service providers.
The architecture requires no modification to existing LISP network The architecture requires no modification to existing LISP network
elements, but it introduces a new (conceptual) network element, the elements, but it introduces a new (conceptual) network element, the
EID Route Server, defined as a router that either propagates routes EID-Route Server, which is defined as a router that either propagates
learned from other EID Route Servers, or it originates EID Routes. routes learned from other EID-Route Servers or originates EID-Routes.
The EID-Routes that it originates are those that it is authoritative The EID-Routes that it originates are those for which it is
for. It propagates these routes to Proxy-ITRs within the AS of the authoritative. It propagates these routes to Proxy-ITRs within the
EID Route Server. It is worth to note that a BGP capable router can AS of the EID-Route Server. It is worth noting that a BGP-capable
be also considered as an EID Route Server. router can also be considered an EID-Route Server.
Further, an EID-Route is defined as a prefix originated via the Route Further, an EID-Route is defined as a prefix originated via the Route
Server of the mapping service provider, which should be aggregated if Server of the MSP, which should be aggregated if the MSP has multiple
the MSP has multiple customers inside a single large continuous customers inside a single large continuous prefix. This prefix is
prefix. This prefix is propagated to other P-ITRs both within the propagated to other PITRs both within the MSP and to other PITR
MSP and to other P-ITR operators it peers with. EID Route Servers operators with which it peers. EID-Route Servers are operated by
are operated either by the LISP site, MSPs or PSPs, and they may be either the LISP site, MSPs, or PSPs and may be collocated with a
collocated with a Map Server or P-ITR, but are a functionally Map-Server or PITR, but they are functionally discrete entities.
discrete entity. They distribute EID-Routes, using BGP, to other They distribute EID-Routes, using BGP, to other domains according to
domains, according to policies set by participants. policies set by participants.
MSP (AS64500) MSP (AS64500)
RS ---> P-ITR RS ---> PITR
| / | /
| _.--./ | _.--./
,-'' /`--. ,-'' /`--.
LISP site ---,' | v `. LISP site ---,' | v `.
( | DFZ )----- Mapping system ( | DFZ )----- Mapping system
non-LISP site ----. | ^ ,' non-LISP site ----. | ^ ,'
`--. / _.-' `--. / _.-'
| `--'' | `--''
v / v /
P-ITR PITR
PSP (AS64501) PSP (AS64501)
Figure 7: The P-ITR Route Distribution architecture Figure 7: PITR-RD Architecture
The architecture described above decouples EID origination from route The architecture described above decouples EID origination from route
propagation, with the following benefits: propagation, with the following benefits:
o Can accurately represent business relationships between P-ITR o Can accurately represent business relationships between PITR
operators operators
o More mapping system agnostic o Is more mapping system agnostic
o Makes minor changes to PITR implementation; no changes to other
o Minor changes to P-ITR implementation, no changes to other
components components
In the example in the figure we have a MSP providing services to the In the example in Figure 7, we have a MSP providing services to the
LISP site. The LISP site does not run BGP, and gets an EID LISP site. The LISP site does not run BGP and gets an EID allocation
allocation directly from a RIR, or from the MSP, who may be a LIR. directly from a RIR, or from the MSP, which may be a Local Internet
Existing PI allocations can be migrated as well. The MSP ensures the Registry (LIR). Existing PI allocations can be migrated as well.
presence of the prefix in the mapping system, and runs an EID Route The MSP ensures the presence of the prefix in the mapping system and
Server to distribute it to P-ITR service providers. Since the LISP runs an EID-Route Server to distribute it to PSPs. Since the LISP
site does not run BGP, the prefix will be originated with the AS site does not run BGP, the prefix will be originated with the AS
number of the MSP. number of the MSP.
In the simple case depicted in Figure 7 the EID-Route of LISP site In the simple case depicted in Figure 7, the EID-Route of a LISP site
will be originated by the Route Server, and announced to the DFZ by will be originated by the Route Server and announced to the DFZ by
the PSP's P-ITRs with AS path 64501 64500. From that point on, the the PSP's PITRs with AS path 64501 64500. From that point on, the
usual BGP dynamics apply. This way, routes announced by P-ITR are usual BGP dynamics apply. This way, routes announced by the PITR are
still originated by the authoritative Route Server. Note that the still originated by the authoritative Route Server. Note that the
peering relationships between MSP/PSPs and those in the underlying peering relationships between MSPs/PSPs and those in the underlying
forwarding plane may not be congruent, making the AS path to a P-ITR forwarding plane may not be congruent, making the AS path to a PITR
shorter than it is in reality. shorter than it is in reality.
The non-LISP site will select the best path towards the EID-prefix, The non-LISP site will select the best path towards the EID-Prefix
according to its local BGP policies. Since AS-path length is usually according to its local BGP policies. Since AS-path length is usually
an important metric for selecting paths, a careful placement of P-ITR an important metric for selecting paths, careful placement of PITRs
could significantly reduce path-stretch between LISP and non-LISP could significantly reduce path stretch between LISP and non-LISP
sites. sites.
The architecture allows for flexible policies between MSP/PSPs. The architecture allows for flexible policies between MSPs/PSPs.
Consider the EID Route Server networks as control plane overlays, Consider the EID-Route Server networks as control plane overlays,
facilitating the implementation of policies necessary to reflect the facilitating the implementation of policies necessary to reflect the
business relationships between participants. The results are then business relationships between participants. The results are then
injected to the common underlying forwarding plane. For example, injected into the common underlying forwarding plane. For example,
some MSP/PSPs may agree to exchange EID-Prefixes and only announce some MSPs/PSPs may agree to exchange EID-Prefixes and only announce
them to each of their forwarding plane customers. Global them to each of their forwarding plane customers. Global
reachability of an EID-prefix depends on the MSP the LISP site buys reachability of an EID-Prefix depends on the MSP from which the LISP
service from, and is also subject to agreement between the mentioned site buys service and is also subject to agreement between the above-
parties. mentioned parties.
In terms of impact on the DFZ, this architecture results in a slower In terms of impact on the DFZ, this architecture results in a slower
routing table increase for new allocations, since traffic engineering routing table increase for new allocations, since traffic engineering
will be done at the LISP level. For existing allocations migrating will be done at the LISP level. For existing allocations migrating
to LISP, the DFZ may decrease since MSPs may be able to aggregate the to LISP, the DFZ may decrease, since MSPs may be able to aggregate
prefixes announced. the prefixes announced.
Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix
deaggregation for traffic engineering purposes, resulting in slower deaggregation for traffic engineering purposes, resulting in slower
routing table increase in the case of new allocations and potential routing table increase in the case of new allocations and potential
decrease for existing ones. Moreover, MSPs serving different clients decrease for existing ones. Moreover, MSPs serving different clients
with adjacent aggregatable prefixes may lead to additional decrease, with adjacent aggregatable prefixes may lead to additional decrease,
but quantifying this decrease is subject to future research study. but quantifying this decrease is subject to future research study.
The flexibility and scalability of this architecture does not come The flexibility and scalability of this architecture do not come
without a cost however: A PSP operator has to establish either without a cost, however: A PSP operator has to establish either
transit or peering relationships to improve their connectivity. transit or peering relationships to improve its connectivity.
5.4. Migration Summary 5.4. Migration Summary
Registering a domain name typically entails an annual fee that should Registering a domain name typically entails an annual fee that should
cover the operating expenses for publishing the domain in the global cover the operating expenses for publishing the domain in the global
DNS. The situation is similar with several other registration DNS. This situation is similar for several other registration
services. A LISP mapping service provider (MSR) client publishing an services. A LISP MSP client publishing an EID-Prefix in the LISP
EID prefix in the LISP mapping system has the option of signing up mapping system has the option of signing up for PITR services as
for PITR services as well, for an extra fee. These services may be well, for an extra fee. These services may be offered by the MSP
offered by the MSP itself, but it is expected that specialized P-ITR itself, but it is expected that specialized PSPs will do it. Clients
service providers (PSPs) will do it. Clients not signing up become that do not sign up will be responsible for getting non-LISP traffic
responsible for getting non-LISP traffic to their EIDs (using the to their EIDs (using the LISP+BGP scenario).
LISP+BGP scenario).
Additionally, Tier 1 ISPs have incentives to offer P-ITR services to Additionally, Tier 1 ISPs have incentives to offer PITR services to
non-subscribers in strategic places just to attract more traffic from non-subscribers in strategic places just to attract more traffic from
competitors, thus more revenue. competitors and thus more revenue.
The following table presents the expected effects of the different The following table presents the expected effects that the transition
transition scenarios during a certain phase on the DFZ routing table scenarios at various phases will have on the DFZ routing table size:
size:
Phase | LISP+BGP | MSP P-ITR | PITR-RD Phase | LISP+BGP | MSP PITR | PITR-RD
-----------------+--------------+-----------------+---------------- -----------------+--------------+-----------------+----------------
Early transition | no change | slower increase | slower increase Early transition | no change | slower increase | slower increase
Late transition | may decrease | slower increase | slower increase Late transition | may decrease | slower increase | slower increase
LISP Internet | considerable decrease LISP Internet | considerable decrease
It is expected that PITR-RD will co-exist with LISP+BGP during the It is expected that PITR-RD will coexist with LISP+BGP during the
migration, with the latter being more popular in the early transition migration, with the latter being more popular in the early transition
phase. As the transition progresses and the MSP P-ITR and PITR-RD phase. As the transition progresses and the MSP PITR and PITR-RD
ecosystem gets more ubiquitous, LISP+BGP should become less ecosystem gets more ubiquitous, LISP+BGP should become less
attractive, slowing down the increase of the number of routes in the attractive, slowing down the increase of the number of routes in
DFZ. the DFZ.
Note that throughout Section 5 we focused on the effects of LISP Note that throughout Section 5 we focused on the effects of LISP
deployment on the DFZ route table size. Other metrics may be deployment on the DFZ routing table size. Other metrics may be
impacted as well, but to the best of our knowlegde have not been impacted as well but to the best of our knowledge have not been
measured as of yet. measured as yet.
6. Security Considerations 6. Security Considerations
All security implications of LISP deployments are to be discussed in All security implications of LISP deployments are to be discussed in
separate documents. [I-D.ietf-lisp-threats] gives an overview of separate documents. [LISP-THREATS] gives an overview of LISP threat
LISP threat models, including ETR operators attracting traffic by models, including ETR operators attracting traffic by overclaiming an
overclaiming an EID-prefix (Section 4.4.3). Securing mapping lookups EID-Prefix (Section 4.4.3 of [LISP-THREATS]). Securing mapping
is discussed in [I-D.ietf-lisp-sec]. lookups is discussed in [LISP-SEC].
7. IANA Considerations
This memo includes no request to IANA.
8. Acknowledgements 7. Acknowledgements
Many thanks to Margaret Wasserman for her contribution to the IETF76 Many thanks to Margaret Wasserman for her contribution to the IETF 76
presentation that kickstarted this work. The authors would also like presentation that kickstarted this work. The authors would also like
to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller, to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller,
Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, Paul Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, Paul
Vinciguerra, Fred Templin, Brian Haberman, and everyone else who Vinciguerra, Fred Templin, Brian Haberman, and everyone else who
provided input. provided input.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013. January 2013.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013. (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, Protocol (LISP) Map-Server Interface", RFC 6833,
January 2013. January 2013.
9.2. Informative References 8.2. Informative References
[CACHE] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS [CACHE] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
performance and the effectiveness of caching", 2002. performance and the effectiveness of caching", IEEE/ACM
Transactions on Networking (TON), Volume 10, Issue 5,
pages 589-603, October 2002.
[DDT-ROOT] [DDT-ROOT] "Introduction to LISP DDT: DDT Root", March 2014,
"DDT Root", <http://ddt-root.org/>. <http://ddt-root.org/>.
[I-D.ietf-lisp-ddt] [LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", Work in Progress, March 2013.
Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
progress), March 2013.
[I-D.ietf-lisp-sec] [LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", Work in
and O. Bonaventure, "LISP-Security (LISP-SEC)", Progress, October 2013.
draft-ietf-lisp-sec-05 (work in progress), October 2013.
[I-D.ietf-lisp-threats] [LISP-THREATS]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-08 (work in progress), Analysis", Work in Progress, April 2014.
October 2013.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- [RFC4459] Savola, P., "MTU and Fragmentation Issues with
Network Tunneling", RFC 4459, April 2006. In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, December 2006. Services", BCP 126, RFC 4786, December 2006.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984, Workshop on Routing and Addressing", RFC 4984,
September 2007. September 2007.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834, Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013. January 2013.
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
Protocol Internet Groper (LIG)", RFC 6835, January 2013.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013. Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, Selkirk, "Port Control Protocol (PCP)", RFC 6887,
April 2013. April 2013.
[TELCO96] "Telecommunications Act of 1996", 1996. [TELCO96] Federal Communications Commission, "Telecommunications Act
of 1996", 1996, <http://transition.fcc.gov/telecom.html>.
Appendix A. Step-by-Step Example BGP to LISP Migration Procedure Appendix A. Step-by-Step Example BGP-to-LISP Migration Procedure
To help the operational community deploy LISP, this informative To help the operational community deploy LISP, this informative
section offers a step-by-step guide for migrating a BGP based section offers a step-by-step guide for migrating a BGP-based
Internet presence to a LISP site. It includes a pre-install/ Internet presence to a LISP site. It includes a pre-install/
pre-turn-up checklist, and customer and provider activation pre-turn-up checklist, and customer and provider activation
procedures. procedures.
A.1. Customer Pre-Install and Pre-Turn-up Checklist A.1. Customer Pre-Install and Pre-Turn-Up Checklist
1. Determine how many current physical service provider connections 1. Determine how many current physical service provider connections
the customer has and their existing bandwidth and traffic the customer has, and their existing bandwidth and traffic
engineering requirements. engineering requirements.
This information will determine the number of routing locators, This information will determine the number of routing locators,
and the priorities and weights that should be configured on the and the priorities and weights that should be configured on
xTRs. the xTRs.
2. Make sure customer router has LISP capabilities. 2. Make sure the customer router has LISP capabilities.
* Check OS version of the CE router. If LISP is an add-on, * Check the OS version of the CE router. If LISP is an add-on,
check if it is installed. check to see if it is installed.
This information can be used to determine if the platform is This information can be used to determine if the platform is
appropriate to support LISP, in order to determine if a appropriate to support LISP, in order to determine if a
software and/or hardware upgrade is required. software and/or hardware upgrade is required.
* Have customer upgrade (if necessary, software and/or hardware) * Have the customer upgrade (if necessary, software and/or
to be LISP capable. hardware) to be LISP capable.
3. Obtain current running configuration of CE router. A suggested 3. Obtain the current running configuration of the CE router. A
LISP router configuration example can be customized to the suggested LISP router configuration example can be customized to
customer's existing environment. the customer's existing environment.
4. Verify MTU Handling 4. Verify MTU handling.
* Request increase in MTU to 1556 or more on service provider * Request an increase in MTU to 1556 or more on service provider
connections. Prior to MTU change verify that 1500 byte packet connections. Prior to the MTU change, verify the transmission
from P-xTR to RLOC with do not fragment (DF-bit) bit set. of a 1500-byte packet from the PxTR to the RLOC with the Don't
Fragment (DF) bit set.
* Ensure they are not filtering ICMP unreachable or time- * Ensure that the customer is not filtering ICMP Unreachable or
exceeded on their firewall or router. Time Exceeded messages on their firewall or router.
LISP, like any tunneling protocol, will increase the size of LISP, like any tunneling protocol, will increase the size of
packets when the LISP header is appended. If increasing the MTU packets when the LISP header is appended. If increasing the MTU
of the access links is not possible, care must be taken that ICMP of the access links is not possible, care must be taken that ICMP
is not being filtered in order to allow for Path MTU Discovery to is not being filtered in order to allow Path MTU Discovery to
take place. take place.
5. Validate member prefix allocation. 5. Validate member prefix allocation.
This step is to check if the prefix used by the customer is a This step checks to see whether the prefix used by the customer
direct (Provider Independent), or if it is a prefix assigned by a is a direct (Provider-Independent) prefix or a prefix assigned by
physical service provider (Provider Aggregatable). If the a physical service provider (Provider Aggregatable). If the
prefixes are assigned by other service providers then a Letter of prefixes are assigned by other service providers, then a Letter
Agreement is required to announce prefixes through the Proxy of Agreement is required to announce prefixes through the Proxy
Service Provider. Service Provider.
6. Verify the member RLOCs and their reachability. 6. Verify the member RLOCs and their reachability.
This step ensures that the RLOCs configured on the CE router are This step ensures that the RLOCs configured on the CE router are
in fact reachable and working. in fact reachable and working.
7. Prepare for cut-over. 7. Prepare for cut-over.
* If possible, have a host outside of all security and filtering * If possible, have a host outside of all security and filtering
policies connected to the console port of the edge router or policies connected to the console port of the edge router or
switch. switch.
* Make sure customer has access to the router in order to * Make sure the customer has access to the router in order to
configure it. configure it.
A.2. Customer Activating LISP Service A.2. Customer Activating LISP Service
1. Customer configures LISP on CE router(s) from service provider 1. The customer configures LISP on CE router(s) according to the
recommended configuration. configuration recommended by the service provider.
The LISP configuration consists of the EID prefix, the locators, The LISP configuration consists of the EID-Prefix, the locators,
and the weights and priorities of the mapping between the two and the weights and priorities of the mapping between the two
values. In addition, the xTR must be configured with Map values. In addition, the xTR must be configured with
Resolver(s), Map Server(s) and the shared key for registering to Map-Resolver(s), Map-Server(s), and the shared key for
Map Server(s). If required, Proxy-ETR(s) may be configured as registering to Map-Server(s). If required, Proxy-ETR(s) may be
well. configured as well.
In addition to the LISP configuration, the following: In addition to the LISP configuration:
* Ensure default route(s) to next-hop external neighbors are * Ensure that the default routes(s) to next-hop external
included and RLOCs are present in configuration. neighbors is included and RLOCs are present in the
configuration.
* If two or more routers are used, ensure all RLOCs are included * If two or more routers are used, ensure that all RLOCs are
in the LISP configuration on all routers. included in the LISP configuration on all routers.
* It will be necessary to redistribute default route via IGP * It will be necessary to redistribute the default route via IGP
between the external routers. between the external routers.
2. When transition is ready perform a soft shutdown on existing eBGP 2. When transition is ready, perform a soft shutdown on existing
peer session(s) eBGP peer session(s).
* From CE router, use LIG to ensure registration is successful. * From the CE router, use the LISP Internet Groper (LIG)
[RFC6835] to ensure that registration is successful.
* To verify LISP connectivity, find and ping LISP connected * To verify LISP connectivity, find and ping LISP connected
sites. If possible, find ping destinations that are not sites. If possible, find ping destinations that are not
covered by a prefix in the global BGP routing system, because covered by a prefix in the global BGP routing system, because
PITRs may deliver the packets even if LISP connectivity is not PITRs may deliver the packets even if LISP connectivity is not
working. Traceroutes may help discover if this is the case. working. Traceroutes may help determine if this is the case.
* To verify connectivity to non-LISP sites, try accessing a * To verify connectivity to non-LISP sites, try accessing a
landmark (e.g., a major Internet site) via a web browser. landmark (e.g., a major Internet site) via a web browser.
A.3. Cut-Over Provider Preparation and Changes A.3. Cut-Over Provider Preparation and Changes
1. Verify site configuration and then active registration on Map 1. Verify site configuration, and then verify active registration on
Server(s) Map-Server(s).
* Authentication key * Authentication key.
* EID prefix * EID-Prefix.
2. Add EID space to map-cache on proxies 2. Add EID space to map-cache on proxies.
3. Add networks to BGP advertisement on proxies 3. Add networks to BGP advertisement on proxies.
* Modify route-maps/policies on P-xTRs * Modify route-maps/policies on PxTRs.
* Modify route policies on core routers (if non-connected * Modify route policies on core routers (if non-connected
member) member).
* Modify ingress policers on core routers * Modify ingress policies on core routers.
* Ensure route announcement in looking glass servers, RouteViews * Ensure route announcement in looking glass servers,
RouteViews.
4. Perform traffic verification test 4. Perform traffic verification test.
* Ensure MTU handling is as expected (PMTUD working) * Ensure that MTU handling is as expected (PMTUD working).
* Ensure proxy-ITR map-cache population * Ensure Proxy-ITR map-cache population.
* Ensure access from traceroute/ping servers around Internet * Ensure access from traceroute/ping servers around Internet.
* Use a looking glass, to check for external visibility of * Use a looking glass to check for external visibility of
registration via several Map Resolvers registration via several Map-Resolvers.
Authors' Addresses Authors' Addresses
Lorand Jakab Lorand Jakab
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: lojakab@cisco.com EMail: lojakab@cisco.com
Albert Cabellos-Aparicio Albert Cabellos-Aparicio
Technical University of Catalonia Technical University of Catalonia
C/Jordi Girona, s/n C/Jordi Girona, s/n
BARCELONA 08034 BARCELONA 08034
Spain Spain
Email: acabello@ac.upc.edu EMail: acabello@ac.upc.edu
Florin Coras Florin Coras
Technical University of Catalonia Technical University of Catalonia
C/Jordi Girona, s/n C/Jordi Girona, s/n
BARCELONA 08034 BARCELONA 08034
Spain Spain
Email: fcoras@ac.upc.edu EMail: fcoras@ac.upc.edu
Jordi Domingo-Pascual Jordi Domingo-Pascual
Technical University of Catalonia Technical University of Catalonia
C/Jordi Girona, s/n C/Jordi Girona, s/n
BARCELONA 08034 BARCELONA 08034
Spain Spain
Email: jordi.domingo@ac.upc.edu EMail: jordi.domingo@ac.upc.edu
Darrel Lewis Darrel Lewis
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: darlewis@cisco.com EMail: darlewis@cisco.com
 End of changes. 237 change blocks. 
585 lines changed or deleted 595 lines changed or added

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