draft-ietf-lisp-deployment-03.txt   draft-ietf-lisp-deployment-04.txt 
Network Working Group L. Jakab Network Working Group L. Jakab
Internet-Draft A. Cabellos-Aparicio Internet-Draft A. Cabellos-Aparicio
Intended status: Informational F. Coras Intended status: Informational F. Coras
Expires: September 13, 2012 J. Domingo-Pascual Expires: March 16, 2013 J. Domingo-Pascual
Technical University of Technical University of
Catalonia Catalonia
D. Lewis D. Lewis
Cisco Systems Cisco Systems
March 12, 2012 September 12, 2012
LISP Network Element Deployment Considerations LISP Network Element Deployment Considerations
draft-ietf-lisp-deployment-03.txt draft-ietf-lisp-deployment-04.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 37
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 13, 2012. This Internet-Draft will expire on March 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . 16 5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 15
5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16
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) . . . . . . . . . . 17
5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19 5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19
6. Step-by-Step BGP to LISP Migration Procedure . . . . . . . . . 20 6. Step-by-Step Example BGP to LISP Migration Procedure . . . . . 20
6.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 20 6.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 20
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 . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Informative References . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
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
[I-D.ietf-lisp] describes how the separation is achieved, which new [I-D.ietf-lisp] describes how the separation is achieved, which new
network elements are introduced, and details the packet formats for network elements are introduced, and details the packet formats for
the data and control planes. the data and control planes.
While the boundary between the core and edge is not strictly defined, LISP assumes that such separation is between the edge and core.
one widely accepted definition places it at the border routers of While the boundary between both is not strictly defined, one widely
stub autonomous systems, which may carry a partial or complete accepted definition places it at the border routers of stub
default-free zone (DFZ) routing table. The initial design of LISP autonomous systems, which may carry a partial or complete default-
took this location as a baseline for protocol development. However, free zone (DFZ) routing table. The initial design of LISP took this
the applications of LISP go beyond of just decreasing the size of the location as a baseline for protocol development. However, the
DFZ routing table, and include improved multihoming and ingress applications of LISP go beyond of just decreasing the size of the DFZ
traffic engineering (TE) support for edge networks, and even routing table, and include improved multihoming and ingress traffic
individual hosts. Throughout the draft we will use the term LISP engineering (TE) support for edge networks, and even individual
site to refer to these networks/hosts behind a LISP Tunnel Router. hosts. Throughout the draft we will use the term LISP site to refer
We formally define it as: to these networks/hosts behind a 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).
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. The main specification [I-D.ietf-lisp] mentions and other protocols. Additionally, this document is intended as a
positioning of tunnel routers, but without an in-depth discussion. guide for the operational community for LISP deployments in their
This document fills that gap, by exploring the most common cases. networks. It is expected to evolve as LISP deployment progresses,
While the theoretical combinations of device placements are quite and the described scenarios are better understood or new scenarios
numerous, the more practical scenarios are given preference in the are discovered.
following.
Additionally, this documents is intended as a guide for the
operational community for LISP deployments in their networks. It is
expected to evolve as LISP deployment progresses, and the described
scenarios are better understood or new scenarios 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).
Comments and discussions about this memo should be directed to the
LISP working group mailing list: lisp@ietf.org.
2. Tunnel Routers 2. Tunnel Routers
LISP is a map-and-encap protocol, with the main goal of improving LISP is a map-and-encap protocol, with the main goal of improving
global routing scalability. To achieve its goal, it introduces global routing scalability. To achieve its goal, it introduces
several new network elements, each performing specific functions several new network elements, each performing specific functions
necessary to separate the edge from the core. The device that is the 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), gateway between the edge and the core is called Tunnel Router (xTR),
performing one or both of two separate functions: 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
skipping to change at page 6, line 35 skipping to change at page 6, line 35
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 today's DNS. over the entries to customer, much like in the Domain Name System at
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 correctly on encapsulated packets.
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.
skipping to change at page 7, line 4 skipping to change at page 7, line 5
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
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 considers that both entities can be deployed in separated network
equipment. ITRs can be deployed closer to the host (i.e., access equipment. ITRs can be deployed closer to the host (i.e., access
routers). This way packets are encapsulated as soon as possible, and routers). This way packets are encapsulated as soon as possible, and
packets exit the network through the best egress point in terms of packets exit the network through the best egress point in terms of
BGP policy. In turn, ETRs can be deployed at the border routers of BGP policy. In turn, ETRs can be deployed at the border routers of
the network, and packets are decapsulated as soon as possible. the network, and packets are decapsulated as soon as possible. Once
Again, once decapsulated packets are routed according to the EID, and decapsulated, packets are routed based on destination EID, according
can follow the best path according to internal routing policy. to internal routing 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 8 skipping to change at page 8, line 9
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 is 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 ETRs. of all ETRs serving their site.
o ITRs encapsulate packets and in order to achieve efficient o MTU within the site network must be large enough to accommodate
communications, the MTU of the site must be large enough to encapsulated packets.
accommodate this extra header.
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 will 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.
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
of ISP_B, are LISP encapsulated at their entry point into the ISP_A's of ISP_B, are LISP encapsulated at their entry point into the ISP_A's
network. The external IP header now has as the source RLOC an IP network. The external IP header now has as the source RLOC an IP
from ISP_A's address space and destination RLOC from ISP_B's address 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 space. One or more ASes separate ISP_A from ISP_B. With a single
level of LISP encapsulation, Stub4 has control over its ingress level of LISP encapsulation, Stub4 has control over its ingress
traffic. However, ISP_B only has the current tools (such as BGP traffic. However, at the time of this writing, ISP_B has only BGP
prefix deaggregation) to control on which of his own upstream or tools (such as prefix deaggregation) to control on which of his own
peering links should packets enter. This is either not feasible (if upstream or peering links should packets enter. This is either not
fine-grained per-customer control is required, the very specific feasible (if fine-grained per-customer control is required, the very
prefixes may not be propagated) or increases DFZ table size. specific prefixes may not be propagated) or increases DFZ table size.
_.--. _.--.
Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub3 Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub3
\ | R_A1|----,' `. ---|R_B1 | / \ | R_A1|----,' `. ---|R_B1 | /
--| R_A2|---( Transit ) | |-- --| R_A2|---( Transit ) | |--
Stub2 .../ | R_A3|-----. ,' ---|R_B2 | \... Stub4 Stub2 .../ | R_A3|-----. ,' ---|R_B2 | \... Stub4
+-------+ `--. _.-' +-------+ +-------+ `--. _.-' +-------+
... ISP_A `--'' ISP_B ... ... ISP_A `--'' ISP_B ...
Figure 4: Inter-Service provider TE scenario Figure 4: Inter-Service provider TE scenario
skipping to change at page 9, line 19 skipping to change at page 9, line 19
system. ISP_A then encapsulates packets destined for the prefixes of system. ISP_A then encapsulates packets destined for the prefixes of
ISP_B, which are listed in the shared mapping system. Note that in ISP_B, which are listed in the shared mapping system. Note that in
this case the packet is double-encapsulated (using R_A1, R_A2 or R_A3 this case the packet is double-encapsulated (using R_A1, R_A2 or R_A3
as source and R_B1 or R_B2 as destination in the example above). as source and R_B1 or R_B2 as destination in the example above).
ISP_B's ETR removes the outer, second layer of LISP encapsulation ISP_B's ETR removes the outer, second layer of LISP encapsulation
from the incoming packet, and routes it towards the original RLOC, from the incoming packet, and routes it towards the original RLOC,
the ETR of Stub4, which does the final decapsulation. the ETR of Stub4, which does the final decapsulation.
If ISP_A and ISP_B agree to share a private distributed mapping If ISP_A and ISP_B agree to share a private distributed mapping
database, both can control their ingress TE without the need of database, both can control their ingress TE without the need of
disaggregating prefixes. In this scenario the private database deaggregating prefixes. In this scenario the private database
contains RLOC-to-RLOC bindings. The convergence time on the TE contains RLOC-to-RLOC bindings. The convergence time on the TE
policies updates is expected to be fast, since ISPs only have to policies updates is expected to be fast, since ISPs only have to
update/query a mapping to/from the database. update/query a mapping to/from the database.
This deployment scenario includes two important recommendations. This deployment scenario includes two important caveats. First, it
First, it is intended to be deployed only between two ISPs (ISP_A and is intended to be deployed between only two ISPs (ISP_A and ISP_B in
ISP_B in Figure 4). If more than two ISPs use this approach, then Figure 4). If more than two ISPs use this approach, then the xTRs
the xTRs deployed at the participating ISPs must either query deployed at the participating ISPs must either query multiple mapping
multiple mapping systems, or the ISPs must agree on a common shared systems, or the ISPs must agree on a common shared mapping system.
mapping system. Second, the scenario is only recommended for ISPs Second, the scenario is only recommended for ISPs providing
providing connectivity to LISP sites, such that source RLOCs of connectivity to LISP sites, such that source RLOCs of packets to be
packets to be reencapsulated belong to said ISP. Otherwise the reencapsulated belong to said ISP. Otherwise the participating ISPs
participating ISPs must register prefixes they do not own in the must register prefixes they do not own in the above mentioned private
above mentioned private mapping system. Failure to follow these mapping system. Failure to follow these recommendations may lead to
recommendations may lead to operational and security issues when operational and security issues when deploying this scenario.
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:
o Extra LISP header is needed. This increases the packet size and, o Extra LISP header is needed. This increases the packet size and
for efficient communications, it requires that the MTU between requires that the MTU between both ISPs accommodates double-
both ISPs can accommodate double-encapsulated packets. encapsulated packets.
o The ISP ITR must encapsulate packets and therefore must know the o The ISP ITR must encapsulate packets and therefore must know the
RLOC-to-RLOC binding. These bindings are stored in a mapping RLOC-to-RLOC 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 extra lookup latency, unless NERD misses lead to an additional lookup latency, unless a push based
[I-D.lear-lisp-nerd] is used for the lookups. 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 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 [I-D.ietf-lisp-eid-block], the EID-to-RLOC encapsulation (first
level) can avoid LISP processing altogether for non-LISP level) can avoid LISP processing altogether for non-LISP
destinations. The ISP tunnel routers however will not be able to destinations. The ISP tunnel routers however will not be able to
take advantage of this optimization, all RLOC-to-RLOC mappings take advantage of this optimization, all RLOC-to-RLOC mappings
need a lookup in the private database (or map-cache, once results need a lookup in the private database (or map-cache, once results
skipping to change at page 10, line 24 skipping to change at page 10, line 24
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.
Map-Requests sent by an ITR, which create the state in the NAT table Map-Requests sent by an ITR, which create the state in the NAT table,
have a different 5-tuple in the IP header than the Map-Reply have a different 5-tuple in the IP header than the Map-Reply
generated by the authoritative ETR. Since the source address of this generated by the authoritative ETR. Since the source address of this
packet is different from the destination address of the request packet is different from the destination address of the request
packet, no state will be matched in the NAT table and the packet will packet, no state will be matched in the NAT table and the packet will
be dropped. To avoid this, the NAT device has to do the following: be dropped. To avoid this, the NAT device has to do the following:
o Send all UDP packets with source port 4342, regardless of the o Send all UDP packets with source port 4342, regardless of the
destination port, to the RLOC of the ITR. The most simple way to destination port, to the RLOC of the ITR. The 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
skipping to change at page 11, line 43 skipping to change at page 11, line 43
MSP can be any of the following: MSP can be any of the following:
o EID registrar. Since the IPv4 address space is nearing o EID registrar. Since the IPv4 address space is nearing
exhaustion, IPv4 EIDs will come from already allocated Provider exhaustion, IPv4 EIDs will come from already allocated Provider
Independent (PI) space. The registrars in this case remain the Independent (PI) space. The registrars in this case remain the
current five Regional Internet Registries (RIRs). In the case of current five Regional Internet Registries (RIRs). In the case of
IPv6, the possibility of reserving a /16 block as EID space is IPv6, the possibility of reserving a /16 block as EID space is
currently under consideration [I-D.ietf-lisp-eid-block]. If currently under consideration [I-D.ietf-lisp-eid-block]. If
granted by IANA, the community will have to determine the body granted by IANA, the community will have to determine the body
responsible for allocations from this block, and the associated responsible for allocations from this block, and the associated
policies. For already allocated IPv6 prefixes the principles from policies. Existing allocation policies apply to EIDs outside this
IPv4 should be applied. block.
o Third parties. Participating in the LISP mapping system is o Third parties. Participating in the LISP mapping system is
similar to participating in global routing or DNS: as long as similar to participating in global routing or DNS: as long as
there is at least another already participating entity willing to there is at least another already participating entity willing to
forward the newcomer's traffic, there is no barrier to entry. forward the newcomer's traffic, there is no barrier to entry.
Still, just like routing and DNS, LISP mappings have the issue of Still, just like routing and DNS, LISP mappings have the issue of
trust, with efforts underway to make the published information trust, with efforts underway to make the published information
verifiable. When these mechanisms will be deployed in the LISP verifiable. When these mechanisms will be deployed in the LISP
mapping system, the burden of providing and verifying trust should mapping system, the burden of providing and verifying trust should
be kept away from MSPs, which will simply host the secured be kept away from MSPs, which will simply host the secured
skipping to change at page 12, line 36 skipping to change at page 12, line 36
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), current known BGP achieve fail-over (or load-balancing, if desired), known mapping
practices can be used on the LISP+ALT BGP overlay network. 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 [I-D.ietf-lisp-ms].
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. In the Map-Resolver and provide EID-to-RLOC mapping lookup service.
case of the LISP+ALT mapping system, the Map-Resolver needs to become Database access setup is mapping system specific.
part of the ALT overlay so that it can forward packets to the
appropriate Map-Servers. For more detail on how the ALT overlay
works, see [I-D.ietf-lisp-alt]
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.
skipping to change at page 14, line 31 skipping to change at page 14, line 27
(proportionally with existing global LISP deployment) when going (proportionally with existing global LISP deployment) when going
LISP, so it has the incentives to deploy the necessary tunnel LISP, so it has the incentives to deploy the necessary tunnel
routers. In order to be reachable from non-LISP sites it has two routers. In order to be reachable from non-LISP sites it has two
options: keep announcing its prefix(es) with BGP, or have a P-ITR options: keep announcing its prefix(es) with BGP, or have a P-ITR
announce prefix(es) covering them. announce prefix(es) covering them.
If the goal of reducing the DFZ routing table size is to be reached, If the goal of reducing the DFZ routing table size is to be reached,
the second option is preferred. Moreover, the second option allows the second option is preferred. Moreover, the second option allows
LISP-based ingress traffic engineering from all sites. However, the LISP-based ingress traffic engineering from all sites. However, the
placement of P-ITRs significantly influences performance and placement of P-ITRs significantly influences performance and
deployment incentives. Section Section 5 is dedicated to the deployment incentives. Section 5 is dedicated to the migration to a
migration to a LISP-enabled Internet, and includes deployment LISP-enabled Internet, and includes deployment scenarios for P-ITRs.
scenarios for P-ITRs.
4.2. P-ETR 4.2. P-ETR
In contrast to P-ITRs, P-ETRs are not required for the correct In contrast to P-ITRs, P-ETRs are not required for the correct
functioning of all LISP sites. There are two cases, where they can functioning of all LISP sites. There are two cases, where they can
be of great help: be of great help:
o LISP sites with unicast reverse path forwarding (uRPF) o LISP sites with unicast reverse path forwarding (uRPF)
restrictions, and restrictions, and
o LISP sites without native IPv6 communicating with LISP nodes with o Communication between sites using different address family RLOCs.
IPv6-only locators.
In the first case, uRPF filtering is applied at their upstream PE In the first case, uRPF filtering is applied at their upstream PE
router. When forwarding traffic to non-LISP sites, an ITR does not router. When forwarding traffic to non-LISP sites, an ITR does not
encapsulate packets, leaving the original IP headers intact. As a encapsulate packets, leaving the original IP headers intact. As a
result, packets will have EIDs in their source address. Since we are result, packets will have EIDs in their source address. Since we are
discussing the transition period, we can assume that a prefix discussing the transition period, we can assume that a prefix
covering the EIDs belonging to the LISP site is advertised to the covering the EIDs belonging to the LISP site is advertised to the
global routing tables by a P-ITR, and the PE router has a route global routing tables by a P-ITR, and the PE router has a route
towards it. However, the next hop will not be on the interface towards it. However, the next hop will not be on the interface
towards the CE router, so non-encapsulated packets will fail uRPF towards the CE router, so non-encapsulated packets will fail uRPF
skipping to change at page 15, line 43 skipping to change at page 15, line 39
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. To enable configured by DHCP, stand to benefit most from P-ETRs.
autoconfiguration of the P-ETR locator, a DHCP option would be Autoconfiguration of the P-ETR locator could be achieved by a DHCP
required. 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 As a security measure, access to P-ETRs should be limited to
legitimate users by enforcing ACLs. 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
skipping to change at page 16, line 43 skipping to change at page 16, line 36
5.2. Mapping Service Provider (MSP) P-ITR Service 5.2. Mapping Service Provider (MSP) P-ITR Service
In addition to publishing their clients' registered prefixes in the In addition to publishing their clients' registered prefixes in the
mapping system, MSPs with enough transit capacity can offer them mapping system, MSPs with enough transit capacity can offer them
P-ITR service as a separate service. This service is especially P-ITR service as a separate service. This service is especially
useful for new PI allocations, to sites without existing BGP useful for new PI allocations, to sites without existing BGP
infrastructure, that wish to avoid BGP altogether. The MSP announces infrastructure, 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 path stretch, which may be greater than 1. 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. When the LISP/non-LISP site
ratio becomes high enough, this approach can prove increasingly ratio becomes high enough, this approach can prove increasingly
attractive. 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
skipping to change at page 18, line 27 skipping to change at page 18, line 27
PSP (AS64501) PSP (AS64501)
Figure 5: The P-ITR Route Distribution architecture Figure 5: The P-ITR Route Distribution architecture
The architecture described above decouples EID origination from route The architecture described above decouples EID origination from route
propagation, with the following benefits: propagation, with the following benefits:
o Can accurately represent business relationships between P-ITR o Can accurately represent business relationships between P-ITR
operators operators
o More mapping system agnostic (no reliance on ALT) o More mapping system agnostic
o Minor changes to P-ITR implementation, no changes to other o Minor changes to P-ITR implementation, no changes to other
components components
In the example in the figure we have a MSP providing services to the In the example in 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
skipping to change at page 20, line 6 skipping to change at page 20, line 6
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 BGP to LISP Migration Procedure 6. Step-by-Step Example BGP to LISP Migration Procedure
6.1. Customer Pre-Install and Pre-Turn-up Checklist 6.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.
skipping to change at page 23, line 17 skipping to change at page 23, line 17
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, and
everyone else who provided input. everyone else who provided input.
10. References 10. Informative References
10.1. Normative References
[I-D.ietf-lisp] [I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-15 (work in progress), July 2011. draft-ietf-lisp-23 (work in progress), May 2012.
[I-D.ietf-lisp-alt] [I-D.ietf-lisp-eid-block]
Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP
Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-09 EID Block", draft-ietf-lisp-eid-block-02 (work in
(work in progress), September 2011. progress), April 2012.
[I-D.ietf-lisp-interworking] [I-D.ietf-lisp-interworking]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6", "Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-02 (work in progress), draft-ietf-lisp-interworking-06 (work in progress),
June 2011. March 2012.
[I-D.ietf-lisp-ms] [I-D.ietf-lisp-ms]
Fuller, V. and D. Farinacci, "LISP Map Server Interface", Fuller, V. and D. Farinacci, "LISP Map Server Interface",
draft-ietf-lisp-ms-12 (work in progress), October 2011. draft-ietf-lisp-ms-16 (work in progress), March 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-00 (work in progress), July 2011. draft-ietf-lisp-sec-02 (work in progress), March 2012.
[I-D.saucez-lisp-security] [I-D.saucez-lisp-security]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Saucez, D., Iannone, L., and O. Bonaventure, "LISP
Security Threats", draft-saucez-lisp-security-03 (work in Security Threats", draft-saucez-lisp-security-03 (work in
progress), March 2011. progress), March 2011.
10.2. Informative References
[I-D.ietf-lisp-eid-block]
Lewis, D., Meyer, D., Iannone, L., and V. Fuller, "LISP
EID Block", draft-ietf-lisp-eid-block-01 (work in
progress), October 2011.
[I-D.lear-lisp-nerd]
Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-08 (work in progress), March 2010.
[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 Technical University of Catalonia
C/Jordi Girona, s/n C/Jordi Girona, s/n
BARCELONA 08034 BARCELONA 08034
Spain Spain
 End of changes. 39 change blocks. 
112 lines changed or deleted 82 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/