Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: May 14, 2008 Cisco November 11, 2007 LISP Alternative Topology (LISP-ALT) draft-fuller-lisp-alt-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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. 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 May 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Farinacci, et al. Expires May 14, 2008 [Page 1] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 Abstract This document describes a method of building an alternative, logical topology for managing Endpoint Identifier to Routing Locator mappings using the Locator/ID Separation Protocol. The logical network is built as an overlay on the public Internet using existing technologies and tools, specifically the Border Gateway Protocol and the Generic Routing Encapsulation. An important design goal for LISP-ALT is to allow for the relatively easy deployment of an efficient mapping system while minimizing changes to existing hardware and software. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 4. The LISP 1.5 model . . . . . . . . . . . . . . . . . . . . . . 7 5. LISP-ALT: Basic Overview . . . . . . . . . . . . . . . . . . . 8 5.1. EID assignment - hierarchy and topology . . . . . . . . . 8 5.2. The EID Prefix Aggregator (EPA) . . . . . . . . . . . . . 8 5.3. Use of GRE tunnels between EPAs . . . . . . . . . . . . . 8 6. How the LAVN uses BGP . . . . . . . . . . . . . . . . . . . . 10 6.1. Subsequent Address Family Identifier (SAFI) . . . . . . . 10 6.2. Alternative Autonomous System numbering space . . . . . . 10 7. EID prefix aggregation . . . . . . . . . . . . . . . . . . . . 11 8. Connecting sites to the LAVN . . . . . . . . . . . . . . . . . 12 8.1. ETRs originating information into the LISP-ALT network . . 12 8.2. ITRs receiving information from the LAVN . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Farinacci, et al. Expires May 14, 2008 [Page 2] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Farinacci, et al. Expires May 14, 2008 [Page 3] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 2. Introduction This document describes a method of building an alternative logical topology for managing Endpoint Identifier to Routing Locator mappings using the Locator/ID Separation Protocol [LISP]. This logical topology uses existing technology and tools, specifically the Border Gateway Protocol [RFC4271] and its multi-protocol extension [RFC2858], along with the Generic Routing Encapsulation [RFC2784] protocol to construct an overlay network of Endpoint Identifier Prefix Aggregators. Endpoint Identifier Prefix Aggregators hold hierarchically-assigned pieces of the Endpoint Identifier space (i.e., prefixes) and their next hops toward the network element which is responsible for Endpoint Identifier-to-Routing Locator mapping for that prefix. Tunnel routers can use this overlay to make queries against and respond to mapping requests made against the distributed Endpoint Identifier-to-Routing Locator mapping database. Note that an important design goal of LISP-ALT is to minimize the number of changes to existing hardware and/or software changes that are required to deploy the mapping system. It is envisioned that in most cases existing technology can be used to implement and deploy LISP-ALT. The remainder of this document is organized as follows: Section 3 provides the definitions of terms used in this document. Section 4 outlines the basic LISP 1.5 model. Section 5 provides a basic overview of the LISP-ALT architecture, and Section 6 describes how LISP-ALT uses BGP to propagate Endpoint Identifier reachability over the overlay network. Section 7 describes the construction of the LISP-ALT aggregation hierarchy, and Section 8 discusses how the elements of the LISP-ALT topology are connected to form the overlay network. Farinacci, et al. Expires May 14, 2008 [Page 4] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 3. Definition of Terms LISP-ALT operates on two name spaces and introduces a new network element, the EID Prefix Aggregators (see below). This section provides high-level definitions of the LISP-ALT name spaces, network elements, and message types. Endpoint ID (EID): A 32- or 128-bit value used in the source and destination fields of the first (most inner) LISP header of a packet. A packet that is emitted by a system contains EIDs in its headers and and LISP headers are prepended only when the packet hits an Ingress Tunnel Router (ITR) on the data path to the destination EID. In LISP-ALT, EID-prefixes MUST BE assigned in a hierarchical manner (in power-of-two or larger chunks) such that they can be aggregated by EID Prefix Aggregators (or EPAs; see below). In addition, a site may have site-local structure in how EIDs are topologically organized (subnetting) for routing within the site; this structure is not visible to the global routing system. EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable in the [RFC4632] sense. That is, an EID-Prefix aggregate is defined to be a single contiguous power-of-two EID-prefix block. Such a block is characterized by a prefix and a length. Routing Locator (RLOC): An IP address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as Provider Aggregatable (PA) addresses. EID-to-RLOC Mapping: A binding between an EID and the RLOC-set that can be used to reach the EID. We use the term "mapping" in this document to refer to a EID-to-RLOC mapping. EID Prefix Reachability: Reachability to the ETR (or its proxy) that is responsible for a given EID-to-RLOC mapping. The LISP Alternative Virtual Network (LAVN): The virtual overlay network made up of Generic Routing Encapsulation (GRE) tunnels between EID Prefix Aggregators. The Border Gateway Protocol (BGP) runs between these devices and is used to carry reachability information for EID prefixes. Farinacci, et al. Expires May 14, 2008 [Page 5] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 Legacy Internet: The portion of the Internet which does not run LISP and does not participate in the LAVN. EID Prefix Aggregator (EPA): The devices which are used to build the LAVN. EPAs are deployed in a hierarchy which matches the EID prefix allocation hierarchy. EPAs at each level in the this hierarchy are responsible for aggregating all EID prefixes learned from EPAs logically "below" them and advertising summary prefixes to the EPAs logically "above" them. All prefix learning and propagation between levels is done using BGP. EPAs at the lowest level, or "edge", of the LAVN learn EID prefixes either over a BGP or TCP session to ETRs. See Section 6 for details on how BGP is configured between the different network elements. It is important to note that the primary function of of the EPAs is provide a forwarding infrastructure for LISP control-plane messages (Map-Request and Map-Reply), and to transport data packets when the packet has the same destination address in both the inner (encapsulated) destination and outer destination addresses (i.e., a data probe packet). Farinacci, et al. Expires May 14, 2008 [Page 6] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 4. The LISP 1.5 model As documented in [LISP], the LISP 1.5 model uses the same basic query/response protocol machinery as LISP 1.0. In particular, LISP- ALT provides two mechanisms for an ITR to obtain EID-to-RLOC mappings (both of these techniques are described in more detail in Section 8.2): Data Probe: An ITR may send the first few data packets into the LISP-ALT topology (hereafter "ALT topology") to minimize packet loss and to probe for the mapping; the authoritative ETR will respond to the ITR with a Map-Reply message when it receives the data packet over the ALT topology. Map-Request: An ITR may also send a Map-Request message into the ALT topology to request the mapping. As in the data probe case, the authoritative ETR will respond to the ITR with a Map-Reply message. See [LISP] for the format of Map-Request and Map-Reply packets. Like LISP 1.0, EIDs are routable and can be used, unaltered, as the source and destination addresses in IP datagrams. Unlike in LISP 1.0, LISP 1.5 EIDs are not routed on the public Internet; instead, they are only routable over a separate, virtual topology referred to as the LISP Alternative Virtual Network. This network is built as an overlay on the public Internet using GRE tunnels to interconnect EID Prefix Aggregators (EPAs). BGP is run over these tunnels to propagate EID prefix reachability information. Importantly, while the ETRs are the source(s) of the unaggregated EID prefix data, LISP- ALT uses existing BGP mechanisms to aggressively aggregate this information. Finally, note that ETRs are not required to participate (or prevented from participating) in the LAVN; they may choose communicate their mappings to their serving EPA(s) at subscription time via configuration. Farinacci, et al. Expires May 14, 2008 [Page 7] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 5. LISP-ALT: Basic Overview LISP-ALT is a hybrid push/pull architecture. Aggregated EID prefixes are "pushed" among the EPAs and, optionally, out to ITRs (which may elect to receive the aggregated information, as opposed to simply using a "default" EID prefix). Specific EID-to-RLOC mappings are "pulled" by ITRs when they either send explicit LISP requests or data packets on the alternate topology that result in triggered replies being generated by ETRs. The basic idea underlying LISP-ALT is to use BGP, running over a GRE overlay, to build the LAVN reachability required to route data probes, Map-Requests, and Map-Replies. The LAVN RIB is comprised of EID prefixes (and associated next hops). The EPAs talk eBGP to each other in order to propagate EID reachability information, which is learned either over eBGP connections from the responsible ETR, or by configuration. ITRs may also eBGP peer with one or more EPAs in order to route data probe packets or Map-Requests (more likely, an ITR will have a default route pointing at one or more EPAs). In summary, the LAVN uses BGP to propagate reachability information used by ITRs and ETRs to forward Map-Requests, Map-Replies, and data probes. This reachability is carried as IPv4 or IPv6 NLRI without modification (since the EID space has the same syntax as IPv4 or IPv6). EPAs eBGP peer with one another, forming the LAVN. An EPA near the edge learns EID prefixes which are originated by authoritative ETRs, which either eBGP peer with them or by configuration. EPAs aggregate EID prefixes, and forward data probes, Map-Requests, and Map-Replies. 5.1. EID assignment - hierarchy and topology TBD, but connections between EPAs in the LAVN, and between EPAs and ETRs, should follow the EID allocation hierarchy so that the opportunity to aggregate the EID space is optimized. 5.2. The EID Prefix Aggregator (EPA) TBD, but its just a BGP speaker in the LAVN overlay. It uses standard BGP machinery to implement its policy, if any. 5.3. Use of GRE tunnels between EPAs The use of GRE [RFC2784] tunnels between EPAs offers many advantages, including: Farinacci, et al. Expires May 14, 2008 [Page 8] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 IGP: Running over GRE leaves open the possibility that the LAVN could run an IGP on the inter-EPA links. Assurance of Authenticity: A bogus Map-Reply can't be injected, since an EPA knows it's not valid unless it comes over a GRE interface. other? Farinacci, et al. Expires May 14, 2008 [Page 9] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 6. How the LAVN uses BGP As described in Section 8.2, an ITR may send either a Map-Request or a data probe to find a given EID-to-RLOC mapping. The LAVN provides the infrastructure that allows these requests to reach the responsible ETR, and possibly for the reply to find its way back to the requesting ITR (the ETR might choose to UDP encapsulate the Map- Reply and send it directly to the requesting ITR, bypassing the LAVN). The LAVN propagates reachability information for use by ITRs (when making Map-Requests or sending data probes), and ETRs (if the ETR is configured to send Map-Replies back to the requesting ITR over the LAVN) using eBGP [RFC4271]. eBGP is run on the inter-EPA links, and and possibly between an edge EPA and an ETR or between an edge EPA and an ITR. The LAVN eBGP RIB consists of aggregated EID prefixes and their next hops towards the responsible ETR for that EID prefix. An ITR or ETR may choose not to run an eBGP instance with the LAVN. Rather, the ITR or ETR may have a default route (for the LAVN) pointing at its EPA. In this case, data probe and Map-Requests messages are sent to the default EPA, and are routed over the LAVN to the responsible ETR. The ETR may send the Map-Reply message back over the LAVN, or it may choose to send the message UDP encapsulated directly back to the requesting ITR, bypassing the LAVN. Finally, note that LISP-ALT requires no modification to the BGP protocol, and is designed to be deployable without additional protocol machinery. 6.1. Subsequent Address Family Identifier (SAFI) TBD [RFC2858] 6.2. Alternative Autonomous System numbering space TBD Farinacci, et al. Expires May 14, 2008 [Page 10] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 7. EID prefix aggregation TBD Farinacci, et al. Expires May 14, 2008 [Page 11] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 8. Connecting sites to the LAVN 8.1. ETRs originating information into the LISP-ALT network ETRs have two ways of originating EID information into the LAVN: eBGP: ETRs may originate information by participating in the LAVN via eBGP. In this case, The ETR advertises reachability for its EID prefixes over this eBGP connection to the EPAs. The EPAs propagate and aggregate this information into the LAVN. That is, here the ETR is simply a peer of an EPA at the edge of the LAVN. An EPA should aggregate the received EID-prefixes (where possible). Configuration: An EPA may be configured with the EID-prefix of the responsible ETR, which is connected to the EPA via TCP connection (port TBD). This TCP connection is used to route Map-Requests to the ETR (if necessary), and for the ETR to respond with Map- Replies. Of course, the EPA could also serve as a proxy for its TCP-connected ETRs. Finally, depending on configuration and which prefixes an ETR is responsible for, an ETR may need to connect to more than one EPA to have all of its prefixes routed via the LAVN. 8.2. ITRs receiving information from the LAVN In order to source Map-Requests to the LAVN and receive Map-Replies from the LAVN, or to route a data probe packet over the LAVN, each ITR participating in the LAVN establishes a connection to one or more EPAs. These connections can be either eBGP or TCP (as described above). In the case in which the ITR is running eBGP, the peer EPAs use these connections to advertise highly aggregated EID-prefixes to the peer ITRs. The ITR then installs the received prefixes into a forwarding table that is used to to send LISP Map-Requests to the appropriate EPA. In most cases, an EPA will send a "default" EID prefix to its client ITRs so that they can send request for any EID prefix into the LAVN. In the case in which the ITR is connected to some set of EPAs without eBGP (i.e., over a TCP connection), the ITR sends Map-Requests to any of its connected EPAs, and receives Map-Replies from the EPA that has the "shortest path" to the authoritative ETR. An ITR may also chose to send the first few data packets over the LAVN, in order to minimize packet loss and reduce mapping latency. In this case, the data packet serves as a mapping probe, and the ETR which receives the data packet (over the LAVN) responds with a Map- Farinacci, et al. Expires May 14, 2008 [Page 12] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 Reply that is either routed back over the LAVN, or UDP encapsulated and sent directly back to the source ITR. In general, an ITR will establish connections only to EPAs at the "edge" of the LAVN topology (typically two for redundancy) but there may also be situations where an ITR would connect to other EPAs to receive more detailed information about a portion of the LAVN topology of interest to it. This can be accomplished by establishing a GRE tunnel between the ITR and the set of EPAs the ITR is interested in. This is a purely local policy issue between the ITR and the EPAs in question. Farinacci, et al. Expires May 14, 2008 [Page 13] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 9. IANA Considerations The IANA SHOULD assign port TBD for ITR and ETR to EPA TCP connections as described in Section 8. Farinacci, et al. Expires May 14, 2008 [Page 14] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 10. Security Considerations TBD Farinacci, et al. Expires May 14, 2008 [Page 15] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 11. Acknowledgments Many of the ideas described in this document developed during detailed discussions with Scott Brim and Darrel Lewis, who made many insightful comments on earlier versions of this document. Farinacci, et al. Expires May 14, 2008 [Page 16] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 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 Plan", BCP 122, RFC 4632, August 2006. 12.2. Informative References [LISP] Farinacci, D., Oran, D., Fuller, V., and D. Meyer, "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-04.txt (work in progress), July 2007. Farinacci, et al. Expires May 14, 2008 [Page 17] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 Authors' Addresses Dino Farinacci Cisco Tasman Drive San Jose, CA 95134 USA Email: dino@cisco.com Vince Fuller Cisco Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com Dave Meyer Cisco Tasman Drive San Jose, CA 95134 USA Email: dmm@cisco.com Farinacci, et al. Expires May 14, 2008 [Page 18] Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Farinacci, et al. Expires May 14, 2008 [Page 19]