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]
