Internet DRAFT - draft-rodrigueznatal-ila-lisp

draft-rodrigueznatal-ila-lisp







Network Working Group                                 A. Rodriguez-Natal
Internet-Draft                                                V. Ermagan
Intended status: Experimental                                   F. Maino
Expires: October 7, 2018                                   Cisco Systems
                                                             A. Cabellos
                                       Technical University of Catalonia
                                                           April 5, 2018


       LISP control-plane for Identifier Locator Addressing (ILA)
                    draft-rodrigueznatal-ila-lisp-01

Abstract

   This document specifies how to use the LISP control-plane to support
   an Identifier Locator Addressing (ILA) data-plane.  In particular, it
   describes how ILA data-plane components can use the LISP control-
   plane to dynamically resolve and register Identifier-to-Locator
   mappings as well as Endpoint Address to Identifier/Locator mappings.

Status of This Memo

   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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://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."

   This Internet-Draft will expire on October 7, 2018.

Copyright Notice

   Copyright (c) 2018 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
   (https://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



Rodriguez-Natal, et al.  Expires October 7, 2018                [Page 1]

Internet-Draft                  ILA-LISP                      April 2018


   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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  LISP Overview . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  ILA encoding in LISP  . . . . . . . . . . . . . . . . . . . .   4
     4.1.  ILA LCAF  . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.1.  Identifier Subtype  . . . . . . . . . . . . . . . . .   5
       4.1.2.  Locator Subtype . . . . . . . . . . . . . . . . . . .   7
       4.1.3.  SIR Prefix Subtype  . . . . . . . . . . . . . . . . .   8
     4.2.  IPv6 addresses  . . . . . . . . . . . . . . . . . . . . .   8
       4.2.1.  Identifiers . . . . . . . . . . . . . . . . . . . . .   8
       4.2.2.  Locators  . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Device Roles and Provision  . . . . . . . . . . . . . . . . .   9
     5.1.  Map Server (MS) . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Map Resolver (MR) . . . . . . . . . . . . . . . . . . . .  10
     5.3.  ILA-Router (ILA-R)  . . . . . . . . . . . . . . . . . . .  10
     5.4.  ILA-Node (ILA-N)  . . . . . . . . . . . . . . . . . . . .  10
   6.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  ILA Identifier to Locator Mappings  . . . . . . . . . . .  11
       6.1.1.  Resolution (via Map-Request to MR)  . . . . . . . . .  12
       6.1.2.  Resolution (via Map-Notify from ILA-R/MS) . . . . . .  12
       6.1.3.  Registration  . . . . . . . . . . . . . . . . . . . .  13
       6.1.4.  PubSub  . . . . . . . . . . . . . . . . . . . . . . .  13
       6.1.5.  Mobility  . . . . . . . . . . . . . . . . . . . . . .  13
     6.2.  Endpoint Address to ILA Identifier/Locator Mappings . . .  14
       6.2.1.  Resolution  . . . . . . . . . . . . . . . . . . . . .  15
       6.2.2.  Registration  . . . . . . . . . . . . . . . . . . . .  16
   7.  Deployment Considerations . . . . . . . . . . . . . . . . . .  16
     7.1.  Protocol Transport  . . . . . . . . . . . . . . . . . . .  16
     7.2.  Mapping System Internal Resolution  . . . . . . . . . . .  16
     7.3.  Mapping System Replication and Synchronization  . . . . .  17
     7.4.  Multiple ILA Domains  . . . . . . . . . . . . . . . . . .  17
     7.5.  Proactive Mapping Push  . . . . . . . . . . . . . . . . .  17
     7.6.  Checksum Adjustment per Locator . . . . . . . . . . . . .  18
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
     8.1.  Signaling Protection  . . . . . . . . . . . . . . . . . .  18
     8.2.  Map-Cache Attacks . . . . . . . . . . . . . . . . . . . .  18
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     11.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21



Rodriguez-Natal, et al.  Expires October 7, 2018                [Page 2]

Internet-Draft                  ILA-LISP                      April 2018


1.  Introduction

   The Locator/ID Separation Protocol (LISP) control-plane document
   [I-D.ietf-lisp-rfc6833bis] defines a generic Mapping Service that in
   addition to encapsulation-based Loc-ID separation data-planes, such
   as the LISP data-plane [I-D.ietf-lisp-rfc6830bis], can be also
   applied to translation-based Loc-ID separation data-planes.

   Between the translation-based Loc-ID separation data-planes, this
   document focuses on the use of LISP control-plane with the Identifier
   Locator Addressing (ILA) [I-D.herbert-intarea-ila] data-plane, but a
   similar approach can be used with other translation-based Loc-ID
   separation data-planes such as the SRv6 Network Programming
   [I-D.filsfils-spring-srv6-network-programming] data-plane, or the
   Identifier-Locator Network Protocol (ILNP) [RFC6740] data-plane.

   The Identifier Locator Addressing (ILA) is an IPv6 data-plane
   protocol that relies on address splitting for ID/location separation.
   Part of the IPv6 address expresses the Identifier of an endpoint, the
   immutable identity of the node (e.g. task, end-host, mobile device,
   etc), while another part represents its Locator, the topological
   location of the endpoint, which can be dynamic.  The Locator defines
   where the Identifier is currently attached to the network and is used
   to route the packets through the ILA domain.  To do so, ILA Locators
   are prepended to the ILA Identifier to form a routable ILA address
   (bitwise equivalent to an IPv6 address).

   The Identifier of an endpoint is unique and permanent for its
   lifetime, meanwhile its locator is not fixed and subject to change
   over time.  A control-plane protocol to resolve Identifier-to-Locator
   mappings is needed in order to use the ILA data-plane.  The ILA data-
   plane is agnostic to the control-plane mechanism in place and
   therefore different control-plane protocols have been proposed
   [I-D.lapukhov-bgp-ila-afi] [I-D.herbert-ila-ilamp].

   This document describes how the LISP control-plane can be used to
   support the operation of the ILA data-plane, including the resolution
   of the Identifier-to-Locator mappings and the Endpoint Address to ILA
   Identifier/Locator mappings.

2.  Requirements Language

   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].






Rodriguez-Natal, et al.  Expires October 7, 2018                [Page 3]

Internet-Draft                  ILA-LISP                      April 2018


3.  LISP Overview

   TBD

4.  ILA encoding in LISP

   ILA Identifiers and Locators can be encoded in LISP messages using an
   ILA-specific LCAF type or within IPv6 addresses.  This section
   describes both options.

4.1.  ILA LCAF

   To support explicit ILA mappings and associated data using the LISP
   control-plane the following LISP Canonical Address Format (LCAF)
   [RFC8060] is introduced.  The ILA LCAF permits to explicitly identify
   addresses as ILA Identifiers or Locators, allows to explicitly
   indicate the length of the Identifier or Locator and enables to carry
   ILA specific metadata with the ILA Identifiers and Locators.  The ILA
   LCAF type defines several subtypes, this document refers to the
   different subtypes of the ILA LCAF using the syntax "ILA-Subtype"
   LCAF (e.g.  ILA-Identifier).  All the ILA subtypes follow the format
   defined below:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           AFI = 16387         |     Rsvd1     |     Flags     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = ILA   |Subtype| Rsvd2 |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        ILA Subtype...                         ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 ILA LCAF

   The fields specific to the the ILA LCAF Type are defined below.  For
   definition of the rest of fields see the LCAF specification
   [RFC8060].

   Subtype:  This is the ILA LCAF Subtype.  This field indicates which
      particular ILA format the ILA LCAF encodes.  Currently the
      following Subtypes are defined:

      0x0:  Reserved.  Reserved for future use.

      0x1:  Identifier Subtype.  Used to encode ILA Identifiers as
         described in Section 4.1.1




Rodriguez-Natal, et al.  Expires October 7, 2018                [Page 4]

Internet-Draft                  ILA-LISP                      April 2018


      0x2:  Locator Subtype.  Used to encode ILA Locators as described
         in Section 4.1.2

      0x3:  SIR Prefix Subtype.  Used to encode SIR Prefixes as
         described in Section 4.1.3

4.1.1.  Identifier Subtype

   The Identifier subtype (aka ILA-Identifier LCAF) can be used to carry
   ILA Identifiers in the LISP control-plane signaling.  The ILA
   specification [I-D.herbert-intarea-ila] defines different Identifiers
   formats that can be used in the data-plane.  The same Identifier
   formats are described in this document for the ILA-Identifier LCAF
   Subtype.  When used in this document, each Identifier format is
   referred by the code point defined in [I-D.herbert-intarea-ila], e.g.
   "ILA-Identifier-0x3" LCAF.  The ILA data-plane formats are bitwise
   compatible with their correspondent LCAF formats.  It is thus
   possible for an ILA data-plane device to resolve the Locator for a
   particular ILA Identifier even if the ILA data-plane device does not
   understand that particular Identifier type.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           AFI = 16387         |     Rsvd1     |     Flags     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = ILA   |  0x1  |E|Rsvd2|             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type|0|                      Identifier                       ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            ILA-Identifier LCAF

   The fields specific to the the ILA-Identifier LCAF Subtype are
   defined below.

   Type:  This is the Type of Identifier as defined in
      [I-D.herbert-intarea-ila].

   E: This is the "Endpoint Address Mapping" bit.  If the 'E' bit is set
      to 1, it indicates that the Identifier is being resolved to an
      Endpoint Address (see Section 6.2).  The 'E' bit is set to 0
      otherwise.

   Identifier:  This is a variable length field that encodes an ILA
      Identifier.  The length of the Identifier can be inferred from the
      Length field of the LCAF.




Rodriguez-Natal, et al.  Expires October 7, 2018                [Page 5]

Internet-Draft                  ILA-LISP                      April 2018


   For reference and using an Identifier size of 64 bits (including the
   first 4 bits with the Type), the different types of Identifiers are
   encoded in the ILA-Identifier LCAF as described below.  The common
   part of the ILA-Identifier LCAF is not shown.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x0 |0|                                                       |
     +-+-+-+-+              Interface Identifier                     |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Interface Identifier (0x0)

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x1 |0|                                                       |
     +-+-+-+-+            Locally Unique Identifier                  |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Locally Unique Identifier (0x1)

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x2 |0|                     VNID                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Virtual IPv4                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Virtual IPv4 Identifier (0x2)

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x3 |0|                     VNID                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Virtual Unicast IPv6 (lower 32 bits)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Virtual Unicast IPv6 Identifier (0x3)







Rodriguez-Natal, et al.  Expires October 7, 2018                [Page 6]

Internet-Draft                  ILA-LISP                      April 2018


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x4 |0|                     VNID                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Scope |      Virtual Multicast IPv6 (lower 28 bits)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Virtual Multicast IPv6 Identifier (0x4)

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x5 |0|          Non-Local Address Identifier                 |
     +-+-+-+-+                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     |                               |              0x0              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Non-Local Address Identifier (0x5)

4.1.2.  Locator Subtype

   The Locator subtype (aka ILA-Locator LCAF) can be used to carry ILA
   Locators in the LISP control-plane signaling.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           AFI = 16387         |     Rsvd1     |     Flags     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = ILA   |  0x2  |C|Rsvd2|             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Locator                            ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 ILA LCAF

   The fields specific to the the ILA-Locator LCAF Subtype are defined
   below.

   C: This is the "Checksum-Adjustment-Needed" bit.  If the 'C' bit is
      set to 1 it indicates that an ILA data-plane device has to compute
      the checksum adjustment as described in [I-D.herbert-intarea-ila]
      when sending ILA packets to this Locator.  The 'C' bit is set to 0
      otherwise.  See Section 7.6 for more details.






Rodriguez-Natal, et al.  Expires October 7, 2018                [Page 7]

Internet-Draft                  ILA-LISP                      April 2018


   Locator:  This is a variable length field that encodes an ILA
      Locator.  The length of the Locator can be inferred from the
      Length field of the LCAF.

4.1.3.  SIR Prefix Subtype

   The SIR Prefix subtype (aka ILA-SIR LCAF) can be used to encode the
   SIR prefix when different ILA domains co-exist as described in
   Section 7.4.

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           AFI = 16387         |     Rsvd1     |     Flags     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = ILA   |  0x3  | Rsvd2 |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |SIR Prefix Len |                  SIR Prefix ...               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                       ... SIR Prefix                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             AFI = x           |            Address...         ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               ILA-SIR LCAF

   The fields specific to the the ILA-SIR LCAF Subtype are defined
   below.

   SIR Prefix Len:  This field indicates the length of the SIR Prefix
      that follows.

   Locator:  This is a variable length field that encodes an ILA SIR
      Prefix.

4.2.  IPv6 addresses

   Alternatively, ILA Identifiers and Locators can be encoded in LISP
   messages using just IPv6 addresses.  This section describes how to
   encode each.  Using an IPv6 representation does not require to use
   any LCAF but prevents from being explicit on the length and ILA
   semantics of the Identifiers and Locators, as well as from carrying
   associated metadata.

4.2.1.  Identifiers

   ILA Identifiers are encoded in the lower end bits of an IPv6 address
   when used within LISP control messages.  The upper bits of the IPv6
   address encode the SIR prefix to which the Identifier belongs to.



Rodriguez-Natal, et al.  Expires October 7, 2018                [Page 8]

Internet-Draft                  ILA-LISP                      April 2018


4.2.2.  Locators

   ILA Locators are encoded in the upper end bits of an IPv6 address
   when used within LISP control messages.  There are two options on
   what to encode in the lower bits of the IPv6 address carrying the ILA
   Locator.  One option is to encode the ILA Identifier that triggered
   the LISP control message.  Another option is to encode the Control-
   Plane Identifier described in Section 5.  In the latter case, there
   is no longer needed to statically configure the Control-Plane
   Identifier in the different devices.

5.  Device Roles and Provision

   The ILA specification [I-D.herbert-intarea-ila] defines different ILA
   data-plane devices (i.e. devices that can perform ILA transformations
   of SIR addresses to/from ILA addresses), namely ILA-Router (ILA-R),
   ILA-Host (ILA-H) and ILA-Node (ILA-N).  This documents relies on the
   terminology introduced in [I-D.herbert-intarea-ila] but uses ILA-
   Router and ILA-Node denominations to distinguish between ILA data-
   plane devices that have a complete map-cache set (ILA-R) versus those
   that only have an incomplete map-cache (ILA-N).  For the purpose of
   this document, it is assumed that an ILA-N has endpoints assigned to
   it to which it has direct connectivity (if it is an ILA-Host it may
   be even hosting the endpoints itself).  On the contrary, no endpoint
   assignment is assumed for an ILA-R (although not precluded).  This
   section describes in general terms the role and required provisioning
   of the different devices involved in an ILA-LISP deployment, for
   operational details of these devices see Section 6

   To avoid verbosity on the description of the provisioning
   requirements listed below, there are two things that are assumed to
   be configured in all the devices belonging to a given ILA domain:

   o  SIR prefix(es) of the ILA domain: This prefix serves to identify
      traffic belonging to the ILA domain.  It is also used to
      differentiate across different ILA domains where several domains
      share the same infrastructure.

   o  Control-Plane Identifier: a given Identifier within the ILA domain
      is reserved to be used when sending control-plane messages across
      devices.  This Identifier is concatenated with the Locator of the
      device that the control-plane message is addressed towards.  When
      receiving an ILA packet with this special Identifier, the packet
      will be delivered to the control-plane process of the device.







Rodriguez-Natal, et al.  Expires October 7, 2018                [Page 9]

Internet-Draft                  ILA-LISP                      April 2018


5.1.  Map Server (MS)

   A MS has the complete mapping information for all the Identifiers in
   the ILA domain.  If the Identifier space is divided into different
   shards, then each MS is responsible for a particular shard of
   Identifiers.  Then, for the Identifiers of its shard, the MS has the
   complete mapping information.  The mapping information at an MS can
   be populated by the ILA devices registering their local mappings and/
   or by an external source.  A MS has to be pre-provisioned with the
   following:

      Shard index: of the shard the MS is responsible for (if any).

5.2.  Map Resolver (MR)

   A MR receives requests for mappings from ILA data-plane devices and
   forwards them to the appropriate MS.  If needed, a MR is also able to
   find which MS is associated with a particular shard.  See Section 7.2
   for a discussion on different options regarding how a MR can find the
   appropriate MS to forward a given mapping request.

5.3.  ILA-Router (ILA-R)

   An ILA-R has a complete map-cache for the mappings in the domain.  If
   shards are used, then each ILA-R is assigned to a particular shard of
   Identifiers for which it has a complete map-cache of mappings.  An
   ILA-R subscribes (as described in Section 6.1.4) to a MS (or to the
   MS responsible for its shard) to populate and keep its map-cache
   updated.  The logical functions of a MS and an ILA-R serving the same
   domain (or shard) can be co-located and assigned to the same box.  In
   that case, the ILA-R does not need to subscribe to the mappings in
   the domain (or shard) since they are locally available.  Normally, an
   ILA-R has no endpoint (e.g. task, user-endpoint, etc) directly
   attached.  Instead, it serves to translate packets that were not
   transformed by an ILA-N.  To do so, as described in
   [I-D.herbert-intarea-ila], an ILA-R announces the SIR prefix (plus
   its shard index if needed) as an "anycast" address on the underlay to
   attract traffic towards itself.  An ILA-R has to be pre-provisioned
   with the following:

      Shard index: of the shard the ILA-R is assigned to.

5.4.  ILA-Node (ILA-N)

   This document uses the term ILA-Node to refer to an ILA translating
   device that does not have a complete map-cache, in contrast with ILA-
   Router that has a complete map-cache for the domain (or its shard).
   Each ILA-N has a set of endpoints (and associated Identifiers)



Rodriguez-Natal, et al.  Expires October 7, 2018               [Page 10]

Internet-Draft                  ILA-LISP                      April 2018


   assigned to it for which it has complete mapping information.  An
   ILA-N registers its local mapping information into a MS (or set of
   MSs) as described in Section 6.1.3.  A given ILA-N may have
   Identifiers from different shards, in that case per each Identifier
   it has to register the mapping information in the appropriate MS (the
   one handling the shard of the Identifier).  Contrary to an ILA-R, the
   ILA-N does not have a full map-cache for remote Identifiers, but
   rather it populates its map-cache on demand (following the mechanisms
   described in Section 6.1) based on the actual data-plane traffic.  An
   ILA-N has to be pre-provisioned with the following:

      Identifiers: that the ILA-N is responsible for (if they are not
      created or auto-discovered by the ILA-N).

      Locators: to use on the ILA underlay (if they are not created or
      auto-discovered by the ILA-N).

      VNID / Tenant-Prefix pairs: if virtualization is used (see also
      Section 6.2).

      MR Locator: to request mappings for remote identifiers.

      MS Locator: of the MS (or MSs) responsible for the Identifiers
      assigned to the ILA-N.

      Checksum adjustment setting: to indicate if the ILA-N has to
      perform or not checksum adjustment (see also Section 7.6).

6.  Operation

   An ILA data-plane can leverage the LISP control-plane to support
   different aspects of its operation.  The main function provided by
   the LISP control plane is resolving the Identifier to Locator
   mappings.  In addition, ILA can also use the LISP control-plane to
   dynamically learn the ILA Identifier associated to an Endpoint
   Address.  These two steps can also be combined into a single
   resolution exchange.

6.1.  ILA Identifier to Locator Mappings

   This section describes how ILA devices can use the LISP control-plane
   to resolve, register and keep updated the Identifier to Locator
   mappings required for the operation of the ILA data-plane.  Two
   different modes of resolving the Identifier are described, one on
   which the ILA-N sends a Map-Request to a MR and another where a ILA-R
   with a co-located MS reacts to data-plane traffic and sends a Map-
   Notify towards the ILA-N.




Rodriguez-Natal, et al.  Expires October 7, 2018               [Page 11]

Internet-Draft                  ILA-LISP                      April 2018


6.1.1.  Resolution (via Map-Request to MR)

   When an ILA-N has to send traffic towards a remote Identifier for
   which it does not have the associated Locator, it can obtain the
   Locator via sending a request to the MR.  To do so, it follows the
   mechanisms described in [I-D.ietf-lisp-rfc6833bis] and sends a Map-
   Request towards one of its configured MRs.  This Map-Request includes
   as EID the ILA Identifier of the remote endpoint encoded as described
   in Section 4.  As a response to this Map-Request, the ILA-N will get
   a Map-Reply from the MS with the Locator(s) associated with the
   remote Identifier (if any).  Locators are carried in the Map-Reply as
   RLOCs and are encoded as discussed in Section 4.  In the current ILA
   specification, Identifiers are considered to be in a flat, non-
   hierarchical space.  Therefore, when resolving a single Identifier
   the "EID mask-len" of the Map-Request and Map-Reply is set to the
   length of the Identifier.

   As specified in [I-D.ietf-lisp-rfc6833bis], an ILA-N can use the
   priority and weight information conveyed in the Map-Reply message to
   load balance data-plane traffic across the different Locators for the
   remote Identifier.  While the mapping is being resolved via the Map-
   Request/Map-Reply process, the ILA-N can still send the data packets
   to the underlay using the SIR address as described in
   [I-D.herbert-intarea-ila].  In that way, they can be attracted and
   transformed at an ILA-R.  See also Section 8.2 for discussion on how
   the ILA-N can protect itself from malicious endpoints trying to
   artificially force map-cache misses (and subsequent Map-Requests).

