[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 draft-ietf-lisp-alt

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/