draft-ietf-lisp-deployment-09.txt   draft-ietf-lisp-deployment-10.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: Experimental A. Cabellos-Aparicio
Expires: January 10, 2014 F. Coras Expires: February 7, 2014 F. Coras
J. Domingo-Pascual J. Domingo-Pascual
Technical University of Technical University of
Catalonia Catalonia
D. Lewis D. Lewis
Cisco Systems Cisco Systems
July 9, 2013 August 6, 2013
LISP Network Element Deployment Considerations LISP Network Element Deployment Considerations
draft-ietf-lisp-deployment-09.txt draft-ietf-lisp-deployment-10.txt
Abstract Abstract
This document discusses the different scenarios for the deployment of This document is a snapshot of different Locator/Identifier
the new network elements introduced by the Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the
Separation Protocol (LISP). placement of new network elements introduced by the protocol,
representing the thinking of the authors as of Summer 2013. LISP
deployment scenarios may have evolved since. This memo represents
one stable point in that evolution of understanding.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 10, 2014. This Internet-Draft will expire on February 7, 2014.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Customer Edge . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Customer Edge . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Provider Edge . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Provider Edge . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . . . 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.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 . . . . . . . . . . . . . . . . 12 3. Map Resolvers and Map Servers . . . . . . . . . . . . . . . . 12
3.1. Map Servers . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Map Servers . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Map Resolvers . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Map Resolvers . . . . . . . . . . . . . . . . . . . . . . 13
4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 14 4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 14
4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 16 5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 16
5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 17 5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 17
5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17 5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17
5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 20 5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Step-by-Step Example BGP to LISP Migration Appendix A. Step-by-Step Example BGP to LISP Migration
Procedure . . . . . . . . . . . . . . . . . . . . . . 22 Procedure . . . . . . . . . . . . . . . . . . . . . . 22
A.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 22 A.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 22
A.2. Customer Activating LISP Service . . . . . . . . . . . . . 23 A.2. Customer Activating LISP Service . . . . . . . . . . . . . 24
A.3. Cut-Over Provider Preparation and Changes . . . . . . . . 24 A.3. Cut-Over Provider Preparation and Changes . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Locator/Identifier Separation Protocol (LISP) is designed to The Locator/Identifier Separation Protocol (LISP) is designed to
address the scaling issues of the global Internet routing system address the scaling issues of the global Internet routing system
identified in [RFC4984] by separating the current addressing scheme identified in [RFC4984] by separating the current addressing scheme
into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs). The into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs). The
main protocol specification [RFC6830] describes how the separation is main protocol specification [RFC6830] describes how the separation is
achieved, which new network elements are introduced, and details the achieved, which new network elements are introduced, and details the
skipping to change at page 3, line 49 skipping to change at page 3, line 49
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).
This experimental specification has areas that require additional
experience and measurement. It is NOT RECOMMENDED for deployment
beyond experimental situations. Results of experimentation may lead
to modifications and enhancements of protocol mechanisms defined in
this document. See Section 15 [of RFC 6830] for specific, known
issues that are in need of further work during development,
implementation, and experimentation.
2. Tunnel Routers 2. Tunnel Routers
The device that is the gateway between the edge and the core is The device that is the gateway between the edge and the core is
called a Tunnel Router (xTR), performing one or both of two separate called a Tunnel Router (xTR), 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
skipping to change at page 6, line 33 skipping to change at page 6, line 35
The problem is aggravated when the LISP site is multihomed. Consider The problem is aggravated when the LISP site is multihomed. Consider
the scenario in Figure 2: whenever a change to TE policies is the scenario in Figure 2: whenever a change to TE policies is
required, the customer contacts both ISP1 and ISP2 to make the required, the customer contacts both ISP1 and ISP2 to make the
necessary changes on the routers (if they provide this possibility). necessary changes on the routers (if they provide this possibility).
It is however unlikely, that both ISPs will apply changes It is however unlikely, that both ISPs will apply changes
simultaneously, which may lead to inconsistent state for the mappings simultaneously, which may lead to inconsistent state for the mappings
of the LISP site. Since the different upstream ISPs are usually of the LISP site. Since the different upstream ISPs are usually
competing business entities, the ETRs may even be configured to competing business entities, the ETRs may even be configured to
compete, either to attract all the traffic or to get no traffic. The compete, 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 configure the
mappings in the Map Server(s), and have their operator give control Map Server(s) to do proxy-replying and have the Mapping Service
over the entries to customer, much like in the Domain Name System at Provider (MSP) apply policies.
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 (LSB) correctly on encapsulated packets. Because of this, and Bits (LSB) correctly on encapsulated packets. Because of this, and
due to the security concerns about LSB described in due to the security concerns about LSB described in
[I-D.ietf-lisp-threats] their use is discouraged without verifying [I-D.ietf-lisp-threats] their use is discouraged (set the L-bit to
ETR reachability through the mapping system or other means. Mapping 0). Mapping versioning is another alternative [RFC6834].
versioning is another alternative [RFC6834].
Compared to the customer edge scenario, deploying LISP at the Compared to the customer edge scenario, deploying LISP at the
provider edge might have the advantage of diminishing potential MTU provider edge might have the advantage of diminishing potential MTU
issues, because the tunnel router is closer to the core, where links issues, because the tunnel router is closer to the core, where links
typically have higher MTUs than edge network links. typically have higher MTUs than edge network links.
2.3. Split ITR/ETR 2.3. Split ITR/ETR
In a simple LISP deployment, xTRs are located at the border of the In a simple LISP deployment, xTRs are located at the border of the
LISP site (see Section 2.1). In this scenario packets are routed LISP site (see Section 2.1). In this scenario packets are routed
skipping to change at page 7, line 50 skipping to change at page 7, line 50
| +-------+ | +-------+ +-------+ | +-------+ | +-------+ +-------+
| | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B |
| +-------+ +-------+ +-------+ | +-------+ +-------+ +-------+
| | | |
+---------------------------------------+ +---------------------------------------+
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 more specific routes in order to choose the
the best egress point, increasing the complexity of the network. best egress point, and typically BGP is used for this, increasing
However, this is usually already the case for LISP sites that the complexity of the network. However, this is usually already
would benefit from this scenario. the case for LISP sites that would benefit from this scenario.
o If the site is multihomed to different ISPs and any of the o If the site is multihomed to different ISPs and any of the
upstream ISPs are doing uRPF filtering, this scenario may become upstream ISPs are doing 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.
skipping to change at page 9, line 4 skipping to change at page 9, line 4
increases DFZ table size. increases DFZ table size.
Typically, LISP is seen applicable only to stub networks, however the Typically, LISP is seen applicable only to stub networks, however the
LISP protocol can be also applied in a recursive manner, providing LISP protocol can be also applied in a recursive manner, providing
service provider ingress/egress TE capabilities without impacting the service provider ingress/egress TE capabilities without impacting the
DFZ table size. DFZ table size.
In order to implement this functionality with LISP consider the In order to implement this functionality with LISP consider the
scenario depicted in Figure 4. The two ISPs willing to achieve 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 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 Stub1 and Stub2 respectively, both are required to be LISP sites with
this scenario we assume that Stub1 and Stub2 are communicating and their own xTRs. In this scenario we assume that Stub1 and Stub2 are
thus, ISP_A and ISP_B offer transit for such communications. ISP_A communicating with each other and thus, ISP_A and ISP_B offer transit
has RLOC_A1 and RLOC_A2 as upstream IP addresses while ISP_B has for such communications. ISP_A has RLOC_A1 and RLOC_A2 as upstream
RLOC_B1 and RLOC_B2. The shared goal among ISP_A and ISP_B is to IP addresses while ISP_B has RLOC_B1 and RLOC_B2. The shared goal
control the transit traffic flow between RLOC_A1/A2 and RLOC_B1/B2. among ISP_A and ISP_B is to control the transit traffic flow between
RLOC_A1/A2 and RLOC_B1/B2.
_.--. _.--.
Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub2 Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub2
\ | R_A1|----,' `. ---|R_B1 | / \ | R_A1|----,' `. ---|R_B1 | /
--| | ( Transit ) | |-- --| | ( Transit ) | |--
... .../ | R_A2|-----. ,' ---|R_B2 | \... ... ... .../ | R_A2|-----. ,' ---|R_B2 | \... ...
+-------+ `--. _.-' +-------+ +-------+ `--. _.-' +-------+
... ... ISP_A `--'' ISP_B ... ... ... ... ISP_A `--'' ISP_B ... ...
Figure 4: Inter-Service provider TE scenario Figure 4: Inter-Service provider TE scenario
skipping to change at page 9, line 31 skipping to change at page 9, line 32
Both ISPs deploy xTRs on on RLOC_A1/A2 and RLOC_B1/B2 respectively Both ISPs deploy xTRs on on RLOC_A1/A2 and RLOC_B1/B2 respectively
and reach a bilateral agreement to deploy their own private mapping and reach a bilateral agreement to deploy their own private mapping
system. This mapping system contains bindings between the RLOCs of system. This mapping system contains bindings between the RLOCs of
Stub1 and Stub2 (owned by ISP_A and ISP_B respectively) and Stub1 and Stub2 (owned by ISP_A and ISP_B respectively) and
RLOC_A1/A2 and RLOC_B1/B2. Such bindings are in fact the TE policies RLOC_A1/A2 and RLOC_B1/B2. Such bindings are in fact the TE policies
between both ISPs and the convergence time is expected to be fast, between both ISPs and the convergence time is expected to be fast,
since ISPs only have to update/query a mapping to/from the database. since ISPs only have to update/query a mapping to/from the database.
The packet flow is as follows. First, a packet originated at Stub1 The packet flow is as follows. First, a packet originated at Stub1
towards Stub2 is LISP encapsulated by Stub1's xTR. The xTR of ISP_A towards Stub2 is LISP encapsulated by Stub1's xTR. The xTR of ISP_A
reencapsulates it and, according to the TE policies stored in the recursively encapsulates it and, according to the TE policies stored
private mapping system, the ISP_A xTR chooses RLOC_B1 or RLOC_B2 as in the private mapping system, the ISP_A xTR chooses RLOC_B1 or
the reencapsulation destination. Note that the packet transits RLOC_B2 as the outer encapsulation destination. Note that the packet
between ISP_A and ISP_B double-encapsulated. Upon reception at the transits between ISP_A and ISP_B double-encapsulated. Upon reception
xTR of ISP_B the packet is decapsulated and sent towards Stub2 which at the xTR of ISP_B the packet is decapsulated and sent towards Stub2
performs the last decapsulation. which performs the last decapsulation.
This deployment scenario, which uses recursive LISP, includes two This deployment scenario, which uses recursive LISP, includes two
important caveats. First, it is intended to be deployed between only important caveats. First, it is intended to be deployed between only
two ISPs. If more than two ISPs use this approach, then the xTRs two ISPs. If more than two ISPs use this approach, then 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 Furthemore, keeping this deployment scenario restricted to only two
ISPs maintains the solution scalable, given that only two entities ISPs maintains the solution scalable, given that only two entities
need to agree on using recursive LISP, and only one private mapping need to agree on using recursive LISP, and only one private mapping
system is involved. 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 recursively encapsulated belong to said ISP. Otherwise the
must register prefixes they do not own in the above mentioned private participating ISPs must register prefixes they do not own in the
mapping system. Failure to follow these recommendations may lead to above mentioned private mapping system. Failure to follow these
operational and security issues when deploying this scenario. recommendations may lead to 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:
o Extra LISP header is needed. This increases the packet size and o Extra LISP header is needed. This increases the packet size and
requires that the MTU between both ISPs accommodates double- requires that the MTU between both ISPs accommodates 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
skipping to change at page 13, line 16 skipping to change at page 13, line 24
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. Map-Register messages to all Map Servers in the redundancy group.
The configuration for fail-over (or load-balancing, if desired) among The configuration for fail-over (or load-balancing, if desired) among
the members of the group depends on the technology behind the mapping the members of the group depends on the technology behind the mapping
system being deployed. Since ALT is based on BGP and DDT was system being deployed. Since ALT is based on BGP and DDT was
inspired from DNS, deployments can leverage current industry best inspired from the Domain Name System (DNS), deployments can leverage
practices for redundancy in BGP and DNS. These best practices are current industry best practices for redundancy in BGP and DNS. These
out of the scope of this document. 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 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 consulting the distributed mapping
or by consulting the distributed mapping database. Map Resolver database. Map Resolver functionality is described in detail in
functionality is described in detail in [RFC6833]. [RFC6833].
Anyone with access to the distributed mapping database can set up a Anyone with access to the distributed mapping database can set up a
Map Resolver and provide EID-to-RLOC mapping lookup service. Map Resolver and provide EID-to-RLOC mapping lookup service.
Database access setup is mapping system specific. Database access setup is mapping system specific.
For performance reasons, it is recommended that LISP sites use Map For performance reasons, it is recommended that LISP sites use 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.
skipping to change at page 20, line 7 skipping to change at page 20, line 15
decrease for existing ones. Moreover, MSPs serving different clients decrease for existing ones. Moreover, MSPs serving different clients
with adjacent aggregatable prefixes may lead to additional decrease, with adjacent aggregatable prefixes may lead to additional decrease,
but quantifying this decrease is subject to future research study. but quantifying this decrease is subject to future research study.
The flexibility and scalability of this architecture does not come The flexibility and scalability of this architecture does not come
without a cost however: A PSP operator has to establish either without a cost however: A PSP operator has to establish either
transit or peering relationships to improve their connectivity. transit or peering relationships to improve their connectivity.
5.4. Migration Summary 5.4. Migration Summary
Registering a domain name typically entails an annual fee that should
cover the operating expenses for publishing the domain in the global
DNS. The situation is similar with several other registration
services. A LISP mapping service provider (MSR) client publishing an
EID prefix in the LISP mapping system has the option of signing up
for PITR services as well, for an extra fee. These services may be
offered by the MSP itself, but it is expected that specialized P-ITR
service providers (PSPs) will do it. Clients not signing up become
responsible for getting non-LISP traffic to their EIDs (using the
LISP+BGP scenario).
Additionally, Tier 1 ISPs have incentives to offer P-ITR services to
non-subscribers in strategic places just to attract more traffic from
competitors, thus more revenue.
The following table presents the expected effects of the different The following table presents the expected effects of the different
transition scenarios during a certain phase on the DFZ routing table transition scenarios during a certain phase on the DFZ routing table
size: size:
Phase | LISP+BGP | MSP P-ITR | PITR-RD Phase | LISP+BGP | MSP P-ITR | PITR-RD
-----------------+--------------+-----------------+---------------- -----------------+--------------+-----------------+----------------
Early transition | no change | slower increase | slower increase Early transition | no change | slower increase | slower increase
Late transition | may decrease | slower increase | slower increase Late transition | may decrease | slower increase | slower increase
LISP Internet | considerable decrease LISP Internet | considerable decrease
 End of changes. 18 change blocks. 
47 lines changed or deleted 73 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/