draft-ietf-lisp-deployment-05.txt   draft-ietf-lisp-deployment-06.txt 
Network Working Group L. Jakab Network Working Group L. Jakab
Internet-Draft A. Cabellos-Aparicio Internet-Draft Cisco Systems
Intended status: Informational F. Coras Intended status: Informational A. Cabellos-Aparicio
Expires: April 23, 2013 J. Domingo-Pascual Expires: July 30, 2013 F. Coras
J. Domingo-Pascual
Technical University of Technical University of
Catalonia Catalonia
D. Lewis D. Lewis
Cisco Systems Cisco Systems
October 20, 2012 January 26, 2013
LISP Network Element Deployment Considerations LISP Network Element Deployment Considerations
draft-ietf-lisp-deployment-05.txt draft-ietf-lisp-deployment-06.txt
Abstract Abstract
This document discusses the different scenarios for the deployment of This document discusses the different scenarios for the deployment of
the new network elements introduced by the Locator/Identifier the new network elements introduced by the Locator/Identifier
Separation Protocol (LISP). Separation Protocol (LISP).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 37 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2013. This Internet-Draft will expire on July 30, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Customer Edge . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Customer Edge . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Provider Edge . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Provider Edge . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Inter-Service Provider Traffic Engineering . . . . . . . . 8 2.4. Inter-Service Provider Traffic Engineering . . . . . . . . 8
2.5. Tunnel Routers Behind NAT . . . . . . . . . . . . . . . . 10 2.5. Tunnel Routers Behind NAT . . . . . . . . . . . . . . . . 10
2.5.1. ITR . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5.1. ITR . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.2. ETR . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5.2. ETR . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6. Summary and Feature Matrix . . . . . . . . . . . . . . . . 11 2.6. Summary and Feature Matrix . . . . . . . . . . . . . . . . 11
3. Map-Resolvers and Map-Servers . . . . . . . . . . . . . . . . 11 3. Map Resolvers and Map Servers . . . . . . . . . . . . . . . . 11
3.1. Map-Servers . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Map Servers . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Map-Resolvers . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Map Resolvers . . . . . . . . . . . . . . . . . . . . . . 12
4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 13 4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 13
4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 15 5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 15
5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16 5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16
5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17 5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 16
5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19 5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19
6. Step-by-Step Example BGP to LISP Migration Procedure . . . . . 20 6. Step-by-Step Example BGP to LISP Migration Procedure . . . . . 19
6.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 20 6.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 19
6.2. Customer Activating LISP Service . . . . . . . . . . . . . 21 6.2. Customer Activating LISP Service . . . . . . . . . . . . . 21
6.3. Cut-Over Provider Preparation and Changes . . . . . . . . 22 6.3. Cut-Over Provider Preparation and Changes . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The Locator/Identifier Separation Protocol (LISP) addresses the The Locator/Identifier Separation Protocol (LISP) addresses the
scaling issues of the global Internet routing system by separating scaling issues of the global Internet routing system by separating
the current addressing scheme into Endpoint IDentifiers (EIDs) and the current addressing scheme into Endpoint IDentifiers (EIDs) and
Routing LOCators (RLOCs). The main protocol specification Routing LOCators (RLOCs). The main protocol specification [RFC6830]
[I-D.ietf-lisp] describes how the separation is achieved, which new describes how the separation is achieved, which new network elements
network elements are introduced, and details the packet formats for are introduced, and details the packet formats for the data and
the data and control planes. control planes.
LISP assumes that such separation is between the edge and core. LISP assumes that such separation is between the edge and core and
While the boundary between both is not strictly defined, one widely uses a map-and-encap scheme for forwarding. While the boundary
accepted definition places it at the border routers of stub between both is not strictly defined, one widely accepted definition
autonomous systems, which may carry a partial or complete default- places it at the border routers of stub autonomous systems, which may
free zone (DFZ) routing table. The initial design of LISP took this carry a partial or complete default-free zone (DFZ) routing table.
location as a baseline for protocol development. However, the The initial design of LISP took this location as a baseline for
applications of LISP go beyond of just decreasing the size of the DFZ protocol development. However, the applications of LISP go beyond of
routing table, and include improved multihoming and ingress traffic just decreasing the size of the DFZ routing table, and include
engineering (TE) support for edge networks, and even individual improved multihoming and ingress traffic engineering (TE) support for
hosts. Throughout the draft we will use the term LISP site to refer edge networks, and even individual hosts. Throughout the draft we
to these networks/hosts behind a LISP Tunnel Router. We formally will use the term LISP site to refer to these networks/hosts behind a
define it as: LISP Tunnel Router. We formally define it as:
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).
Network element: Active or passive device that is connected
connected to other active or passive devices for transporting
packet switched data.
Since LISP is a protocol which can be used for different purposes, it Since LISP is a protocol which 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, discussing the impact of
deployment scenarios on the protocol specification. For definition deployment scenarios on the protocol specification. For definition
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).
2. Tunnel Routers 2. Tunnel Routers
LISP is a map-and-encap protocol, with the main goal of improving The device that is the gateway between the edge and the core is
global routing scalability. To achieve its goal, it introduces called Tunnel Router (xTR), performing one or both of two separate
several new network elements, each performing specific functions functions:
necessary to separate the edge from the core. The device that is the
gateway between the edge and the core is called Tunnel Router (xTR),
performing one or both of two separate 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 end-point 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),
the second by an Egress Tunnel Router (ETR). the second by an Egress Tunnel Router (ETR).
Section 8 of the main LISP specification [I-D.ietf-lisp] 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. scenarios as well.
2.1. Customer Edge 2.1. Customer Edge
LISP was designed with deployment at the core-edge boundary in mind, The first scenario we discuss is customer edge, when xTR
which can be approximated as the set of DFZ routers belonging to non- functionality is placed on the router(s) that connect the LISP site
transit ASes. For the purposes of this document, we will consider to its upstream(s), but are under its control. As such, this is the
this boundary to be consisting of the routers connecting LISP sites most common expected scenario for xTRs, and this document considers
to their upstreams. As such, this is the most common expected it the reference location, comparing the other scenarios to this one.
scenario for xTRs, and this document considers 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 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 is easy to set up and maintain active/active, active/backup, makes it easy to set up and maintain active/active, active/backup, or
or more complex TE policies, without involving third parties. more complex TE policies, 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 Loc-Status-Bits can be set correctly in the LISP data header and the Loc-Status-Bits can be set correctly in the LISP data header
of outgoing packets. 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.
skipping to change at page 5, line 30 skipping to change at page 5, line 32
Another thing to consider when placing tunnel routers are MTU issues. Another thing to consider when placing tunnel routers are MTU issues.
Since encapsulating packets increases overhead, the MTU of the end- Since encapsulating packets increases overhead, the MTU of the end-
to-end path may decrease, when encapsulated packets need to travel to-end path may decrease, when encapsulated packets need to travel
over segments having close to minimum MTU. Some transit networks are over segments having close to minimum MTU. Some transit networks are
known to provide larger MTU than the typical value of 1500 bytes of known to provide larger MTU than the typical value of 1500 bytes of
popular access technologies used at end hosts (e.g., IEEE 802.3 and popular access technologies used at end hosts (e.g., IEEE 802.3 and
802.11). However, placing the LISP router connecting to such a 802.11). However, placing the LISP router connecting to such a
network at the customer edge could possibly bring up MTU issues, network at the customer edge could possibly bring up MTU issues,
depending on the link type to the provider as opposed to the depending on the link type to the provider as opposed to the
following scenario. following scenario. See [RFC4459] for MTU considerations of
tunneling protocols.
2.2. Provider Edge 2.2. Provider Edge
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
skipping to change at page 6, line 34 skipping to change at page 6, line 34
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, either to attract all the traffic or to 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 have the connectivity has a fixed price. A solution could be to have the
mappings in the Map-Server(s), and have their operator give control mappings in the Map Server(s), and have their operator give control
over the entries to customer, much like in the Domain Name System at over the entries to customer, much like in the Domain Name System at
the time of this writing. the time of this writing.
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 Loc-Status-
Bits correctly on encapsulated packets. Bits (LSB) correctly on encapsulated packets. Because of this, and
due to the security concerns about LSB described in
[I-D.ietf-lisp-threats] their use is discouraged without verifying
ETR reachability through the mapping system or other means. Mapping
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.3. Split ITR/ETR 2.3. 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). In this scenario packets are routed LISP site (see Section 2.1). In this scenario packets are routed
skipping to change at page 8, line 22 skipping to change at page 8, line 27
encapsulated packets. 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 cache hit ratio grows logarithmically with the amount
of users [cache]. Taking this into account, when ITRs are 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 ratio is higher). Another
consequence of this is that the site may transmit a higher amount consequence of this is that the site may transmit a higher amount
of Map-Requests, increasing the load on the distributed mapping of Map-Requests, increasing the load on the distributed mapping
database. database. To lower the impact, the site could use a local caching
Map Resolver.
o By placing the ITRs inside the site, they will still need global
RLOCs, and this may add complexity to intra-site routing
configuration, and further intra-site issues when there is a
change of providers.
2.4. Inter-Service Provider Traffic Engineering 2.4. Inter-Service Provider Traffic Engineering
With LISP, two LISP sites can route packets among them and control With LISP, two LISP sites can route packets among them and control
their ingress TE policies. Typically, LISP is seen as applicable to their ingress TE policies. Typically, LISP is seen as applicable to
stub networks, however the LISP protocol can also be applied to stub networks, however the LISP protocol can also be applied to
transit networks recursively. transit networks recursively.
Consider the scenario depicted in Figure 4. Packets originating from Consider the scenario depicted in Figure 4. Packets originating from
the LISP site Stub1, client of ISP_A, with destination Stub4, client the LISP site Stub1, client of ISP_A, with destination Stub4, client
skipping to change at page 10, line 40 skipping to change at page 10, line 49
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 most simple 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 a single ITR behind the NAT device. This setup supports only a single ITR behind the NAT device.
2.5.2. ETR 2.5.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.
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 can not be behind carrier based NATs, since two different sites
would collide on the port forwarding. would collide on the port forwarding.
2.6. Summary and Feature Matrix 2.6. Summary and Feature Matrix
Feature CE PE Split Rec. Feature CE PE Split Recursive
-------------------------------------------------------- -------------------------------------------------------------
Control of ingress TE x - x x Control of ingress TE x - x x
No modifications to existing No modifications to existing
int. network infrastructure x x - - int. network infrastructure x x - -
Loc-Status-Bits sync x - x x Loc-Status-Bits sync x - x x
MTU/PMTUD issues minimized - x - x MTU/PMTUD issues minimized - x - x
3. Map-Resolvers and Map-Servers 3. Map Resolvers and Map Servers
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 Map-
Register messages sent by authoritative ETRs. Also, upon reception Register messages sent by authoritative ETRs. Also, upon reception
of a Map-Request, the Map-Server verifies that the destination EID of a Map-Request, the Map Server verifies that the destination EID
matches an EID-prefix for which it is authoritative for, and then re- matches an EID-prefix for which it is authoritative for, and then re-
encapsulates and forwards it to a matching ETR. Map-Server encapsulates and forwards it to a matching ETR. Map Server
functionality is described in detail in [I-D.ietf-lisp-ms]. functionality is described in detail in [RFC6833].
The Map-Server is provided by a Mapping Service Provider (MSP). A
MSP can be any of the following:
o EID registrar. Since the IPv4 address space is nearing
exhaustion, IPv4 EIDs will come from already allocated Provider
Independent (PI) space. The registrars in this case remain the
current five Regional Internet Registries (RIRs). In the case of
IPv6, the possibility of reserving a /16 block as EID space is
currently under consideration [I-D.ietf-lisp-eid-block]. If
granted by IANA, the community will have to determine the body
responsible for allocations from this block, and the associated
policies. Existing allocation policies apply to EIDs outside this
block.
o Third parties. Participating in the LISP mapping system is The Map Server is provided by a Mapping Service Provider (MSP). The
similar to participating in global routing or DNS: as long as MSP participates in the global distributed mapping database
there is at least another already participating entity willing to infrastructure, by setting up connections to other participants,
forward the newcomer's traffic, there is no barrier to entry. according to the specific mapping system that is employed (e.g., ALT,
Still, just like routing and DNS, LISP mappings have the issue of DDT). Participation in the mapping database, and the storing of EID-
trust, with efforts underway to make the published information to-RLOC mapping data is subject to the policies of the "root"
verifiable. When these mechanisms will be deployed in the LISP operators, who SHOULD check ownership rights for the EID prefixes
mapping system, the burden of providing and verifying trust should stored in the database by participants. These policies are out of
be kept away from MSPs, which will simply host the secured the scope of this document.
mappings. This will keep the low barrier of entry to become an
MSP for third parties.
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 end sites, there is a need for mechanisms to: some LISP end 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 the
AS. 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 EID-
prefixes it is serving. On the one hand it is publishing these prefixes it is serving. On the 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 hand
it is encapsulating and forwarding Map-Requests to the authoritative it is encapsulating and forwarding Map-Requests to the authoritative
ETRs of these prefixes. ITRs encapsulating towards EIDs under the ETRs of these prefixes. ITRs encapsulating towards EIDs under the
responsibility of a failed Map-Server will be unable to look up any responsibility of a failed Map Server will be unable to look up any
of their covering prefixes. The only exception are the ITRs that of their covering prefixes. The only exception are the ITRs that
already contain the mappings in their local cache. In this case ITRs already contain the mappings in their local cache. In this case ITRs
can reach ETRs until the entry expires (typically 24 hours). For can reach ETRs until the entry expires (typically 24 hours). For
this reason, redundant Map-Server deployments are desirable. A set this reason, redundant Map Server deployments are desirable. A set
of Map-Servers providing high-availability service to the same set of of Map Servers providing high-availability service to the same set of
prefixes is called a redundancy group. ETRs are configured to send prefixes is called a redundancy group. ETRs are configured to send
Map-Register messages to all Map-Servers in the redundancy group. To Map-Register messages to all Map Servers in the redundancy group. To
achieve fail-over (or load-balancing, if desired), known mapping achieve fail-over (or load-balancing, if desired), known mapping
system specific best practices should be used. system specific best practices should be used.
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 a is a network infrastructure component which accepts A Map Resolver a is a network infrastructure component which 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 either consulting its local cache appropriate EID-to-RLOC mapping by either consulting its local cache
or by consulting the distributed mapping database. Map-Resolver or by consulting the distributed mapping database. Map Resolver
functionality is described in detail in [I-D.ietf-lisp-ms]. functionality is described in detail in [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 Map
Resolvers that are topologically close to their ITRs. ISPs 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, operation which can be done manually. However, in
Small Office Home Office (SOHO) scenarios a mechanism for Small Office Home Office (SOHO) scenarios a mechanism for
autoconfiguration should be provided. 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 for Map-Resolvers similar to the DNS root is the use of anycast RLOCs for Map Resolvers similar to the DNS root
server infrastructure. Since LISP uses UDP encapsulation, the use of server infrastructure. Since LISP uses UDP encapsulation, the use of
anycast would not affect reliability. LISP routers are then shipped anycast would not affect reliability. LISP routers are then shipped
with a preconfigured list of well know Map-Resolver RLOCs, which can with a preconfigured list of well know Map Resolver RLOCs, which can
be edited by the network administrator, if needed. be edited by the network administrator, if needed.
The use of anycast also helps improving mapping lookup performance. The use of anycast also helps improving 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 running this kind of setup, to ensure minimal
connection setup latency for those connecting to their network from connection setup latency for those connecting to their network from
LISP sites. 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 a single Map-Resolver/Map-Server in each PoP where they have a deploy 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. P-ITR
Proxy Ingress Tunnel Routers (P-ITRs) are part of the non-LISP/LISP Proxy Ingress Tunnel Routers (P-ITRs) 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 simply by not
encapsulating traffic. See [I-D.ietf-lisp-interworking] for a encapsulating traffic. See [RFC6832] for a detailed description of
detailed description of P-ITR functionality. P-ITR 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 inter-operate 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 P-ITR 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 going
skipping to change at page 15, line 23 skipping to change at page 15, line 17
still offer IPv6 to their clients, by providing a CPE device running still offer IPv6 to their clients, by providing a CPE device running
LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP
sites, with IPv6-only locators. Packets originating from the client sites, with IPv6-only locators. Packets originating from the client
LISP site for these destinations would be encapsulated towards the LISP site for these destinations would be encapsulated towards the
P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network, P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network,
decapsulating and forwarding packets. For non-LISP destination, the decapsulating and forwarding packets. For non-LISP destination, the
packet travels natively from the P-ETR. For LISP destinations with packet travels natively from the P-ETR. For LISP destinations with
IPv6-only locators, the packet will go through a P-ITR, in order to IPv6-only locators, the packet will go through a P-ITR, in order to
reach its destination. reach its destination.
For more details on P-ETRs see the [I-D.ietf-lisp-interworking] For more details on P-ETRs see the [RFC6832] draft.
draft.
P-ETRs can be deployed by ISPs wishing to offer value-added services P-ETRs 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 P-ITRs, P-ETRs too may
introduce path stretch. Because of this the ISP needs to consider introduce path stretch. Because of this the ISP needs to consider
the tradeoff of using several devices, close to the customers, to the tradeoff of using several devices, close to the customers, to
minimize it, or few devices, farther away from the customers, minimize it, or few devices, farther away from the customers,
minimizing cost instead. minimizing cost instead.
Since the deployment incentives for P-ITRs and P-ETRs are different, Since the deployment incentives for P-ITRs and P-ETRs are different,
it is likely they will be deployed in separate devices, except for it is likely they will be deployed in separate devices, except for
the CDN case, which may deploy both in a single device. the 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 P-ETR 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 P-ETRs.
Autoconfiguration of the P-ETR locator could be achieved by a DHCP Autoconfiguration of the P-ETR locator could be achieved by a DHCP
option, or adding a P-ETR field to either Map-Notifys or Map-Replies. option, or adding a P-ETR field to either Map-Notifys or Map-Replies.
As a security measure, access to P-ETRs should be limited to
legitimate users by enforcing ACLs.
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 of
"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 go LISP with their PI prefix the least
disruptive way is to upgrade their border routers to support LISP, disruptive way is to upgrade their border routers to support LISP,
register the prefix into the LISP mapping system, but keep announcing register the prefix into the LISP mapping system, but keep announcing
it with BGP as well. This way LISP sites will reach them over LISP, it with BGP as well. This way LISP sites will reach them over LISP,
while legacy sites will be unaffected by the change. The main while legacy sites will be unaffected by the change. The main
disadvantage of this approach is that no decrease in the DFZ routing disadvantage of this approach is that no decrease in the DFZ routing
table size is achieved. Still, just increasing the number of LISP table size is achieved. Still, just increasing the number of LISP
sites is an important gain, as an increasing LISP/non-LISP site ratio sites is an important gain, as an increasing LISP/non-LISP site ratio
will slowly decrease the need for BGP-based traffic engineering that will slowly decrease the need for BGP-based traffic engineering that
leads to prefix deaggregation. That, in turn, may lead to a decrease leads to prefix deaggregation. That, in turn, may lead to a decrease
in the DFZ size in the late transition phase. 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) P-ITR Service
skipping to change at page 16, line 42 skipping to change at page 16, line 32
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, that wish 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 adding path stretch.
Routing all non-LISP ingress traffic through a third party which is Routing all non-LISP ingress traffic through a third party which 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. When the LISP/non-LISP site significant number of legacy sites. This is because the handling of
ratio becomes high enough, this approach can prove increasingly said traffic is likely to result in additional costs, which would be
attractive. passed down to the client. When the LISP/non-LISP site ratio becomes
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 aggregable 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 their EIDs with BGP to
the DFZ, this function can be outsourced to a third party, a P-ITR the DFZ, this function can be outsourced to a third party, a P-ITR
Service Provider (PSP). This will result in a decrease of the Service Provider (PSP). This will result in a decrease of the
operational complexity both at the site and at the MSP. operational complexity both at the site and at the MSP.
The PSP manages a set of distributed P-ITR(s) that will advertise the The PSP manages a set of distributed P-ITR(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 P-ITR(s)
will then encapsulate the traffic they receive for those EIDs towards will then encapsulate the traffic they receive for those EIDs towards
the RLOCs of the LISP site, ensuring their reachability from non-LISP the RLOCs of the LISP site, ensuring their reachability from non-LISP
sites. sites. Note that handling non-LISP-originated traffic may incur
additional costs for the PSP, which may be passed down to the client.
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, defined as a router that either propagates routes
learned from other EID Route Servers, or it originates EID Routes. learned from other EID Route Servers, or it originates EID Routes.
The EID-Routes that it originates are those that it is authoritative The EID-Routes that it originates are those that it is authoritative
for. It propagates these routes to Proxy-ITRs within the AS of the for. It propagates these routes to Proxy-ITRs within the AS of the
EID Route Server. It is worth to note that a BGP capable router can EID Route Server. It is worth to note that a BGP capable router can
be also considered as an EID Route Server. be also considered as 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 mapping service provider, which should be aggregated if
the MSP has multiple customers inside a single netblock. This prefix the MSP has multiple customers inside a single large continuous
is propagated to other P-ITRs both within the MSP and to other P-ITR prefix. This prefix is propagated to other P-ITRs both within the
operators it peers with. EID Route Servers are operated either by MSP and to other P-ITR operators it peers with. EID Route Servers
the LISP site, MSPs or PSPs, and they may be collocated with a Map- are operated either by the LISP site, MSPs or PSPs, and they may be
Server or P-ITR, but are a functionally discrete entity. They collocated with a Map Server or P-ITR, but are a functionally
distribute EID-Routes, using BGP, to other domains, according to discrete entity. They distribute EID-Routes, using BGP, to other
policies set by participants. domains, according to policies set by participants.
MSP (AS64500) MSP (AS64500)
RS ---> P-ITR RS ---> P-ITR
| / | /
| _.--./ | _.--./
,-'' /`--. ,-'' /`--.
LISP site ---,' | v `. LISP site ---,' | v `.
( | DFZ )----- Mapping system ( | DFZ )----- Mapping system
non-LISP site ----. | ^ ,' non-LISP site ----. | ^ ,'
`--. / _.-' `--. / _.-'
skipping to change at page 19, line 28 skipping to change at page 19, line 11
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 the
prefixes announced. 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 aggregable 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 does 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 their connectivity.
5.4. Migration Summary 5.4. Migration Summary
The following table presents the expected effects of the different The following table presents the expected effects of the different
transition scenarios during a certain phase on the DFZ routing table transition scenarios during a certain phase on the DFZ routing table
skipping to change at page 20, line 20 skipping to change at page 20, line 5
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 the
xTRs. xTRs.
2. Make sure customer router has LISP capabilities. 2. Make sure customer router has LISP capabilities.
* Obtain output of 'show version' from the CE router. * Check OS version of the CE router. If LISP is an add-on,
check 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 customer upgrade (if necessary, software and/or hardware)
to be LISP capable. to be LISP capable.
3. Obtain current running configuration of CE router. A suggested 3. Obtain current running configuration of CE router. A suggested
LISP router configuration example can be customized to the LISP router configuration example can be customized to the
customer's existing environment. customer's existing environment.
4. Verify MTU Handling 4. Verify MTU Handling
* Request increase in MTU to (1556) on service provider * Request increase in MTU to 1556 on service provider
connections. Prior to MTU change verify that 1500 byte packet connections. Prior to MTU change verify that 1500 byte packet
from P-xTR to RLOC with do not fragment (DF-bit) bit set. from P-xTR to RLOC with do not fragment (DF-bit) bit set.
* Ensure they are not filtering ICMP unreachable or time- * Ensure they are not filtering ICMP unreachable or time-
exceeded on their firewall or router. exceeded 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 for 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 is to check if the prefix used by the customer is a
direct (Provider Independent), or if it is a prefix assigned by a direct (Provider Independent), or if it is a prefix assigned by a
physical service provider (Provider Allocated). If the prefixes physical service provider (Provider Aggregatable). If the
are assigned by other service provivers then a Letter of prefixes are assigned by other service provivers then a Letter of
Agreement is required to announce prefixes through the Proxy 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.
skipping to change at page 21, line 31 skipping to change at page 21, line 15
* Make sure customer has access to the router in order to * Make sure customer has access to the router in order to
configure it. configure it.
6.2. Customer Activating LISP Service 6.2. Customer Activating LISP Service
1. Customer configures LISP on CE router(s) from service provider 1. Customer configures LISP on CE router(s) from service provider
recommended configuration. recommended configuration.
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 Map
Resolver(s), Map-Server(s) and the shared key for registering to Resolver(s), Map Server(s) and the shared key for registering to
Map-Server(s). If required, Proxy-ETR(s) may be configured as Map Server(s). If required, Proxy-ETR(s) may be configured as
well. well.
In addition to the LISP configuration, the following: In addition to the LISP configuration, the following:
* Ensure default route(s) to next-hop external neighbors are * Ensure default route(s) to next-hop external neighbors are
included and RLOCs are present in configuration. included and RLOCs are present in configuration.
* If two or more routers are used, ensure all RLOCs are included * If two or more routers are used, ensure all RLOCs are included
in the LISP configuration on all routers. in the LISP configuration on all routers.
* It will be necessary to redistribute default route via IGP * It will be necessary to redistribute 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 eBGP
peer session(s) peer session(s)
* From CE router, use LIG to ensure registration is successful. * From CE router, use LIG to ensure registration is successful.
* To verify LISP connectivity, ping LISP connected sites. See * To verify LISP connectivity, ping LISP connected sites. See
http://www.lisp4.net/ and/or http://www.lisp6.net/ for http://www.lisp4.net/ and/or http://www.lisp6.net/ for
potential candidates. potential candidates. If possible, find ping destinations
that are not covered by a prefix in the global BGP routing
system, because PITRs may deliver the packets even if LISP
connectivity is not working. Traceroutes may help discover if
this is the case.
* To verify connectivity to non-LISP sites, try accessing major * To verify connectivity to non-LISP sites, try accessing a
Internet sites via a web browser. landmark (e.g., a major Internet site) via a web browser.
6.3. Cut-Over Provider Preparation and Changes 6.3. Cut-Over Provider Preparation and Changes
1. Verify site configuration and then active registration on Map- 1. Verify site configuration and then active registration on Map
Server(s) 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 P-xTRs
skipping to change at page 22, line 43 skipping to change at page 22, line 30
4. Perform traffic verification test 4. Perform traffic verification test
* Ensure MTU handling is as expected (PMTUD working) * Ensure 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 (e.g., registration via several Map Resolvers (e.g.,
http://lispmon.net/). http://lispmon.net/).
7. Security Considerations 7. Security Considerations
Security implications of LISP deployments are to be discussed in Security implications of LISP deployments are to be discussed in
separate documents. [I-D.saucez-lisp-security] gives an overview of separate documents. [I-D.ietf-lisp-threats] gives an overview of
LISP threat models, while securing mapping lookups is discussed in LISP threat models, while securing mapping lookups is discussed in
[I-D.ietf-lisp-sec]. [I-D.ietf-lisp-sec].
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Acknowledgements 9. Acknowledgements
Many thanks to Margaret Wasserman for her contribution to the IETF76 Many thanks to Margaret Wasserman for her contribution to the IETF76
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, and Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, Paul
everyone else who provided input. Vinciguerra and everyone else who provided input.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-lisp] [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Locator/ID Separation Protocol (LISP)", RFC 6830,
"Locator/ID Separation Protocol (LISP)", January 2013.
draft-ietf-lisp-23 (work in progress), May 2012.
[I-D.ietf-lisp-interworking] [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol
"Interworking LISP with IPv4 and IPv6", (LISP) and Non-LISP Sites", RFC 6832, January 2013.
draft-ietf-lisp-interworking-06 (work in progress),
March 2012.
[I-D.ietf-lisp-ms] [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Fuller, V. and D. Farinacci, "LISP Map Server Interface", Protocol (LISP) Map-Server Interface", RFC 6833,
draft-ietf-lisp-ms-16 (work in progress), March 2012. January 2013.
10.2. Informative References 10.2. Informative References
[I-D.ietf-lisp-eid-block] [I-D.ietf-lisp-eid-block]
Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP
EID Block", draft-ietf-lisp-eid-block-02 (work in EID Block", draft-ietf-lisp-eid-block-03 (work in
progress), April 2012. progress), November 2012.
[I-D.ietf-lisp-sec] [I-D.ietf-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)", and O. Bonaventure, "LISP-Security (LISP-SEC)",
draft-ietf-lisp-sec-04 (work in progress), October 2012. draft-ietf-lisp-sec-04 (work in progress), October 2012.
[I-D.saucez-lisp-security] [I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Security Threats", draft-saucez-lisp-security-03 (work in Analysis", draft-ietf-lisp-threats-03 (work in progress),
progress), March 2011. October 2012.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, April 2006.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013.
[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", 2002.
Authors' Addresses Authors' Addresses
Lorand Jakab Lorand Jakab
Technical University of Catalonia Cisco Systems
C/Jordi Girona, s/n 170 Tasman Drive
BARCELONA 08034 San Jose, CA 95134
Spain USA
Email: ljakab@ac.upc.edu 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
 End of changes. 82 change blocks. 
180 lines changed or deleted 181 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/