draft-ietf-lisp-deployment-01.txt   draft-ietf-lisp-deployment-02.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: January 12, 2012 J. Domingo-Pascual Expires: May 4, 2012 J. Domingo-Pascual
Technical University of Catalonia Technical University of Catalonia
D. Lewis D. Lewis
Cisco Systems Cisco Systems
July 11, 2011 November 1, 2011
LISP Network Element Deployment Considerations LISP Network Element Deployment Considerations
draft-ietf-lisp-deployment-01.txt draft-ietf-lisp-deployment-02.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 January 12, 2012. This Internet-Draft will expire on May 4, 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 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . 17 5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17
5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19 5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
skipping to change at page 8, line 35 skipping to change at page 8, line 35
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 (R_A1, R_A2, or R_A3) and destination RLOC from ISP_A's address space and destination RLOC from ISP_B's address
from ISP_B's address space (R_B1 or R_B2). One or more ASes separate space. One or more ASes separate ISP_A from ISP_B. With a single
ISP_A from ISP_B. With a single level of LISP encapsulation, Stub4 level of LISP encapsulation, Stub4 has control over its ingress
has control over its ingress traffic. However, ISP_B only has the traffic. However, ISP_B only has the current tools (such as BGP
current tools (such as BGP prefix deaggregation) to control on which prefix deaggregation) to control on which of his own upstream or
of his own upstream or peering links should packets enter. This is peering links should packets enter. This is either not feasible (if
either not feasible (if fine-grained per-customer control is fine-grained per-customer control is required, the very specific
required, the very specific prefixes may not be propagated) or prefixes may not be propagated) or increases DFZ table size.
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
A solution for this is to apply LISP recursively. ISP_A and ISP_B A solution for this is to apply LISP recursively. ISP_A and ISP_B
may reach a bilateral agreement to deploy their own private mapping may reach a bilateral agreement to deploy their own private mapping
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. ISP_B's ETR removes the this case the packet is double-encapsulated (using R_A1, R_A2 or R_A3
outer, second layer of LISP encapsulation from the incoming packet, as source and R_B1 or R_B2 as destination in the example above).
and routes it towards the original RLOC, the ETR of Stub4, which does ISP_B's ETR removes the outer, second layer of LISP encapsulation
the final decapsulation. from the incoming packet, and routes it towards the original RLOC,
the ETR of Stub4, which does the final decapsulation.
If ISP_A and ISP_B agree to share a private distributed mapping 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 disaggregating 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 recommendations.
First, it is intended to be deployed only between two ISPs (ISP_A and First, it is intended to be deployed only between two ISPs (ISP_A and
skipping to change at page 10, line 11 skipping to change at page 10, line 5
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 extra lookup latency, unless NERD
[I-D.lear-lisp-nerd] is used for the lookups. [I-D.lear-lisp-nerd] is used for the lookups.
o The operational overhead of maintaining the shared mapping o The operational overhead of maintaining the shared mapping
database. database.
o If an IPv6 address block is reserved for EID use, as specified in
[I-D.ietf-lisp-eid-block], the EID-to-RLOC encapsulation (first
level) can avoid LISP processing altogether for non-LISP
destinations. The ISP tunnel routers however will not be able to
take advantage of this optimization, all RLOC-to-RLOC mappings
need a lookup in the private database (or map-cache, once results
are cached).
2.5. Tunnel Routers Behind NAT 2.5. Tunnel Routers Behind NAT
NAT in this section refers to IPv4 network address and port NAT in this section refers to IPv4 network address and port
translation. translation.
2.5.1. ITR 2.5.1. ITR
Packets encapsulated by an ITR are just UDP packets from a NAT Packets encapsulated by an ITR are just UDP packets from a NAT
device's point of view, and they are handled like any UDP packet, device's point of view, and they are handled like any UDP packet,
there are no additional requirements for LISP data packets. there are no additional requirements for LISP data packets.
skipping to change at page 17, line 12 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.
5.3. Proxy-ITR Route Distribution 5.3. Proxy-ITR Route Distribution (PITR-RD)
Instead of a LISP site, or the MSP, announcing their EIDs with BGP to Instead of a LISP site, or the MSP, announcing their EIDs with BGP to
the DFZ, this function can be outsourced to a third party, a P-ITR the DFZ, this function can be outsourced to a third party, a P-ITR
Service Provider (PSP). This will result in a decrease of the Service Provider (PSP). This will result in a decrease of the
operational complexity both at the site and at the MSP. operational complexity both at the site and at the MSP.
The PSP manages a set of distributed P-ITR(s) that will advertise the The PSP manages a set of distributed P-ITR(s) that will advertise the
corresponding EID prefixes through BGP to the DFZ. These P-ITR(s) corresponding EID prefixes through BGP to the DFZ. These P-ITR(s)
will then encapsulate the traffic they receive for those EIDs towards will then encapsulate the traffic they receive for those EIDs towards
the RLOCs of the LISP site, ensuring their reachability from non-LISP the RLOCs of the LISP site, ensuring their reachability from non-LISP
skipping to change at page 20, line 22 skipping to change at page 20, line 22
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. 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, Hannu Flinck, and
provided input. everyone else who provided input.
9. References 9. References
9.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-15 (work in progress), July 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-07 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-09
(work in progress), June 2011. (work in progress), September 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-02 (work in progress), draft-ietf-lisp-interworking-02 (work in progress),
June 2011. 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 Interface",
draft-ietf-lisp-ms-10 (work in progress), July 2011. draft-ietf-lisp-ms-12 (work in progress), October 2011.
[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-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.
9.2. Informative References 9.2. Informative References
[I-D.ietf-lisp-eid-block] [I-D.ietf-lisp-eid-block]
Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP
EID Block", draft-ietf-lisp-eid-block-00 (work in EID Block", draft-ietf-lisp-eid-block-01 (work in
progress), July 2011. progress), October 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.
[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
 End of changes. 13 change blocks. 
27 lines changed or deleted 35 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/