draft-ietf-lisp-deployment-00.txt   draft-ietf-lisp-deployment-01.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: November 4, 2011 J. Domingo-Pascual Expires: January 12, 2012 J. Domingo-Pascual
Technical University of Catalonia Technical University of Catalonia
D. Lewis D. Lewis
Cisco Systems Cisco Systems
May 3, 2011 July 11, 2011
LISP Network Element Deployment Considerations LISP Network Element Deployment Considerations
draft-ietf-lisp-deployment-00.txt draft-ietf-lisp-deployment-01.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 36 skipping to change at page 1, line 36
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 November 4, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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.1.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.2. Mapping Service Provider P-ITR Service . . . . . . . . 15 5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3. Tier 1 P-ITR Service . . . . . . . . . . . . . . . . . 15 5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.4. Migration Summary . . . . . . . . . . . . . . . . . . 17 5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16
4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Proxy-ITR Route Distribution . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
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.
skipping to change at page 11, line 38 skipping to change at page 11, line 38
functionality is described in detail in [I-D.ietf-lisp-ms]. functionality is described in detail in [I-D.ietf-lisp-ms].
The Map-Server is provided by a Mapping Service Provider (MSP). A The Map-Server is provided by a Mapping Service Provider (MSP). A
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.meyer-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. For already allocated IPv6 prefixes the principles from
IPv4 should be applied. IPv4 should be applied.
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
skipping to change at page 14, line 22 skipping to change at page 14, line 22
maintain backwards compatibility and inter-operate with the maintain backwards compatibility and inter-operate with the
protocol(s) they intend to enhance or replace, and on the incentives protocol(s) they intend to enhance or replace, and on the incentives
to deploy the necessary new software or equipment. A LISP site needs to deploy the necessary new software or equipment. A LISP site needs
an interworking mechanism to be reachable from non-LISP sites. A an interworking mechanism to be reachable from non-LISP sites. A
P-ITR can fulfill this role, enabling early adopters to see the P-ITR can fulfill this role, enabling early adopters to see the
benefits of LISP, similar to tunnel brokers helping the transition benefits of LISP, similar to tunnel brokers helping the transition
from IPv4 to IPv6. A site benefits from new LISP functionality from IPv4 to IPv6. A site benefits from new LISP functionality
(proportionally with existing global LISP deployment) when going (proportionally with existing global LISP deployment) when going
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 (see next options: keep announcing its prefix(es) with BGP, or have a P-ITR
subsection), 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 greatly influences performance and deployment placement of P-ITRs significantly influences performance and
incentives. The following subsections present the LISP+BGP deployment incentives. Section Section 5 is dedicated to the
transition strategy and then possible P-ITR deployment scenarios. migration to a LISP-enabled Internet, and includes deployment
They use the loosely defined terms of "early transition phase", "late scenarios for P-ITRs.
transition phase", and "LISP Internet phase", which refer to time
periods when LISP sites are a minority, a majority, or represent all
edge networks respectively.
4.1.1. LISP+BGP 4.2. P-ETR
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
be of great help:
o LISP sites with unicast reverse path forwarding (uRPF)
restrictions, and
o LISP sites without native IPv6 communicating with LISP nodes with
IPv6-only locators.
In the first case, uRPF filtering is applied at their upstream PE
router. When forwarding traffic to non-LISP sites, an ITR does not
encapsulate packets, leaving the original IP headers intact. As a
result, packets will have EIDs in their source address. Since we are
discussing the transition period, we can assume that a prefix
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
towards it. However, the next hop will not be on the interface
towards the CE router, so non-encapsulated packets will fail uRPF
checks.
To avoid this filtering, the affected ITR encapsulates packets
towards the locator of the P-ETR for non-LISP destinations. Now the
source address of the packets, as seen by the PE router is the ITR's
locator, which will not fail the uRPF check. The P-ETR then
decapsulates and forwards the packets.
The second use case is IPv4-to-IPv6 transition. Service providers
using older access network hardware, which only supports IPv4 can
still offer IPv6 to their clients, by providing a CPE device running
LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP
sites, with IPv6-only locators. Packets originating from the client
LISP site for these destinations would be encapsulated towards the
P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network,
decapsulating and forwarding packets. For non-LISP destination, the
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
reach its destination.
For more details on P-ETRs see the [I-D.ietf-lisp-interworking]
draft.
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
introduce path stretch. Because of this the ISP needs to consider
the tradeoff of using several devices, close to the 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,
it is likely they will be deployed in separate devices, except for
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
configuration of a LISP router. CPE routers, which are typically
configured by DHCP, stand to benefit most from P-ETRs. To enable
autoconfiguration of the P-ETR locator, a DHCP option would be
required.
As a security measure, access to P-ETRs should be limited to
legitimate users by enforcing ACLs.
5. Migration to LISP
This section discusses a deployment architecture to support the
migration to a LISP-enabled Internet. The loosely defined terms of
"early transition phase", "late transition phase", and "LISP Internet
phase" refer to time periods when LISP sites are a minority, a
majority, or represent all edge networks respectively.
5.1. LISP+BGP
For sites wishing to go LISP with their PI prefix the least For sites wishing to go LISP with their PI prefix the least
disruptive way is to upgrade their border routers to support LISP, disruptive way is to upgrade their border routers to support LISP,
register the prefix into the LISP mapping system, but keep announcing register the prefix into the LISP mapping system, but keep announcing
it with BGP as well. This way LISP sites will reach them over LISP, it with BGP as well. This way LISP sites will reach them over LISP,
while legacy sites will be unaffected by the change. The main while legacy sites will be unaffected by the change. The main
disadvantage of this approach is that no decrease in the DFZ routing disadvantage of this approach is that no decrease in the DFZ routing
table size is achieved. Still, just increasing the number of LISP table size is achieved. Still, just increasing the number of LISP
sites is an important gain, as an increasing LISP/non-LISP site ratio sites is an important gain, as an increasing LISP/non-LISP site ratio
will slowly decrease the need for BGP-based traffic engineering that will slowly decrease the need for BGP-based traffic engineering that
leads to prefix deaggregation. That, in turn, may lead to a decrease leads to prefix deaggregation. That, in turn, may lead to a decrease
in the DFZ size in the late transition phase. in the DFZ size 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, one of the following Since this leads to an increase in the DFZ size, the following
scenarios should be preferred for new allocations. architecture should be preferred for new allocations.
4.1.2. Mapping Service Provider 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 path stretch, which may be greater than 1.
skipping to change at page 15, line 35 skipping to change at page 17, line 12
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
deaggregation for traffic engineering purposes, resulting in slower deaggregation for traffic engineering purposes, resulting in slower
routing table increase in the case of new allocations and potential routing table increase in the case of new allocations and potential
decrease for existing ones. Moreover, MSPs serving different clients decrease for existing ones. Moreover, MSPs serving different clients
with adjacent aggregable prefixes may lead to additional decrease, with adjacent aggregable prefixes may lead to additional decrease,
but quantifying this decrease is subject to future research study. but quantifying this decrease is subject to future research study.
4.1.3. Tier 1 P-ITR Service 5.3. Proxy-ITR Route Distribution
The ideal location for a P-ITR is on the traffic path, as close to Instead of a LISP site, or the MSP, announcing their EIDs with BGP to
non-LISP site as possible, to minimize or completely eliminate path the DFZ, this function can be outsourced to a third party, a P-ITR
stretch. However, this location is far away from the networks that Service Provider (PSP). This will result in a decrease of the
most benefit from the P-ITR services (i.e., LISP sites, destinations operational complexity both at the site and at the MSP.
of encapsulated traffic) and have the most incentives to deploy them.
But the biggest challenge having P-ITRs close to the traffic source
is the large number of devices and their wide geographical diversity
required to have a good coverage, in addition to considerable transit
capacity. Tier 1 service providers fulfill these requirements and
have clear incentives to deploy P-ITRs: to attract more traffic from
their customers. Since a large fraction is multihomed to different
providers with more than one active link, they compete with the other
providers for traffic.
To operate the P-ITR service, the ISP announces an aggregate of all The PSP manages a set of distributed P-ITR(s) that will advertise the
known EID prefixes (a mechanism will be needed to obtain this list) corresponding EID prefixes through BGP to the DFZ. These P-ITR(s)
downstream to their customers with BGP. First, the performance will then encapsulate the traffic they receive for those EIDs towards
concerns of the MSP P-ITR service described in the previous section the RLOCs of the LISP site, ensuring their reachability from non-LISP
are now addressed, as P-ITRs are on-path, eliminating path stretch sites.
(except when combined with LISP+BGP, see below). Second, thanks to
the direction of the announcements, the DFZ routing table size is not
affected.
The main downside of this approach is non-global coverage for the While it is possible for a PSP to manually configure each client's
announced prefixes, caused by the downstream direction of the EID routes to be announced, this approach offers little flexibility
announcements. As a result, a LISP site will be only reachable from and is not scalable. This section presents a scalable architecture
customers of service providers running P-ITRs, unless one of the that offers automatic distribution of EID routes to LISP sites and
previous approaches is used as well. Due to this issue, it is service providers.
unlikely that existing BGP speakers migrating to LISP will withdraw
their announcements to the DFZ, resulting in a combination of this
approach with LISP+BGP. At the same time, smaller new LISP sites
still depend on MSP for global reachability. The early transition
phase thus will keep the status quo in the DFZ routing table size,
but offers the benefits of increasingly better ingress traffic
engineering to early adopters.
As the number of LISP destinations increases, traffic levels from The architecture requires no modification to existing LISP network
those non-LISP, large multihomed clients who rely on BGP path length elements, but it introduces a new (conceptual) network element, the
for provider selection (such as national/regional ISPs), start to EID Route Server, defined as a router that either propagates routes
shift towards the Tier 1 providing P-ITRs. The competition is then learned from other EID Route Servers, or it originates EID Routes.
incentivised to deploy their own service, thus improving global P-ITR The EID-Routes that it originates are those that it is authoritative
coverage. If all Tier 1 providers have P-ITR service, the LISP+BGP for. It propagates these routes to Proxy-ITRs within the AS of the
and MSP alternatives are not required for global reachability of LISP EID Route Server. It is worth to note that a BGP capable router can
sites. Still, LISP+BGP users may still want to keep announcing their be also considered as an EID Route Server.
prefixes for security reasons (i.e., preventing hijacking). DFZ size
evolution in this phase depends on that choice, and the aggregability
of all LISP prefixes. As a result, it may decrease or stay at the
same level.
For performance reasons, and to simplify P-ITR implementations, it is Further, an EID-Route is defined as a prefix originated via the Route
desirable to minimize the number of non-aggregable EID prefixes. In Server of the mapping service provider, which should be aggregated if
IPv6 this can be easily achieved if a large prefix block is reserved the MSP has multiple customers inside a single netblock. This prefix
as LISP EID space [I-D.meyer-lisp-eid-block]. If the EID space is is propagated to other P-ITRs both within the MSP and to other P-ITR
not fragmented, new LISP sites will not cause increase in the DFZ operators it peers with. EID Route Servers are operated either by
size, unless they do LISP+BGP. the LISP site, MSPs or PSPs, and they may be collocated with a Map-
Server or P-ITR, but are a functionally discrete entity. They
distribute EID-Routes, using BGP, to other domains, according to
policies set by participants.
To summarize, the main benefits of this scenario are stopping the MSP (AS64500)
increase and potentially decreasing the size of the DFZ routing RS ---> P-ITR
tables, while keeping path stretch close to 1, with the cost of not | /
having global coverage of one's prefixes. | _.--./
,-'' /`--.
LISP site ---,' | v `.
( | DFZ )----- Mapping system
non-LISP site ----. | ^ ,'
`--. / _.-'
| `--''
v /
P-ITR
PSP (AS64501)
4.1.4. Migration Summary Figure 5: The P-ITR Route Distribution architecture
The following table presents the expected effects of the different The architecture described above decouples EID origination from route
transition scenarios during a certain phase on the DFZ routing table propagation, with the following benefits:
size:
Phase | LISP+BGP | MSP | Tier 1 o Can accurately represent business relationships between P-ITR
-----------------+--------------+-------------------+------------- operators
Early transition | no change | slowdown increase | no change
Late transition | may decrease | slowdown increase | may decrease
LISP Internet | considerable decrease
It is expected that a combination of these scenarios will exist o More mapping system agnostic (no reliance on ALT)
during the migration period, in particular existing sites choosing
LISP+BGP, new small sites choosing MSP, and competition between Tier
1 providers bringing optimized service. If all Tier 1 ISPs have
P-ITR service in place, the other scenarios can be deprecated,
greatly reducing DFZ size.
4.2. P-ETR o Minor changes to P-ITR implementation, no changes to other
components
In contrast to P-ITRs, P-ETRs are not required for the correct In the example in the figure we have a MSP providing services to the
functioning of all LISP sites. There are two cases, where they can LISP site. The LISP site does not run BGP, and gets an EID
be of great help: 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
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
site does not run BGP, the prefix will be originated with the AS
number of the MSP.
o LISP sites with unicast reverse path forwarding (uRPF) In the simple case depicted in Figure 5 the EID-Route of LISP Site
restrictions, and 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
usual BGP dynamics apply. This way, routes announced by P-ITR are
still originated by the authoritative Route Server. Note that the
peering relationships between MSP/PSPs and those in the underlying
forwarding plane may not be congruent, making the AS path to a P-ITR
shorter than it is in reality.
o LISP sites without native IPv6 communicating with LISP nodes with The non-LISP site will select the best path towards the EID-prefix,
IPv6-only locators. according to its local BGP policies. Since AS-path length is usually
an important metric for selecting paths, a careful placement of P-ITR
could significantly reduce path-stretch between LISP and non-LISP
sites.
In the first case, uRPF filtering is applied at their upstream PE The architecture allows for flexible policies between MSP/PSPs.
router. When forwarding traffic to non-LISP sites, an ITR does not Consider the EID Route Server networks as control plane overlays,
encapsulate packets, leaving the original IP headers intact. As a facilitating the implementation of policies necessary to reflect the
result, packets will have EIDs in their source address. Since we are business relationships between participants. The results are then
discussing the transition period, we can assume that a prefix injected to the common underlying forwarding plane. For example,
covering the EIDs belonging to the LISP site is advertised to the some MSP/PSPs may agree to exchange EID-Prefixes and only announce
global routing tables by a P-ITR, and the PE router has a route them to each of their forwarding plane customers. Global
towards it. However, the next hop will not be on the interface reachability of an EID-prefix depends on the MSP the LISP site buys
towards the CE router, so non-encapsulated packets will fail uRPF service from, and is also subject to agreement between the mentioned
checks. parties.
To avoid this filtering, the affected ITR encapsulates packets In terms of impact on the DFZ, this architecture results in a slower
towards the locator of the P-ETR for non-LISP destinations. Now the routing table increase for new allocations, since traffic engineering
source address of the packets, as seen by the PE router is the ITR's will be done at the LISP level. For existing allocations migrating
locator, which will not fail the uRPF check. The P-ETR then to LISP, the DFZ may decrease since MSPs may be able to aggregate the
decapsulates and forwards the packets. prefixes announced.
The second use case is IPv4-to-IPv6 transition. Service providers Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix
using older access network hardware, which only supports IPv4 can deaggregation for traffic engineering purposes, resulting in slower
still offer IPv6 to their clients, by providing a CPE device running routing table increase in the case of new allocations and potential
LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP decrease for existing ones. Moreover, MSPs serving different clients
sites, with IPv6-only locators. Packets originating from the client with adjacent aggregable prefixes may lead to additional decrease,
LISP site for these destinations would be encapsulated towards the but quantifying this decrease is subject to future research study.
P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network,
decapsulating and forwarding packets. For non-LISP destination, the
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
reach its destination.
For more details on P-ETRs see the [I-D.ietf-lisp-interworking] The flexibility and scalability of this architecture does not come
draft. without a cost however: A PSP operator has to establish either
transit or peering relationships to improve their connectivity.
P-ETRs can be deployed by ISPs wishing to offer value-added services 5.4. Migration Summary
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
the tradeoff of using several devices, close to the 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, The following table presents the expected effects of the different
it is likely they will be deployed in separate devices, except for transition scenarios during a certain phase on the DFZ routing table
the CDN case, which may deploy both in a single device. size:
In all cases, the existence of a P-ETR involves another step in the Phase | LISP+BGP | MSP P-ITR | PITR-RD
configuration of a LISP router. CPE routers, which are typically -----------------+--------------+-----------------+----------------
configured by DHCP, stand to benefit most from P-ETRs. To enable Early transition | no change | slower increase | slower increase
autoconfiguration of the P-ETR locator, a DHCP option would be Late transition | may decrease | slower increase | slower increase
required. LISP Internet | considerable decrease
As a security measure, access to P-ETRs should be limited to It is expected that PITR-RD will co-exist with LISP+BGP during the
legitimate users by enforcing ACLs. migration, with the latter being more popular in the early transition
phase. As the transition progresses and the MSP P-ITR and PITR-RD
ecosystem gets more ubiquitous, LISP+BGP should become less
attractive, slowing down the increase of the number of routes in the
DFZ.
5. Security Considerations 6. Security Considerations
Security implications of LISP deployments are to be discussed in Security implications of LISP deployments are to be discussed in
separate documents. [I-D.saucez-lisp-security] gives an overview of separate documents. [I-D.saucez-lisp-security] gives an overview of
LISP threat models, while securing mapping lookups is discussed in LISP threat models, while securing mapping lookups is discussed in
[I-D.maino-lisp-sec]. [I-D.ietf-lisp-sec].
6. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Acknowledgements 8. 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, and everyone else who Dino Farinacci, Terry Manderson, Noel Chiappa, and everyone else who
provided input. provided input.
8. References 9. References
8.1. Normative References 9.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-12 (work in progress), April 2011. draft-ietf-lisp-15 (work in progress), July 2011.
[I-D.ietf-lisp-alt] [I-D.ietf-lisp-alt]
Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-06 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-07
(work in progress), March 2011. (work in progress), June 2011.
[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-01 (work in progress), draft-ietf-lisp-interworking-02 (work in progress),
August 2010. June 2011.
[I-D.ietf-lisp-ms] [I-D.ietf-lisp-ms]
Fuller, V. and D. Farinacci, "LISP Map Server", Fuller, V. and D. Farinacci, "LISP Map Server",
draft-ietf-lisp-ms-08 (work in progress), April 2011. draft-ietf-lisp-ms-10 (work in progress), July 2011.
[I-D.maino-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-maino-lisp-sec-00 (work in progress), March 2011. draft-ietf-lisp-sec-00 (work in progress), July 2011.
[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.
8.2. Informative References 9.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-00 (work in
progress), July 2011.
[I-D.lear-lisp-nerd] [I-D.lear-lisp-nerd]
Lear, E., "NERD: A Not-so-novel EID to RLOC Database", Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-08 (work in progress), March 2010. draft-lear-lisp-nerd-08 (work in progress), March 2010.
[I-D.meyer-lisp-eid-block]
Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP
EID Block", draft-meyer-lisp-eid-block-02 (work in
progress), March 2011.
[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. 48 change blocks. 
173 lines changed or deleted 233 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/