--- 1/draft-ietf-lisp-alt-03.txt 2010-04-26 19:11:28.000000000 +0200 +++ 2/draft-ietf-lisp-alt-04.txt 2010-04-26 19:11:28.000000000 +0200 @@ -1,73 +1,67 @@ Network Working Group V. Fuller Internet-Draft D. Farinacci Intended status: Experimental D. Meyer -Expires: September 30, 2010 D. Lewis +Expires: October 28, 2010 D. Lewis Cisco - March 29, 2010 + April 26, 2010 LISP Alternative Topology (LISP+ALT) - draft-ietf-lisp-alt-03.txt + draft-ietf-lisp-alt-04.txt Abstract This document describes a simple mapping database to be used by the Locator/ID Separation Protocol (LISP) to find Endpoint Identifier (EID) to Routing Locator (RLOC) mappings. Termed the Alternative Logical Topology (ALT), the database is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). Using these proven protocols, the ALT can be built and deployed relatively quickly without major changes to the existing routing infrastructure. 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. Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at - 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. + This Internet-Draft will expire on October 28, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as - described in the BSD License. + described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 8 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.3. Map Server Model preferred . . . . . . . . . . . . . . 9 3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 9 3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 10 4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 11 4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 12 @@ -97,33 +91,38 @@ 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction 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 the Border Gateway Protocol (BGP, [RFC4271]), the BGP multi-protocol 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 destinations. ALT Routers advertise hierarchically-delegated segments of the EID namespace (i.e., prefixes) toward the rest of the ALT; they also forward traffic destined for an EID covered by one of those prefixes - toward the network element which is authoritative for that EID (i.e. - is the origin of the advertisement of the EID-to-RLOC mapping which - applies to that EID). Map Resolvers (MRs; see [LISP-MS]) and, in - some cases, Ingress Tunnel Routers (ITRs) use this overlay to send - mapping requests (using [LISP]) to the Egress Tunnel Routers (ETRs) - that hold the EID-to-RLOC mappings for a particular EID-prefix + toward the network element that is authoritative for that EID and is + the origin of the BGP advertisement for that EID-prefix. An Ingress + Tunnel Router (ITR) uses this overlay to send a LISP Map-Request (see + [LISP]) to the Egress Tunnel Router (ETR) that holds the EID-to-RLOC + mapping for a matching EID-prefix. In most cases, an ITR does not + 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- 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 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- Reply containing the needed mapping information. 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- @@ -556,22 +555,22 @@ be reachable by each other; any addressing plan, including private addressing, can therefore be used for ALT tunnels. 5. EID-prefix Propagation and Map-Request Forwarding 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 these requests to reach the authoritative ETR. 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 original Map-Request. There may be scenarios, perhaps to + the ALT; an ETR sends a Map-Reply to one of the ITR RLOCs learned + from the original Map-Request. There may be scenarios, perhaps to 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 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 Router. These cases will not be supported by initial LISP+ALT implementations but may be subject to future experimentation. ALT Routers propagate path information via BGP ([RFC4271]) that is 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 @@ -596,25 +595,31 @@ router(s), it selects the appropriate ALT Router based on the BGP information received. If it is not running BGP, it uses a statically-configued ALT Default Route to select an ALT Router. 5.2. Changes to ETR behavior with LISP+ALT As previously described, an ETR will usually use the Map Server interface (see [LISP-MS]) and will register its EID-prefixes with its 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 - Routers. Note that when an ETR generates a Map-Reply message to - 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 - latency penalty (or "stretch") that might be incurred by routing over - the ALT). + Routers. + + As documented in [LISP], when an ETR generates a Map-Reply message to + return to a querying ITR, it sets the outer header IP destination + 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.1. Autonomous System Numbers (ASNs) in LISP+ALT The primary use of BGP today is to define the global Internet routing topology in terms of its participants, known as Autonomous Systems. 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 global routing database, the ALT serves a very different purpose and @@ -716,32 +721,32 @@ engineering. 7.3. Edge aggregation and dampening Normal BGP best common practices apply to the ALT network. In particular, first-hop ALT Routers will aggregate EID prefixes and dampen changes to them in the face of excessive updates. Since EID- prefix assignments are not expected to change as frequently as global routing BGP prefix reachability, such dampening should be very rare, and might be worthy of logging as an exceptional event. It is again - worth noting that the ALT carries only EID-prefixes, used to - construct BGP paths to their owning ETRs; it does not carry - reachability about RLOCs. In addition, EID-prefix information may be - aggregated as the topology and address assignment hierarchy allow. - Since the topology is all tunneled and can be modified as needed, - reasonably good aggregation should be possible. In addition, since - most ETRs are expected to connect to the ALT using the Map Server - interface, Map Servers will implement a natural "edge" for the ALT - where dampening and aggregation can be applied. For these reasons, - the set of prefix information on the ALT can be expected to be both - better aggregated and considerably less volatile than the actual EID- - to-RLOC mappings. + worth noting that the ALT carries only EID-prefixes, used to a + construct BGP path to each ETR (or Map-Server) that originates each + prefix; the ALT does not carry reachability about RLOCs. In + addition, EID-prefix information may be aggregated as the topology + and address assignment hierarchy allow. Since the topology is all + tunneled and can be modified as needed, reasonably good aggregation + should be possible. In addition, since most ETRs are expected to + connect to the ALT using the Map Server interface, Map Servers will + implement a natural "edge" for the ALT where dampening and + aggregation can be applied. For these reasons, the set of prefix + information on the ALT can be expected to be both better aggregated + and considerably less volatile than the actual EID-to-RLOC mappings. 7.4. EID assignment flexibility vs. ALT scaling There are major open questions regarding how the ALT will be deployed and what organization(s) will operate it. In a simple, non- distributed world, centralized administration of EID prefix assignment and ALT network design would facilitate a well- aggregated ALT routing system. Business and other realities will likely result in a more complex, distributed system involving multiple levels of prefix delegation, multiple operators of parts of the ALT @@ -944,47 +949,46 @@ for third party devices to either insert or modify messages. 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 a Map-Request originated by that ITR (this is a general property of LISP; LISP+ALT does not change this behavior). 10.3. Use of new IETF standard BGP Security mechanisms LISP+ALT's use of BGP allows the ALT to take advantage of BGP - security features designed for existing Internet BGP use. - - For example, should either S-BGP [I-D.murphy-bgp-secr] or soBGP - [I-D.white-sobgparchitecture] become widely deployed it expected that - LISP+ALT could use these mechanisms to provide authentication of EID- - to-RLOC mappings, and EID origination. + security features designed for existing Internet BGP use. Should the + Internet community converge on the work currently being done in the + IETF SIDR working group or should either S-BGP [I-D.murphy-bgp-secr] + or soBGP [I-D.white-sobgparchitecture] be implemented and widely- + deployed, LISP+ALT can readily use these mechanisms to provide + authentication of EID-prefix origination and EID-to-RLOC mappings. 11. Acknowledgments 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 ideas from which made their way into LISP+ALT) and who has continued to provide invaluable insight as the LISP effort has evolved. Others who have provided valuable contributions include John Zwiebel, Hannu Flinck, Amit Jain, John Scudder, and Scott Brim. 12. References 12.1. Normative References [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "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", - draft-ietf-lisp-ms-04.txt (work in progress), - October 2009. + draft-ietf-lisp-ms-05.txt (work in progress), April 2010. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation