draft-ietf-lisp-pubsub-00.txt   draft-ietf-lisp-pubsub-01.txt 
LISP Working Group A. Rodriguez-Natal LISP Working Group A. Rodriguez-Natal
Internet-Draft V. Ermagan Internet-Draft V. Ermagan
Intended status: Experimental J. Leong Intended status: Experimental J. Leong
Expires: October 27, 2018 F. Maino Expires: April 7, 2019 F. Maino
Cisco Systems Cisco Systems
A. Cabellos-Aparicio A. Cabellos-Aparicio
Technical University of Catalonia Technical University of Catalonia
S. Barkai S. Barkai
Fermi Serverless Fermi Serverless
D. Farinacci D. Farinacci
lispers.net lispers.net
M. Boucadair M. Boucadair
C. Jacquenet C. Jacquenet
Orange Orange
S. Secci S. Secci
LIP6 UPMC LIP6 UPMC
April 25, 2018 October 4, 2018
Publish/Subscribe Functionality for LISP Publish/Subscribe Functionality for LISP
draft-ietf-lisp-pubsub-00 draft-ietf-lisp-pubsub-01
Abstract Abstract
This document specifies an extension to the use of Map-Request to This document specifies an extension to the use of Map-Request to
enable Publish/Subscribe (PubSub) operation for LISP. enable Publish/Subscribe (PubSub) operation for LISP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 27, 2018. This Internet-Draft will expire on April 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 3 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
4. Map-Request Additions . . . . . . . . . . . . . . . . . . . . 4 4. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 4
5. Mapping Request Subscribe Procedures . . . . . . . . . . . . 5 5. Map-Request Additions . . . . . . . . . . . . . . . . . . . . 4
6. Mapping Notification Publish Procedures . . . . . . . . . . . 7 6. Mapping Request Subscribe Procedures . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Mapping Notification Publish Procedures . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 11. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The Locator/ID Separation Protocol (LISP) [RFC6830] splits current IP The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6833bis]
addresses in two different namespaces, Endpoint Identifiers (EIDs) splits current IP addresses in two different namespaces, Endpoint
and Routing Locators (RLOCs). LISP uses a map-and-encap approach Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map-
that relies on (1) a Mapping System (basically a distributed and-encap approach that relies on (1) a Mapping System (basically a
database) that stores and disseminates EID-RLOC mappings and on (2) distributed database) that stores and disseminates EID-RLOC mappings
LISP tunnel routers (xTRs) that encapsulate and decapsulate data and on (2) LISP tunnel routers (xTRs) that encapsulate and
packets based on the content of those mappings. decapsulate data packets based on the content of those mappings.
ITRs/RTRs/PITRs pull EID-to-RLOC mapping information from the Mapping ITRs/RTRs/PITRs pull EID-to-RLOC mapping information from the Mapping
System by means of an explicit request message. [RFC6830] indicates System by means of an explicit request message.
how ETRs can tell ITRs/RTRs/PITRs about mapping changes. This [I-D.ietf-lisp-rfc6833bis] indicates how ETRs can tell ITRs/RTRs/
document presents a Publish/Subscribe (PubSub) extension in which the PITRs about mapping changes. This document presents a Publish/
Mapping System can notify ITRs/RTRs/PITRs about mapping changes. Subscribe (PubSub) extension in which the Mapping System can notify
When this mechanism is used, mapping changes can be notified faster ITRs/RTRs/PITRs about mapping changes. When this mechanism is used,
and can be managed in the Mapping System versus the LISP sites. mapping changes can be notified faster and can be managed in the
Mapping System versus the 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 steps occur: changes for a given EID-prefix, the following steps occur:
(1) The ITR/RTR/PITR sends a Map-Request for that EID-prefix. (1) The ITR/RTR/PITR sends a Map-Request for that EID-prefix.
(2) The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on (2) The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on
the Map-Request and includes its xTR-ID. the Map-Request and includes its xTR-ID and Site-ID.
(3) The Map-Request is forwarded to one of the Map-Servers that the (3) The Map-Request is forwarded to one of the Map-Servers that the
EID-prefix is registered to. EID-prefix is registered to.
(4) The Map-Server creates subscription state for the ITR/RTR/PITR (4) The Map-Server creates subscription state for the ITR/RTR/PITR
on the EID-prefix. on the EID-prefix.
(5) The Map-Server sends a Map-Notify to the ITR/RTR/PITR to (5) The Map-Server sends a Map-Notify to the ITR/RTR/PITR to
acknowledge the successful subscription. acknowledge the successful subscription.
(6) When there is an RLOC-set change for the EID-prefix, the Map- (6) When there is an RLOC-set change for the EID-prefix, the Map-
Server sends a Map-Notify message to each ITR/RTR/PITR in the Server sends a Map-Notify message to each ITR/RTR/PITR in 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 ITR/RTR/ This operation is repeated for all EID-prefixes for which ITR/RTR/
PITR want to be notified. The ITR/RTR/PITR can set the N-bit for PITR want to be notified. The ITR/RTR/PITR can set the N-bit for
several EID-prefixes within a single Map-Request several EID-prefixes within a single Map-Request.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Deployment Assumptions 3. Definition of Terms
LISP xTR-ID: A 128-bit field that is used as a unique identifier
for an xTR. The xTR-ID is especially useful for identifying
multiple xTRs serving the same site/EID-prefix. A value of all
zeros indicate the xTR-ID is unspecified.
LISP Site-ID: A 64-bit field that is used as a unique identifier
of a group of xTRs belonging to the same site. A value of 0
indicate the Site-ID is unspecified.
4. Deployment Assumptions
The specification described in this document makes the following The specification described in this document makes the following
deployment assumptions: deployment assumptions:
(1) A unique 128-bit xTR-ID identifier is assigned to each xTR. (1) A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is
assigned to each xTR.
(2) Map-Servers are configured in proxy-reply mode, i.e., they are (2) Map-Servers are configured in proxy-reply mode, 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) There can be either a soft-state or hard-state security (3) There can be either a soft-state or hard-state security
association between the xTRs and the Map-Servers. association between the xTRs and the Map-Servers.
The distribution of xTR-IDs and the management of security The distribution of xTR-IDs (and Site-IDs) and the management of
associations are out of the scope of this document. security associations are out of the scope of this document.
4. Map-Request Additions 5. Map-Request Additions
Figure 1 shows the format of the updated Map-Request Figure 1 shows the format of the updated Map-Request
[I-D.ietf-lisp-rfc6833bis] to support the PubSub functionality. [I-D.ietf-lisp-rfc6833bis] to support the PubSub functionality.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|m|I| Reserved | IRC | Record Count | |Type=1 |A|M|P|S|p|s|R|I| Reserved | IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... | | Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
skipping to change at page 4, line 44 skipping to change at page 5, line 36
| Map-Reply Record ... | | Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ xTR-ID + + xTR-ID +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Site-ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Map-Request with N-bit and xTR-ID Figure 1: Map-Request with I-bit, N-bit, xTR-ID and Site-ID
The meaning of the fields is exactly the same as defined in The following is added to the Map-Request message defined in
[I-D.ietf-lisp-rfc6833bis]. The only addition is a flag bit in the [I-D.ietf-lisp-rfc6833bis]:
EID-Record field. The meaning of this flag bit is as follows:
Notification-Requested bit (N-bit): the first bit in the EID- xTR-ID bit (I-bit): The I-bit of a Map-Request message is set to 1
Record section of a Map-Request message. The N-bit of an EID- to indicate that a 128 bit xTR-ID and a 64 bit Site-ID fields are
record is set to 1 to specify that the xTR wants to be notified of present at the end of the Map-Request message. If an xTR is
updates for that mapping record. configured with an xTR-ID or Site-ID, it MUST set the I bit to 1
and include its xTR-ID and Site-ID in the Map-Request messages it
generates. If either the xTR-ID or Site-ID is not configured an
unspecified value is encoded for whichever ID that is not
configured.
The PubSub functionality requires to include an xTR-ID in the Map- Notification-Requested bit (N-bit): The N-bit of an EID-record is
Request. This is done by setting the xTR-ID bit (I-bit) defined in set to 1 to specify that the xTR wants to be notified of updates
[I-D.ietf-lisp-rfc6833bis]. When the I-bit of a Map-Request message for that mapping record.
is set, a 128-bit xTR-ID field is appended to the end of the Map-
Request, immediately following the last EID-Record (or the Map-Reply
Record, if present). The xTR-ID field uniquely identifies each xTR
of a given LISP deployment. Provisioning of unique xTR-IDs is out of
the scope of this document.
5. Mapping Request Subscribe Procedures xTR-ID field: xTR-ID is a 128 bit field at the end of the Map-
Request message, starting after the final Record in the message
(or the Map-Reply Record, if present). The xTR-ID is used to
uniquely identify the sender of a Map-Request message, especially
in the case where a site has more than one xTR. A value of all
zeros indicate that an xTR-ID is not specified, though encoded in
the message. This is useful in the case where a Site-ID is
specified, but no xTR-ID is configured.
Site-ID field: Site-ID is a 64 bit field at the end of the Map-
Request message, following the xTR-ID. Site-ID is used by the
Map-Server receiving the Map-Request message to identify which
xTRs belong to the same site. A value of 0 indicate that a Site-
ID is not specified, though encoded in the message.
6. Mapping Request Subscribe Procedures
The xTR subscribes for RLOC-set changes for a given EID-prefix by The xTR subscribes for RLOC-set changes for a given EID-prefix by
sending a Map-Request to the Mapping System with the N-bit set on the sending a Map-Request to the Mapping System with the N-bit set on the
EID-Record. The xTR builds a Map-Request according to [RFC6830] but EID-Record. The xTR builds a Map-Request according to
also does the following: [I-D.ietf-lisp-rfc6833bis] but also does the following:
(1) The xTR MUST set the I-bit of the Map-Request message to 1, to (1) The xTR MUST set the I-bit of the Map-Request message to 1 and
specify the presence of an xTR-ID field that uniquely identifies append its xTR-ID and Site-ID to the Map-Request. The xTR-ID
the xTR. uniquely identifies the xTR.
(2) The xTR MUST set the N-bit to 1 for each EID-Record to which the (2) The xTR MUST set the N-bit to 1 for each EID-Record to which the
xTR wants to subscribe. xTR wants to subscribe.
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 to notify that specific xTR about future mapping changes responsible to notify that specific xTR about future mapping changes
for the subscribed mapping records. for the subscribed mapping records.
Upon reception of the Map-Request, the Map-Server processes it as Upon reception of the Map-Request, the Map-Server processes it as
described in [RFC6830]. Upon processing, for each EID-Record that described in [I-D.ietf-lisp-rfc6833bis]. Upon processing, for each
has the N-bit set to 1, the Map-Server proceeds adding the xTR-ID EID-Record that has the N-bit set to 1, the Map-Server proceeds
contained in the Map-Request to the list of xTR that have requested adding the xTR-ID contained in the Map-Request to the list of xTR
to be subscribed to that mapping record. that have requested to be subscribed to that mapping record.
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 MUST follow the specification in subscription. The Map-Server MUST follow the specification in
Section 6.1.7 of [RFC6830] to build the Map-Notify with the following Section 6.1.7 of [I-D.ietf-lisp-rfc6833bis] to build the Map-Notify
considerations. 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
(see Section 3) to compute the authentication data of the Map- (see Section 4) to compute the authentication data of the Map-
Notify. Notify.
(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. received in the Map-Request.
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
[RFC6830] with the following considerations. The xTR MUST use its [I-D.ietf-lisp-rfc6833bis] with the following considerations. The
security association with the Map-Server (see Section 3) to validate xTR MUST use its security association with the Map-Server (see
the authentication data on the Map-Notify. The xTR MUST use the Map- Section 4) to validate the authentication data on the Map-Notify.
Notify to populate its map-cache with the returned EID-prefix and The xTR MUST use the Map-Notify to populate its map-cache with the
RLOC-set. returned EID-prefix and RLOC-set.
The subscription of an xTR-ID to the list of subscribers for the EID- The subscription of an xTR-ID to the list of subscribers for the EID-
Record may fail for a number of reasons. For example, because of Record may fail for a number of reasons. For example, because of
local configuration policies (such as white/black lists of local configuration policies (such as white/black lists of
subscribers), or because the Map-Server has exhausted the resources subscribers), or because the Map-Server has exhausted the resources
to dedicate to the subscription of that EID-Record (e.g., the number to dedicate to the subscription of that EID-Record (e.g., the number
of subscribers excess the capacity of the Map-Server). of subscribers excess the capacity of the Map-Server).
If the subscription fails, the Map-Server MUST send a Map-Reply to If the subscription fails, the Map-Server MUST send a Map-Reply to
the originator of the Map-Request, as described in [RFC6830]. This the originator of the Map-Request, as described in
is also the case when the Map-Server does not support PubSub [I-D.ietf-lisp-rfc6833bis]. This is also the case when the Map-
operation. The xTR processes the Map-Reply as specified in Server does not support PubSub operation. The xTR processes the Map-
[RFC6830]. Reply as specified in [I-D.ietf-lisp-rfc6833bis].
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-Record, the Map-Server MUST extract the ITR-RLOCs present in the EID-Record, the Map-Server MUST extract the ITR-RLOCs present in the
Map-Request, and store the association between the xTR-ID and those Map-Request, and store the association between the xTR-ID and those
RLOCs. Any already present state regarding ITR-RLOCs for the same RLOCs. Any already present state regarding ITR-RLOCs for the same
xTR-ID MUST be overwritten. xTR-ID MUST be overwritten.
If the Map-Request only has one ITR-RLOC with AFI = 0 (i.e. Unknown If the Map-Request only has one ITR-RLOC with AFI = 0 (i.e. Unknown
Address), the Map-Server MUST remove the subscription state for that Address), the Map-Server MUST remove the subscription state for that
xTR-ID. In this case, the Map-Server MUST send the Map-Notify to the xTR-ID. In this case, the Map-Server MUST send the Map-Notify to the
source RLOC of the Map-Request. When the TTL for the EID-record source RLOC of the Map-Request. When the TTL for the EID-record
expires, the EID-prefix is removed from the Map-Server's subscription expires, the EID-prefix is removed from the Map-Server's subscription
cache. On EID-Record removal, the Map-Server notifies the cache. On EID-Record removal, the Map-Server notifies the
subscribers via a Map-Notify with TTL equal 0. subscribers via a Map-Notify with TTL equal 0.
6. Mapping Notification Publish Procedures 7. 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 reception of Map-
Notifies via sending Map-Notify-Ack messages back to the Map-Server. Notifies via 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 updated
mapping information. The Map-Notify message sent to each of the mapping information. The Map-Notify message sent to each of the
subscribers as a result of an update event MUST follow the exact subscribers as a result of an update event MUST follow the exact
encoding and logic defined in [RFC6830] for Map-Notify, except for encoding and logic defined in [I-D.ietf-lisp-rfc6833bis] for Map-
the following: 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. with the xTR-ID of the subscriber.
(2) The nonce of the Map-Notify MUST be the one the subscriber sent (2) The nonce of the Map-Notify MUST be the one the subscriber sent
in the Map-Request. If the subscriber sent no Map-Request (e.g. in the Map-Request. If the subscriber sent no Map-Request (e.g.
was subscribed via configuration at the Map-Server) the nonce was subscribed via configuration at the Map-Server) the nonce
MUST be randomly generated by the Map-Server. MUST be randomly generated by the Map-Server.
(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 a nonce sent previously in a When the xTR receives a Map-Notify with a nonce sent previously in a
Map-Request, or with a nonce not present in any list of previously Map-Request, or with a nonce not present in any list of previously
sent nonces but with an EID not local to the xTR, the xTR knows that sent nonces but with an EID not local to the xTR, the xTR knows that
the Map-Notify has been received to update an entry on its map-cache. the Map-Notify has been received to update an entry on its map-cache.
Processing of unsolicited Map-Notify messages MUST be explicitly Processing of unsolicited Map-Notify messages MUST be explicitly
enabled via configuration at the xTR. enabled via configuration at the xTR.
The xTR processes the received Map-Notify as specified in [RFC6830], The xTR processes the received Map-Notify as specified in
with the following considerations. The xTR MUST use its security [I-D.ietf-lisp-rfc6833bis], with the following considerations. The
association with the Map-Server (see Section 3) to validate the xTR MUST use its security association with the Map-Server (see
authentication data on the Map-Notify. The xTR MUST use the mapping Section 4) to validate the authentication data on the Map-Notify.
information carried in the Map-Notify to update its internal map- The xTR MUST use the mapping information carried in the Map-Notify to
cache. The xTR MUST acknowledge the Map-Notify by sending back a update its internal map-cache. The xTR MUST acknowledge the Map-
Map-Notify-Ack (specified in [I-D.ietf-lisp-rfc6833bis]), with the Notify by sending back a Map-Notify-Ack (specified in
nonce from the Map-Notify, to the Map-Server. If after a [I-D.ietf-lisp-rfc6833bis]), with the nonce from the Map-Notify, to
configurable timeout, the Map-Server has not received back the Map- the Map-Server. If after a configurable timeout, the Map-Server has
Notify-Ack, it CAN try to send the Map-Notify to a different ITR-RLOC not received back the Map-Notify-Ack, it CAN try to send the Map-
for that xTR-ID. Notify to a different ITR-RLOC for that xTR-ID.
7. Security Considerations 8. Security Considerations
The way to provide a security association between the ITRs and the The way to provide a security association between the ITRs and the
Map-Servers must be evaluated according to the size of the Map-Servers must be evaluated according to the size of the
deployment. For small deployments, it is possible to have a shared deployment. For small deployments, it is possible to have a shared
key (or set of keys) between the ITRs and the Map-Servers. For key (or set of keys) between the ITRs and the Map-Servers. For
larger and Internet-scale deployments, scalability is a concern and larger and Internet-scale deployments, scalability is a concern and
further study is needed. further study is needed.
8. Acknowledgments 9. Acknowledgments
This work is partly funded by the ANR LISP-Lab project #ANR- This work is partly funded by the ANR LISP-Lab project #ANR-
13-INFR-009 (https://lisplab.lip6.fr). 13-INFR-009 (https://lisplab.lip6.fr).
9. IANA Considerations 10. IANA Considerations
This document makes no request to IANA. This document is requesting bit allocations in the Map-Request
message. The registry is introduced in [I-D.ietf-lisp-rfc6833bis]
and named "LISP Control Plane Header Bits". This document is adding
bits to the sub-registry "Map-Request Header Bits".
10. Normative References Sub-Registry: Map-Request Header Bits:
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=1 |A|M|P|S|p|s|R|I| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... Nonce, Source EID and ITR RLOCs ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| Reserved | EID mask-len | EID-Prefix-AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+----------+---------------+-------------+--------------------------+
| Spec | IANA Name | Bit | Description |
| Name | | Position | |
+----------+---------------+-------------+--------------------------+
| I | map-request-I | 11 | xTR-ID Bit |
| N | map-request-N | ... + 0 | Notification-Requested |
| | | | Bit |
+----------+---------------+-------------+--------------------------+
LISP Map-Request Header Bits
11. Normative References
[I-D.ietf-lisp-rfc6833bis] [I-D.ietf-lisp-rfc6833bis]
Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
"Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) Control-Plane",
draft-ietf-lisp-rfc6833bis-10 (work in progress), March draft-ietf-lisp-rfc6833bis-17 (work in progress), October
2018. 2018.
[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>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
Authors' Addresses Authors' Addresses
Alberto Rodriguez-Natal Alberto Rodriguez-Natal
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA San Jose, CA
USA USA
Email: natal@cisco.com Email: natal@cisco.com
Vina Ermagan Vina Ermagan
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA San Jose, CA
USA USA
Email: vermagan@cisco.com Email: vermagan@cisco.com
Johnson Leong Johnson Leong
Cisco Systems Cisco Systems
 End of changes. 38 change blocks. 
97 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/