draft-ietf-lisp-deployment-11.txt   draft-ietf-lisp-deployment-12.txt 
Network Working Group L. Jakab Network Working Group L. Jakab
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Experimental A. Cabellos-Aparicio Intended status: Experimental A. Cabellos-Aparicio
Expires: June 12, 2014 F. Coras Expires: July 21, 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
December 9, 2013 January 17, 2014
LISP Network Element Deployment Considerations LISP Network Element Deployment Considerations
draft-ietf-lisp-deployment-11.txt draft-ietf-lisp-deployment-12.txt
Abstract Abstract
This document is a snapshot of different Locator/Identifier This document is a snapshot of different Locator/Identifier
Separation Protocol (LISP) deployment scenarios. It discusses the Separation Protocol (LISP) deployment scenarios. It discusses the
placement of new network elements introduced by the protocol, placement of new network elements introduced by the protocol,
representing the thinking of the LISP working group as of Summer representing the thinking of the LISP working group as of Summer
2013. LISP deployment scenarios may have evolved since. This memo 2013. LISP deployment scenarios may have evolved since. This memo
represents one stable point in that evolution of understanding. represents one stable point in that evolution of understanding.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 June 12, 2014. This Internet-Draft will expire on July 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 3, line 28 skipping to change at page 3, line 28
places it at the border routers of stub autonomous systems, which may places it at the border routers of stub autonomous systems, which may
carry a partial or complete default-free zone (DFZ) routing table. carry a partial or complete default-free zone (DFZ) routing table.
The initial design of LISP took this location as a baseline for The initial design of LISP took this location as a baseline for
protocol development. However, the applications of LISP go beyond protocol development. However, the applications of LISP go beyond
just decreasing the size of the DFZ routing table, and include just decreasing the size of the DFZ routing table, and include
improved multihoming and ingress traffic engineering (TE) support for improved multihoming and ingress traffic engineering (TE) support for
edge networks, and even individual hosts. Throughout the document we edge networks, and even individual hosts. Throughout the document we
will use the term LISP site to refer to these networks/hosts behind a will use the term LISP site to refer to these networks/hosts behind a
LISP Tunnel Router. We formally define the following two terms: LISP Tunnel Router. We formally define the following two terms:
Network element: Active or passive device that is connected to other Network element: Facility or equipment used in the provision of a
active or passive devices for transporting packet switched data. communications service over the Internet [TELCO96].
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. Additionally, this document is intended as a and other protocols. Additionally, this document is intended as a
guide for the operational community for LISP deployments in their guide for the operational community for LISP deployments in their
skipping to change at page 10, line 17 skipping to change at page 10, line 17
o In LISP, ITRs set the reachability bits when encapsulating data o In LISP, ITRs set the reachability bits when encapsulating data
packets. Hence, ITRs need a mechanism to be aware of the liveness packets. Hence, ITRs need a mechanism to be aware of the liveness
of all ETRs serving their site. of all ETRs serving their site.
o MTU within the site network must be large enough to accommodate o MTU within the site network must be large enough to accommodate
encapsulated packets. encapsulated packets.
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 may 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.
o By placing the ITRs inside the site, they will still need global o By placing the ITRs inside the site, they will still need global
RLOCs, and this may add complexity to intra-site routing RLOCs, and this may add complexity to intra-site routing
configuration, and further intra-site issues when there is a configuration, and further intra-site issues when there is a
change of providers. change of providers.
skipping to change at page 14, line 18 skipping to change at page 14, line 18
according to the specific mapping system that is employed (e.g., ALT according to the specific mapping system that is employed (e.g., ALT
[RFC6836], DDT [I-D.ietf-lisp-ddt]). Participation in the mapping [RFC6836], DDT [I-D.ietf-lisp-ddt]). Participation in the mapping
database, and the storing of EID-to-RLOC mapping data is subject to database, and the storing of EID-to-RLOC mapping data is subject to
the policies of the "root" operators, who should check ownership the policies of the "root" operators, who should check ownership
rights for the EID prefixes stored in the database by participants. rights for the EID prefixes stored in the database by participants.
These policies are out of the scope of this document. These policies are out of the scope of this document.
The LISP DDT protocol is used by LISP Mapping Service providers to The LISP DDT protocol is used by LISP Mapping Service providers to
provide reachability between those providers' Map-Resolvers and Map- provide reachability between those providers' Map-Resolvers and Map-
Servers. The DDT Root is currently operated by a collection of Servers. The DDT Root is currently operated by a collection of
organizations on an open basis. See [DDT-Root] for more details. organizations on an open basis. See [DDT-ROOT] for more details.
Similarly to the DNS root, it has several different server instances Similarly to the DNS root, it has several different server instances
using names of the letters of the Greek alphabet (alpha, delta, using names of the letters of the Greek alphabet (alpha, delta,
etc.), operated by independent organizations. When this document was etc.), operated by independent organizations. When this document was
published, there were 5 such instances, one of them being anycasted. published, there were 5 such instances, one of them being anycasted.
The Root provides the list of server instances on their web site and The Root provides the list of server instances on their web site and
configuration files for several map server implementations. The DDT configuration files for several map server implementations. The DDT
Root, and LISP Mapping Providers both rely on and abide by existing Root, and LISP Mapping Providers both rely on and abide by existing
allocation policies by Regional Internet Registries to determine allocation policies by Regional Internet Registries to determine
prefix ownership for use as EIDs. prefix ownership for use as EIDs.
skipping to change at page 22, line 48 skipping to change at page 22, line 48
Note that throughout Section 5 we focused on the effects of LISP Note that throughout Section 5 we focused on the effects of LISP
deployment on the DFZ route table size. Other metrics may be deployment on the DFZ route table size. Other metrics may be
impacted as well, but to the best of our knowlegde have not been impacted as well, but to the best of our knowlegde have not been
measured as of yet. measured as of yet.
6. Security Considerations 6. Security Considerations
All security implications of LISP deployments are to be discussed in All security implications of LISP deployments are to be discussed in
separate documents. [I-D.ietf-lisp-threats] gives an overview of separate documents. [I-D.ietf-lisp-threats] gives an overview of
LISP threat models, while securing mapping lookups is discussed in LISP threat models, including ETR operators attracting traffic by
[I-D.ietf-lisp-sec]. overclaiming an EID-prefix (Section 4.4.3). Securing mapping lookups
is discussed in [I-D.ietf-lisp-sec].
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,
skipping to change at page 23, line 36 skipping to change at page 23, line 36
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013. (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, Protocol (LISP) Map-Server Interface", RFC 6833,
January 2013. January 2013.
9.2. Informative References 9.2. Informative References
[DDT-Root] [CACHE] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
performance and the effectiveness of caching", 2002.
[DDT-ROOT]
"DDT Root", <http://ddt-root.org/>. "DDT Root", <http://ddt-root.org/>.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
progress), March 2013. progress), March 2013.
[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)",
skipping to change at page 24, line 29 skipping to change at page 24, line 32
January 2013. January 2013.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013. Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, Selkirk, "Port Control Protocol (PCP)", RFC 6887,
April 2013. April 2013.
[cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS [TELCO96] "Telecommunications Act of 1996", 1996.
performance and the effectiveness of caching", 2002.
Appendix A. Step-by-Step Example BGP to LISP Migration Procedure Appendix A. Step-by-Step Example BGP to LISP Migration Procedure
To help the operational community deploy LISP, this informative To help the operational community deploy LISP, this informative
section offers a step-by-step guide for migrating a BGP based section offers a step-by-step guide for migrating a BGP based
Internet presence to a LISP site. It includes a pre-install/ Internet presence to a LISP site. It includes a pre-install/
pre-turn-up checklist, and customer and provider activation pre-turn-up checklist, and customer and provider activation
procedures. procedures.
A.1. Customer Pre-Install and Pre-Turn-up Checklist A.1. Customer Pre-Install and Pre-Turn-up Checklist
 End of changes. 11 change blocks. 
14 lines changed or deleted 17 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/