draft-ietf-lisp-pubsub-08.txt		draft-ietf-lisp-pubsub-09.txt
	LISP Working Group A. Rodriguez-Natal		LISP Working Group A. Rodriguez-Natal
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Experimental V. Ermagan		Intended status: Experimental V. Ermagan
	Expires: August 6, 2021 Google		Expires: December 30, 2021 Google
	A. Cabellos		A. Cabellos
	UPC/BarcelonaTech		UPC/BarcelonaTech
	S. Barkai		S. Barkai
	Nexar		Nexar
	M. Boucadair		M. Boucadair
	Orange		Orange
	February 2, 2021		June 28, 2021
	Publish/Subscribe Functionality for LISP		Publish/Subscribe Functionality for LISP
	draft-ietf-lisp-pubsub-08		draft-ietf-lisp-pubsub-09
	Abstract		Abstract
	This document specifies an extension to the use of Map-Request to		This document specifies an extension to the Request/Reply based LISP
	enable Publish/Subscribe (PubSub) operation for LISP.		Control Plane to enable Publish/Subscribe (PubSub) operation.
	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.
	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 August 6, 2021.		This Internet-Draft will expire on December 30, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 Notation . . . . . . . . . . . . . . . . . . . . 3
	3. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 3		3. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 3
	4. Map-Request PubSub Additions . . . . . . . . . . . . . . . . 4		4. Map-Request PubSub Additions . . . . . . . . . . . . . . . . 4
	5. Mapping Request Subscribe Procedures . . . . . . . . . . . . 5		5. Mapping Request Subscribe Procedures . . . . . . . . . . . . 5
	6. Mapping Notification Publish Procedures . . . . . . . . . . . 7		6. Mapping Notification Publish Procedures . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7.1. Security Association between ITR and MS . . . . . . . . . 8		7.1. Security Association between ITR and MS . . . . . . . . . 8
	7.2. DDoS Attack Mitigation . . . . . . . . . . . . . . . . . 9		7.2. DDoS Attack Mitigation . . . . . . . . . . . . . . . . . 9
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	11. Normative References . . . . . . . . . . . . . . . . . . . . 11		11. Normative References . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6833bis]		The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6830bis]
	splits current IP addresses in two different namespaces, Endpoint		[I-D.ietf-lisp-rfc6833bis] splits current IP addresses in two
	Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map-		different namespaces, Endpoint Identifiers (EIDs) and Routing
	and-encap approach that relies on (1) a Mapping System (basically a		Locators (RLOCs). LISP uses a map-and-encap approach that relies on
	distributed database) that stores and disseminates EID-RLOC mappings		(1) a Mapping System (basically a distributed database) that stores
	and on (2) LISP tunnel routers (xTRs) that encapsulate and		and disseminates EID-RLOC mappings and on (2) LISP tunnel routers
	decapsulate data packets based on the content of those mappings.		(xTRs) that encapsulate 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) / 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 7.1 of [I-D.ietf-lisp-rfc6833bis] indicates		request message. Section 6.1 of [I-D.ietf-lisp-rfc6833bis] indicates
	how Egress Tunnel Routers (ETRs) can tell ITRs/RTRs/PITRs about		how Egress Tunnel Routers (ETRs) can tell ITRs/RTRs/PITRs about
	mapping changes. This document presents a Publish/Subscribe (PubSub)		mapping changes. This document presents a Publish/Subscribe (PubSub)
	extension in which the Mapping System can notify ITRs/RTRs/PITRs		extension in which the Mapping System can notify ITRs/RTRs/PITRs
	about mapping changes. When this mechanism is used, mapping changes		about mapping changes. When this mechanism is used, mapping changes
	can be notified faster and can be managed in the Mapping System		can be notified faster and can be managed in the Mapping System
	versus the LISP sites.		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:
	skipping to change at page 3, line 17 ¶		skipping to change at page 3, line 17 ¶
	(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 a change in the mapping of the EID-Prefix, the
	Server sends a Map-Notify message to each ITR/RTR/PITR in the		Map-Server sends a Map-Notify message to each ITR/RTR/PITR in
	subscription list.		the 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 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 BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Deployment Assumptions		3. Deployment Assumptions
	The specification described in this document makes the following		The specification described in this document makes the following
	skipping to change at page 4, line 51 ¶		skipping to change at page 4, line 51 ¶
	| |		| |
	+ 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 [I-D.ietf-lisp-rfc6833bis]:		Section 5.2 of [I-D.ietf-lisp-rfc6833bis]:
	xTR-ID bit (I-bit): The I-bit of a Map-Request message is set to 1		xTR-ID bit (I-bit): This bit is set to 1 to indicate that a 128
	to indicate that a 128 bit xTR-ID and a 64 bit Site-ID fields are		bit xTR-ID and a 64 bit Site-ID fields are present at the end of
	present at the end of the Map-Request message. If an xTR is		the Map-Request message. For PubSub operation, an xTR MUST be
	configured with an xTR-ID or Site-ID, it MUST set the I-bit to 1		configured with an xTR-ID and Site-ID, and it MUST set the I bit
	and include its xTR-ID and Site-ID in the Map-Request messages it		to 1 and include its xTR-ID and Site-ID in the Map-Request
	generates. If either the xTR-ID or Site-ID is not configured, an		messages it generates.
	unspecified value is encoded for whichever ID that is not
	configured.
	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 mapping record.		for that mapping record.
	xTR-ID field: xTR-ID is a 128 bit field at the end of the Map-		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		Request message, starting after the final Record in the message
	(or the Map-Reply Record, if present). The xTR-ID is used to		(or the Map-Reply Record, if present). The xTR-ID is used to
	uniquely identify the sender of a Map-Request message. The xTR-ID		uniquely identify the sender of a Map-Request message. The xTR-ID
	is defined in Section 5.6 of [I-D.ietf-lisp-rfc6833bis]		is defined in Section 5.6 of [I-D.ietf-lisp-rfc6833bis]
	Site-ID field: Site-ID is a 64 bit field at the end of the Map-		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		Request message, following the xTR-ID. Site-ID is used by the
	Map-Server receiving the Map-Request message to identify which		Map-Server receiving the Map-Request message to identify which
	xTRs belong to the same site. The Site-ID is defined in		xTRs belong to the same site. The Site-ID is defined in
	Section 5.6 of [I-D.ietf-lisp-rfc6833bis]		Section 5.6 of [I-D.ietf-lisp-rfc6833bis]
	5. Mapping Request Subscribe Procedures		5. Mapping Request Subscribe Procedures
	The xTR subscribes for RLOC-set changes for a given EID-prefix by		The xTR subscribes for changes for a given EID-prefix by sending a
	sending a Map-Request to the Mapping System with the N-bit set on the		Map-Request to the Mapping System with the N-bit set on the EID-
	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
	[I-D.ietf-lisp-rfc6833bis] but also does the following:		[I-D.ietf-lisp-rfc6833bis] but 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 to the Map-Request. The xTR-ID uniquely identifies the xTR.		ID to the Map-Request. The xTR-ID 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 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 [I-D.ietf-lisp-rfc6833bis]. Furthermore,		described in Section 8.3 of [I-D.ietf-lisp-rfc6833bis]. Furthermore,
	upon processing, for each EID-Record that has the N-bit set to 1, the		upon processing, for each EID-Record that has the N-bit set to 1, the
	Map-Server proceeds adding the xTR-ID contained in the Map-Request to		Map-Server proceeds to add the xTR-ID contained in the Map-Request to
	the list of xTR that have requested to be subscribed to that mapping		the list of xTRs that have requested to be subscribed to that mapping
	record.		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 5.7 of [I-D.ietf-lisp-rfc6833bis] to build the Map-Notify		Section 5.7 of [I-D.ietf-lisp-rfc6833bis] to build the Map-Notify
	with the following 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 7.1) to compute the authentication data of the Map-		(see Section 7.1) 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 (which one is implementation
			specific).
	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 [I-D.ietf-lisp-rfc6833bis] with the following		Section 5.7 of [I-D.ietf-lisp-rfc6833bis] with the following
	considerations. The xTR MUST use its security association with the		considerations. The xTR MUST use its security association with the
	Map-Server (see Section 7.1) to validate the authentication data on		Map-Server (see Section 7.1) to validate the authentication data on
	the Map-Notify. The xTR MUST use the Map-Notify to populate its map-		the Map-Notify. The xTR MUST use the Map-Notify to populate its map-
	cache with the returned EID-prefix and RLOC-set.		cache with the returned EID-prefix and RLOC-set.
	skipping to change at page 7, line 9 ¶		skipping to change at page 7, line 6 ¶
	EID-Record, the Map-Server MUST extract the nonce and ITR-RLOCs		EID-Record, 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-Record, xTR-ID, ITR-RLOCs and nonce. Any already present state		EID-Record, xTR-ID, ITR-RLOCs and nonce. Any already present state
	regarding ITR-RLOCs and/or nonce for the same xTR-ID MUST be		regarding ITR-RLOCs and/or nonce for the same xTR-ID MUST be
	overwritten.		overwritten.
	The following specifies the procedure to remove a subscription. If		The following specifies the procedure to remove a subscription. If
	the Map-Request only has one ITR-RLOC with AFI = 0 (i.e., Unknown		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.
	expires, the EID-prefix is removed from the Map-Server's subscription
	cache. On EID-Record removal, the Map-Server notifies the		When an EID-Record is removed from the Map-Server (either when
	subscribers via a Map-Notify with TTL equal 0.		explicitly withdrawn or when its TTL expires), the Map-Server
			notifies its subscribers (if any) via a Map-Notify with TTL equal 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 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 Section 5.7 of		encoding and logic defined in Section 5.7 of
	[I-D.ietf-lisp-rfc6833bis] for Map-Notify, except for the following:		[I-D.ietf-lisp-rfc6833bis] 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.		with the xTR-ID of the subscriber (which one is implementation
			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-
	Record. The starting nonce is set as follows, if the		Record. The starting nonce is set as follows, if the
	subscription state at the Map-Server was created by a received		subscription state at the Map-Server was created by a received
	Map-Request with the N-bit set, the starting nonce in the Map-		Map-Request with the N-bit set, the starting nonce in the Map-
	Notify sent as publication MUST be the one used in the Map-		Notify sent as publication MUST be the one used in the Map-
	Request that created the subscription state. If the		Request that created the subscription state. If the
	subscription state was created by explicit configuration at the		subscription state was created by explicit configuration at the
	Map-Server, the starting nonce in the Map-Notify sent as		Map-Server (possible when a pre-shared security association
	publication MUST be randomly generated by the Map-Server.		exists, see Section 7), the starting nonce in the Map-Notify
			sent as publication 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 an EID not local to the xTR,		When the xTR receives a Map-Notify with an EID not local to the xTR,
	the xTR knows that the Map-Notify has been received to update an		the xTR knows that the Map-Notify has been received to update an
	entry on its map-cache. Processing of unsolicited Map-Notify		entry on its map-cache. Processing of unsolicited Map-Notify
	messages MUST be explicitly enabled via configuration at the xTR.		messages MUST be explicitly enabled via configuration at the xTR.
	The xTR MUST keep track of the last nonce seen in a Map-Notify		The xTR MUST keep track of the last nonce seen in a Map-Notify
	received as a publication from the Map-Server for the EID-Record. If		received as a publication from the Map-Server for the EID-Record. If
	skipping to change at page 8, line 26 ¶		skipping to change at page 8, line 28 ¶
	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 [I-D.ietf-lisp-rfc6833bis], with the following considerations.		of [I-D.ietf-lisp-rfc6833bis], with the following considerations.
	The xTR MUST use its security association with the Map-Server (see		The xTR MUST use its security association with the Map-Server (see
	Section 7.1) to validate the authentication data on the Map-Notify.		Section 7.1) to validate the authentication data on the Map-Notify.
	The xTR MUST use the mapping information carried in the Map-Notify to		The xTR MUST use the mapping information carried in the Map-Notify to
	update its internal map-cache. The xTR MUST acknowledge the Map-		update its internal map-cache. The xTR MUST acknowledge the Map-
	Notify by sending back a Map-Notify-Ack (specified in Section 5.7 of		Notify by sending back a Map-Notify-Ack (specified in Section 5.7 of
	[I-D.ietf-lisp-rfc6833bis]), with the nonce from the Map-Notify, to		[I-D.ietf-lisp-rfc6833bis]), with the nonce from the Map-Notify, to
	the Map-Server. If after a configurable timeout, the Map-Server has		the Map-Server. If after a configurable timeout, the Map-Server has
	not received back the Map-Notify-Ack, it can try to send the Map-		not received back the Map-Notify-Ack, it can try to send the Map-
	Notify to a different ITR-RLOC for that xTR-ID.		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 [I-D.ietf-lisp-rfc6833bis].		discussed in Section 9 of [I-D.ietf-lisp-rfc6833bis].
	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 11, line 12 ¶		skipping to change at page 11, line 43 ¶
	Email: stefano.secci@cnam.fr		Email: stefano.secci@cnam.fr
	9. 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://www.lisp-lab.org).		13-INFR-009 (https://www.lisp-lab.org).
	10. IANA Considerations		10. IANA Considerations
	This document is requesting bit allocations in the Map-Request		This document requests IANA to assign a new bit from the "LISP
	message from the "LISP Control Plane Header Bits" registry introduced		Control Plane Header Bits: Map-Request" sub-registry under the
	in Section 12.6 of [I-D.ietf-lisp-rfc6833bis]. In particular, this		"Locator/ID Separation Protocol (LISP) Parameters" registry available
	document requests allocating the following two bits from the sub-		at [IANA-LISP]. The position of this bit in the Map-Request message
	registry "Map-Request Header Bits". The position of these two bits		can be found in Figure 1.
	in the Map-Request message can be found in Figure 1.
			+-----------+---------------+--------------+-------------+
			| Spec Name | IANA Name | Bit Position | Description |
			+-----------+---------------+--------------+-------------+
			| I | map-request-I | 11 | xTR-ID Bit |
			+-----------+---------------+--------------+-------------+
			Table 1: Additions to the Map-Request Header Bits Sub-Registry
			This document also requests the creation of a new sub-registry
			entitled "LISP Map-Request Record Bits" under the "Locator/ID
			Separation Protocol (LISP) Parameters" registry available at
			[IANA-LISP].
			The initial content of this sub-registry is shown below:
	+----------+---------------+-------------+--------------------------+		+----------+---------------+-------------+--------------------------+
	| Spec | IANA Name | Bit | Description |		| Spec | IANA Name | Bit | Description |
	| Name | | Position | |		| Name | | Position | |
	+----------+---------------+-------------+--------------------------+		+----------+---------------+-------------+--------------------------+
	| I | map-request-I | 11 | xTR-ID Bit |		| N | map-request-N | 1 | Notification-Requested |
	| N | map-request-N | ... + 0 | Notification-Requested |
	| | | | Bit |		| | | | Bit |
	+----------+---------------+-------------+--------------------------+		+----------+---------------+-------------+--------------------------+
	Table 1: Additions to the LISP Map-Request Header Bits Sub-Registry		Bits in position 2-8 are for future assignment.
			The policy for allocating new bits from this sub-registry is
			Specification Required (Section 4.6 of [RFC8126]).
	11. Normative References		11. Normative References
			[I-D.ietf-lisp-rfc6830bis]
			Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
			Cabellos, "The Locator/ID Separation Protocol (LISP)",
			draft-ietf-lisp-rfc6830bis-36 (work in progress), November
			2020.
	[I-D.ietf-lisp-rfc6833bis]		[I-D.ietf-lisp-rfc6833bis]
	Farinacci, D., Maino, F., Fuller, V., and A. Cabellos-		Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
	Aparicio, "Locator/ID Separation Protocol (LISP) Control-		"Locator/ID Separation Protocol (LISP) Control-Plane",
	Plane", draft-ietf-lisp-rfc6833bis-30 (work in progress),		draft-ietf-lisp-rfc6833bis-30 (work in progress), November
	November 2020.		2020.
	[I-D.ietf-lisp-sec]		[I-D.ietf-lisp-sec]
	Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.		Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
	Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-22		"LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-22 (work
	(work in progress), January 2021.		in progress), January 2021.
			[IANA-LISP]
			IANA, "Locator/ID Separation Protocol (LISP) Parameters",
			<https://www.iana.org/assignments/lisp-parameters/lisp-
			parameters.xhtml>.
	[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,		[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
	DOI 10.17487/RFC1982, August 1996,		DOI 10.17487/RFC1982, August 1996,
	<https://www.rfc-editor.org/info/rfc1982>.		<https://www.rfc-editor.org/info/rfc1982>.
	[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>.
			[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
			Writing an IANA Considerations Section in RFCs", BCP 26,
			RFC 8126, DOI 10.17487/RFC8126, June 2017,
			<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	Authors' Addresses		Authors' Addresses
	Alberto Rodriguez-Natal		Alberto Rodriguez-Natal
	Cisco		Cisco
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA		San Jose, CA
End of changes. 26 change blocks.
	59 lines changed or deleted		97 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/