6.1.2.  Resolution (via Map-Notify from ILA-R/MS)

   As described in [I-D.herbert-intarea-ila], the ILA-N sends the SIR
   traffic to the underlay if it has no map-cache entry to transform
   packets.  The SIR traffic will be eventually attracted to an ILA-R
   announcing the SIR prefix.  Thus, the cache of an ILA-N can also be
   populated via unsolicited Map-Notifies (as described in
   [I-D.rodrigueznatal-lisp-pubsub]) when the MS is co-located with the
   ILA-R.  In this scenario, the ILA-R/MS reacts to the data-plane
   traffic received sending unsolicited Map-Notify to the origin of the
   traffic.  To build the Map-Notify, the ILA-R extracts the ILA
   Identifier from the data-packet received and finds the matching
   mapping entry in its co-located MS.  The ILA-R/MS then encodes the
   Identifier and Locators from that mapping as EID and RLOC(s)
   respectively in the Map-Notify, using the encoding described in
   Section 4.

   In general, the unsolicited Map-Notify resolution mode assumes that
   the ILA-R/MS has both the mapping for the destination Identifier as
   well as the source Identifier received in the data-packet.  If the



Rodriguez-Natal, et al.  Expires October 7, 2018               [Page 12]

Internet-Draft                  ILA-LISP                      April 2018


   ILA domain is sharded and the ILA-R/MS does not contain the mapping
   for the source Identifier, the Map-Notify has to be routed towards
   another ILA-R/MS that contains the Locator for the source Identifier.

6.1.3.  Registration

   An ILA-N registers its local Identifier-to-Locator mappings in the
   appropriate MSs (i.e. those handling its Identifiers) by sending Map-
   Register messages following the process documented in
   [I-D.ietf-lisp-rfc6833bis].  To do so, it uses the encoding defined
   in Section 4 to include the ILA Identifier as EID in the Map-
   Register.  Similarly to the mapping resolution process, the "EID
   mask-len" of the Map-Register is fixed to the length of the
   Identifier.  The ILA-N includes its local Locators in the Map-
   Register using the encoding defined in Section 4.  As described in
   [I-D.ietf-lisp-rfc6833bis], the mapping registration may happen
   periodically as well as when there is a change in the mapping(s) that
   the ILA-N is registering.

6.1.4.  PubSub

   An ILA-N can explicitly subscribe to mapping updates using the
   mechanisms described in [I-D.rodrigueznatal-lisp-pubsub].  When using
   the mapping resolution described in Section 6.1.1 to populate its
   map-cache, an ILA-N can combine the resolution and subscription into
   the same Map-Request/Map-Reply exchange.

   Additionally, when ILA-Rs are not co-located with the MSs they need
   to subscribe to mappings in the domain (or their shard).  An ILA-R
   subscribes using [I-D.rodrigueznatal-lisp-pubsub] to receive updates
   for all the Identifier-Locator mappings in the domain (or in its
   shard).  To subscribe to all Identifier mappings in the ILA domain,
   the ILA-R sets the "EID mask-len" in the Map-Request to 0 and encodes
   the ILA Identifier as described in Section 4 with all the Identifier
   bits set to 0.  To subscribe to all Identifier mappings in a
   particular shard, the ILA-R sets the "EID mask-len" in the Map-
   Request to the shard index length and encodes the Identifier with the
   proper shard index set and the rest of the Identifier bits set to 0.

6.1.5.  Mobility

   Mobility of Identifiers is supported by the mechanisms described in
   [I-D.ietf-lisp-eid-mobility].  As described there, when an Identifier
   moves to a different ILA-N, its previous ILA-N is notified with the
   new Locator(s) for the Identifier.  When traffic is received at the
   old Locator, the ILA-N there can use the updated Identifier-Locator
   mapping information to replace the old Locator with the new Locator
   and forward the traffic back to the underlay.  In the interim between



Rodriguez-Natal, et al.  Expires October 7, 2018               [Page 13]

Internet-Draft                  ILA-LISP                      April 2018


   the ILA-N detects that the Identifier has moved but the notification
   with the new Locator is yet to be received, the ILA-N can translate
   received traffic for the Identifier to the SIR address and forward it
   back to the underlay (to be intercepted, transformed and forwarded by
   an ILA-R).

   Following [I-D.ietf-lisp-eid-mobility], when the old ILA-N receives
   traffic addressed for the Identifier that is no longer locally
   connected, it sends a Solict-Map-Request (SMR) to the Locator
   associated with the source Identifier to inform it that it should
   update its map-cache.  Note that when ILA is used as the data-plane,
   the source Locator may not be present in the received data packet and
   a mapping resolution (to find the ILA-N that originated the packet)
   may be needed before the SMR can be sent.  Note also that, if the
   data packet was transformed and sent by an ILA-R, the source
   Identifier will not resolve to the Locator of the ILA-R (but instead
   to the ILA-N where the source Identifier is attached).  For this
   version of the document, the case of sending this SMR to an ILA-R is
   not considered.

