draft-ietf-lisp-pubsub-02.txt		draft-ietf-lisp-pubsub-03.txt
	LISP Working Group A. Rodriguez-Natal		LISP Working Group A. Rodriguez-Natal
	Internet-Draft V. Ermagan		Internet-Draft Cisco Systems
	Intended status: Experimental J. Leong		Intended status: Experimental V. Ermagan
	Expires: May 7, 2019 F. Maino		Expires: September 12, 2019 Google
			J. Leong
			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
	Cnam		Cnam
	November 3, 2018		March 11, 2019
	Publish/Subscribe Functionality for LISP		Publish/Subscribe Functionality for LISP
	draft-ietf-lisp-pubsub-02		draft-ietf-lisp-pubsub-03
	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 46 ¶
	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 May 7, 2019.		This Internet-Draft will expire on September 12, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3		3. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 3
	4. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 4		4. Map-Request PubSub Additions . . . . . . . . . . . . . . . . 4
	5. Map-Request PubSub Additions . . . . . . . . . . . . . . . . 4		5. Mapping Request Subscribe Procedures . . . . . . . . . . . . 6
	6. Mapping Request Subscribe Procedures . . . . . . . . . . . . 6		6. Mapping Notification Publish Procedures . . . . . . . . . . . 8
	7. Mapping Notification Publish Procedures . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		10. Normative References . . . . . . . . . . . . . . . . . . . . 10
	11. Normative References . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	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-rfc6833bis]
	splits current IP addresses in two different namespaces, Endpoint		splits current IP addresses in two different namespaces, Endpoint
	Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map-		Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map-
	and-encap approach that relies on (1) a Mapping System (basically a		and-encap approach that relies on (1) a Mapping System (basically a
	distributed database) that stores and disseminates EID-RLOC mappings		distributed database) that stores and disseminates EID-RLOC mappings
	and on (2) LISP tunnel routers (xTRs) that encapsulate and		and on (2) LISP tunnel routers (xTRs) that encapsulate and
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 41 ¶
	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. Definition of Terms		3. Deployment Assumptions
	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 (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 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 Site-IDs) as well as the management		The distribution of xTR-IDs (and Site-IDs) as well as the management
	of security associations are out of the scope of this document and		of security associations are out of the scope of this document and
	are for further study (see Section 8).		are for further study (see Section 7).
	5. 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.		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|R|I| Reserved | IRC | Record Count |		|Type=1 |A|M|P|S|p|s|R|I| Rsvd |L|D| 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 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	unspecified value is encoded for whichever ID that is not		unspecified value is encoded for whichever ID that is not
	configured.		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, especially		uniquely identify the sender of a Map-Request message. The xTR-ID
	in the case where a site has more than one xTR. A value of all		is defined in [I-D.ietf-lisp-rfc6833bis]
	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-		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. A value of 0 indicates that a Site-		xTRs belong to the same site. The Site-ID is defined in
	ID is not specified, though encoded in the message.		[I-D.ietf-lisp-rfc6833bis]
	6. 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 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		EID-Record. The xTR builds a Map-Request according to
	[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
	skipping to change at page 7, line 15 ¶		skipping to change at page 7, line 12 ¶
	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 [I-D.ietf-lisp-rfc6833bis] to build the Map-Notify		Section 6.1.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 4) to compute the authentication data of the Map-		(see Section 3) 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
	[I-D.ietf-lisp-rfc6833bis] with the following considerations. The		[I-D.ietf-lisp-rfc6833bis] with the following considerations. The
	xTR MUST use its security association with the Map-Server (see		xTR MUST use its security association with the Map-Server (see
	Section 4) to validate the authentication data on the Map-Notify.		Section 3) to validate the authentication data on the Map-Notify.
	The xTR MUST use the Map-Notify to populate its map-cache with the		The xTR MUST use the Map-Notify to populate its map-cache with the
	returned EID-prefix and 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).
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 7 ¶
	ITR-RLOCs and/or nonce for the same xTR-ID MUST be overwritten.		ITR-RLOCs and/or nonce for the same 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.
	7. 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
	skipping to change at page 8, line 50 ¶		skipping to change at page 8, line 48 ¶
	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		The xTR processes the received Map-Notify as specified in
	[I-D.ietf-lisp-rfc6833bis], with the following considerations. The		[I-D.ietf-lisp-rfc6833bis], with the following considerations. The
	xTR MUST use its security association with the Map-Server (see		xTR MUST use its security association with the Map-Server (see
	Section 4) to validate the authentication data on the Map-Notify.		Section 3) 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		Notify by sending back a Map-Notify-Ack (specified in
	[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.
	8. 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 [I-D.ietf-lisp-rfc6833bis].		discussed in [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. Nevertheless, the		association between the ITRs and the Map-Servers. Nevertheless, the
	way to provide a security association between the ITRs and the Map-		way to provide a security association between the ITRs and the Map-
	Servers must be evaluated according to the size of the deployment.		Servers must be evaluated according to the size of the deployment.
	For small deployments, it is possible to have a shared key (or set of		For small deployments, it is possible to have a shared key (or set of
	skipping to change at page 9, line 44 ¶		skipping to change at page 9, line 43 ¶
	rate-limit Map-Notifies, a Map-Server MUST NOT send more than one		rate-limit Map-Notifies, a Map-Server MUST NOT send more than one
	Map-Notify per second to a particular xTR-ID. This parameter MUST be		Map-Notify per second to a particular xTR-ID. This parameter MUST be
	configurable. Note that when the Map-Notify rate-limit threshold is		configurable. Note that when the Map-Notify rate-limit threshold is
	met for a particular xTR-ID, the Map-Server will silently discard		met for a particular xTR-ID, the Map-Server will silently discard
	additional subscription requests from that xTR-ID. Similarly, for		additional subscription requests from that xTR-ID. Similarly, for
	pending mapping updates that need to be notified to that xTR-ID, the		pending mapping updates that need to be notified to that xTR-ID, the
	Map-Server will combine them into a single Map-Notify (with multiple		Map-Server will combine them into a single Map-Notify (with multiple
	EID-records) which it will send when the rate-limit mechanism allows		EID-records) which it will send when the rate-limit mechanism allows
	it to transmit again Map-Notifies to that xTR-ID.		it to transmit again Map-Notifies to that xTR-ID.
	9. Acknowledgments		8. 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		9. IANA Considerations
	This document is requesting bit allocations in the Map-Request		This document is requesting bit allocations in the Map-Request
	message from the "LISP Control Plane Header Bits" registry introduced		message from the "LISP Control Plane Header Bits" registry introduced
	in [I-D.ietf-lisp-rfc6833bis]. In particular, this document requests		in [I-D.ietf-lisp-rfc6833bis]. In particular, this document requests
	allocating the following two bits from the sub-registry "Map-Request		allocating the following two bits from the sub-registry "Map-Request
	Header Bits". The position of these two bits in the Map-Request		Header Bits". The position of these two bits in the Map-Request
	message can be found in Figure 1.		message can be found in Figure 1.
	+----------+---------------+-------------+--------------------------+		+----------+---------------+-------------+--------------------------+
	| Spec | IANA Name | Bit | Description |		| Spec | IANA Name | Bit | Description |
	| Name | | Position | |		| Name | | Position | |
	+----------+---------------+-------------+--------------------------+		+----------+---------------+-------------+--------------------------+
	| I | map-request-I | 11 | xTR-ID Bit |		| I | map-request-I | 11 | xTR-ID Bit |
	| N | map-request-N | ... + 0 | Notification-Requested |		| N | map-request-N | ... + 0 | Notification-Requested |
	| | | | Bit |		| | | | Bit |
	+----------+---------------+-------------+--------------------------+		+----------+---------------+-------------+--------------------------+
	Table 1: Additions to the LISP Map-Request Header Bits Sub-Registry		Table 1: Additions to the LISP Map-Request Header Bits Sub-Registry
	11. Normative References		10. 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-19 (work in progress), October		draft-ietf-lisp-rfc6833bis-24 (work in progress), February
	2018.		2019.
	[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>.
	Authors' Addresses		Authors' Addresses
	Alberto Rodriguez-Natal		Alberto Rodriguez-Natal
	Cisco Systems		Cisco Systems
	skipping to change at page 11, line 4 ¶		skipping to change at page 10, line 41 ¶
	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		Google
	170 Tasman Drive
	San Jose, CA
	USA		USA
	Email: vermagan@cisco.com		Email: ermagan@gmail.com
	Johnson Leong		Johnson Leong
	Cisco Systems		Cisco Systems
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA		San Jose, CA
	USA		USA
	Email: joleong@cisco.com		Email: joleong@cisco.com
	Fabio Maino		Fabio Maino
	Cisco Systems		Cisco Systems
End of changes. 26 change blocks.
	54 lines changed or deleted		40 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/