rfc9437.original   rfc9437.txt 
LISP Working Group A. Rodriguez-Natal Internet Engineering Task Force (IETF) A. Rodriguez-Natal
Internet-Draft Cisco Request for Comments: 9437 Cisco
Intended status: Standards Track V. Ermagan Category: Standards Track V. Ermagan
Expires: 1 September 2023 Google ISSN: 2070-1721 Google
A. Cabellos A. Cabellos
UPC/BarcelonaTech UPC/BarcelonaTech
S. Barkai S. Barkai
Nexar Nexar
M. Boucadair M. Boucadair
Orange Orange
28 February 2023 July 2023
Publish/Subscribe Functionality for the Locator/ID Separation Protocol Publish/Subscribe Functionality for the Locator/ID Separation Protocol
(LISP) (LISP)
draft-ietf-lisp-pubsub-15
Abstract Abstract
This document specifies an extension to the request/reply based This document specifies an extension to the Locator/ID Separation
Locator/ID Separation Protocol (LISP) control plane to enable Protocol (LISP) control plane to enable Publish/Subscribe (PubSub)
Publish/Subscribe (PubSub) operation. operation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 1 September 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9437.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Please review these documents carefully, as they describe your rights carefully, as they describe your rights and restrictions with respect
and restrictions with respect to this document. Code Components to this document. Code Components extracted from this document must
extracted from this document must include Revised BSD License text as include Revised BSD License text as described in Section 4.e of the
described in Section 4.e of the Trust Legal Provisions and are Trust Legal Provisions and are provided without warranty as described
provided without warranty as described in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Scope of Applicability . . . . . . . . . . . . . . . . . 4 1.1. Scope of Applicability
2. Terminology and Requirements Notation . . . . . . . . . . . . 4 2. Terminology and Requirements Notation
3. Deployment Requirements . . . . . . . . . . . . . . . . . . . 4 3. Deployment Requirements
4. Map-Request PubSub Additions . . . . . . . . . . . . . . . . 5 4. Map-Request PubSub Additions
5. Mapping Request Subscribe Procedures . . . . . . . . . . . . 6 5. Mapping Request Subscribe Procedures
6. Mapping Notification Publish Procedures . . . . . . . . . . . 11 6. Mapping Notification Publish Procedures
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations
7.1. Security Association between ITR and Map-Server . . . . . 12 7.1. Security Association between ITR and Map-Server
7.2. DDoS Attack Mitigation . . . . . . . . . . . . . . . . . 13 7.2. DDoS Attack Mitigation
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References
Appendix A. Sample PubSub Deployment Experiences . . . . . . . . 17 Appendix A. Sample PubSub Deployment Experiences
A.1. PubSub as a Monitoring Tool . . . . . . . . . . . . . . . 17 A.1. PubSub as a Monitoring Tool
A.2. Mitigating Negative Map-Cache Entries . . . . . . . . . . 17 A.2. Mitigating Negative Map-Cache Entries
A.3. Improved Mobility Latency . . . . . . . . . . . . . . . . 18 A.3. Improved Mobility Latency
A.4. Enhanced Reachability with Dynamic Redistribution of A.4. Enhanced Reachability with Dynamic Redistribution of
Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 18 Prefixes
A.5. Better Serviceability . . . . . . . . . . . . . . . . . . 19 A.5. Better Serviceability
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgments
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses
1. Introduction 1. Introduction
The Locator/ID Separation Protocol (LISP) [RFC9300] [RFC9301] splits The Locator/ID Separation Protocol (LISP) [RFC9300] [RFC9301] splits
IP addresses into two different namespaces: Endpoint Identifiers IP addresses into two different namespaces: Endpoint Identifiers
(EIDs) and Routing Locators (RLOCs). LISP uses a map and encapsulate (EIDs) and Routing Locators (RLOCs). LISP uses a map and encapsulate
(a.k.a., map-and-encap) approach that relies on (1) a Mapping System (a.k.a., map-and-encap) approach that relies on (1) a Mapping System
(basically a distributed database) that stores and disseminates EID- (basically a distributed database) that stores and disseminates EID-
RLOC mappings and on (2) LISP tunnel routers (xTRs) that encapsulate RLOC mappings and on (2) LISP Tunnel Routers (xTRs) that encapsulate
and decapsulate data packets based on the content of those mappings. and decapsulate data packets based on the content of those mappings.
Ingress Tunnel Routers (ITRs) / Re-encapsulating Tunnel Routers Ingress Tunnel Routers (ITRs), Re-encapsulating Tunnel Routers
(RTRs) / Proxy Ingress Tunnel Routers (PITRs) pull EID-to-RLOC (RTRs), and Proxy Ingress Tunnel Routers (PITRs) pull EID-to-RLOC
mapping information from the Mapping System by means of an explicit mapping information from the Mapping System by means of an explicit
request message. Section 6.1 of [RFC9301] indicates how Egress request message. Section 6.1 of [RFC9301] indicates how Egress
Tunnel Routers (ETRs) can tell ITRs/RTRs/PITRs about mapping changes. Tunnel Routers (ETRs) can tell ITRs/RTRs/PITRs about mapping changes.
This document presents a Publish/Subscribe (PubSub) extension in This document presents a Publish/Subscribe (PubSub) extension in
which the Mapping System can notify ITRs/RTRs/PITRs about mapping which the Mapping System can notify ITRs/RTRs/PITRs about mapping
changes. When this mechanism is used, mapping changes can be changes. When this mechanism is used, mapping changes can be
notified faster and can be managed in the Mapping System versus the notified faster and can be managed in the Mapping System versus the
LISP sites. LISP sites.
In general, when an ITR/RTR/PITR wants to be notified for mapping In general, when an ITR/RTR/PITR wants to be notified for mapping
changes for a given EID-Prefix, the following main steps occur: changes for a given EID-Prefix, the following main steps occur:
(1) The ITR/RTR/PITR builds a Map-Request for that EID-Prefix with 1. The ITR/RTR/PITR builds a Map-Request for that EID-Prefix with
the Notification-Requested bit (N-bit) set and which also the Notification-Requested bit (N-bit) set and that also includes
includes its xTR-ID and Site-ID. its xTR-ID and Site-ID.
(2) The Map-Request is forwarded to one of the Map-Servers that the 2. The Map-Request is forwarded to one of the Map-Servers that the
EID-Prefix is registered to. EID-Prefix is registered to.
(3) The Map-Server creates subscription state for the ITR/RTR/PITR 3. The Map-Server creates subscription state for the ITR/RTR/PITR on
on the EID-Prefix. the EID-Prefix.
(4) The Map-Server sends a Map-Notify to the ITR/RTR/PITR to confirm 4. The Map-Server sends a Map-Notify to the ITR/RTR/PITR to confirm
that the subscription has been created and then waits for an that the subscription has been created and then waits for an
acknowledgement of the notification. acknowledgement of the notification.
(5) The ITR/RTR/PITR sends back a Map-Notify-Ack to acknowledge the 5. The ITR/RTR/PITR sends back a Map-Notify-Ack to acknowledge the
successful receipt of the Map-Notify. successful receipt of the Map-Notify.
(6) When there is a change in the mapping of the EID-Prefix, the 6. When there is a change in the mapping of the EID-Prefix, the Map-
Map-Server sends a Map-Notify message to each ITR/RTR/PITR in Server sends a Map-Notify message to each ITR/RTR/PITR in the
the subscription list. subscription list.
(7) Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the 7. Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the
received Map-Notify. received Map-Notify.
This operation is repeated for all EID-Prefixes for which ITRs/RTRs/ This operation is repeated for all EID-Prefixes for which ITRs/RTRs/
PITRs want to be notified. An ITR/RTR/PITR can set the N-bit for PITRs want to be notified. An ITR/RTR/PITR can set the N-bit for
several EID-Prefixes within a single Map-Request. Please note that several EID-Prefixes within a single Map-Request. Please note that
the steps above illustrate only the simplest scenario and that the steps above illustrate only the simplest scenario and that
details for this and other scenarios are described later in the details for this and other scenarios are described later in the
document. document.
The reader may refer to [I-D.boucadair-lisp-pubsub-flow-examples] for The reader may refer to [FLOW-EXAMPLES] for sample flows to
sample flows to illustrate the use of the PubSub specification. illustrate the use of the PubSub specification.
1.1. Scope of Applicability 1.1. Scope of Applicability
The PubSub procedure specified in this document is intended to be The PubSub procedure specified in this document is intended for use
used in contexts with controlled access to the Map-Server. How a in contexts with controlled access to the Map-Server. How a
deployment controls access to a Map-Server is deployment specific, deployment controls access to a Map-Server is deployment specific and
and therefore out of the scope of this document. However, the Map- therefore out of the scope of this document. However, the Map-
Resolvers and Map-Servers need to be configured with the required Resolvers and Map-Servers need to be configured with the required
information to at least ensure the following: information to ensure at least the following:
(1) Map-Resolvers MUST verify that an xTR is allowed to (1) set the 1. Map-Resolvers MUST verify that an xTR is allowed to (1) set the
N-bit to 1 and (2) use the xTR-ID, Site-ID, and ITR-RLOCs N-bit to 1 and (2) use the xTR-ID, Site-ID, and ITR-RLOCs
included in a Map-Request. included in a Map-Request.
(2) Map-Servers MUST only accept subscription requests from Map- 2. Map-Servers MUST only accept subscription requests from Map-
Resolvers that verify Map-Requests as previously described. Resolvers that verify Map-Requests as previously described.
2. Terminology and Requirements Notation 2. Terminology and Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The document uses the terms defined in Section 3 of [RFC9300]. The document uses the terms defined in Section 3 of [RFC9300].
3. Deployment Requirements 3. Deployment Requirements
In addition to the general assumptions and expectations that In addition to the general assumptions and expectations that
[RFC9301] makes for LISP deployments, this document makes the [RFC9301] makes for LISP deployments, this document imposes the
following deployment requirements: following deployment requirements:
(1) A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is 1. A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is
assigned to each xTR. assigned to each xTR.
(2) Map-Servers are configured to proxy Map-Replying (i.e., they are 2. Map-Servers are configured to proxy Map-Replying (i.e., they are
solicited to generate and send Map-Reply messages) for the solicited to generate and send Map-Reply messages) for the
mappings they are serving. mappings they are serving.
(3) A security association (e.g., a PubSubKey) is required between 3. A security association (e.g., a PubSubKey) is required between
the ITRs and the Map-Servers (see Section 7.1). the ITRs and the Map-Servers (see Section 7.1).
If a requirement is not met, a subscription cannot be established, If a requirement is not met, a subscription cannot be established,
and the network will continue operating without this enhancement. and the network will continue operating without this enhancement.
The configuration of xTR-IDs and Site-IDs is out of the scope of this The configuration of xTR-IDs and Site-IDs is out of the scope of this
document. The reader may refer to [I-D.ietf-lisp-yang] for an document. The reader may refer to [LISP-YANG] for an example of how
example of how these identifiers can be provisioned to LISP nodes. these identifiers can be provisioned to LISP nodes.
4. Map-Request PubSub Additions 4. Map-Request PubSub Additions
Figure 1 shows the format of the updated Map-Request to support the Figure 1 shows the format of the updated Map-Request to support the
PubSub functionality. In particular, this document associates a PubSub functionality. In particular, this document associates a
meaning with one of the reserved bits (see Section 8). meaning with one of the reserved bits (see Section 8).
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 52 skipping to change at line 232
| | | |
+ Site-ID + + Site-ID +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Map-Request with I-bit, N-bit, xTR-ID, and Site-ID Figure 1: Map-Request with I-bit, N-bit, xTR-ID, and Site-ID
The following is added to the Map-Request message defined in The following is added to the Map-Request message defined in
Section 5.2 of [RFC9301]: Section 5.2 of [RFC9301]:
xTR-ID bit (I-bit): This bit is set to 1 to indicate that 128-bit xTR-ID bit (I-bit): This bit is set to 1 to indicate that 128-bit
xTR-ID and 64-bit Site-ID fields are present in the Map-Request xTR-ID and 64-bit Site-ID fields are present in the Map-Request
message. For PubSub operation, an xTR MUST be configured with an message. For PubSub operation, an xTR MUST be configured with an
xTR-ID and Site-ID, and it MUST set the I-bit to 1 and include its xTR-ID and Site-ID, and it MUST set the I-bit to 1 and include its
xTR-ID and Site-ID in the Map-Request messages it generates. If xTR-ID and Site-ID in the Map-Request messages it generates. If
the I-bit is set, but the Site-ID and/or xTR-ID are not included, the I-bit is set but the Site-ID and/or xTR-ID are not included, a
a receiver can detect the error because, after processing that receiver can detect the error because, after processing that last
last EID-record, there are no bytes left from processing the EID-Record, there are no bytes left from processing the message.
message. In this case, the receiver SHOULD log a malformed Map- In this case, the receiver SHOULD log a malformed Map-Request and
Request and MUST drop the message. MUST drop the message.
Notification-Requested bit (N-bit): The N-bit of an EID-Record is Notification-Requested bit (N-bit): The N-bit of an EID-Record is
set to 1 to specify that the xTR wants to be notified of updates set to 1 to specify that the xTR wants to be notified of updates
for that EID-Prefix. for that EID-Prefix.
xTR-ID field: If the I-bit is set, this field is added to the Map- xTR-ID field: If the I-bit is set, this field is added to the Map-
Request message as shown in Figure 1, starting right after the Request message as shown in Figure 1, starting right after the
final Record in the message (or the Map-Reply Record, if present). final Record in the message (or the Map-Reply Record, if present).
The xTR-ID is specified in Section 5.6 of [RFC9301]. The xTR-ID is specified in Section 5.6 of [RFC9301].
Site-ID field: If the I-bit is set, this field is added to the Site-ID field: If the I-bit is set, this field is added to the Map-
Map-Request message as shown in Figure 1, following the xTR-ID Request message as shown in Figure 1, following the xTR-ID field.
field. The Site-ID is defined in Section 5.6 of [RFC9301]. The Site-ID is defined in Section 5.6 of [RFC9301].
5. Mapping Request Subscribe Procedures 5. Mapping Request Subscribe Procedures
The xTR subscribes for changes, to a given EID-Prefix, by sending a The xTR subscribes for changes to a given EID-Prefix by sending a
Map-Request to the Mapping System with the N-bit set on the EID- Map-Request to the Mapping System with the N-bit set on the EID-
Record. The xTR builds a Map-Request according to Section 5.3 of Record. The xTR builds a Map-Request according to Section 5.3 of
[RFC9301] but also does the following: [RFC9301] and also does the following:
(1) The xTR MUST set the I-bit to 1 and append its xTR-ID and Site- 1. The xTR MUST set the I-bit to 1 and append its xTR-ID and Site-ID
ID to the Map-Request. to the Map-Request.
(2) The xTR MUST set the N-bit to 1 for the EID-Record to which the 2. The xTR MUST set the N-bit to 1 for the EID-Record to which the
xTR wants to subscribe. xTR wants to subscribe.
(3) If the xTR has a nonce associated with the EID-Prefix, it MUST 3. If the xTR has a nonce associated with the EID-Prefix, it MUST
use this nonce increased by one in the Map-Request. Otherwise, use this nonce increased by one in the Map-Request. Otherwise,
it generates a nonce following Section 5.2 of [RFC9301]. It is it generates a nonce as described in Section 5.2 of [RFC9301].
RECOMMENDED that the xTR uses persistent storage to keep nonce It is RECOMMENDED that the xTR use persistent storage to keep
state. If the xTR does not have persistent storage and does not nonce state. If the xTR does not have persistent storage and
have a nonce associated with the EID-Prefix, it MUST reset the does not have a nonce associated with the EID-Prefix, it MUST
nonce by using the procedure described in Section 7.1 to reset the nonce by using the procedure described in Section 7.1
successfully create a new security association with the Map- to successfully create a new security association with the Map-
Server. Server.
The Map-Request is forwarded to the appropriate Map-Server through The Map-Request is forwarded to the appropriate Map-Server through
the Mapping System. This document does not assume that a Map-Server the Mapping System. This document does not assume that a Map-Server
is pre-assigned to handle the subscription state for a given xTR. is pre-assigned to handle the subscription state for a given xTR.
The Map-Server that receives the Map-Request will be the Map-Server The Map-Server that receives the Map-Request will be the Map-Server
responsible for notifying that specific xTR about future mapping responsible for notifying that specific xTR about future mapping
changes for the subscribed mapping records. changes for the subscribed mapping records.
Upon receipt of the Map-Request, the Map-Server processes it as Upon receipt of the Map-Request, the Map-Server processes it as
described in Section 8.3 of [RFC9301]. In addition, unless the xTR described in Section 8.3 of [RFC9301]. In addition, unless the xTR
skipping to change at page 7, line 27 skipping to change at line 301
with the xTR-ID (and EID-Prefix, when applicable). Otherwise, the with the xTR-ID (and EID-Prefix, when applicable). Otherwise, the
Map-Server MUST silently drop the Map-Request message and SHOULD log Map-Server MUST silently drop the Map-Request message and SHOULD log
the event to record that a replay attack could have occurred. the event to record that a replay attack could have occurred.
Furthermore, upon processing, for the EID-Record that has the N-bit Furthermore, upon processing, for the EID-Record that has the N-bit
set to 1, the Map-Server proceeds to add the xTR-ID contained in the set to 1, the Map-Server proceeds to add the xTR-ID contained in the
Map-Request to the list of xTRs that have requested to be subscribed Map-Request to the list of xTRs that have requested to be subscribed
to that EID-Prefix. to that EID-Prefix.
If an xTR-ID is successfully added to the list of subscribers for an If an xTR-ID is successfully added to the list of subscribers for an
EID-Prefix, the Map-Server MUST extract the nonce and ITR-RLOCs EID-Prefix, the Map-Server MUST extract the nonce and ITR-RLOCs
present in the Map-Request, and store the association between the present in the Map-Request and store the association between the EID-
EID-Prefix, xTR-ID, ITR-RLOCs, and nonce. Any already present state Prefix, xTR-ID, ITR-RLOCs, and nonce. Any state that is already
regarding ITR-RLOCs and/or nonce for the same xTR-ID MUST be present regarding ITR-RLOCs and/or nonce for the same xTR-ID MUST be
overwritten. When the LISP deployment has a single Map-Server, the overwritten. When the LISP deployment has a single Map-Server, the
Map-Server can be configured to keep a single nonce per xTR-ID for Map-Server can be configured to keep a single nonce per xTR-ID for
all EID-Prefixes (when used, this option MUST be enabled at the Map- all EID-Prefixes (when used, this option MUST be enabled at the Map-
Server and all xTRs). Server and all xTRs).
If the xTR-ID is added to the list, the Map-Server MUST send a Map- If the xTR-ID is added to the list, the Map-Server MUST send a Map-
Notify message back to the xTR to acknowledge the successful Notify message back to the xTR to acknowledge the successful
subscription. The Map-Server builds the Map-Notify according to subscription. The Map-Server builds the Map-Notify according to
Sections 5.5 and 5.7 of [RFC9301] with the following considerations: Sections 5.5 and 5.7 of [RFC9301] with the following considerations:
(1) The Map-Server MUST use the nonce from the Map-Request as the 1. The Map-Server MUST use the nonce from the Map-Request as the
nonce for the Map-Notify. nonce for the Map-Notify.
(2) The Map-Server MUST use its security association with the xTR 2. The Map-Server MUST use its security association with the xTR
(Section 7.1) to sign the authentication data of the Map-Notify. (Section 7.1) to sign the authentication data of the Map-Notify.
The xTR MUST use the security association to verify the received The xTR MUST use the security association to verify the received
authentication data. authentication data.
(3) The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs 3. The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs
received in the Map-Request (which one is implementation received in the Map-Request (which one is implementation
specific). specific).
As a reminder, the initial transmission and retransmission of Map- As a reminder, the initial transmission and retransmission of Map-
Notify messages by a Map-Server follow the procedure specified in Notify messages by a Map-Server follow the procedure specified in
Section 5.7 of [RFC9301]. Some state changes may trigger an overload Section 5.7 of [RFC9301]. Some state changes may trigger an overload
that would impact, e.g., the outbound capacity of a Map-Server. A that would impact, e.g., the outbound capacity of a Map-Server. A
similar problem may be experienced when a large number of state similar problem may be experienced when a large number of state
entries are simultaneously updated. To prevent such phenomena, Map- entries are simultaneously updated. To prevent such phenomena, Map-
Servers SHOULD be configured with policies to control the maximum Servers SHOULD be configured with policies to control the maximum
number of subscriptions and also the pace of Map-Notify messages. number of subscriptions and also the pace of Map-Notify messages.
For example, the Map-Server may be instructed to limit the resources For example, the Map-Server may be instructed to limit the resources
skipping to change at page 8, line 25 skipping to change at line 346
fraction (e.g., less than 10%) of its overall processing and fraction (e.g., less than 10%) of its overall processing and
forwarding capacity. The exact details to characterize such policies forwarding capacity. The exact details to characterize such policies
are deployment and implementation specific. Likewise, this document are deployment and implementation specific. Likewise, this document
does not specify which notifications take precedence when these does not specify which notifications take precedence when these
policies are enforced. policies are enforced.
When the xTR receives a Map-Notify with a nonce that matches one in When the xTR receives a Map-Notify with a nonce that matches one in
the list of outstanding Map-Request messages sent with an N-bit set, the list of outstanding Map-Request messages sent with an N-bit set,
it knows that the Map-Notify is to acknowledge a successful it knows that the Map-Notify is to acknowledge a successful
subscription. The xTR processes this Map-Notify, as described in subscription. The xTR processes this Map-Notify, as described in
Section 5.7 of [RFC9301], and MUST use the Map-Notify to populate its Section 5.7 of [RFC9301] and MUST use the Map-Notify to populate its
Map-Cache with the returned EID-Prefix and RLOC-set. As a reminder, Map-Cache with the returned EID-Prefix and RLOC-set. As a reminder,
following Section 5.7 of [RFC9301], the xTR has to send a Map-Notify- following Section 5.7 of [RFC9301], the xTR has to send a Map-Notify-
Ack back to the Map-Server. If the Map-Server does not receive the Ack back to the Map-Server. If the Map-Server does not receive the
Map-Notify-Ack after exhausting the Map-Notify retransmissions Map-Notify-Ack after exhausting the Map-Notify retransmissions
described in Section 5.7 of [RFC9301], the Map-Server can remove the described in Section 5.7 of [RFC9301], the Map-Server can remove the
subscription state. If the Map-Server removes the subscription subscription state. If the Map-Server removes the subscription
state, and absent explicit policy, it SHOULD notify the xTR by state, and absent explicit policy, it SHOULD notify the xTR by
sending a single Map-Notify with the same nonce but with Loc-Count = sending a single Map-Notify with the same nonce but with Loc-Count =
0 (and Loc-AFI = 0), and ACT bits set to 5 "Drop/Auth-Failure". It 0 (and Loc-AFI = 0) and ACT bits set to 5 "Drop/Auth-Failure". It is
is OPTIONAL for the xTR to update its map-cache entry for the EID- OPTIONAL for the xTR to update its Map-Cache entry for the EID-Prefix
Prefix (if any) based on this Map-Notify. This message is (if any) based on this Map-Notify. This message is specifically
specifically useful for cases where Map-Notifies are successfully useful for cases where Map-Notifies are successfully received by an
received by an xTR but the corresponding Map-Notify-Acks were lost xTR, but the corresponding Map-Notify-Acks are lost when forwarded to
when forwarded to the Map-Server. xTR implementations can use this the Map-Server. xTR implementations can use this signal to try to
signal to try to reinstall their subscription state instead of reinstall their subscription state instead of maintaining stale
maintaining stale mappings. mappings.
The subscription of an xTR-ID may fail for a number of reasons. For The subscription of an xTR-ID may fail for a number of reasons. For
example, it fails because of local configuration policies (such as example, it fails because of local configuration policies (such as
accept and drop lists of subscribers), because the Map-Server has accept and drop lists of subscribers), because the Map-Server has
exhausted the resources to dedicate to the subscription of that EID- exhausted the resources to dedicate to the subscription of that EID-
Prefix (e.g., the number of subscribers excess the capacity of the Prefix (e.g., the number of subscribers excess the capacity of the
Map-Server), or because the xTR tried but was not successful in Map-Server), or because the xTR was not successful tried but was not
establishing a new security association (Section 7.1). successful in establishing a new security association (Section 7.1).
If the subscription request fails, the Map-Server sends a Map-Reply If the subscription request fails, the Map-Server sends a Map-Reply
to the originator of the Map-Request, as described in Section 8.3 of to the originator of the Map-Request, as described in Section 8.3 of
[RFC9301], with the following considerations: [RFC9301], with the following considerations:
* If the subscription request fails due to policy (e.g. for * If the subscription request fails due to policy (e.g., for
explicitly configured subscriptions, as described later in this explicitly configured subscriptions, as described later in this
section) the Map-Server MUST respond to the Map-Request with a section), the Map-Server MUST respond to the Map-Request with a
Negative Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT bits Negative Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT bits
set to 4 "Drop/Policy-Denied". set to 4 "Drop/Policy-Denied".
* If the subscription request fails due to authentication (e.g. when * If the subscription request fails due to authentication (e.g.,
a new security associationg is being established, as described in when a new security association is being established, as described
Section 7.1), the Map-Server MUST respond to the Map-Request with in Section 7.1), the Map-Server MUST respond to the Map-Request
a Negative Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT bits with a Negative Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT
set to 5 "Drop/Auth-Failure". bits set to 5 "Drop/Auth-Failure".
* If the subscription request fails due to any other reason, the * If the subscription request fails due to any other reason, the
Map-Server MUST follow Section 8.3 of [RFC9301] with no changes. Map-Server MUST follow Section 8.3 of [RFC9301] with no changes.
The xTR processes any (Negative) Map-Reply as specified in The xTR processes any Map-Reply or Negative Map-Reply as specified in
Section 8.1 of [RFC9301], with the following considerations: if the Section 8.1 of [RFC9301], with the following considerations: if the
xTR receives a Negative Map-Reply with ACT bits set to 4 "Drop/ xTR receives a Negative Map-Reply with ACT bits set to 4 "Drop/
Policy-Denied" or 5 "Drop/Auth-Failure" as a response to a Policy-Denied" or 5 "Drop/Auth-Failure" as a response to a
subscription request, it is OPTIONAL for the xTR to update its map- subscription request, it is OPTIONAL for the xTR to update its Map-
cache entry for the EID-Prefix (if any) based on this Negative Map- Cache entry for the EID-Prefix (if any). If the subscription request
Reply. If the subscription request fails (for whichever reason), it fails (for whichever reason), it is up to the implementation of the
is up to the implementation of the xTR to try to subscribe again. xTR to try to subscribe again.
If the Map-Server receives a subscription request for an EID-Prefix If the Map-Server receives a subscription request for an EID-Prefix
not present in the mapping database, it SHOULD follow the same logic not present in the mapping database, it SHOULD follow the same logic
described in Section 8.4 of [RFC9301] and create a temporary described in Section 8.4 of [RFC9301] and create a temporary
subscription state for the xTR-ID to the least-specific prefix that subscription state for the xTR-ID to the least specific prefix that
both matches the original query and does not match any EID-Prefix both matches the original query and does not match any EID-Prefix
known to exist in the LISP-capable infrastructure. Alternatively, known to exist in the LISP-capable infrastructure. Alternatively,
the Map-Server can instead determine that such a subscription request the Map-Server can determine that such a subscription request fails
fails, and send a Negative Map-Reply following Section 8.3 of and send a Negative Map-Reply following Section 8.3 of [RFC9301]. In
[RFC9301]. In both cases, the TTL of the temporary subscription both cases, the TTL of the temporary subscription state or the
state or the Negative Map-Reply SHOULD be configurable, with a value Negative Map-Reply SHOULD be configurable, with a value of 15 minutes
of 15-minutes being RECOMMENDED. being RECOMMENDED.
The subscription state can also be created explicitly by The subscription state can also be created explicitly by
configuration at the Map-Server (possible when a pre-shared security configuration at the Map-Server (possible when a pre-shared security
association exists, see Section 7) using a variety of means that are association exists, see Section 7) using a variety of means that are
out of scope. If at the time the explicit subscription is configured outside the scope of this document. If there is no nonce that can be
there is no nonce that can be used for the explicit subscription used for the explicit subscription state at the time the explicit
state (e.g., from a different subscription already established with subscription is configured (e.g., from a different subscription
the same xTR when a single nonce is kept per xTR-ID), then both the already established with the same xTR when a single nonce is kept per
xTR and Map-Server MUST be configured with the initial nonce to use. xTR-ID), then both the xTR and Map-Server MUST be configured with the
initial nonce. RECOMMENDED to have a configuration option to enable
It is RECOMMENDED to have a configuration option to enable (or (or disable) the xTR to accept publication information for EID-
disable) the xTR to accept publication information for EID-Prefixes Prefixes that the xTR did not explicitly subscribe to. By default,
the xTR did not explicitly subscribe to. By default, the xTR is the xTR is allowed to modify explicitly configured subscription state
allowed to modify explicitly configured subscription state following following the procedures described in this section; however, this MAY
the procedures described in this section, however this MAY be be disabled at the Map-Server via configuration. If the Map-Server
disabled at the Map-Server via configuration. If the Map-Server is is instructed to not allow xTRs to modify explicitly configured
instructed to not allow xTRs to modify explicitly configured
subscriptions, and an xTR tries to do so, this triggers a Negative subscriptions, and an xTR tries to do so, this triggers a Negative
Map-Reply with ACT bits set to 4 "Drop/Policy-Denied" as described Map-Reply with ACT bits set to 4 "Drop/Policy-Denied" as described
earlier in this section. earlier in this section.
The following specifies the procedure to remove a subscription: If a The following specifies the procedure to remove a subscription:
valid Map-Request with the N-bit set to 1 only has one ITR-RLOC with
AFI = 0 (i.e., Unknown Address), the Map-Server MUST remove the * If a valid Map-Request with the N-bit set to 1 only has one ITR-
subscription state for that xTR-ID (unless this is disabled via RLOC with AFI = 0 (i.e., Unknown Address), the Map-Server MUST
configuration, see previous paragraph). If the subscription state is remove the subscription state for that xTR-ID (unless this is
removed, the Map-Server MUST send a Map-Notify to the source RLOC of disabled via configuration, see previous paragraph).
the Map-Request. If the subscription removal fails due to
configuration, this triggers a Negative Map-Reply with with ACT bits * If the subscription state is removed, the Map-Server MUST send a
set to 4 "Drop/Policy-Denied" as described earlier in this section; Map-Notify to the source RLOC of the Map-Request.
the Map-Server sends the Negative Map-Reply to the source RLOC of the
Map-Request in this case. Removing subscription state at the Map- * If the subscription removal fails due to configuration, this
Server can lead to replay attacks. To soften this, the Map-Server triggers a Negative Map-Reply with ACT bits set to 4 "Drop/Policy-
SHOULD keep the last nonce seen per xTR-ID (and EID-Prefix, when Denied" as described earlier in this section; the Map-Server sends
applicable). If the Map-Server does not keep last nonces seen, then the Negative Map-Reply to the source RLOC of the Map-Request in
the Map-Server MUST require the xTRs to subscribe using the procedure this case.
described in Section 7.1 to create a new security association with
the Map-Server. * Removing subscription state at the Map-Server can lead to replay
attacks. To soften this, the Map-Server SHOULD keep the last
nonce seen per xTR-ID (and EID-Prefix, when applicable).
* If the Map-Server does not keep the last nonces seen, then the
Map-Server MUST require the xTRs to subscribe using the procedure
described in Section 7.1 to create a new security association with
the Map-Server.
If the Map-Server receives a Map-Request asking to remove a If the Map-Server receives a Map-Request asking to remove a
subscription for an EID-Prefix without subscription state for that subscription for an EID-Prefix without subscription state for that
xTR-ID, but covered by a less-specific EID-Prefix for which xTR-ID and the EID-Prefix is covered by a less-specific EID-Prefix
subscription state exists for the xTR-ID, the Map-Server SHOULD stop for which subscription state exists for the xTR-ID, the Map-Server
publishing updates about this more-specific EID-Prefix to that xTR, SHOULD stop publishing updates about this more-specific EID-Prefix to
until the xTR subscribes to the more-specific EID-Prefix. The same that xTR until the xTR subscribes to the more-specific EID-Prefix.
considerations regarding authentication, integrity protection, and The same considerations regarding authentication, integrity
nonce checks described in this section and Section 7 for Map-Requests protection, and nonce checks, which are described in this section and
used to update subscription state, apply for Map-Requests used to Section 7 for Map-Requests used to update subscription state, apply
remove subscription state. for Map-Requests used to remove subscription state.
When an EID-Prefix is removed from the Map-Server (either when When an EID-Prefix is removed from the Map-Server (either when
explicitly withdrawn or when its TTL expires), the Map-Server explicitly withdrawn or when its TTL expires), the Map-Server
notifies its subscribers (if any) via a Map-Notify with TTL equal 0. notifies its subscribers (if any) via a Map-Notify with TTL equal to
0.
6. Mapping Notification Publish Procedures 6. Mapping Notification Publish Procedures
The publish procedure is implemented via Map-Notify messages that the The publish procedure is implemented via Map-Notify messages that the
Map-Server sends to xTRs. The xTRs acknowledge the reception of Map- Map-Server sends to xTRs. The xTRs acknowledge the receipt of Map-
Notifies via sending Map-Notify-Ack messages back to the Map-Server. Notifies by sending Map-Notify-Ack messages back to the Map-Server.
The complete mechanism works as follows: The complete mechanism works as follows:
When a mapping stored in a Map-Server is updated (e.g., via a Map- When a mapping stored in a Map-Server is updated (e.g., via a Map-
Register from an ETR), the Map-Server MUST notify the subscribers of Register from an ETR), the Map-Server MUST notify the subscribers of
that mapping via sending Map-Notify messages with the most updated that mapping via sending Map-Notify messages with the most up to date
mapping information. If subscription state in the Map-Server exists mapping information. If subscription state in the Map-Server exists
for a less-specific EID-Prefix and a more-specific EID-Prefix is for a less-specific EID-Prefix and a more-specific EID-Prefix is
updated, then the Map-Notify is sent with the more-specific EID- updated, then the Map-Notify is sent with the more-specific EID-
Prefix mapping to the subscribers of the less-specific EID-Prefix Prefix mapping to the subscribers of the less-specific EID-Prefix
mapping. The Map-Notify message sent to each of the subscribers as a mapping. The Map-Notify message sent to each of the subscribers as a
result of an update event follows the encoding and logic defined in result of an update event follows the encoding and logic defined in
Section 5.7 of [RFC9301] for Map-Notify, except for the following: Section 5.7 of [RFC9301] for Map-Notify, except for the following:
(1) The Map-Notify MUST be sent to one of the ITR-RLOCs associated 1. The Map-Notify MUST be sent to one of the ITR-RLOCs associated
with the xTR-ID of the subscriber (which one is implementation with the xTR-ID of the subscriber (which one is implementation
specific). specific).
(2) The Map-Server increments the nonce by one every time it sends a 2. The Map-Server increments the nonce by one every time it sends a
Map-Notify as publication to an xTR-ID for a particular EID- Map-Notify as publication to an xTR-ID for a particular EID-
Prefix. Prefix.
(3) The Map-Server MUST use its security association with the xTR to 3. The Map-Server MUST use its security association with the xTR to
compute the authentication data of the Map-Notify. compute the authentication data of the Map-Notify.
When the xTR receives a Map-Notify with an EID not local to the xTR, When the xTR receives a Map-Notify with an EID that is not local to
the xTR knows that the Map-Notify has been received to update an the xTR, the xTR knows that the Map-Notify is to update an entry on
entry on its Map-Cache. The xTR MUST keep track of the last nonce its Map-Cache. The xTR MUST keep track of the last nonce seen in a
seen in a Map-Notify received as a publication from the Map-Server Map-Notify received as a publication from the Map-Server for the EID-
for the EID-Prefix. When the LISP deployment has a single Map- Prefix. When the LISP deployment has a single Map-Server, the xTR
Server, the xTR can be configured to keep track of a single nonce for can be configured to keep track of a single nonce for all EID-
all EID-Prefix (when used, this option MUST be enabled at the Map- Prefixes (when used, this option MUST be enabled at the Map-Server
Server and all xTRs). If a Map-Notify received as a publication has and all xTRs). If a Map-Notify that is received as a publication has
a nonce value that is not greater than the saved nonce, the xTR drops a nonce value that is not greater than the saved nonce, the xTR drops
the Map-Notify message and logs the fact a replay attack could have the Map-Notify message and logs the fact a replay attack could have
occurred. The same considerations discussed in Section 5.6 of occurred. The same considerations discussed in Section 5.6 of
[RFC9301] regarding Map-Register nonces apply here for Map-Notify [RFC9301] regarding Map-Register nonces apply here for Map-Notify
nonces. nonces.
The xTR processes the received Map-Notify as specified in Section 5.7 The xTR processes the received Map-Notify as specified in Section 5.7
of [RFC9301], with the following considerations: The xTR MUST use its of [RFC9301], with the following considerations:
security association with the Map-Server (Section 7.1) to validate
the authentication data on the Map-Notify. The xTR MUST use the * The xTR MUST use its security association with the Map-Server
mapping information carried in the Map-Notify to update its internal (Section 7.1) to validate the authentication data on the Map-
Map-Cache. If after following Section 5.7 of [RFC9301] regarding Notify.
retransmission of Map-Notify messages, the Map-Server has not
received back the Map-Notify-Ack, it can try to send the Map-Notify * The xTR MUST use the mapping information carried in the Map-Notify
to a different ITR-RLOC for that xTR-ID. If the Map-Server tries all to update its internal Map-Cache.
the ITR-RLOCs without receiving a response, it may stop trying to
send the Map-Notify. * If after following Section 5.7 of [RFC9301] regarding
retransmission of Map-Notify messages, the Map-Server has not
received the Map-Notify-Ack, it can try sending the Map-Notify to
a different ITR-RLOC for that xTR-ID.
* If the Map-Server tries all the ITR-RLOCs without receiving a
response, it may stop trying to send the Map-Notify.
7. Security Considerations 7. Security Considerations
Generic security considerations related to LISP control messages are Generic security considerations related to LISP control messages are
discussed in Section 9 of [RFC9301]. discussed in Section 9 of [RFC9301].
In the particular case of PubSub, cache poisoning via malicious Map- In the particular case of PubSub, cache poisoning via malicious Map-
Notify messages is avoided by the use of nonce and the security Notify messages is avoided by the use of nonce and the security
association between the ITRs and the Map-Servers. association between the ITRs and the Map-Servers.
skipping to change at page 12, line 32 skipping to change at line 554
messages (e.g., to prevent xTR-ID hijacking). messages (e.g., to prevent xTR-ID hijacking).
7.1. Security Association between ITR and Map-Server 7.1. Security Association between ITR and Map-Server
Since Map-Notifies from the Map-Server to the ITR need to be Since Map-Notifies from the Map-Server to the ITR need to be
authenticated, there is a need for a soft-state or hard-state authenticated, there is a need for a soft-state or hard-state
security association (e.g., a PubSubKey) between the ITRs and the security association (e.g., a PubSubKey) between the ITRs and the
Map-Servers. For some controlled deployments, it might be possible Map-Servers. For some controlled deployments, it might be possible
to have a shared PubSubKey (or set of keys) between the ITRs and the to have a shared PubSubKey (or set of keys) between the ITRs and the
Map-Servers. However, if pre-shared keys are not used in the Map-Servers. However, if pre-shared keys are not used in the
deployment, LISP-SEC [RFC9303] can be used as follows to create a deployment, LISP Security (LISP-SEC) [RFC9303] can be used as follows
security association between the ITR and the Map-Server. to create a security association between the ITR and the Map-Server.
First, when the ITR is sending a Map-Request with the N-bit set First, when the ITR is sending a Map-Request with the N-bit set as
following Section 5, the ITR also performs the steps described in described in Section 5, the ITR also performs the steps described in
Section 6.4 of [RFC9303]. The ITR can then generate a PubSubKey by Section 6.4 of [RFC9303]. The ITR can then generate a PubSubKey by
deriving a key from the One-Time Key (OTK) and Map-Request's nonce as deriving a key from the One-Time Key (OTK) and Map-Request's nonce as
follows: PubSubKey = KDF(OTK + nonce), where KDF is the Key follows: PubSubKey = KDF(OTK + nonce), where KDF is the Key
Derivation Function indicated by the OTK Wrapping ID. If OTK Derivation Function indicated by the OTK Wrapping ID. If the OTK
Wrapping ID equals NULL-KEY-WRAP-128, then the PubSubKey is the OTK. Wrapping ID equals NULL-KEY-WRAP-128, then the PubSubKey is the OTK.
Note that as opposed to the pre-shared PubSubKey, this generated Note that, as opposed to the pre-shared PubSubKey, this generated
PubSubKey is different per EID-Prefix to which an ITR subscribes PubSubKey is different per EID-Prefix to which an ITR subscribes
(since the ITR will use a different OTK per Map-Request). (since the ITR will use a different OTK per Map-Request).
When the Map-Server receives the Map-Request it follows the procedure When the Map-Server receives the Map-Request, it follows the
specified in Section 5 with the following considerations: The Map- procedure specified in Section 5 with the following considerations:
Server MUST verify that the OTK has not been used before. If the the Map-Server MUST verify that the OTK has not been used before. If
Map-Server verifies the OTK and cannot determine that the OTK has not the Map-Server verifies the OTK and cannot determine that the OTK has
been used before, the subscription request fails due to not been used before, the subscription request fails due to
authentication and this triggers a Negative Map-Reply with ACT bits authentication, which triggers a Negative Map-Reply with ACT bits set
set to 5 "Drop/Auth-Failure", as described in Section 5. The xTR to 5 "Drop/Auth-Failure", as described in Section 5. The xTR might
might try again with a different OTK upon reception of this Negative try again with a different OTK upon receipt of this Negative Map-
Map-Reply. Note that a Map-Server implementation might decide to not Reply. Note that a Map-Server implementation may decide not to keep
keep full past OTKs and instead use some form of hash. In that case, track of all past OTKs and instead use some form of hash. In that
hash collisions are handled as if the OTK has been reused. Such an case, hash collisions are handled as if the OTK has been reused.
implementation needs to balance the hash length with the rate of Such an implementation needs to balance the hash length with the rate
collisions expected for the particular deployment; this is of collisions expected for the particular deployment; this is
implementation specific. If the Map-Server has to reply with a Map- implementation specific. If the Map-Server has to reply with a Map-
Reply for any other reason (e.g., if PubSub is not supported or a Reply for any other reason (e.g., if PubSub is not supported or a
subscription is not accepted), then it follows normal LISP-SEC subscription is not accepted), then it follows the normal LISP-SEC
procedure described in Section 5.7 of [RFC9303]. No PubSubKey, procedure described in Section 5.7 of [RFC9303]. No PubSubKey,
security association, or subscription state is created when the Map- security association, or subscription state is created when the Map-
Server responds with any Map-Reply message. Server responds with any Map-Reply message.
Otherwise, if the Map-Server has to reply with a Map-Notify (e.g., Otherwise, if the Map-Server has to reply with a Map-Notify (e.g.,
due to subscription accepted) to a received Map-Request, the due to the subscription being accepted) to a received Map-Request,
following extra steps take place: the following extra steps take place:
* The Map-Server extracts the OTK and OTK Wrapping ID from the LISP- * The Map-Server extracts the OTK and the OTK Wrapping ID from the
SEC ECM Authentication Data. LISP-SEC Encapsulated Control Message (ECM) Authentication Data.
* The Map-Server generates a PubSubKey by deriving a key from the * The Map-Server generates a PubSubKey by deriving a key from the
OTK as described before for the ITR. This is the same PubSubKey OTK, as described before for the ITR. This is the same PubSubKey
derived at the ITR which is used to establish a security derived at the ITR that is used to establish a security
association between the ITR and the Map-Server. association between the ITR and the Map-Server.
* The PubSubKey can now be used to sign and authenticate any Map- * The PubSubKey can now be used to sign and authenticate any Map-
Notify between the Map-Server and the ITR for the subscribed EID- Notify between the Map-Server and the ITR for the subscribed EID-
Prefix. This includes the Map-Notify sent as a confirmation to Prefix. This includes the Map-Notify sent as a confirmation to
the subscription. When the ITR wants to update the security the subscription. When the ITR wants to update the security
association for that Map-Server and EID-Prefix, it once again association for that Map-Server and EID-Prefix, it once again
follows the procedure described in this section. follows the procedure described in this section.
Note that if the Map-Server replies with a Map-Notify, none of the Note that if the Map-Server replies with a Map-Notify, none of the
regular LISP-SEC steps regarding Map-Reply described in Section 5.7 regular LISP-SEC steps regarding Map-Reply described in Section 5.7
of [RFC9303] occur. of [RFC9303] occur.
7.2. DDoS Attack Mitigation 7.2. DDoS Attack Mitigation
If PubSub is deployed under the scope of applicability defined in If PubSub is deployed under the scope of applicability defined in
Section 1.1 only known nodes can participate on the PubSub Section 1.1, only known nodes can participate on the PubSub
deployment. DDoS attacks based on replayed messages by unknown nodes deployment. DDoS attacks based on replayed messages by unknown nodes
are avoided by the use of nonce and the security association between are avoided by the use of nonce and the security association between
the ITRs and the Map-Servers. Misbehaving known nodes may send the ITRs and the Map-Servers. Misbehaving known nodes may send
massive subscription requests which may lead to exhausting the massive subscription requests, which may lead to exhausting the
resources of a Map-Server. Furthermore, frequently changing the resources of a Map-Server. Furthermore, frequently changing the
state of a subscription may also be considered as an attack vector. state of a subscription may also be considered as an attack vector.
To mitigate such issues, Section 5.3 of [RFC9301] discusses rate- To mitigate such issues, Section 5.3 of [RFC9301] discusses rate-
limiting Map-Requests and Section 5.7 of [RFC9301] discusses rate- limiting Map-Requests, and Section 5.7 of [RFC9301] discusses rate-
limiting Map-Notifies. Note that when the Map-Notify rate-limit limiting Map-Notifies. Note that when the Map-Notify rate-limit
threshold is met for a particular xTR-ID, the Map-Server will discard threshold is met for a particular xTR-ID, the Map-Server will discard
additional subscription requests from that xTR-ID and will fall back additional subscription requests from that xTR-ID and will fall back
to [RFC9301] behavior when receiving a Map-Request from that xTR-ID to the behavior described in [RFC9301] when receiving a Map-Request
(i.e., the Map-Server will send a Map-Reply). from that xTR-ID (i.e., the Map-Server will send a Map-Reply).
8. IANA Considerations 8. IANA Considerations
This document requests IANA to assign a new bit from the "LISP IANA has assigned the following new bit from the "LISP Control Plane
Control Plane Header Bits: Map-Request" sub-registry under the Header Bits: Map-Request" registry within the "Locator/ID Separation
"Locator/ID Separation Protocol (LISP) Parameters" registry available Protocol (LISP) Parameters" group of registries [IANA-LISP]:
at [IANA-LISP]. The suggested position of this bit in the Map-
Request message can be found in Figure 1.
+======+===============+==========+=============+===============+ +===========+===============+==========+=============+===========+
| Spec | IANA Name | Bit | Description | Reference | | Spec Name | IANA Name | Bit | Description | Reference |
| Name | | Position | | | | | | Position | | |
+======+===============+==========+=============+===============+ +===========+===============+==========+=============+===========+
| I | Map-Request-I | 11 | xTR-ID Bit | This-Document | | I | Map-Request-I | 11 | xTR-ID Bit | RFC 9437 |
+------+---------------+----------+-------------+---------------+ +-----------+---------------+----------+-------------+-----------+
Table 1: Additions to the Map-Request Header Bits Sub-Registry Table 1: Addition to the Map-Request Header Bits Registry
This document also requests the creation of a new sub-registry IANA has also created a new registry entitled "LISP Control Plane
entitled "LISP Control Plane Header Bits: Map-Request-Record" under Header Bits: Map-Request-Record" within the "Locator/ID Separation
the "Locator/ID Separation Protocol (LISP) Parameters" registry Protocol (LISP) Parameters" group of registries [IANA-LISP].
available at [IANA-LISP].
The initial content of this sub-registry is shown in Table 2: The initial content of this registry is shown in Table 2.
+====+=============+========+========================+=============+ +====+===============+========+========================+===========+
|Spec|IANA Name |Bit | Description |Reference | |Spec| IANA Name |Bit | Description | Reference |
|Name| |Position| | | |Name| |Position| | |
+====+=============+========+========================+=============+ +====+===============+========+========================+===========+
|N |Map-Request-N|1 | Notification-Requested |This-Document| |N | Map-Request-N |1 | Notification-Requested | RFC 9437 |
| | | | Bit | | | | | | Bit | |
+----+-------------+--------+------------------------+-------------+ +----+---------------+--------+------------------------+-----------+
Table 2: Initial Content of LISP Control Plane Header Bits: Map- Table 2: Initial Content of LISP Control Plane Header Bits: Map-
Request-Record Sub-Registry Request-Record Registry
The remaining bits (i.e., Bit positions 2-8) are Unassigned. The remaining bits (i.e., bit positions 2-8) are Unassigned.
The policy for allocating new bits from this sub-registry is The policy for allocating new bits in this registry is "Specification
Specification Required (Section 4.6 of [RFC8126]). Required" (Section 4.6 of [RFC8126]).
Review requests are evaluated on the advice of one or more designated Allocation requests are evaluated on the advice of one or more
experts. Criteria that should be applied by the designated experts designated experts. Designated experts should consider whether the
include determining whether the proposed registration duplicates proposed registration duplicates existing entries and whether the
existing entries and whether the registration description is registration description is sufficiently detailed and fits the
sufficiently detailed and fits the purpose of this registry. These purpose of this registry. These criteria are to be considered in
criteria are considered in addition to those already provided in addition to those provided in Section 4.6 of [RFC8126] (e.g., the
Section 4.6 of [RFC8126] (e.g., the proposed registration must be proposed registration "must be documented in a permanent and readily
documented in a permanent and readily available public available public specification"). The designated experts will either
specification). The designated experts will either approve or deny approve or deny the registration request, and communicate their
the registration request, communicating this decision to IANA. decision to IANA. Denials should include an explanation and, if
Denials should include an explanation and, if applicable, suggestions applicable, suggestions as to how to make the request successful.
as to how to make the request successful.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 16, line 5 skipping to change at line 713
Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022, Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/info/rfc9301>. <https://www.rfc-editor.org/info/rfc9301>.
[RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, [RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
"Locator/ID Separation Protocol Security (LISP-SEC)", "Locator/ID Separation Protocol Security (LISP-SEC)",
RFC 9303, DOI 10.17487/RFC9303, October 2022, RFC 9303, DOI 10.17487/RFC9303, October 2022,
<https://www.rfc-editor.org/info/rfc9303>. <https://www.rfc-editor.org/info/rfc9303>.
9.2. Informative References 9.2. Informative References
[I-D.boucadair-lisp-pubsub-flow-examples] [EID-MOBILITY]
Portoles, 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-11, 10 January 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
eid-mobility-11>.
[FLOW-EXAMPLES]
Boucadair, M., "LISP PubSub Flow Examples", Work in Boucadair, M., "LISP PubSub Flow Examples", Work in
Progress, Internet-Draft, draft-boucadair-lisp-pubsub- Progress, Internet-Draft, draft-boucadair-lisp-pubsub-
flow-examples-03, 10 February 2023, flow-examples-03, 10 February 2023,
<https://datatracker.ietf.org/doc/html/draft-boucadair- <https://datatracker.ietf.org/doc/html/draft-boucadair-
lisp-pubsub-flow-examples-03>. lisp-pubsub-flow-examples-03>.
[I-D.haindl-lisp-gb-atn] [GB-ATN] Haindl, B., Lindner, M., Moreno, V., Portoles, M., Maino,
Haindl, B., Lindner, M., Moreno, V., Portoles-Comeras, M., F., and B. Venkatachalapathy, "Ground-Based LISP for the
Maino, F., and B. Venkatachalapathy, "Ground-Based LISP Aeronautical Telecommunications Network", Work in
for the Aeronautical Telecommunications Network", Work in Progress, Internet-Draft, draft-haindl-lisp-gb-atn-09, 27
Progress, Internet-Draft, draft-haindl-lisp-gb-atn-08, 23 March 2023, <https://datatracker.ietf.org/doc/html/draft-
September 2022, <https://datatracker.ietf.org/doc/html/ haindl-lisp-gb-atn-09>.
draft-haindl-lisp-gb-atn-08>.
[I-D.ietf-lisp-eid-mobility] [IANA-LISP]
Portoles-Comeras, M., Ashtaputre, V., Maino, F., Moreno, IANA, "Locator/ID Separation Protocol (LISP) Parameters",
V., and D. Farinacci, "LISP L2/L3 EID Mobility Using a <https://www.iana.org/assignments/lisp-parameters/>.
Unified Control Plane", Work in Progress, Internet-Draft,
draft-ietf-lisp-eid-mobility-11, 10 January 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
eid-mobility-11>.
[I-D.ietf-lisp-yang] [LISP-YANG]
Ermagan, V., Rodriguez-Natal, A., Coras, F., Moberg, C., Ermagan, V., Rodriguez-Natal, A., Coras, F., Moberg, C.,
Rahman, R., Cabellos-Aparicio, A., and F. Maino, "LISP Rahman, R., Cabellos, A., and F. Maino, "LISP YANG Model",
YANG Model", Work in Progress, Internet-Draft, draft-ietf- Work in Progress, Internet-Draft, draft-ietf-lisp-yang-19,
lisp-yang-18, 29 August 2022, 2 March 2023, <https://datatracker.ietf.org/doc/html/
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp- draft-ietf-lisp-yang-19>.
yang-18>.
[I-D.moreno-lisp-uberlay] [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
Moreno, V., Farinacci, D., Rodriguez-Natal, A., Portoles- Protocol Internet Groper (LIG)", RFC 6835,
DOI 10.17487/RFC6835, January 2013,
<https://www.rfc-editor.org/info/rfc6835>.
[UBERLAY] Moreno, V., Farinacci, D., Rodriguez-Natal, A., Portoles-
Comeras, M., Maino, F., and S. Hooda, "Uberlay Comeras, M., Maino, F., and S. Hooda, "Uberlay
Interconnection of Multiple LISP overlays", Work in Interconnection of Multiple LISP overlays", Work in
Progress, Internet-Draft, draft-moreno-lisp-uberlay-06, 28 Progress, Internet-Draft, draft-moreno-lisp-uberlay-06, 28
September 2022, <https://datatracker.ietf.org/doc/html/ September 2022, <https://datatracker.ietf.org/doc/html/
draft-moreno-lisp-uberlay-06>. draft-moreno-lisp-uberlay-06>.
[IANA-LISP]
IANA, "Locator/ID Separation Protocol (LISP) Parameters",
<https://www.iana.org/assignments/lisp-parameters/lisp-
parameters.xhtml>.
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
Protocol Internet Groper (LIG)", RFC 6835,
DOI 10.17487/RFC6835, January 2013,
<https://www.rfc-editor.org/info/rfc6835>.
Appendix A. Sample PubSub Deployment Experiences Appendix A. Sample PubSub Deployment Experiences
Some LISP production networks have been running different forms of Some LISP production networks have been running different forms of
PubSub for some time. The following subsections provide an inventory PubSub for some time. The following subsections provide an inventory
of some experience lessons from these deployments. of some experience lessons from these deployments.
A.1. PubSub as a Monitoring Tool A.1. PubSub as a Monitoring Tool
Some LISP deployments are using PubSub as a way to monitor EID- Some LISP deployments are using PubSub as a way to monitor EID-
Prefixes (particularly, EID-to-RLOC mappings). To that aim, some Prefixes (particularly, EID-to-RLOC mappings). To that aim, some
LISP implementations have extended the LISP Internet Groper (lig) LISP implementations have extended the LISP Internet Groper ('lig')
[RFC6835] tool to use PubSub. Such an extension is meant to support [RFC6835] tool to use PubSub. Such an extension is meant to support
an interactive mode with lig, and request subscription for the EID of an interactive mode with 'lig' and to request subscription for the
interest. If there are RLOC changes, the Map-Server sends a EID of interest. If there are RLOC changes, the Map-Server sends a
notification and then the lig client displays that change to the notification, and then the 'lig' client displays that change to the
user. user.
A.2. Mitigating Negative Map-Cache Entries A.2. Mitigating Negative Map-Cache Entries
Section 8.1 of [RFC9301] suggests two TTL values for Negative Map- Section 8.1 of [RFC9301] suggests two TTL values for Negative Map-
Replies: either 15-minute (if the EID-Prefix does not exist) or Replies: either a 15-minute TTL (if the EID-Prefix does not exist) or
1-minute (if the prefix exists but has not been registered). While a 1-minute TTL (if the prefix exists but has not been registered).
these values are based on the original operational experience of the While these values are based on the original operational experience
LISP protocol designers, negative cache entries have two unintended of the LISP protocol designers, negative cache entries have two
effects that were observed in production. unintended effects that were observed in production.
First, if the xTR keeps receiving traffic for a negative EID First, if the xTR keeps receiving traffic for a negative EID
destination (i.e., an EID-Prefix with no RLOCs associated with it), destination (i.e., an EID-Prefix with no RLOCs associated with it),
it will try to resolve the destination again once the cached state it will try to resolve the destination again once the cached state
expires, even if the state has not changed in the Map-Server. It was expires, even if the state has not changed in the Map-Server. It was
observed in production that this is happening often in networks that observed in production that this is happening often in networks that
have a significant amount of traffic addressed for outside of the have a significant amount of traffic addressed for outside of the
LISP network. This might result on excessive resolution signaling to LISP network. This might result in excessive resolution signaling to
keep retrieving the same state due to the cache expiring. PubSub is keep retrieving the same state due to the cache expiring. PubSub is
used to relax TTL values and cache negative mapping entries for used to relax TTL values and cache negative mapping entries for
longer periods of time, avoiding unnecessary refreshes of these longer periods of time, avoiding unnecessary refreshes of these
forwarding entries, and drastically reducing signaling in these forwarding entries and drastically reducing signaling in these
scenarios. In general, a TTL-based schema is a “polling mechanism” scenarios. In general, a TTL-based schema is a "polling mechanism"
that leads to more signaling where PubSub provides an "event that leads to more signaling where PubSub provides an "event-
triggered mechanism" at the cost of state. triggered mechanism" at the cost of state.
Second, if the state does indeed change in the Map-Server, updates Second, if the state does indeed change in the Map-Server, updates
based on TTL timeouts might prevent the cached state at the xTR from based on TTL timeouts might prevent the cached state at the xTR from
being updated until the TTL expires. This behavior was observed being updated until the TTL expires. This behavior was observed
during configuration (or reconfiguration) periods on the network, during configuration (or reconfiguration) periods on the network,
where no-longer-negative EID-Prefixes do not receive the traffic yet where EID-Prefixes that are no longer negative do not receive the
due to stale Map-Cache entries present in the network. With the traffic yet, due to stale Map-Cache entries present in the network.
activation of PubSub, stale caches can be updated as soon as the With the activation of PubSub, stale caches can be updated as soon as
state changes. the state changes.
A.3. Improved Mobility Latency A.3. Improved Mobility Latency
An improved convergence time was observed on the presence of mobility An improved convergence time was observed on the presence of mobility
events on LISP networks running PubSub as compared with running LISP events on LISP networks running PubSub as compared with running LISP
[RFC9301]. As described in Section 4.1.2.1 of [RFC9301]. As described in Section 4.1.2.1 of [EID-MOBILITY], LISP
[I-D.ietf-lisp-eid-mobility], LISP can rely on data-driven Solicit- can rely on data-driven Solicit-Map-Requests (SMRs) to ensure
Map-Requests (SMRs) to ensure eventual network converge. Generally, eventual network convergence. Generally, PubSub offers faster
PubSub offers faster convergence due to (1) no need to wait for a convergence due to (1) no need to wait for a data-triggered event and
data triggered event and (2) less signaling as compared with the SMR- (2) less signaling as compared with the SMR-based flow. Note that
based flow. Note that when a Map-Server running PubSub has to update when a Map-Server running PubSub has to update a large number of
a large number of subscribers at once (i.e., when a popular mapping subscribers at once (i.e., when a popular mapping is updated), SMR-
is updated) SMR based convergence may be faster for a small subset of based convergence may be faster for a small subset of the subscribers
the subscribers (those receiving PubSub updates last). Deployment (those receiving PubSub updates last). Deployment experience reveals
experience reveals that data-driven SMRs and PubSub mechanisms that data-driven SMRs and PubSub mechanisms complement each other and
complement each other and provide a fast and resilient network provide a fast and resilient network infrastructure in the presence
infrastructure in the presence of mobility events. of mobility events.
Furthermore, experience showed that not all LISP entities on the Furthermore, experience showed that not all LISP entities on the
network need to implement PubSub for the network to get the benefits. network need to implement PubSub for the network to get the benefits.
In scenarios with significant traffic coming from outside of the LISP In scenarios with significant traffic coming from outside of the LISP
network, the experience showed that enabling PubSub in the border network, the experience showed that enabling PubSub in the border
routers significantly improves mobility latency overall. Even if routers significantly improves mobility latency overall. Even if
edge xTRs do not implement PubSub, and traffic is exchanged between edge xTRs do not implement PubSub, and traffic is exchanged between
EID-Prefixes at the edge, xTRs still converge based on data-driven EID-Prefixes at the edge, xTRs still converge based on data-driven
events and SMR-triggered updates. events and SMR-triggered updates.
A.4. Enhanced Reachability with Dynamic Redistribution of Prefixes A.4. Enhanced Reachability with Dynamic Redistribution of Prefixes
There is a need to interconnect LISP networks with other networks There is a need to interconnect LISP networks with other networks
that might or might not run LISP. Some of those scenarios are that might or might not run LISP. Some of those scenarios are
similar to the ones described in [I-D.haindl-lisp-gb-atn] and similar to the ones described in [GB-ATN] and [UBERLAY]. When
[I-D.moreno-lisp-uberlay]. When connecting LISP to other networks, connecting LISP to other networks, the experience revealed that in
the experience revealed that in many deployments the point of many deployments the point of interaction with the other domains is
interaction with the other domains is not the Mapping System but not the Mapping System but rather the border router of the LISP site.
rather the border router of the LISP site. For those cases the For those cases, the border router needs to be aware of the LISP
border router needs to be aware of the LISP prefixes to redistribute prefixes to redistribute them to the other networks. Over the years,
them to the other networks. Over the years different solutions have different solutions have been used.
been used.
First, Map-Servers were collocated with the border routers, but this First, Map-Servers were collocated with the border routers, but this
was hard to scale since border routers scale at a different pace than was hard to scale since border routers scale at a different pace than
Map-Servers. Second, decoupled Map-Servers and border routers were Map-Servers. Second, decoupled Map-Servers and border routers were
used with static configuration of LISP entries on the border, which used with static configuration of LISP entries on the border, which
was problematic when modifications were made. Third, a routing was problematic when modifications were made. Third, a routing
protocol (e.g., BGP) can be used to redistributed LISP prefixes from protocol (e.g., BGP) can be used to redistribute LISP prefixes from
the Map-Servers to a border router, but this comes with some the Map-Servers to a border router, but this comes with some
implications, particularly the Map-Servers needs to implement an implications; in particular, the Map-Servers need to implement an
additional protocol which consumes resources and needs to be properly additional protocol, which consumes resources and needs to be
configured. Therefore, once PubSub was available, deployments properly configured. Therefore, once PubSub was available,
started to adapt it to enable border routers to dynamically learn the deployments started to adapt it to enable border routers to
prefixes they need to redistribute without the need of extra dynamically learn the prefixes they need to redistribute without a
protocols or extra configuration on the network. need for extra protocols or extra configuration on the network.
In other words, PubSub can be used to discover EID-Prefixes so they In other words, PubSub can be used to discover EID-Prefixes so they
can be imported into other routing domains that do not use LISP. can be imported into other routing domains that do not use LISP.
Similarly, PubSub can also be used to discover when EID-Prefixes need Similarly, PubSub can also be used to discover when EID-Prefixes need
to be withdrawn from other routing domains. That is, in a typical to be withdrawn from other routing domains. That is, in a typical
deployment, a border router will withdraw an EID-Prefix it has been deployment, a border router will withdraw an EID-Prefix that it has
announcing to external routing domains, if it receives a notification been announcing to external routing domains if it receives a
that the RLOC-set for that EID-Prefix is now empty. notification that the RLOC-set for that EID-Prefix is now empty.
A.5. Better Serviceability A.5. Better Serviceability
EID-to-RLOC mappings can have very long TTL, sometimes in the order EID-to-RLOC mappings can have a very long TTL, sometimes on the order
of several hours. Upon the expiry of that TTL, the xTR checks if of several hours. Upon the expiry of that TTL, the xTR checks if
these entries are being used and removes any entry that is not being these entries are being used and removes any entry that is not being
used. The problem with very long Map-Cache TTL is that (in the used. The problem with a very long Map-Cache TTL is that (in the
absence of PubSub) if a mapping changes, but it is not being used, absence of PubSub) if a mapping changes but is not being used, the
the cache remains but it is stale. This is due to no data traffic cache remains but is stale. This is due to no data traffic being
being sent to the old location to trigger an SMR based Map-Cache sent to the old location to trigger an SMR-based Map-Cache update as
update as described in Section 4.1.2.1 of described in Section 4.1.2.1 of [EID-MOBILITY]. If the network
[I-D.ietf-lisp-eid-mobility]. If the network operator runs a show operator runs a show command on a router to track the state of the
command on a router to track the state of the Map-Cache, the router Map-Cache, the router will display multiple entries waiting to expire
will display multiple entries waiting to expire but with stale RLOC but with stale RLOC information. This might be confusing for
information. This might be confusing for operators sometimes, operators sometimes, particularly when they are debugging problems.
particularly when they are debugging problems. With PubSub, the Map- With PubSub, the Map-Cache is updated with the correct RLOC
Cache is updated with the correct RLOC information, even when it is information, even when it is not being used or waiting to expire,
not being used or waiting to expire, and this helps with debugging. which helps with debugging.
Acknowledgments Acknowledgments
We would like to thank Marc Portoles, Balaji Venkatachalapathy, We would like to thank Marc Portoles, Balaji Venkatachalapathy,
Bernhard Haindl, Luigi Iannone, and Padma Pillay-Esnault for their Bernhard Haindl, Luigi Iannone, and Padma Pillay-Esnault for their
great suggestions and help regarding this document. great suggestions and help regarding this document.
Many thanks to Alvaro Retana for the careful AD review. Many thanks to Alvaro Retana for the careful AD review.
Thanks to Chris M. Lonvick for the security directorate review, Al Thanks to Chris M. Lonvick for the security directorate review, Al
Morton for the OPS-DIR review, Roni Even for the Gen-ART review, Mike Morton for the OPS-DIR review, Roni Even for the Gen-ART review, Mike
McBride for the rtg-dir review, Magnus Westerlund for the tsv McBride for the rtg-dir review, Magnus Westerlund for the tsv
directorate review, and Sheng Jiang for the int-dir review. directorate review, and Sheng Jiang for the int-dir review.
Thanks to John Scudder, Erik Kline, Lars Eggert, Warren Kumari, Thanks to John Scudder, Erik Kline, Lars Eggert, Warren Kumari,
Martin Duke, Murray Kucherawy, Éric Vyncke, Robert Wilton, Martin Duke, Murray Kucherawy, Éric Vyncke, Robert Wilton,
Zaheduzzaman Sarker, and Roman Danyliw for the IESG review. Zaheduzzaman Sarker, and Roman Danyliw for the IESG review.
This work was partly funded by the ANR LISP-Lab project #ANR- This work was partly funded by the ANR LISP-Lab project #ANR-
13-INFR-009 (https://anr.fr/Projet-ANR-13-INFR-0009). 13-INFR-009 <https://anr.fr/Projet-ANR-13-INFR-0009>.
Contributors Contributors
Dino Farinacci
lispers.net
San Jose, CA
USA
Email: farinacci@gmail.com
Johnson Leong
Email: johnsonleong@gmail.com
Fabio Maino Dino Farinacci
Cisco lispers.net
San Jose, CA San Jose, CA
USA United States of America
Email: farinacci@gmail.com
Email: fmaino@cisco.com
Christian Jacquenet Johnson Leong
Orange Email: johnsonleong@gmail.com
Rennes
France
Email: christian.jacquenet@orange.com Fabio Maino
Cisco
San Jose, CA
United States of America
Email: fmaino@cisco.com
Stefano Secci Christian Jacquenet
Cnam Orange
France Rennes
France
Email: christian.jacquenet@orange.com
Email: stefano.secci@cnam.fr Stefano Secci
Cnam
France
Email: stefano.secci@cnam.fr
Authors' Addresses Authors' Addresses
Alberto Rodriguez-Natal Alberto Rodriguez-Natal
Cisco Cisco
Barcelona Barcelona
Spain Spain
Email: natal@cisco.com Email: natal@cisco.com
Vina Ermagan Vina Ermagan
 End of changes. 117 change blocks. 
423 lines changed or deleted 418 lines changed or added

This html diff was produced by rfcdiff 1.48.