6.2.  Endpoint Address to ILA Identifier/Locator Mappings

   The ILA data-plane [I-D.herbert-intarea-ila] defines some cases where
   the address used by an endpoint is not a SIR address.  In those
   cases, the Endpoint Address needs to be mapped to an ILA Identifier
   before an ILA address (or SIR address) can be formed.  These mappings
   of Endpoint Addresses to ILA Identifiers can be statically
   provisioned at the ILA-N or can also be resolved via the LISP
   control-plane.  There are currently two cases defined in
   [I-D.herbert-intarea-ila] where an endpoint does not use a SIR
   address and requires a mapping of Endpoint Address to ILA Identifier.

   o  Virtualization: In virtualization scenarios, the endpoints use
      virtual addresses (with a Tenant Prefix in the case of IPv6)
      rather than SIR addresses.  Before packets can be sent over the
      ILA underlay, the Tenant Prefix has to be converted into a VNID.
      Instead of pre-provisioning the Tenant Prefix to VNID pairs in
      advance, the ILA data-plane can also use the LISP control-plane to
      resolve the mapping of Tenant Prefix to VNID.  Dynamic resolution
      instead of static provisioning can be specially useful for cases
      of cross-communication between different virtual networks (since
      the mapping of a remote Virtual Prefix to VNID may not be
      available at the ILA-N).  Once the ILA-N has resolved the VNID
      associated with a Tenant Prefix, it can cache this information and
      only request Identifier to Locator mappings for new remote
      Endpoint Addresses using the same Tenant Prefix.  Note that for
      virtualization cases using IPv4, the current version of this




Rodriguez-Natal, et al.  Expires October 7, 2018               [Page 14]

Internet-Draft                  ILA-LISP                      April 2018


      document assumes that the VNID has to be pre-provisioned since
      there is not Tenant Prefix that can be resolved into a VNID.

   o  Non-Local Addresses: ILA uses the concept of Non-Local Addresses
      to refer to Endpoint Addresses that do not belong to the SIR
      prefix(es) of the domain.  To use Non-Local Addresses with an ILA
      data-plane, they need to be first converted into an ILA identifier
      (of 44 bits in the current ILA specification).  The LISP control-
      plane can be used by the ILA data-plane to retrieve the mappings
      of Non-Local Addresses to Identifiers (on packet transmission) and
      of Identifiers to Non-Local Addresses (on packet reception).  If
      the ILA data-plane devices are also performing the assignment of
      Non-Local Addresses to ILA Identifiers, the LISP control-plane can
      also be used to register this assignment into the Mapping System.

   This section covers the resolution (including reverse resolution) and
   registration of Endpoint Address mappings.  Contrary to the
   Identifier to Locator mappings, the mappings of Endpoint Address to
   Identifier are not expected to change once they have been
   established.  Therefore, the cases of PubSub and mobility are not
   considered in this section.

6.2.1.  Resolution

   As with Identifier to Locator mapping resolution, the resolution of
   Endpoint Address to Identifier is done via the Map-Request/Map-Reply
   exchange specified in [I-D.ietf-lisp-rfc6833bis].  It is assumed that
   in the scenario where LISP is used to resolve Endpoint Address to
   Identifier mappings, the MR is able to find the MS storing the
   requested Endpoint Address mapping.

   When Endpoint Addresses are carried as EIDs in LISP control messages
   they are encoded using the same format the endpoint is using (i.e.
   IPv6 in the currently defined cases).  The Identifier associated to
   the Endpoint Address is returned in the Map-Reply as an RLOC with
   priority 255 and encoded as defined in Section 4.  Note that when
   resolving an Endpoint Address to Identifier mapping, the Identifier
   to Locator mapping can be included as well.  In other words, the
   Locators can also be encoded as RLOCs in the Map-Reply returned by
   the MS.

   In some cases (such in the Non-Local Address case) some ILA devices
   may need to perform a reverse resolution of the Endpoint Address
   mapping (i.e. obtain the Endpoint Address associated with a given
   Identifier).  In those cases, and when using the encoding described
   in Section 4.1.1, the Identifier is sent as EID in the Map-Request
   with the 'E' bit (defined in Section 4.1.1) set to '1'.  The 'E' bit
   is used to signal that the requested mapping is "Identifier to



Rodriguez-Natal, et al.  Expires October 7, 2018               [Page 15]

Internet-Draft                  ILA-LISP                      April 2018


   Endpoint Address" and distinguish the request from the default
   "Identifier to Locator" resolution that is triggered when sending an
   Identifier in the Map-Request.  On this reverse resolution, the MS
   will return the Endpoint Address in the Map-Reply encoded as an RLOC
   with priority 255.  If the encoding described in Section 4.2 is used
   instead, both the Endpoint Address and the Locators have to be
   returned when querying for an ILA Identifier.  In this latter case,
   the Endpoint Address is still encoded in the Map-Reply with priority
   255.

