draft-ietf-lisp-deployment-07.txt   draft-ietf-lisp-deployment-08.txt 
Network Working Group L. Jakab Network Working Group L. Jakab
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational A. Cabellos-Aparicio Intended status: Informational A. Cabellos-Aparicio
Expires: September 21, 2013 F. Coras Expires: December 28, 2013 F. Coras
J. Domingo-Pascual J. Domingo-Pascual
Technical University of Technical University of
Catalonia Catalonia
D. Lewis D. Lewis
Cisco Systems Cisco Systems
March 20, 2013 June 26, 2013
LISP Network Element Deployment Considerations LISP Network Element Deployment Considerations
draft-ietf-lisp-deployment-07.txt draft-ietf-lisp-deployment-08.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 38 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 September 21, 2013. This Internet-Draft will expire on December 28, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5.2. ETR . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.3. Additional Notes . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 12
3.1. Map Servers . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Map Servers . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Map Resolvers . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Map Resolvers . . . . . . . . . . . . . . . . . . . . . . 13
4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 13 4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 14
4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 15 5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 16
5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16 5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 17
5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 16 5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17
5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19 5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 20
6. Step-by-Step Example BGP to LISP Migration Procedure . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.2. Customer Activating LISP Service . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Cut-Over Provider Preparation and Changes . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Step-by-Step Example BGP to LISP Migration
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Procedure . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 A.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 23 A.2. Customer Activating LISP Service . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 A.3. Cut-Over Provider Preparation and Changes . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Locator/Identifier Separation Protocol (LISP) addresses the The Locator/Identifier Separation Protocol (LISP) is designed to
scaling issues of the global Internet routing system by separating address the scaling issues of the global Internet routing system
the current addressing scheme into Endpoint IDentifiers (EIDs) and identified in [RFC4984] by separating the current addressing scheme
Routing LOCators (RLOCs). The main protocol specification [RFC6830] into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs). The
describes how the separation is achieved, which new network elements main protocol specification [RFC6830] describes how the separation is
are introduced, and details the packet formats for the data and achieved, which new network elements are introduced, and details the
control planes. 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 a map-and-encap scheme 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 of 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 draft we edge networks, and even individual hosts. Throughout the document we
will use the term LISP site to refer to these networks/hosts behind a will use the term LISP site to refer to these networks/hosts behind a
LISP Tunnel Router. We formally define it as: LISP Tunnel Router. We formally define the following two terms:
Network element: Active or passive device that is connected to other
active or passive devices for transporting packet switched data.
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
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 Tunnel Router (xTR), performing one or both of two separate called a Tunnel Router (xTR), performing 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 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),
skipping to change at page 5, line 9 skipping to change at page 5, line 5
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 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, 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 Locator Status Bits (Loc-Status-Bits, defined in [RFC6830])
of outgoing packets. can be set correctly in the LISP data 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 with many external connections, distributed in geographically diverse
PoPs, and complex internal topology, it may however make more sense points of presence (PoPs), and complex internal topology, it may
to both encapsulate and decapsulate as soon as possible, to benefit however make more sense to both encapsulate and decapsulate as soon
from the information in the IGP to choose the best path (see as possible, to benefit from the information in the IGP to choose the
Section 2.3 for a discussion of this scenario). best path (see Section 2.3 for a discussion of this scenario).
Another thing to consider when placing tunnel routers are MTU issues. Another thing to consider when placing tunnel routers is MTU issues.
Since encapsulating packets increases overhead, the MTU of the end- Encapsulation increases the amount of overhead associated with each
to-end path may decrease, when encapsulated packets need to travel packet. This added overhead decreases the effective end-to-end path
over segments having close to minimum MTU. Some transit networks are MTU (unless fragmentation and reassembly is used). Some transit
known to provide larger MTU than the typical value of 1500 bytes of networks are known to provide larger MTU than the typical value of
popular access technologies used at end hosts (e.g., IEEE 802.3 and 1500 bytes of popular access technologies used at end hosts (e.g.,
802.11). However, placing the LISP router connecting to such a IEEE 802.3 and 802.11). However, placing the LISP router connecting
network at the customer edge could possibly bring up MTU issues, to such a network at the customer edge could possibly bring up MTU
depending on the link type to the provider as opposed to the issues, depending on the link type to the provider as opposed to the
following scenario. See [RFC4459] for MTU considerations of following scenario. See [RFC4459] for MTU considerations of
tunneling protocols on how to mitigate potential issues. Still, even tunneling protocols on how to mitigate potential issues. Still, even
with these mitigations, path MTU issues are still possible. with these mitigations, path MTU issues are still possible.
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.
skipping to change at page 6, line 18 skipping to change at page 6, line 18
| +----+ | | +----+ +----+ | | +----+ | | +----+ +----+ |
+--|xTR1|--+ +--|xTR2|--|xTR3|--+ +--|xTR1|--+ +--|xTR2|--|xTR3|--+
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | |
| | | | | |
+--<[LISP site]>---+-------+ +--<[LISP site]>---+-------+
Figure 2: xTR at the PE Figure 2: xTR at the PE
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 looses 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
skipping to change at page 7, line 14 skipping to change at page 7, line 14
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
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
considers that both entities can be deployed in separated network allows both entities to be deployed in separated network equipment.
equipment. ITRs can be deployed closer to the host (i.e., access ITRs can be deployed closer to the host (i.e., access routers). This
routers). This way packets are encapsulated as soon as possible, and way packets are encapsulated as soon as possible, and egress point
packets exit the network through the best egress point in terms of selection is driven by operational policy. In turn, ETRs can be
BGP policy. In turn, ETRs can be deployed at the border routers of deployed at the border routers of the network, and packets are
the network, and packets are decapsulated as soon as possible. Once decapsulated as soon as possible. Once decapsulated, packets are
decapsulated, packets are routed based on destination EID, according routed based on destination EID, according to internal routing
to internal routing policy. policy.
In the following figure we can see an example. The Source (S) In the following figure we can see an example. The Source (S)
transmits packets using its EID and in this particular case packets transmits packets using its EID and in this particular case packets
are encapsulated at ITR_1. The encapsulated packets are routed are encapsulated at ITR_1. The encapsulated packets are routed
inside the domain according to the destination RLOC, and can egress inside the domain according to the destination RLOC, and can egress
the network through the best point (i.e., closer to the RLOC's AS). the network through the best point (i.e., closer to the RLOC's 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.
skipping to change at page 8, line 7 skipping to change at page 8, line 7
Figure 3: Split ITR/ETR Scenario Figure 3: Split ITR/ETR Scenario
This scenario has a set of implications: This scenario has a set of implications:
o The site must carry at least partial BGP routes in order to choose o The site must carry at least partial BGP routes in order to choose
the best egress point, increasing the complexity of the network. the best egress point, increasing the complexity of the network.
However, this is usually already the case for LISP sites that However, this is usually already the case for LISP sites that
would benefit from this scenario. 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 is doing uRPF filtering, this scenario may become upstream ISPs are doing uRPF filtering, this scenario may become
impractical. ITRs need to determine the exit ETR, for setting the impractical. ITRs need to determine the exit ETR, for setting the
correct source RLOC in the encapsulation header. This adds correct source RLOC in the encapsulation header. This adds
complexity and reliability concerns. 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 MTU within the site network must be large enough to accommodate
encapsulated packets. encapsulated packets.
skipping to change at page 8, line 37 skipping to change at page 8, line 37
database. To lower the impact, the site could use a local caching database. To lower the impact, the site could use a local caching
Map Resolver. Map Resolver.
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, and this may add complexity to intra-site routing
configuration, and further intra-site issues when there is a configuration, and further intra-site issues when there is a
change of providers. 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 At the time of this writing, if two ISPs want to control their
their ingress TE policies. Typically, LISP is seen as applicable to ingress TE policies for transit traffic between them, they need to
stub networks, however the LISP protocol can also be applied to rely on existing BGP mechanisms. This typically means deaggregating
transit networks recursively. prefixes to choose on which upstream link packets should enter. This
is either not feasible (if fine-grained per-customer control is
required, the very specific prefixes may not be propagated) or
increases DFZ table size.
Consider the scenario depicted in Figure 4. Packets originating from Typically, LISP is seen applicable only to stub networks, however the
the LISP site Stub1, client of ISP_A, with destination Stub4, client LISP protocol can be also applied in a recursive manner, providing
of ISP_B, are LISP encapsulated at their entry point into the ISP_A's service provider ingress/egress TE capabilities without impacting the
network. The external IP header now has as the source RLOC an IP DFZ table size.
from ISP_A's address space and destination RLOC from ISP_B's address
space. One or more ASes separate ISP_A from ISP_B. With a single
level of LISP encapsulation, Stub4 has control over its ingress
traffic. However, at the time of this writing, ISP_B has only BGP
tools (such as prefix deaggregation) to control on which of his own
upstream or peering links should packets enter. This is either not
feasible (if fine-grained per-customer control is required, the very
specific prefixes may not be propagated) or increases DFZ table size.
_.--. In order to implement this functionality with LISP consider the
Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub3 scenario depicted in Figure 4. The two ISPs willing to achieve
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. In
this scenario we assume that Stub1 and Stub2 are communicating and
thus, ISP_A and ISP_B offer transit for such communications. ISP_A
has RLOC_A1 and RLOC_A2 as upstream IP addresses while ISP_B has
RLOC_B1 and RLOC_B2. The shared goal among ISP_A and ISP_B is to
control the transit traffic flow between RLOC_A1/A2 and RLOC_B1/B2.
_.--.
Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub2
\ | R_A1|----,' `. ---|R_B1 | / \ | R_A1|----,' `. ---|R_B1 | /
--| R_A2|---( Transit ) | |-- --| | ( Transit ) | |--
Stub2 .../ | R_A3|-----. ,' ---|R_B2 | \... Stub4 ... .../ | R_A2|-----. ,' ---|R_B2 | \... ...
+-------+ `--. _.-' +-------+ +-------+ `--. _.-' +-------+
... ISP_A `--'' ISP_B ... ... ... ISP_A `--'' ISP_B ... ...
Figure 4: Inter-Service provider TE scenario Figure 4: Inter-Service provider TE scenario
A solution for this is to apply LISP recursively. ISP_A and ISP_B Both ISPs deploy xTRs on on RLOC_A1/A2 and RLOC_B1/B2 respectively
may reach a bilateral agreement to deploy their own private mapping and reach a bilateral agreement to deploy their own private mapping
system. ISP_A then encapsulates packets destined for the prefixes of system. This mapping system contains bindings between the RLOCs of
ISP_B, which are listed in the shared mapping system. Note that in Stub1 and Stub2 (owned by ISP_A and ISP_B respectively) and
this case the packet is double-encapsulated (using R_A1, R_A2 or R_A3 RLOC_A1/A2 and RLOC_B1/B2. Such bindings are in fact the TE policies
as source and R_B1 or R_B2 as destination in the example above). between both ISPs and the convergence time is expected to be fast,
ISP_B's ETR removes the outer, second layer of LISP encapsulation since ISPs only have to update/query a mapping to/from the database.
from the incoming packet, and routes it towards the original RLOC,
the ETR of Stub4, which does the final decapsulation.
If ISP_A and ISP_B agree to share a private distributed mapping The packet flow is as follows. First, a packet originated at Stub1
database, both can control their ingress TE without the need of towards Stub2 is LISP encapsulated by Stub1's xTR. The xTR of ISP_A
deaggregating prefixes. In this scenario the private database reencapsulates it and, according to the TE policies stored in the
contains RLOC-to-RLOC bindings. The convergence time on the TE private mapping system, the ISP_A xTR chooses RLOC_B1 or RLOC_B2 as
policies updates is expected to be fast, since ISPs only have to the reencapsulation destination. Note that the packet transits
update/query a mapping to/from the database. between ISP_A and ISP_B double-encapsulated. Upon reception at the
xTR of ISP_B the packet is decapsulated and sent towards Stub2 which
performs the last decapsulation.
This deployment scenario includes two important caveats. First, it This deployment scenario, which uses recursive LISP, includes two
is intended to be deployed between only two ISPs (ISP_A and ISP_B in important caveats. First, it is intended to be deployed between only
Figure 4). If more than two ISPs use this approach, then the xTRs two ISPs. If more than two ISPs use this approach, then the xTRs
deployed at the participating ISPs must either query multiple mapping deployed at the participating ISPs must either 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.
Furthemore, keeping this deployment scenario restricted to only two
ISPs maintains the solution scalable, given that only two entities
need to agree on using recursive LISP, and only one private mapping
system 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
reencapsulated belong to said ISP. Otherwise the participating ISPs reencapsulated belong to said ISP. Otherwise the participating ISPs
must register prefixes they do not own in the above mentioned private must register prefixes they do not own in the above mentioned private
mapping system. Failure to follow these recommendations may lead to mapping system. Failure to follow these recommendations may lead to
operational and security issues when deploying this scenario. operational and security issues when deploying this scenario.
Besides these recommendations, the main disadvantages of this Besides these recommendations, the main disadvantages of this
deployment case are: deployment case are:
skipping to change at page 10, line 14 skipping to change at page 10, line 24
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 binding. 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 The operational overhead of maintaining the shared mapping
database. database.
o If an IPv6 address block is reserved for EID use, as specified in
[I-D.ietf-lisp-eid-block], the EID-to-RLOC encapsulation (first
level) can avoid LISP processing altogether for non-LISP
destinations. The ISP tunnel routers however will not be able to
take advantage of this optimization, all RLOC-to-RLOC mappings
need a lookup in the private database (or map-cache, once results
are cached).
2.5. Tunnel Routers Behind NAT 2.5. 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.5.1. ITR 2.5.1. ITR
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.
skipping to change at page 11, line 16 skipping to change at page 11, line 16
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.
2.5.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 can not be behind carrier based NATs, since two different sites
would collide on the port forwarding. would collide on the port forwarding. An alternative to static hole-
punching to explore is the use of the Port Control Protocol (PCP)
[RFC6887].
2.6. Summary and Feature Matrix 2.6. Summary and Feature Matrix
The following table gives a quick overview of the features supported
by each of the deployment scenarios discussed above (marked with an
"x") in the appropriate column: "CE" for customer edge, "PE" for
provider edge, "Split" for split ITR/ETR, and "Recursive" for inter-
service provider traffic engineering. The discussed features
include:
Control of ingress TE: The scenario allows the LISP site to easily
control LISP ingress traffic engineering policies.
No modifcations to existing int. network infrastruncture: The
scenario doesn't require the LISP site to modify internal network
configurations.
Loc-Status-Bits sync: The scenario allows easy synchronization of
the Locator Status Bits.
MTU/PMTUD issues minimized: The scenario minimizes potential MTU and
Path MTU Discovery issues.
Feature CE PE Split Recursive 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 - - MTU/PMTUD issues minimized - x - -
3. Map Resolvers and Map Servers 3. Map Resolvers and Map Servers
Map Resolvers and Map Servers make up the LISP mapping system and
provide a means to find authoritative EID-to-RLOC mapping
information, conforming to [RFC6833]. They are meant to be deployed
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 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 [RFC6833]. 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., ALT
DDT). Participation in the mapping database, and the storing of EID- [RFC6836], DDT [I-D.ietf-lisp-ddt]). Participation in the mapping
to-RLOC mapping data is subject to the policies of the "root" database, and the storing of EID-to-RLOC mapping data is subject to
operators, who SHOULD check ownership rights for the EID prefixes the policies of the "root" operators, who should check ownership
stored in the database by participants. These policies are out of rights for the EID prefixes stored in the database by participants.
the scope of this document. These policies are out of the scope of this document.
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 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.
achieve fail-over (or load-balancing, if desired), known mapping The configuration for fail-over (or load-balancing, if desired) among
system specific best practices should be used. the members of the group depends on the technology behind the mapping
system being deployed. Since ALT is based on BGP and DDT was
inspired from DNS, deployments can leverage current industry best
practices for redundancy in BGP and DNS. These best practices are
out of the scope of 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 a is a network infrastructure component which accepts A Map Resolver 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 [RFC6833]. 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
skipping to change at page 13, line 16 skipping to change at page 13, line 51
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 [RFC4786] for Map Resolvers similar to
server infrastructure. Since LISP uses UDP encapsulation, the use of the DNS root server infrastructure. Since LISP uses UDP
anycast would not affect reliability. LISP routers are then shipped encapsulation, the use of anycast would not affect reliability. LISP
with a preconfigured list of well know Map Resolver RLOCs, which can routers are then shipped with a preconfigured list of well know Map
be edited by the network administrator, if needed. Resolver RLOCs, which can be edited by the network administrator, if
needed.
The use of anycast also helps improving 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 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
skipping to change at page 15, line 21 skipping to change at page 16, line 7
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 [RFC6832] draft. For more details on P-ETRs see the [RFC6832] 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 (the ratio between the cost of the selected
the tradeoff of using several devices, close to the customers, to path and that of the optimal path). Because of this the ISP needs to
minimize it, or few devices, farther away from the customers, consider the tradeoff of using several devices, close to the
minimizing cost instead. customers, to minimize it, or few devices, farther away from the
customers, 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.
skipping to change at page 16, line 6 skipping to change at page 16, line 41
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 may decrease the need for BGP-based traffic engineering that leads to
leads to prefix deaggregation. That, in turn, may lead to a decrease prefix deaggregation. That, in turn, may lead to a decrease in the
in the DFZ size and churn in the late transition phase. 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 17, line 7 skipping to change at page 17, line 43
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. Note that handling non-LISP-originated traffic may incur sites.
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
skipping to change at page 18, line 23 skipping to change at page 19, line 9
In the example in the figure we have a MSP providing services to the In the example in the figure 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 directly from a RIR, or from the MSP, who may be a LIR. allocation directly from a RIR, or from the MSP, who may be a LIR.
Existing PI allocations can be migrated as well. The MSP ensures the Existing PI allocations can be migrated as well. The MSP ensures the
presence of the prefix in the mapping system, and runs an EID Route presence of the prefix in the mapping system, and runs an EID Route
Server to distribute it to P-ITR service providers. Since the LISP Server to distribute it to P-ITR service providers. 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 5 the EID-Route of LISP Site In the simple case depicted in Figure 5 the EID-Route of 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 P-ITRs 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 P-ITR 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 MSP/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 P-ITR
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
skipping to change at page 19, line 37 skipping to change at page 20, line 24
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 co-exist 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 P-ITR 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 the
DFZ. DFZ.
6. Step-by-Step Example BGP to LISP Migration Procedure Note that throughout Section 5 we focused on the effects of LISP
deployment on the DFZ route table size. Other metrics may be
impacted as well, but to the best of our knowlegde have not been
measured as of yet.
6.1. Customer Pre-Install and Pre-Turn-up Checklist 6. Security Considerations
Security implications of LISP deployments are to be discussed in
separate documents. [I-D.ietf-lisp-threats] gives an overview of
LISP threat models, while securing mapping lookups is discussed in
[I-D.ietf-lisp-sec].
7. IANA Considerations
This memo includes no request to IANA.
8. Acknowledgements
Many thanks to Margaret Wasserman for her contribution to the IETF76
presentation that kickstarted this work. The authors would also like
to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller,
Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, Paul
Vinciguerra, Fred Templin, Brian Haberman, and everyone else who
provided input.
9. References
9.1. Normative References
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833,
January 2013.
9.2. Informative References
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
progress), March 2013.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
and O. Bonaventure, "LISP-Security (LISP-SEC)",
draft-ietf-lisp-sec-04 (work in progress), October 2012.
[I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-04 (work in progress),
February 2013.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, April 2006.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, December 2006.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984,
September 2007.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887,
April 2013.
[cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
performance and the effectiveness of caching", 2002.
Appendix A. Step-by-Step Example BGP to LISP Migration Procedure
To help the operational community deploy LISP, this informative
section offers a step-by-step guide for migrating a BGP based
Internet presence to a LISP site. It includes a pre-install/
pre-turn-up checklist, and customer and provider activation
procedures.
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 the
xTRs. xTRs.
2. Make sure customer router has LISP capabilities. 2. Make sure customer router has LISP capabilities.
skipping to change at page 20, line 39 skipping to change at page 23, line 22
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 Aggregatable). If the physical service provider (Provider Aggregatable). If the
prefixes are assigned by other service provivers then a Letter of prefixes are assigned by other service providers 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.
* 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 customer has access to the router in order to
configure it. configure it.
6.2. Customer Activating LISP Service A.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.
skipping to change at page 21, line 36 skipping to change at page 24, line 21
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, find and ping LISP connected
http://www.lisp4.net/ and/or http://www.lisp6.net/ for sites. If possible, find ping destinations that are not
potential candidates. If possible, find ping destinations covered by a prefix in the global BGP routing system, because
that are not covered by a prefix in the global BGP routing PITRs may deliver the packets even if LISP connectivity is not
system, because PITRs may deliver the packets even if LISP working. Traceroutes may help discover if this is the case.
connectivity is not working. Traceroutes may help discover 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.
6.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 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 30 skipping to change at page 25, line 14
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
http://lispmon.net/).
7. Security Considerations
Security implications of LISP deployments are to be discussed in
separate documents. [I-D.ietf-lisp-threats] gives an overview of
LISP threat models, while securing mapping lookups is discussed in
[I-D.ietf-lisp-sec].
8. IANA Considerations
This memo includes no request to IANA.
9. Acknowledgements
Many thanks to Margaret Wasserman for her contribution to the IETF76
presentation that kickstarted this work. The authors would also like
to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller,
Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, Paul
Vinciguerra, Fred Templin, and everyone else who provided input.
10. References
10.1. Normative References
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833,
January 2013.
10.2. Informative References
[I-D.ietf-lisp-eid-block]
Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP
EID Block", draft-ietf-lisp-eid-block-04 (work in
progress), February 2013.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
and O. Bonaventure, "LISP-Security (LISP-SEC)",
draft-ietf-lisp-sec-04 (work in progress), October 2012.
[I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-04 (work in progress),
February 2013.
[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
performance and the effectiveness of caching", 2002.
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
 End of changes. 52 change blocks. 
219 lines changed or deleted 281 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/