doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc7954.txt b/doc/rfc/rfc7954.txt
new file mode 100644
index 0000000..4f69972
--- /dev/null
+++ b/doc/rfc/rfc7954.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        L. Iannone
+Request for Comments: 7954                             Telecom ParisTech
+Category: Experimental                                          D. Lewis
+ISSN: 2070-1721                                      Cisco Systems, Inc.
+                                                                D. Meyer
+                                                                 Brocade
+                                                               V. Fuller
+                                                          September 2016
+
+
+ Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block
+
+Abstract
+
+   This document directs IANA to allocate a /32 IPv6 prefix for use with
+   the Locator/ID Separation Protocol (LISP).  The prefix will be used
+   for local intra-domain routing and global endpoint identification, by
+   sites deploying LISP as Endpoint Identifier (EID) addressing space.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7954.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iannone, et al.               Experimental                      [Page 1]
+
+RFC 7954                     LISP EID Block               September 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 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 Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Rationale and Intent  . . . . . . . . . . . . . . . . . . . .   3
+   4.  Expected Use  . . . . . . . . . . . . . . . . . . . . . . . .   5
+   5.  Block Dimension . . . . . . . . . . . . . . . . . . . . . . .   5
+   6.  3+3 Allocation Plan . . . . . . . . . . . . . . . . . . . . .   6
+   7.  Allocation Lifetime . . . . . . . . . . . . . . . . . . . . .   7
+   8.  Routing Considerations  . . . . . . . . . . . . . . . . . . .   7
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
+   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
+   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
+     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
+     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iannone, et al.               Experimental                      [Page 2]
+
+RFC 7954                     LISP EID Block               September 2016
+
+
+1.  Introduction
+
+   This document directs the IANA to allocate a /32 IPv6 prefix for use
+   with the Locator/ID Separation Protocol (LISP [RFC6830]), LISP Map-
+   Server ([RFC6833]), LISP Alternative Topology (LISP+ALT [RFC6836])
+   (or other) mapping systems, and LISP Interworking ([RFC6832]).
+
+   This block will be used as global Endpoint Identifier (EID) space.
+
+2.  Definition of Terms
+
+   The present document does not introduce any new terms with respect to
+   the set of LISP Specifications ([RFC6830], [RFC6831], [RFC6832],
+   [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC6837]), but it
+   assumes that the reader is familiar with the LISP terminology.
+   [LISP-INTRO] provides an introduction to the LISP technology,
+   including its terminology.
+
+3.  Rationale and Intent
+
+   Discussion within the LISP working group led to the identification of
+   several scenarios in which the existence of a LISP-specific address
+   block brings technical benefits.  The most relevant scenarios are
+   described below:
+
+   Early LISP destination detection:  With the current specifications,
+         there is no direct way to detect whether or not a certain
+         destination is in a LISP domain without performing a LISP
+         mapping lookup.  For instance, if an Ingress Tunnel Router
+         (ITR) is sending packets to all types of destinations (i.e.,
+         non-LISP destinations, LISP destinations not in the IPv6 EID
+         block, and LISP destinations in the IPv6 EID block), the only
+         way to understand whether or not to encapsulate the traffic is
+         to perform a cache lookup and, in case of a LISP cache miss,
+         send a Map-Request to the mapping system.  In the meanwhile
+         (while waiting for the Map-Reply), packets may be dropped to
+         avoid excessive buffering.
+
+   Avoid penalizing non-LISP traffic:  In certain circumstances, it
+         might be desirable to configure a router using LISP features to
+         natively forward all packets that do not have a destination
+         address in the block and, hence, no lookup whatsoever is
+         performed and packets destined to non-LISP sites are not
+         penalized in any manner.
+
+
+
+
+
+
+
+Iannone, et al.               Experimental                      [Page 3]
+
+RFC 7954                     LISP EID Block               September 2016
+
+
+   Traffic Engineering:  In some deployment scenarios, it might be
+         desirable to apply different traffic-engineering policies for
+         LISP and non-LISP traffic.  A LISP-specific EID block would
+         allow improved traffic-engineering capabilities with respect to
+         LISP vs. non-LISP traffic.  In particular, LISP traffic might
+         be identified without having to use Deep Packet Inspection
+         (DPI) techniques in order to parse the encapsulated packet.
+         Instead, performing a simple inspection of the outer header is
+         sufficient.
+
+   Transition Mechanism:  The existence of a LISP-specific EID block may
+         prove useful in transition scenarios.  A non-LISP domain would
+         ask for an allocation in the LISP EID block and use it to
+         deploy LISP in its network.  Such allocation would not be
+         announced in the BGP routing infrastructure (cf. Section 4).
+         This approach will allow non-LISP domains to avoid fragmenting
+         their already allocated non-LISP addressing space, which may
+         lead to BGP routing table inflation since it may (rightfully)
+         be announced in the BGP routing infrastructure.
+
+   Limit the impact on the BGP routing infrastructure:  As described in
+         the previous scenario, LISP adopters will avoid fragmenting
+         their addressing space, since fragmentation would negatively
+         impact the BGP routing infrastructure.  Adopters will use
+         addressing space from the EID block, which might be announced
+         in large aggregates and in a tightly controlled manner only by
+         Proxy Tunnel Routers (PxTRs).
+
+   It is worth mentioning that new use cases may arise in the future,
+   due to new and unforeseen scenarios.
+
+   Furthermore, the use of a dedicated address block allows for tighter
+   control over the traffic in the initial experimental phase
+   (especially filtering), while facilitating its large-scale
+   deployment.
+
+   [RFC3692] considers assigning experimental and testing numbers
+   useful; having a reserved IPv6 prefix enables this practice.  The
+   present document follows the guidelines provided in [RFC3692], with
+   one exception.  [RFC3692] suggests the use of values similar to those
+   called "Private Use" in [RFC5226], which by definition are not
+   unique.  One purpose of the present request to IANA is to guarantee
+   uniqueness to the EID block.  The lack thereof would result in a lack
+   of real utility of a reserved IPv6 prefix.
+
+
+
+
+
+
+
+Iannone, et al.               Experimental                      [Page 4]
+
+RFC 7954                     LISP EID Block               September 2016
+
+
+4.  Expected Use
+
+   Sites planning to deploy LISP may request a prefix in the IPv6 EID
+   block.  Such prefixes will be used for routing and endpoint
+   identification inside the site requesting it.  Mappings related to
+   such a prefix, or part of it, will be made available through the
+   mapping system in use and registered to one or more Map-Server(s).
+
+   The EID block must be used for LISP experimentation and must not be
+   advertised in the form of more specific route advertisements in the
+   non-LISP inter-domain routing environment.  Interworking between the
+   EID block sub-prefixes and the non-LISP Internet is done according to
+   the techniques described in [RFC6832] and [RFC7215].
+
+   As the LISP adoption progresses, the EID block may potentially have a
+   reduced impact on the BGP routing infrastructure, compared to the
+   case of having the same number of adopters using global unicast space
+   allocated by Regional Internet Registries (RIRs) ([MobiArch2007]).
+   From a short-term perspective, the EID block offers potentially large
+   aggregation capabilities since it is announced by Proxy Tunnel
+   Routers (PxTRs), possibly concentrating several contiguous prefixes.
+   This trend should continue with even lower impact from a long-term
+   perspective, because more aggressive aggregation can be used,
+   potentially leading to using fewer PxTRs announcing the whole EID
+   block ([FIABook2010]).
+
+   The EID block will be used only at the configuration level, so it is
+   recommended not to hard-code the IPv6 EID block in the router
+   hardware in any way.  This prevents locking out sites that may want
+   to switch to LISP while keeping their own IPv6 prefix, which is not
+   in the IPv6 EID block.  Furthermore, in the case of a future
+   permanent allocation, the allocated prefix may differ from the
+   experimental temporary prefix allocated during the experimentation
+   phase.
+
+   With the exception of the Proxy Ingress Tunnel Router (PITR) case
+   (described in Section 8), prefixes out of the EID block must not be
+   announced in the BGP routing infrastructure.
+
+5.  Block Dimension
+
+   The working group reached consensus on an initial allocation of a /32
+   prefix.  The reason of such consensus is manifold:
+
+   o  The working group agreed that the /32 prefix is sufficiently large
+      to cover initial allocation and requests for prefixes in the EID
+      space in the next few years for very large-scale experimentation
+      and deployment.
+
+
+
+Iannone, et al.               Experimental                      [Page 5]
+
+RFC 7954                     LISP EID Block               September 2016
+
+
+   o  As a comparison, it is worth mentioning that the current LISP Beta
+      Network ([BETA]) is using a /32 prefix, with more than 250 sites
+      using a /48 sub-prefix.  Hence, a /32 prefix appears sufficiently
+      large to allow the current deployment to scale up and be open for
+      interoperation with independent deployments using the EIDs in the
+      new /32 prefix.
+
+   o  A /32 prefix is sufficiently large to allow deployment of
+      independent (commercial) LISP-enabled networks by third parties,
+      but may as well boost LISP experimentation and deployment.
+
+   o  The use of a /32 prefix is in line with previous similar prefix
+      allocation for tunneling protocols ([RFC3056]).
+
+6.  3+3 Allocation Plan
+
+   Per this document, IANA has initially assigned a /32 prefix out of
+   the IPv6 addressing space for use as EID in LISP.
+
+   IANA allocated the requested address space in September 2016 for a
+   duration of 3 (three) years (through September 2019), with an option
+   to extend this period by 3 (three) more years (until September 2022).
+   By the end of the first period, the IETF will provide a decision on
+   whether to transform the prefix into a permanent assignment or to put
+   it back in the free pool (see Section 7 for more information).
+
+   In the first case, i.e., if the IETF decides to transform the block
+   into a permanent allocation, the EID block allocation period will be
+   extended for three years (until September 2022) to give the IETF time
+   to define the final size of the EID block and create a transition
+   plan.  The transition of the EID block into a permanent allocation
+   might pose policy issues (as recognized in [RFC2860], Section 4.3);
+   therefore, discussion with the IANA, the RIR communities, and the
+   IETF community will be necessary to determine the appropriate policy
+   for permanent EID-block allocation and management.  Note as well that
+   the final permanent allocation may differ from the initial
+   experimental assignment; hence, it is recommended not to hard-code
+   the experimental EID block on LISP-capable devices in any way.
+
+   In the latter case, i.e., if the IETF decides to terminate the
+   experimental-use EID block, all temporary prefix allocations in this
+   address range must expire and be released by September 2019, so that
+   the entire /32 is returned to the free pool.
+
+   The allocation and management of the EID block for the initial 3-year
+   period (and the optional 3 more years) is detailed in [RFC7955].
+
+
+
+
+
+Iannone, et al.               Experimental                      [Page 6]
+
+RFC 7954                     LISP EID Block               September 2016
+
+
+7.  Allocation Lifetime
+
+   If no explicit action is carried out by the end of the experiment (by
+   September 2019), it is automatically considered that there was not
+   sufficient interest in having a permanent allocation; therefore, the
+   address block will be returned to the free pool.
+
+   Otherwise, if the LISP working group recognizes that there is value
+   in having a permanent allocation, then explicit action is needed.
+
+   In order to trigger the process for a permanent allocation, a
+   document is required.  Such a document has to articulate the
+   rationale for why a permanent allocation would be beneficial.  More
+   specifically, the document has to detail the experience gained during
+   experimentation and all of the technical benefits provided by the use
+   of a LISP-specific prefix.  Such technical benefits are expected to
+   lay in the scenarios described in Section 3.  However, new and
+   unforeseen benefits may appear during experimentation.  The
+   description should be sufficiently articulate that the needed size of
+   the permanent allocation can be estimated.  However, note that, as
+   explained in Section 6, it is up to IANA to decide which address
+   block will be used as a permanent allocation and that such a block
+   may be different from the temporary experimental allocation.
+
+8.  Routing Considerations
+
+   In order to provide connectivity between the Legacy Internet and LISP
+   sites, PITRs announcing large aggregates (ideally one single, large
+   aggregate) of the IPv6 EID block could be deployed.  By doing so,
+   PITRs will attract traffic destined for LISP sites in order to
+   encapsulate and forward it toward the specific destination LISP site.
+   Routers in the Legacy Internet must treat announcements of prefixes
+   from the IPv6 EID block as normal announcements, applying best
+   current practices for traffic engineering and security.
+
+   Even in a LISP site, not all routers need to run LISP elements.  In
+   particular, routers that are not at the border of the local domain,
+   used only for intra-domain routing, do not need to provide any
+   specific LISP functionality but must be able to route traffic using
+   addresses in the IPv6 EID block.
+
+   For the above-mentioned reasons, routers that do not run any LISP
+   element must not include any special handling code or hardware for
+   addresses in the IPv6 EID block.  In particular, it is recommended
+   that the default router configuration not handle such addresses in
+   any special way.  Doing differently could prevent communication
+   between the Legacy Internet and LISP sites or even break local intra-
+   domain connectivity.
+
+
+
+Iannone, et al.               Experimental                      [Page 7]
+
+RFC 7954                     LISP EID Block               September 2016
+
+
+9.  Security Considerations
+
+   This document does not introduce new security threats in the LISP
+   architecture nor in the legacy Internet architecture.
+
+10.  IANA Considerations
+
+   IANA has assigned a /32 IPv6 prefix for use as the global EID space
+   for LISP using a hierarchical allocation as outlined in [RFC5226] and
+   summarized in Table 1.  The assigned block is from the 2001:5 global
+   unicast space.
+
+   IANA is not requested to issue an AS0 Route Origin Attestation (ROA
+   [RFC6491]), because the global EID space is be used for routing
+   purposes.
+
+               +----------------------+--------------------+
+               | Attribute            | Value              |
+               +----------------------+--------------------+
+               | Address Block        | 2001:5::/32        |
+               | Name                 | EID Space for LISP |
+               | RFC                  | RFC 7954           |
+               | Allocation Date      | September 2016     |
+               | Termination Date     | September 2019 [1] |
+               | Source               | True [2]           |
+               | Destination          | True               |
+               | Forwardable          | True               |
+               | Global               | True               |
+               | Reserved-by-protocol | True [3]           |
+               +----------------------+--------------------+
+
+      [1] According to the 3+3 Plan outlined in this document, the
+          termination date can be postponed to September 2022.
+      [2] Can be used as a multicast source as well.
+      [3] To be used as EID space by routers enabled by LISP [RFC6830].
+
+                            Table 1: Global EID Space
+
+   The reserved address space is requested for an initial 3-year period
+   starting in September 2016 (until September 2019), with an option to
+   extend it by three years (until September 2022) upon the decision of
+   the IETF (see Sections 6 and 7).  Following the policies outlined in
+   [RFC5226], upon IETF Review, the decision should be made on whether
+   to have a permanent EID block assignment by September 2019.  If no
+   explicit action is taken or, if the IETF Review outcome is that it is
+   not worth having a reserved prefix as a global EID space, the whole
+   /32 will be taken out from the "IANA IPv6 Special-Purpose Address
+   Registry" and put back in the free pool managed by IANA.
+
+
+
+Iannone, et al.               Experimental                      [Page 8]
+
+RFC 7954                     LISP EID Block               September 2016
+
+
+   Allocation and management of the global EID space is detailed in
+   [RFC7955].  Nevertheless, all prefix allocations out of this space
+   must be temporary and no allocation must go beyond September 2019
+   unless the IETF Review decides for a permanent global EID space
+   assignment.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
+              Understanding Concerning the Technical Work of the
+              Internet Assigned Numbers Authority", RFC 2860,
+              DOI 10.17487/RFC2860, June 2000,
+              <http://www.rfc-editor.org/info/rfc2860>.
+
+   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
+              Considered Useful", BCP 82, RFC 3692,
+              DOI 10.17487/RFC3692, January 2004,
+              <http://www.rfc-editor.org/info/rfc3692>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
+              Locator/ID Separation Protocol (LISP)", RFC 6830,
+              DOI 10.17487/RFC6830, January 2013,
+              <http://www.rfc-editor.org/info/rfc6830>.
+
+   [RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
+              Locator/ID Separation Protocol (LISP) for Multicast
+              Environments", RFC 6831, DOI 10.17487/RFC6831, January
+              2013, <http://www.rfc-editor.org/info/rfc6831>.
+
+   [RFC6832]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
+              "Interworking between Locator/ID Separation Protocol
+              (LISP) and Non-LISP Sites", RFC 6832,
+              DOI 10.17487/RFC6832, January 2013,
+              <http://www.rfc-editor.org/info/rfc6832>.
+
+   [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
+              Protocol (LISP) Map-Server Interface", RFC 6833,
+              DOI 10.17487/RFC6833, January 2013,
+              <http://www.rfc-editor.org/info/rfc6833>.
+
+
+
+
+
+Iannone, et al.               Experimental                      [Page 9]
+
+RFC 7954                     LISP EID Block               September 2016
+
+
+   [RFC6834]  Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
+              Separation Protocol (LISP) Map-Versioning", RFC 6834,
+              DOI 10.17487/RFC6834, January 2013,
+              <http://www.rfc-editor.org/info/rfc6834>.
+
+   [RFC6835]  Farinacci, D. and D. Meyer, "The Locator/ID Separation
+              Protocol Internet Groper (LIG)", RFC 6835,
+              DOI 10.17487/RFC6835, January 2013,
+              <http://www.rfc-editor.org/info/rfc6835>.
+
+   [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
+              "Locator/ID Separation Protocol Alternative Logical
+              Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
+              January 2013, <http://www.rfc-editor.org/info/rfc6836>.
+
+   [RFC6837]  Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
+              Routing Locator (RLOC) Database", RFC 6837,
+              DOI 10.17487/RFC6837, January 2013,
+              <http://www.rfc-editor.org/info/rfc6837>.
+
+   [RFC7955]  Iannone, L., Jorgensen, R., Conrad, D., and G. Huston,
+              "Locator/ID Separation Protocol (LISP) Endpoint Identifier
+              (EID) Block Management Guidelines", RFC 7955,
+              DOI 10.17487/RFC7955, September 2016,
+              <http://www.rfc-editor.org/info/rfc7955>.
+
+11.2.  Informative References
+
+   [BETA]     LISP Beta Network, "Locator/ID Separation Protocol",
+              <http://www.lisp4.net>.
+
+   [FIABook2010]
+              Iannone, L. and T. Leva, "Modeling the economics of Loc/ID
+              Separation for the Future Internet", Towards the Future
+              Internet, Pages 11-20, ISBN: 9781607505389, IOS Press,
+              DOI 10.3233/978-1-60750-539-6-11, May 2010.
+
+   [LISP-INTRO]
+              Cabellos-Aparicio, A. and D. Saucez, "An Architectural
+              Introduction to the Locator/ID Separation Protocol
+              (LISP)", Work in Progress, draft-ietf-lisp-introduction-
+              13, April 2015.
+
+
+
+
+
+
+
+
+
+Iannone, et al.               Experimental                     [Page 10]
+
+RFC 7954                     LISP EID Block               September 2016
+
+
+   [MobiArch2007]
+              Quoitin, B., Iannone, L., de Launois, C., and O.
+              Bonaventure, "Evaluating the Benefits of the Locator/
+              Identifier Separation", The 2nd ACM-SIGCOMM International
+              Workshop on Mobility in the Evolving Internet
+              Architecture (MobiArch'07), DOI 10.1145/1366919.1366926,
+              August 2007.
+
+   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+              via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February
+              2001, <http://www.rfc-editor.org/info/rfc3056>.
+
+   [RFC6491]  Manderson, T., Vegoda, L., and S. Kent, "Resource Public
+              Key Infrastructure (RPKI) Objects Issued by IANA",
+              RFC 6491, DOI 10.17487/RFC6491, February 2012,
+              <http://www.rfc-editor.org/info/rfc6491>.
+
+   [RFC7215]  Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
+              Pascual, J., and D. Lewis, "Locator/Identifier Separation
+              Protocol (LISP) Network Element Deployment
+              Considerations", RFC 7215, DOI 10.17487/RFC7215, April
+              2014, <http://www.rfc-editor.org/info/rfc7215>.
+
+Acknowledgments
+
+   Special thanks to Roque Gagliano for his suggestions and pointers.
+   Thanks to Alvaro Retana, Deborah Brungard, Ron Bonica, Damien Saucez,
+   David Conrad, Scott Bradner, John Curran, Paul Wilson, Geoff Huston,
+   Wes George, Arturo Servin, Sander Steffann, Brian Carpenter, Roger
+   Jorgensen, Terry Manderson, Brian Haberman, Adrian Farrel, Job
+   Snijders, Marla Azinger, Chris Morrow, and Peter Schoenmaker for
+   their insightful comments.  Thanks as well to all participants for
+   the fruitful discussions on the IETF mailing list.
+
+   The work of Luigi Iannone has been partially supported by the
+   ANR-13-INFR-0009 LISP-Lab Project <www.lisp-lab.org> and the EIT KIC
+   ICT-Labs SOFNETS Project.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iannone, et al.               Experimental                     [Page 11]
+
+RFC 7954                     LISP EID Block               September 2016
+
+
+Authors' Addresses
+
+   Luigi Iannone
+   Telecom ParisTech
+
+   Email: ggx@gigix.net
+
+
+   Darrel Lewis
+   Cisco Systems, Inc.
+
+   Email: darlewis@cisco.com
+
+
+   David Meyer
+   Brocade
+
+   Email: dmm@1-4-5.net
+
+
+   Vince Fuller
+
+   Email: vaf@vaf.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iannone, et al.               Experimental                     [Page 12]
+