6.2.2.  Registration

   When the assignment of Endpoint Address to ILA Identifier is
   performed by the ILA-N, the ILA-N can register this assignment into
   its MS(s).  The ILA-N encodes the Endpoint Address as EID (using the
   same format the endpoint is using) and the Identifier as RLOC with
   priority 255 (using the encoding discussed in Section 4).  It is
   assumed that the MS(s) assigned to the ILA-N are able to understand
   and store the Endpoint Address to Identifier mappings generated by
   the ILA-N.  Similarly to the resolution case, the Identifier to
   Locator mapping can be also included when registering the Endpoint
   Address mapping via means of providing too the Locators as RLOCs in
   the Map-Register message.

7.  Deployment Considerations

   This section discusses different options and deployment scenarios to
   consider when deploying an ILA data-plane using a LISP control-plane.

7.1.  Protocol Transport

   LISP as defined in [I-D.ietf-lisp-rfc6833bis] runs over a UDP
   transport, however the exact same signaling can be used over a TCP
   transport without affecting the protocol operation.  If a TCP
   transport is available, then the mechanisms described in
   [I-D.kouvelas-lisp-map-server-reliable-transport] can also be used to
   optimize the LISP control-plane protocol operation when this runs
   over a reliable channel.

7.2.  Mapping System Internal Resolution

   For small deployments where each MS has the complete mapping
   information for the domain, the MRs may just be provisioned with the
   Locators for all the MSs.  They can then do load balancing across the
   MSs based on different metrics (e.g. latency, load, etc)






Rodriguez-Natal, et al.  Expires October 7, 2018               [Page 16]

Internet-Draft                  ILA-LISP                      April 2018


   If the domain is split into shards, there are different ways for a MR
   to find the MS that corresponds to a given shard.  Some options can
   include LISP-DDT [RFC8111] or LISP-ALT [RFC6836] for instance.

   There is also the option that a backend database is used as Mapping
   System, in which case both the MRs and MSs are just interfaces to
   interact with the backend database.  In that scenario, the database
   internal implementation will find the appropriate instance that is
   hosting the requested mapping.

7.3.  Mapping System Replication and Synchronization

   For reliability and latency purposes, several MSs can be deployed for
   the same domain or the same shard.  In that scenario, it is required
   to have a mechanism to synchronize the mapping information across
   them.  One option is that, as described in
   [I-D.ietf-lisp-rfc6833bis], the ILA-Ns register their local mappings
   to several MSs.  Alternatively, when a backend database is in place,
   mechanisms specific to the database implementation can be leveraged
   to provide synchronization across different replicas.

7.4.  Multiple ILA Domains

   When different ILA domains co-exist using the same infrastructure, it
   may be needed to distinguish the particular domain to which a control
   message refers to.  In that case, the Identifiers and Endpoint
   Addresses must be qualified with the appropriate ILA domain for the
   control-plane operation.  This can be done by prepending the ILA-SIR
   LCAF described in Section 4.1.3 when needed.  If the encoding
   described in Section 4.1 is used both the ILA Identifiers and
   Endpoint Addresses need to be qualified when used as EIDs in LISP
   messages.  When the encoding described in Section 4.2 is used only
   Endpoint Addresses need to be qualified.

7.5.  Proactive Mapping Push

   Optionally, when a MS receives a Map-Request (or when an ILA-R/MS
   receives data-traffic) for an Identifier, it can send a proactive
   Map-Notify towards the ILA-N associated with that Identifier.  In
   this Map-Notify the MS (or ILA-R/MS) includes the mapping associated
   with the Identifier that triggered the Map-Request.  This will pre-
   populate the map-cache of the destination ILA-N and provide the ILA-N
   the mapping required to handle the returning traffic.  This mechanism
   assumes that the MS (or ILA-R/MS) has both the mapping for the
   destination and source Identifiers.






Rodriguez-Natal, et al.  Expires October 7, 2018               [Page 17]

Internet-Draft                  ILA-LISP                      April 2018


7.6.  Checksum Adjustment per Locator

   While performing ILA transformations, ILA data-plane devices
   optionally perform checksum adjustments to keep the transport
   checksum neutral to the transformation.  As an alternative to
   statically configuring the checksum-neutral adjustment option per
   ILA-N (or ILA-R), the Locators associated with a particular
   Identifier can be qualified with the requested selection regarding
   checksum-neutral adjustment.  Then, the need to perform or not this
   checksum adjustment when sending traffic to a particular Locator can
   be stored and retrieved from the MSs encoded in the ILA Locator LCAF
   defined in Section 4.1.2.

8.  Security Considerations

8.1.  Signaling Protection

   All LISP messages have a field for authentication data defined in
   either [I-D.ietf-lisp-rfc6833bis] or [I-D.ietf-lisp-sec].  As
   described in [I-D.ietf-lisp-rfc6833bis] a shared key is required
   between the data-plane devices and their associated MSs to sign and
   secure the signaling.  Additional authentication and integrity
   protection can be enabled by using [I-D.ietf-lisp-sec].
   Complementary, if a TCP session is in place between the ILA data-
   plane elements and the LISP control-plane components, then TLS can be
   used to provide authentication and integrity protection.

8.2.  Map-Cache Attacks

   Malicious endpoints can try to deplete the map-cache and/or overload
   the Map-Request channel of an ILA-N.  To prevent against these
   attacks, the ILA-N should implement efficient heavy hitters counters
   such as Count-Min Sketch [CMS] to prevent data-plane traffic from
   certain endpoints to trigger further control-plane processing once a
   threshold has been reached.  In addition, similar mechanisms can be
   used to protect popular map-cache entries from eviction when the map-
   cache space is being depleted.  Discussion on how to apply heavy
   hitter counters to LISP in particular can be found in [CMS-LISP].

