LISP Delegated Mappings
draft-portoles-lisp-delegated-mappings-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Marc Portoles-Comeras , Balaji Venkatachalapathy , Sanjay Hooda | ||
| Last updated | 2025-10-17 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-portoles-lisp-delegated-mappings-00
Network Working Group M. Portoles
Internet-Draft B. Pitta
Intended status: Informational S. Hooda
Expires: 20 April 2026 Cisco Systems
17 October 2025
LISP Delegated Mappings
draft-portoles-lisp-delegated-mappings-00
Abstract
The LISP protocol with its inherent decoupling of control-plane and
data-plane, offers the flexibility to support modern networking
paradigms. This document specifies how to use the LISP protocol to
enable centralized onboarding and management of EIDs within a network
from an external controller or orchestration system.
Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 20 April 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Portoles, et al. Expires 20 April 2026 [Page 1]
Internet-Draft lisp-delegated-mappings October 2025
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 include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of terms . . . . . . . . . . . . . . . . . . . . . 3
3. General Procedures . . . . . . . . . . . . . . . . . . . . . 4
3.1. Reference System . . . . . . . . . . . . . . . . . . . . 4
3.2. Flow Sequence to distribute Delegated Mappings . . . . . 5
3.3. Distribution of Delegated Mappings . . . . . . . . . . . 6
3.4. Map-Server procedures . . . . . . . . . . . . . . . . . . 6
3.5. ETR procedures . . . . . . . . . . . . . . . . . . . . . 7
4. Message Extensions . . . . . . . . . . . . . . . . . . . . . 7
4.1. Map-Register . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Map-Notify . . . . . . . . . . . . . . . . . . . . . . . 8
5. Sending EID access information . . . . . . . . . . . . . . . 8
6. Implementation Considerations . . . . . . . . . . . . . . . . 10
6.1. Virtual Private Network Considerations . . . . . . . . . 10
6.2. EID Mobility Considerations . . . . . . . . . . . . . . . 11
6.3. Reliable Transport Considerations . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
As new compute system environments emerge, routing networks have been
adapting to serve their communication needs. In many of these cases,
network controllers or orchestration engines are used to organize
resources or enforce network policies in a centralized manner.
Examples of these types of systems range from wireless systems in
enterprise environments, Software-Defined Networks (SDN) (e.g., in
WAN, Datacenter, or Campus environments), and include public (or
private) cloud networks.
Portoles, et al. Expires 20 April 2026 [Page 2]
Internet-Draft lisp-delegated-mappings October 2025
In all these cases, it is common that a centralized controller or
orchestrator drives how endpoints authenticate, join, leave, or move
within the network. In many cases, this centralized controller is
also the point of reference that determines the policies that need to
be enforced.
Networks running the LISP protocol can exploit the vantage point of
these controllers for early and faster onboarding and movement of
endpoints at selected locations of the network. Controllers that
deploy or authenticate sites and endpoints can interface directly
with the Mapping System to distribute this information to selected
locations (xTRs).
This document specifies Delegated Mappings, where a controller can
use its interface to a LISP Mapping System to delegate ownership of
specific EIDs to selected xTRs of the network. The document provides
a detailed description of the mechanisms used to distribute this type
of mappings in a network running the LISP protocol.
In particular, the specification describes:
* How a controller may use the LISP Map-Register and Map-Notify
interfaces to distribute Delegated Mappings to LISP sites that
should take ownership of specific EIDs.
* The procedures that an ETR follows to take ownership of a
Delegated Mapping so that an EID can be resolved using LISP
protocol procedures.
* Finally, it also details how the controller can make use of
specific LCAF encodings such as ELPs and multiple data-planes (see
[RFC8060]), to convey EID access information to the corresponding
ETR.
Note also that Delegated Mappings can be combined with the procedures
specified in [I-D.ietf-lisp-eid-mobility] to support controller-based
mobility in a network running the LISP protocol.
2. Definition of terms
The document uses the terms defined in Section 3 of documents
[RFC9300] and [RFC9301].
Additionally, this document introduces the following terms:
Delegated Mapping: This is the term used in this document to
Portoles, et al. Expires 20 April 2026 [Page 3]
Internet-Draft lisp-delegated-mappings October 2025
identify a Mapping record registered with the Mapping system so
that it is relayed (delegated) to a corresponding xTR (or xTRs) of
a LISP site.
xTR-Controller: This term designates a network element that uses
Delegated Mappings to distribute EID records to the corresponding
LISP sites where they are connected to.
3. General Procedures
3.1. Reference System
Figure 1 illustrates a reference system model used to support the
discussion of Delegated Mappings through this section.
------------
| xTR |
| Controller |------------,
| | |
------------ |
+----+----+
| Map |
| Server |
+----+----+
_..-._.--._..._.,.-|._._.-._.-_._.-..
.-.' '.-.
( )
( )
'.-..-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-.'
| |
RLOC=IP_A RLOC=IP_B
+-+--+--+ +-+--+--+
.| xTR A |.-. .| xTR B |.-.
( +-+--+--+ ) ( +-+--+--+ )
.' Site A ) .' Site B )
( . ( .
'--'._.'. ) '--'._.'. )
| '--' | '--'
'--------' '--------'
: Host 1 : : Host 2 :
'--------' '--------'
IP: 10.0.0.1 IP: 10.1.1.2
Figure 1: Reference System Architecture with delegated Mappings
A xTR-controller implements LISP control-plane interfaces so that it
can interact with the LISP Mapping System, represented with a single
Map-Server in the figure. The interconnection between the xTR-
Portoles, et al. Expires 20 April 2026 [Page 4]
Internet-Draft lisp-delegated-mappings October 2025
controller and the Map-Server is out of the scope of this
specification, but the Map-Server MUST be able to handle Map
Registration procedures through this connection.
The network running the LISP protocol has two sites (A and B) with
the corresponding xTRs providing access to them. There is a local
endpoint on each one of the sites (host 1 and 2)
For the purpose of this specification the xTR-Controller knows when
endpoints are connected, authenticated or released from each one of
the sites. The controller is also aware of the xTRs (and their
corresponding RLOC addresses) that provide access to each one of the
sites.
3.2. Flow Sequence to distribute Delegated Mappings
When a xTR-Controller attempts to use the process of Delegated
Mappings to distribute EID Mappings to target LISP sites, it MUST
know beforehand the RLOCs of the xTRs providing access to those
sites. Using Figure 1 as reference, the xTR-controller knows that
IP_A is the RLOC of xTR A, associated to site A.
Using this information, the xTR-controller uses Delegated Mappings to
distribute information about Host 1 to Site A using the following
procedures:
1. The xTR-Controller builds a Map-Register with the EID record
information it wants to distribute. The Map-Register carries the
Delegated Mapping (D) bit set (see Section 4). Using the
reference example, the xTR-Controller sends a Map-Register to the
Map-Server that carries the EID-to-RLOC mapping of EID=<10.0.0.1>
-> RLOC=IP_A and is built with the D-bit set.
2. When a Map-Server receives a Map-Register with the D-bit set, it
prepares a Map-Notify with the same EID record that also has the
D-bit set. This Map-Notify is sent to all the RLOCs in the RLOC
record of the Mapping. Following the example, the Map-Server
sends a Map-Notify with the D-bit set to IP_A (RLOC of xTR A).
3. When an ETR receives a Map-Notify with the D-bit set, it verifies
that its own RLOC is in the RLOC record of the Mapping in the
message. When that is the case, the ETR creates an entry for the
EID in its database mapping. Continuing with the example, xTR A
receives the Map-Notify with the D-bit set and learns that
EID=<10.0.0.1> is local to site A.
Portoles, et al. Expires 20 April 2026 [Page 5]
Internet-Draft lisp-delegated-mappings October 2025
4. Once the ETR verifies the presence of the EID in the site, it
confirms the EID with a new Map-Register to the Map-Server. This
is a regular Map-Register, without the D-bit and marked as
authoritative. In the example the ETR sends an authoritative
Map-Register with EID-to-RLOC mapping of EID=<10.0.0.1> ->
RLOC=IP_A.
This operation repeats for every EID and for every site that the xTR-
Controller wants to distribute information to.
3.3. Distribution of Delegated Mappings
The distribution of Delegated Mappings relies on the use of the D-bit
(see Section 4) both in the Map-Register and Map-Notify messages.
The xTR-Controller sending a Delegated Mapping MUST NOT set the
authoritative bit in the EID record. Only the site ETR, after
accepting a Delegated Mapping can set this bit when registering the
EID prefix.
Equally, a Map-Register carrying a Delegated Mapping MUST NOT have
the Proxy Map-Reply bit (P-bit) or the security-capable (S-bit) set.
Since the xTR-controller is not authoritative for the Mapping, it
cannot set either of these bits. Only the authoritative ETR for the
destination site can set these bits with its corresponding Map-
Register, when accepting the Delegated Mapping.
A Delegated Mapping can also be removed. In that case the xTR-
Controller MUST send the Map-Register with the D-bit and with a TTL
with value 0 in the EID record. This removal MUST carry the RLOC
record corresponding to the site that the Delegated Mapping is being
removed from. The Map-Notify with the D-bit set is sent to all the
RLOCs in the RLOC record with the same TTL of value 0.
3.4. Map-Server procedures
A Map-Server that supports Delegated Mappings, SHOULD send a Map-
Notify with the D-bit to all the RLOCs in the RLOC record of the
Delegated Mapping.
A Map-Server MAY record in its registration table a Delegated
Mapping, but it MUST NOT use a Delegated Mapping Record to send a
proxy Map-Reply in response to a Map-Request for the EID in the
Mapping. In such a case, the Map-Server MAY forward the Map-Request
to one of the RLOCs in the record, following [RFC9301].
Portoles, et al. Expires 20 April 2026 [Page 6]
Internet-Draft lisp-delegated-mappings October 2025
This restriction extends to the procedures described in [RFC9437]. A
Map-Server MUST NOT send Map-Notify with a Delegated Mapping as a
publication message for EID subscribers. Only the Map-Register from
the authoritative ETR can be published following LISP Publish/
Subscribe procedures.
In order to avoid periodic Map-Register and Map-Notification
messages, Delegated Mappings MAY be distributed using a reliable
transport as described in
[I-D.ietf-lisp-map-server-reliable-transport].
3.5. ETR procedures
When an ETR receives Map-Notify with a Delegated Mapping (D-bit set)
that carries its own RLOC in the RLOC record it SHOULD verify the
reachability of the EID in the site before accepting the mapping.
The verification process is out of scope of this document.
Once the Mapping is accepted the ETR adds the EID in its local
mapping database and it MUST send a Map-Register with the EID Record
setting the authoritative bit (A-bit).
The ETR MUST be able to follow procedures described in [RFC9300] and
[RFC9301] when handling EID records learned through the Delegated
Mapping procedure.
When the ETR receives a Map-Notify with a Delegated Mapping with a
TTL of value 0 it SHOULD remove the EID from the local mapping
database.
When the ETR receives a Delegated Mapping that does not carry its own
RLOC in the RLOC record it MUST follow the procedures described in
[I-D.ietf-lisp-eid-mobility] and handle this as a mobility event.
4. Message Extensions
This document proposes an extension of the Map-Register and Map-
Notify messages to carry the notion that a Mapping is being
distributed as a Delegated Mapping. This information is used by both
Map-Server and ETRs to implement the procedures described in this
specification.
4.1. Map-Register
The Map-Register header, as defined in [RFC9301] is extended with an
additional field, the Delegated Mapping bit (D-bit).
Portoles, et al. Expires 20 April 2026 [Page 7]
Internet-Draft lisp-delegated-mappings October 2025
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P|S|I|D| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D: This is the Delegated Mapping bit in the Map-Register header. It
should be set to 1 when Map-Register messages carry Delegated
Mappings. When D-bit is set the P-bit and S-bit MUST be 0.
4.2. Map-Notify
a
The Map-Notify header, as defined in [RFC9301], is extended with an
additional field, the Delegated Mapping bit.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=4 |D| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D: This is the Delegated Mapping bit in the Map-Notify header. It
should be set to 1 when the Map-Notify message carries a Delegated
Mapping.
5. Sending EID access information
In many cases a controller using Delegated Mappings needs to convey
EID access information to the ETRs that receive the EID record. This
access information indicates what is the path that the ETR can take
to reach the EID within the local site.
As a reference example, if we take site B in the reference system,
Figure 2 illustrates the case when there is an intermediate router
(r) between xTR B and Host 2. In this example xTR B must route
traffic through the intermediate router to reach the endpoint:
Portoles, et al. Expires 20 April 2026 [Page 8]
Internet-Draft lisp-delegated-mappings October 2025
|
RLOC=IP_B
+-+--+--+
| xTR B |
+-+--+--+
|
(IP_r)
+-+--+--+
| r |
+-+--+--+
|
'--------'
: Host 2 :
'--------'
IP: 10.1.1.2
Figure 2: routed EID reachability in site B
A xTR-Controller MAY use ELPs (LCAF type 10 in [RFC8060]) in
Delegated Mappings to convey information to the ETR about how to
access the EID, when required. The ETR can use this information to
program a forwarding path to the EID and also to verify reachability
of the EID before accepting a Delegated Mapping.
The First locator in the ELP sequence MUST correspond to the RLOC of
the ETR and the rest of locators MUST correspond to the sequence of
hops that the ETR should follow to reach the EID.
It is worth noting also that local site reachability between the ETR
and the endpoint may not require encapsulation or alternative
encapsulations to the one used in the rest of the network. To solve
this case each locator in the ELP is sent using the Multiple Data-
Planes LCAF (Type 16 in [RFC8060]) and selecting the bit
corresponding to the encapsulation type. When no encapsulation is
needed Type 16 is also used but with all encapsulation bits set to 0.
In order to illustrate this, Figure 3 exemplifies the use of the ELP
and Multiple Data-Plane LCAFs for the figure above. In this
reference encoding, the ELP carries both the IP address of xTR B and
the intermediate router r. The IP of the intermmediate router is
disttribured indicating that no encapsulation is needed and xTR B can
access Host 2 routing packets through IP_r.
Portoles, et al. Expires 20 April 2026 [Page 9]
Internet-Draft lisp-delegated-mappings October 2025
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E | Locator Count | EID mask-len | ACT |A| Reserved |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D | Rsvd | Map-Version Number | EID-AFI = 1 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix (10.1.1.2) |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c /| Priority | Weight | M Priority | M Weight |
o | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r R | Unused Flags |L|p|R| AFI = 16387 |
d L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O | Rsvd1 | Flags | Type = 10 | Rsvd2 |
| C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Length | Rsvd3 |L|P|S|
| R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E | AFI = 1 or 2 | IP_B ~
| C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O ~ IP_B |
| R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| D | Rsvd3 |L|P|S| AFI = 16387 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E | Rsvd1 | Flags | Type = 16 | Rsvd2 |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P | Length | 0 ~
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ~ 0 | AFI = 1 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| IP_r |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
6. Implementation Considerations
Delegated Mappings can be used in environments running the LISP
protocol that implement VPN based segmentation ([I-D.ietf-lisp-vpn])
and EID mobility ([I-D.ietf-lisp-eid-mobility]).
6.1. Virtual Private Network Considerations
Delegated Mappings can be distributed using VPN segmentation
procedures, following the procedures described in
[I-D.ietf-lisp-vpn]. When the xTR-controller intents to distribute
EIDs within specific VPN segments, it MUST use the same IID that is
used in the target LISP site for that segment.
Portoles, et al. Expires 20 April 2026 [Page 10]
Internet-Draft lisp-delegated-mappings October 2025
Following the same procedures, a Map-Register and Map-Notify with the
D-bit set carry the XEID encoded using the Instance-id LCAF
([RFC8060]) in the EID record.
An ETR receiving a Map-Notify with the D-bit set and with an IID that
is not known or used, SHOULD ignore the Map-Notify.
It is NOT RECOMMENDED to use Delegated Mappings with extranet
encoding to distribute Mappings across IID boundaries. The Map-
Server SHOULD prevent this distribution.
6.2. EID Mobility Considerations
When Delegated Mappings are combined with the procedures of
[I-D.ietf-lisp-eid-mobility], a controller can be used to drive the
mobility of EIDs through the network.
A Map-Server that receives a Map-Register with the D-bit set, SHOULD
generate a Map-Notify with the D-bit set to all ETRs that have an
active registration of the Mapping.
When an ETR receives a Delegated Mapping with a RLOC record that does
not have any local RLOC on the ETR, it must treat the Mapping as a
mobility event and follow the procedures in
[I-D.ietf-lisp-eid-mobility]
6.3. Reliable Transport Considerations
Delegated Mappings can be distributed using a reliable transport as
described in [I-D.ietf-lisp-map-server-reliable-transport]. Since
both Map-Register and Map-Notify encodings are reuse when sending
Reliable Registrations and Reliable Notifications, the same D-bit is
used in this case to indicate the distribution of a Delegated
Mapping.
7. Security Considerations
Map-Register and Map-Notify messages MUST be authenticated following
the procedures specified in [RFC9301]. XTR-Controllers follow the
same procedures.
Map-Notify messages carrying Delegated Mappings are handled by ETRs
as unsolicited Map-Notify messages, following [RFC9301]. The Map-
Server MUST use the pre-shared key associated to the target Site of
the Delegated Mapping to authenticate the Map-Notify.
Portoles, et al. Expires 20 April 2026 [Page 11]
Internet-Draft lisp-delegated-mappings October 2025
8. IANA Considerations
This memo includes no request to IANA.
9. References
9.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>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>.
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
Ed., "Locator/ID Separation Protocol (LISP) Control
Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/info/rfc9301>.
[RFC9437] Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai,
S., and M. Boucadair, "Publish/Subscribe Functionality for
the Locator/ID Separation Protocol (LISP)", RFC 9437,
DOI 10.17487/RFC9437, August 2023,
<https://www.rfc-editor.org/info/rfc9437>.
9.2. Informative References
[I-D.ietf-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Maino, F., Moreno,
V., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", Work in Progress, Internet-Draft,
draft-ietf-lisp-eid-mobility-16, 8 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
eid-mobility-16>.
Portoles, et al. Expires 20 April 2026 [Page 12]
Internet-Draft lisp-delegated-mappings October 2025
[I-D.ietf-lisp-map-server-reliable-transport]
Venkatachalapathy, B., Portoles-Comeras, M., Lewis, D.,
Kouvelas, I., and C. Cassar, "LISP Map Server Reliable
Transport", Work in Progress, Internet-Draft, draft-ietf-
lisp-map-server-reliable-transport-07, 2 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
map-server-reliable-transport-07>.
[I-D.ietf-lisp-vpn]
Moreno, V. and D. Farinacci, "LISP Virtual Private
Networks (VPNs)", Work in Progress, Internet-Draft, draft-
ietf-lisp-vpn-12, 19 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
vpn-12>.
Authors' Addresses
Marc Portoles Comeras
Cisco Systems
170 Tasman Drive
San Jose, CA 95134
United States of America
Email: mportole@cisco.com
Balaji Pitta
Cisco Systems
Tasman Drive
San Jose, CA 95134
United States of America
Email: bvenkata@cisco.com
Sanjay Hooda
Cisco Systems
170 Tasman Drive
San Jose, California 95134
United States of America
Email: shooda@cisco.com
Portoles, et al. Expires 20 April 2026 [Page 13]