draft-ietf-lisp-alt-03.txt   draft-ietf-lisp-alt-04.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Intended status: Experimental D. Meyer Intended status: Experimental D. Meyer
Expires: September 30, 2010 D. Lewis Expires: October 28, 2010 D. Lewis
Cisco Cisco
March 29, 2010 April 26, 2010
LISP Alternative Topology (LISP+ALT) LISP Alternative Topology (LISP+ALT)
draft-ietf-lisp-alt-03.txt draft-ietf-lisp-alt-04.txt
Abstract Abstract
This document describes a simple mapping database to be used by the This document describes a simple mapping database to be used by the
Locator/ID Separation Protocol (LISP) to find Endpoint Identifier Locator/ID Separation Protocol (LISP) to find Endpoint Identifier
(EID) to Routing Locator (RLOC) mappings. Termed the Alternative (EID) to Routing Locator (RLOC) mappings. Termed the Alternative
Logical Topology (ALT), the database is built as an overlay network Logical Topology (ALT), the database is built as an overlay network
on the public Internet using the Border Gateway Protocol (BGP) and on the public Internet using the Border Gateway Protocol (BGP) and
the Generic Routing Encapsulation (GRE). Using these proven the Generic Routing Encapsulation (GRE). Using these proven
protocols, the ALT can be built and deployed relatively quickly protocols, the ALT can be built and deployed relatively quickly
without major changes to the existing routing infrastructure. without major changes to the existing routing infrastructure.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 28, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 8 3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 8 3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 8
3.1.1. Mechanisms for an ETR to originate EID-prefixes . . . 9 3.1.1. Mechanisms for an ETR to originate EID-prefixes . . . 9
3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 9 3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 9
3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 9 3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 9
3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 9 3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 9
3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 10 3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 10
4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 11 4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 11
4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 12 4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 4, line 11 skipping to change at page 3, line 11
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This document describes the LISP+ALT mapping database, to be used by This document describes the LISP+ALT mapping database, to be used by
LISP to find EID-to-RLOC mappings. The ALT network is built using LISP to find EID-to-RLOC mappings. The ALT network is built using
the Border Gateway Protocol (BGP, [RFC4271]), the BGP multi-protocol the Border Gateway Protocol (BGP, [RFC4271]), the BGP multi-protocol
extension [RFC4760], and the Generic Routing Encapsulation (GRE, extension [RFC4760], and the Generic Routing Encapsulation (GRE,
[RFC2784]) to construct an overlay nnetwork of devices (ALT Routers) [RFC2784]) to construct an overlay network of devices (ALT Routers)
which operate on EID-prefixes and use EIDs as forwarding which operate on EID-prefixes and use EIDs as forwarding
destinations. destinations.
ALT Routers advertise hierarchically-delegated segments of the EID ALT Routers advertise hierarchically-delegated segments of the EID
namespace (i.e., prefixes) toward the rest of the ALT; they also namespace (i.e., prefixes) toward the rest of the ALT; they also
forward traffic destined for an EID covered by one of those prefixes forward traffic destined for an EID covered by one of those prefixes
toward the network element which is authoritative for that EID (i.e. toward the network element that is authoritative for that EID and is
is the origin of the advertisement of the EID-to-RLOC mapping which the origin of the BGP advertisement for that EID-prefix. An Ingress
applies to that EID). Map Resolvers (MRs; see [LISP-MS]) and, in Tunnel Router (ITR) uses this overlay to send a LISP Map-Request (see
some cases, Ingress Tunnel Routers (ITRs) use this overlay to send [LISP]) to the Egress Tunnel Router (ETR) that holds the EID-to-RLOC
mapping requests (using [LISP]) to the Egress Tunnel Routers (ETRs) mapping for a matching EID-prefix. In most cases, an ITR does not
that hold the EID-to-RLOC mappings for a particular EID-prefix connect directly to the overlay network but instead sends Map-
Requests via a Map-Resolver (MR; see [LISP-MS]) which does.
Likewise, in most cases, an ETR does not connect directly to the
overlay network but instead registers its EID-prefixes with a Map-
Server that advertises those EID-prefixes on to the ALT and forwards
Map-Requests for them to the ETR.
It is important to note that the ALT does not distribute actual EID- It is important to note that the ALT does not distribute actual EID-
to-RLOC mappings. What it does provide is a forwarding path from an to-RLOC mappings. What it does provide is a forwarding path from an
ITR (or MR) which requires an EID-to-RLOC mapping to an ETR which ITR (or MR) which requires an EID-to-RLOC mapping to an ETR which
holds that mapping. The ITR/MR uses this path to send an ALT holds that mapping. The ITR/MR uses this path to send an ALT
Datagram (see Section 3) to an ETR which then responds with a Map- Datagram (see Section 3) to an ETR which then responds with a Map-
Reply containing the needed mapping information. Reply containing the needed mapping information.
One design goal for LISP+ALT is to use existing technology wherever One design goal for LISP+ALT is to use existing technology wherever
possible. To this end, the ALT is intended to be built using off- possible. To this end, the ALT is intended to be built using off-
skipping to change at page 15, line 12 skipping to change at page 15, line 12
be reachable by each other; any addressing plan, including private be reachable by each other; any addressing plan, including private
addressing, can therefore be used for ALT tunnels. addressing, can therefore be used for ALT tunnels.
5. EID-prefix Propagation and Map-Request Forwarding 5. EID-prefix Propagation and Map-Request Forwarding
As described in Section 8.2, an ITR sends an ALT Datagram to a given As described in Section 8.2, an ITR sends an ALT Datagram to a given
EID-to-RLOC mapping. The ALT provides the infrastructure that allows EID-to-RLOC mapping. The ALT provides the infrastructure that allows
these requests to reach the authoritative ETR. these requests to reach the authoritative ETR.
Note that under normal circumstances Map-Replies are not sent over Note that under normal circumstances Map-Replies are not sent over
the ALT - an ETR sends a Map-Reply to the source RLOC learned from the ALT; an ETR sends a Map-Reply to one of the ITR RLOCs learned
the original Map-Request. There may be scenarios, perhaps to from the original Map-Request. There may be scenarios, perhaps to
encourage caching of EID-to-RLOC mappings by ALT Routers, where Map- encourage caching of EID-to-RLOC mappings by ALT Routers, where Map-
Replies could be sent over the ALT or where a "first-hop" ALT router Replies could be sent over the ALT or where a "first-hop" ALT router
might modify the originating RLOC on a Map-Request received from an might modify the originating RLOC on a Map-Request received from an
ITR to force the Map-Reply to be returned to the "first-hop" ALT ITR to force the Map-Reply to be returned to the "first-hop" ALT
Router. These cases will not be supported by initial LISP+ALT Router. These cases will not be supported by initial LISP+ALT
implementations but may be subject to future experimentation. implementations but may be subject to future experimentation.
ALT Routers propagate path information via BGP ([RFC4271]) that is ALT Routers propagate path information via BGP ([RFC4271]) that is
used by ITRs to send ALT Datagrams toward the appropriate ETR for used by ITRs to send ALT Datagrams toward the appropriate ETR for
each EID-prefix. BGP is run on the inter-ALT Router links, and each EID-prefix. BGP is run on the inter-ALT Router links, and
skipping to change at page 15, line 52 skipping to change at page 15, line 52
router(s), it selects the appropriate ALT Router based on the BGP router(s), it selects the appropriate ALT Router based on the BGP
information received. If it is not running BGP, it uses a information received. If it is not running BGP, it uses a
statically-configued ALT Default Route to select an ALT Router. statically-configued ALT Default Route to select an ALT Router.
5.2. Changes to ETR behavior with LISP+ALT 5.2. Changes to ETR behavior with LISP+ALT
As previously described, an ETR will usually use the Map Server As previously described, an ETR will usually use the Map Server
interface (see [LISP-MS]) and will register its EID-prefixes with its interface (see [LISP-MS]) and will register its EID-prefixes with its
configured Map Servers. When an ETR instead connects using BGP to configured Map Servers. When an ETR instead connects using BGP to
one or more ALT Routers, it announces its EID-prefix(es) to those ALT one or more ALT Routers, it announces its EID-prefix(es) to those ALT
Routers. Note that when an ETR generates a Map-Reply message to Routers.
return to a querying ITR, it sends it to the ITR's source-RLOC (i.e.,
on the underlying Internet topology, not on the ALT; this avoids any As documented in [LISP], when an ETR generates a Map-Reply message to
latency penalty (or "stretch") that might be incurred by routing over return to a querying ITR, it sets the outer header IP destination
the ALT). address to one of the requesting ITR's RLOCs so that the Map-Reply
will be sent on the underlying Internet topology, not on the ALT;
this avoids any latency penalty (or "stretch") that might be incurred
by sending the Map-Reply via the ALT, reduces load on the ALT, and
ensures that the Map-Reply can be routed even if the original ITR
does not have an ALT-routed EID. For details on how an ETR selects
which ITR RLOC to use, see section 6.1.5 of [LISP].
6. BGP configuration and protocol considerations 6. BGP configuration and protocol considerations
6.1. Autonomous System Numbers (ASNs) in LISP+ALT 6.1. Autonomous System Numbers (ASNs) in LISP+ALT
The primary use of BGP today is to define the global Internet routing The primary use of BGP today is to define the global Internet routing
topology in terms of its participants, known as Autonomous Systems. topology in terms of its participants, known as Autonomous Systems.
LISP+ALT specifies the use of BGP to create a global overlay network LISP+ALT specifies the use of BGP to create a global overlay network
(the ALT) for finding EID-to-RLOC mappings. While related to the (the ALT) for finding EID-to-RLOC mappings. While related to the
global routing database, the ALT serves a very different purpose and global routing database, the ALT serves a very different purpose and
skipping to change at page 19, line 31 skipping to change at page 19, line 31
engineering. engineering.
7.3. Edge aggregation and dampening 7.3. Edge aggregation and dampening
Normal BGP best common practices apply to the ALT network. In Normal BGP best common practices apply to the ALT network. In
particular, first-hop ALT Routers will aggregate EID prefixes and particular, first-hop ALT Routers will aggregate EID prefixes and
dampen changes to them in the face of excessive updates. Since EID- dampen changes to them in the face of excessive updates. Since EID-
prefix assignments are not expected to change as frequently as global prefix assignments are not expected to change as frequently as global
routing BGP prefix reachability, such dampening should be very rare, routing BGP prefix reachability, such dampening should be very rare,
and might be worthy of logging as an exceptional event. It is again and might be worthy of logging as an exceptional event. It is again
worth noting that the ALT carries only EID-prefixes, used to worth noting that the ALT carries only EID-prefixes, used to a
construct BGP paths to their owning ETRs; it does not carry construct BGP path to each ETR (or Map-Server) that originates each
reachability about RLOCs. In addition, EID-prefix information may be prefix; the ALT does not carry reachability about RLOCs. In
aggregated as the topology and address assignment hierarchy allow. addition, EID-prefix information may be aggregated as the topology
Since the topology is all tunneled and can be modified as needed, and address assignment hierarchy allow. Since the topology is all
reasonably good aggregation should be possible. In addition, since tunneled and can be modified as needed, reasonably good aggregation
most ETRs are expected to connect to the ALT using the Map Server should be possible. In addition, since most ETRs are expected to
interface, Map Servers will implement a natural "edge" for the ALT connect to the ALT using the Map Server interface, Map Servers will
where dampening and aggregation can be applied. For these reasons, implement a natural "edge" for the ALT where dampening and
the set of prefix information on the ALT can be expected to be both aggregation can be applied. For these reasons, the set of prefix
better aggregated and considerably less volatile than the actual EID- information on the ALT can be expected to be both better aggregated
to-RLOC mappings. and considerably less volatile than the actual EID-to-RLOC mappings.
7.4. EID assignment flexibility vs. ALT scaling 7.4. EID assignment flexibility vs. ALT scaling
There are major open questions regarding how the ALT will be deployed There are major open questions regarding how the ALT will be deployed
and what organization(s) will operate it. In a simple, non- and what organization(s) will operate it. In a simple, non-
distributed world, centralized administration of EID prefix distributed world, centralized administration of EID prefix
assignment and ALT network design would facilitate a well- aggregated assignment and ALT network design would facilitate a well- aggregated
ALT routing system. Business and other realities will likely result ALT routing system. Business and other realities will likely result
in a more complex, distributed system involving multiple levels of in a more complex, distributed system involving multiple levels of
prefix delegation, multiple operators of parts of the ALT prefix delegation, multiple operators of parts of the ALT
skipping to change at page 25, line 35 skipping to change at page 25, line 35
for third party devices to either insert or modify messages. for third party devices to either insert or modify messages.
Message Sequence Numbers and Nonce Values in Messages: This allows Message Sequence Numbers and Nonce Values in Messages: This allows
an ITR to verify that the Map-Reply from an ETR is in response to an ITR to verify that the Map-Reply from an ETR is in response to
a Map-Request originated by that ITR (this is a general property a Map-Request originated by that ITR (this is a general property
of LISP; LISP+ALT does not change this behavior). of LISP; LISP+ALT does not change this behavior).
10.3. Use of new IETF standard BGP Security mechanisms 10.3. Use of new IETF standard BGP Security mechanisms
LISP+ALT's use of BGP allows the ALT to take advantage of BGP LISP+ALT's use of BGP allows the ALT to take advantage of BGP
security features designed for existing Internet BGP use. security features designed for existing Internet BGP use. Should the
Internet community converge on the work currently being done in the
For example, should either S-BGP [I-D.murphy-bgp-secr] or soBGP IETF SIDR working group or should either S-BGP [I-D.murphy-bgp-secr]
[I-D.white-sobgparchitecture] become widely deployed it expected that or soBGP [I-D.white-sobgparchitecture] be implemented and widely-
LISP+ALT could use these mechanisms to provide authentication of EID- deployed, LISP+ALT can readily use these mechanisms to provide
to-RLOC mappings, and EID origination. authentication of EID-prefix origination and EID-to-RLOC mappings.
11. Acknowledgments 11. Acknowledgments
The authors would like to specially thank J. Noel Chiappa who was a The authors would like to specially thank J. Noel Chiappa who was a
key contributer to the design of the LISP-CONS mapping database (many key contributer to the design of the LISP-CONS mapping database (many
ideas from which made their way into LISP+ALT) and who has continued ideas from which made their way into LISP+ALT) and who has continued
to provide invaluable insight as the LISP effort has evolved. Others to provide invaluable insight as the LISP effort has evolved. Others
who have provided valuable contributions include John Zwiebel, Hannu who have provided valuable contributions include John Zwiebel, Hannu
Flinck, Amit Jain, John Scudder, and Scott Brim. Flinck, Amit Jain, John Scudder, and Scott Brim.
12. References 12. References
12.1. Normative References 12.1. Normative References
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-06.txt (work in progress), January 2010. draft-ietf-lisp-07.txt (work in progress), April 2010.
[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server", [LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server",
draft-ietf-lisp-ms-04.txt (work in progress), draft-ietf-lisp-ms-05.txt (work in progress), April 2010.
October 2009.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
 End of changes. 16 change blocks. 
51 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/