9.  Acknowledgments

   The authors would like to thank Sri Gundavelli, Marc Portoles-
   Comeras, Tom Herbert, Dino Farinacci, Joel Halpern and Luigi Iannone
   for their comments and feedback regarding this document.







Rodriguez-Natal, et al.  Expires October 7, 2018               [Page 18]

Internet-Draft                  ILA-LISP                      April 2018


10.  IANA Considerations

   Following the guidelines of [RFC5226], this document requests IANA to
   update the "LISP Canonical Address Format (LCAF) Types" Registry
   defined in [RFC8060] to allocate the following assignment:

              +---------+---------------------+-------------+
              | Value # | LISP LCAF Type Name |  Reference  |
              +---------+---------------------+-------------+
              |   TBD   |         ILA         | Section 4.1 |
              +---------+---------------------+-------------+

                       Table 1: ILA LCAF assignment

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https://www.rfc-editor.org/info/rfc5226>.

   [RFC6740]  Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
              Protocol (ILNP) Architectural Description", RFC 6740,
              DOI 10.17487/RFC6740, November 2012,
              <https://www.rfc-editor.org/info/rfc6740>.

   [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, <https://www.rfc-editor.org/info/rfc6836>.

   [RFC8060]  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
              February 2017, <https://www.rfc-editor.org/info/rfc8060>.

   [RFC8111]  Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
              Smirnov, "Locator/ID Separation Protocol Delegated
              Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
              May 2017, <https://www.rfc-editor.org/info/rfc8111>.





Rodriguez-Natal, et al.  Expires October 7, 2018               [Page 19]

Internet-Draft                  ILA-LISP                      April 2018


11.2.  Informative References

   [CMS]      Cormode, G. and S. Muthukrishnan, "An improved data stream
              summary: the count-min sketch and its applications",
              Journal of Algorithms 55(1), 58-75, April 2005.

   [CMS-LISP]
              Almasan, P., Paillisse, J., Rodriguez-Natal, A., Barlet-
              Ros, P., Coras, F., Ermagan, V., Maino, F., and A.
              Cabellos-Aparicio, "Securing the Control-plane Channel and
              Cache of Pull-based ID/LOC Protocols", ArXiv
              e-prints 1803.08568, March 2018.

   [I-D.filsfils-spring-srv6-network-programming]
              Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d.,
              daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
              Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
              Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and
              M. Sharif, "SRv6 Network Programming", draft-filsfils-
              spring-srv6-network-programming-04 (work in progress),
              March 2018.

   [I-D.herbert-ila-ilamp]
              Herbert, T., "Identifier Locator Addressing Mapping
              Protocol", draft-herbert-ila-ilamp-00 (work in progress),
              December 2017.

   [I-D.herbert-intarea-ila]
              Herbert, T. and P. Lapukhov, "Identifier-locator
              addressing for IPv6", draft-herbert-intarea-ila-01 (work
              in progress), March 2018.

   [I-D.ietf-lisp-eid-mobility]
              Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
              F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
              Unified Control Plane", draft-ietf-lisp-eid-mobility-01
              (work in progress), November 2017.

   [I-D.ietf-lisp-rfc6830bis]
              Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
              Cabellos-Aparicio, "The Locator/ID Separation Protocol
              (LISP)", draft-ietf-lisp-rfc6830bis-12 (work in progress),
              March 2018.








Rodriguez-Natal, et al.  Expires October 7, 2018               [Page 20]

Internet-Draft                  ILA-LISP                      April 2018


   [I-D.ietf-lisp-rfc6833bis]
              Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
              "Locator/ID Separation Protocol (LISP) Control-Plane",
              draft-ietf-lisp-rfc6833bis-10 (work in progress), March
              2018.

   [I-D.ietf-lisp-sec]
              Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
              Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
              (work in progress), October 2017.

   [I-D.kouvelas-lisp-map-server-reliable-transport]
              Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J.
              Arango, "LISP Map Server Reliable Transport", draft-
              kouvelas-lisp-map-server-reliable-transport-04 (work in
              progress), September 2017.

   [I-D.lapukhov-bgp-ila-afi]
              Lapukhov, P., "Use of BGP for dissemination of ILA mapping
              information", draft-lapukhov-bgp-ila-afi-02 (work in
              progress), October 2016.

   [I-D.rodrigueznatal-lisp-pubsub]
              Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
              Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
              Boucadair, M., Jacquenet, C., and s.
              stefano.secci@lip6.fr, "Publish/Subscribe Functionality
              for LISP", draft-rodrigueznatal-lisp-pubsub-02 (work in
              progress), March 2018.

Authors' Addresses

   Alberto Rodriguez-Natal
   Cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: natal@cisco.com


   Vina Ermagan
   Cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: vermagan@cisco.com



Rodriguez-Natal, et al.  Expires October 7, 2018               [Page 21]

Internet-Draft                  ILA-LISP                      April 2018


   Fabio Maino
   Cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: fmaino@cisco.com


   Albert Cabellos
   Technical University of Catalonia
   Barcelona
   Spain

   Email: acabello@ac.upc.edu




































Rodriguez-Natal, et al.  Expires October 7, 2018               [Page 22]