Diff: rfc9962.original

	rfc9962.original	rfc9962.txt


	Network Working Group D. Farinacci	Independent Submission D. Farinacci
	Internet-Draft lispers.net	Request for Comments: 9962 lispers.net
	Intended status: Informational C. Cantrell	Category: Informational C. Cantrell
	Expires: 15 September 2026 Nexus	ISSN: 2070-1721 Nexus
	14 March 2026	April 2026

	A Decent LISP Mapping System (LISP-Decent)	A Decent LISP Mapping System (LISP-Decent)

	draft-farinacci-lisp-decent-22

	Abstract	Abstract


	This draft describes how the LISP mapping system can be distributed	This document describes how the Locator/ID Separation Protocol (LISP)
	for scale, decentralized for management and maintain trust among	mapping system can be distributed for scale, decentralized for
	data-plane nodes. The intended status for this document is	management and maintain trust among data plane nodes. This is an
	Informational RFC and should be used by LISP-Decent implementations	Informational RFC and should be used by LISP-Decent implementations
	to interoperate with each other.	to interoperate with each other.


	Requirements Language

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.

	Status of This Memo	Status of This Memo


	This Internet-Draft is submitted in full conformance with the	This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.	published for informational purposes.

	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 is a contribution to the RFC Series, independently of any other
	and may be updated, replaced, or obsoleted by other documents at any	RFC stream. The RFC Editor has chosen to publish this document at
	time. It is inappropriate to use Internet-Drafts as reference	its discretion and makes no statement about its value for
	material or to cite them other than as "work in progress."	implementation or deployment. Documents approved for publication by
		the RFC Editor are not candidates for any level of Internet Standard;
		see Section 2 of RFC 7841.


	This Internet-Draft will expire on 15 September 2026.	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/rfc9962.

	Copyright Notice	Copyright Notice

	Copyright (c) 2026 IETF Trust and the persons identified as the	Copyright (c) 2026 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
	Please review these documents carefully, as they describe your rights	publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components	carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as	to this document.
	described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.

	Table of Contents	Table of Contents


	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction
	2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4	2. Definitions of Terms
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5	2.1. Requirements Language
	4. Decent-Push Based Mapping System . . . . . . . . . . . . . . 6	3. Overview
	4.1. Components of a Decent-Pushed Based LISP-Decent xTR . . . 7	4. Decent-Push-Based Mapping System
	4.2. Implementation Considerations . . . . . . . . . . . . . . 8	4.1. Components of a Decent-Pushed Based LISP-Decent xTR
	4.3. Configuration and Authentication . . . . . . . . . . . . 9	4.2. Implementation Considerations
	4.4. Core Seed-Group . . . . . . . . . . . . . . . . . . . . . 9	4.3. Configuration and Authentication
	5. Decent-Pull Based Mapping System . . . . . . . . . . . . . . 11	4.4. Core Seed-Group
	5.1. Components of a Decent-Pulled Based LISP-Decent xTR . . . 11	5. Decent-Pull-Based Mapping System
	5.2. Configurable EID Prefix Lengths for Lookups . . . . . . . 12	5.1. Components of a Decent-Pulled Based LISP-Decent xTR
	5.3. Deployment Example . . . . . . . . . . . . . . . . . . . 14	5.2. Configurable EID Prefix Lengths for Lookups
	5.4. Management Considerations . . . . . . . . . . . . . . . . 15	5.3. Deployment Example
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 15	5.4. Management Considerations
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16	6. Security Considerations
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16	7. IANA Considerations
	8.1. Normative References . . . . . . . . . . . . . . . . . . 16	8. References
	8.2. Informative References . . . . . . . . . . . . . . . . . 17	8.1. Normative References
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18	8.2. Informative References
	Appendix B. Document Change Log . . . . . . . . . . . . . . . . 18	Acknowledgments
	B.1. Changes to draft-farinacci-lisp-decent-22 . . . . . . . . 18	Authors' Addresses
	B.2. Changes to draft-farinacci-lisp-decent-21 . . . . . . . . 18
	B.3. Changes to draft-farinacci-lisp-decent-20 . . . . . . . . 18
	B.4. Changes to draft-farinacci-lisp-decent-19 . . . . . . . . 19
	B.5. Changes to draft-farinacci-lisp-decent-18 . . . . . . . . 19
	B.6. Changes to draft-farinacci-lisp-decent-17 . . . . . . . . 19
	B.7. Changes to draft-farinacci-lisp-decent-16 . . . . . . . . 19
	B.8. Changes to draft-farinacci-lisp-decent-15 . . . . . . . . 19
	B.9. Changes to draft-farinacci-lisp-decent-14 . . . . . . . . 19
	B.10. Changes to draft-farinacci-lisp-decent-13 . . . . . . . . 20
	B.11. Changes to draft-farinacci-lisp-decent-12 . . . . . . . . 20
	B.12. Changes to draft-farinacci-lisp-decent-11 . . . . . . . . 20
	B.13. Changes to draft-farinacci-lisp-decent-10 . . . . . . . . 20
	B.14. Changes to draft-farinacci-lisp-decent-09 . . . . . . . . 20
	B.15. Changes to draft-farinacci-lisp-decent-08 . . . . . . . . 20
	B.16. Changes to draft-farinacci-lisp-decent-07 . . . . . . . . 20
	B.17. Changes to draft-farinacci-lisp-decent-06 . . . . . . . . 20
	B.18. Changes to draft-farinacci-lisp-decent-05 . . . . . . . . 21
	B.19. Changes to draft-farinacci-lisp-decent-04 . . . . . . . . 21
	B.20. Changes to draft-farinacci-lisp-decent-03 . . . . . . . . 21
	B.21. Changes to draft-farinacci-lisp-decent-02 . . . . . . . . 21
	B.22. Changes to draft-farinacci-lisp-decent-01 . . . . . . . . 21
	B.23. Changes to draft-farinacci-lisp-decent-00 . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22

	1. Introduction	1. Introduction

	The LISP architecture and protocols [RFC9300] introduces two new	The LISP architecture and protocols [RFC9300] introduces two new
	numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators	numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators
	(RLOCs) that are intended to provide overlay network functionality.	(RLOCs) that are intended to provide overlay network functionality.

	To map from EID to a set of RLOCs, a control-plane mapping system is	To map from EIDs to a set of RLOCs, a control plane mapping system is
	used [RFC6836] [RFC8111]. These mapping systems are naturally	used [RFC6836] [RFC8111]. These mapping systems are naturally
	distributed in their deployment for scalability but are centrally	distributed in their deployment for scalability but are centrally
	managed by a third-party entity, namely a Mapping System Provider	managed by a third-party entity, namely a Mapping System Provider

	(MSP). The entities that use the mapping system, such as data-plane	(MSP). The entities that use the mapping system, such as data plane
	LISP Tunnel Routers (xTRs), depend on and trust the MSP. They do not	LISP Tunnel Routers (xTRs), depend on and trust the MSP. They do not
	participate in the mapping system other than to register and retrieve	participate in the mapping system other than to register and retrieve
	information [RFC9301].	information [RFC9301].

	This document introduces a Decentralized Mapping System (DMS) so the	This document introduces a Decentralized Mapping System (DMS) so the
	xTRs can participate in the mapping system as well as use it. They	xTRs can participate in the mapping system as well as use it. They
	can trust each other rather than rely on third-party infrastructure.	can trust each other rather than rely on third-party infrastructure.
	The xTRs act as Map-Servers to maintain distributed state for scale	The xTRs act as Map-Servers to maintain distributed state for scale
	and reduce the attack surface. The trust relationships between the	and reduce the attack surface. The trust relationships between the
	xTRs are established through authentication and authorization	xTRs are established through authentication and authorization

	procedures in [RFC9301] and [I-D.ietf-lisp-ecdsa-auth].	procedures in [RFC9301] and [ECDSA-AUTH].


	This design was first introduced to the LISP WG in January 2018. It	This design was first introduced to the LISP Working Group (WG) in
	was presented in London March 2018 [MAR-WG-PRESO] and in Prague July	January of 2018. It was presented in London in March 2018
	2019 [JUL-WG-PRESO]. This informational document is not a standard	[IETF101-PRESO] and in Prague in March 2019 [IETF104-PRESO]. This
	and did not reach community consensus to make it IETF LISP working	Informational document is not a standard and did not reach community
	group document.	consensus to make it an IETF LISP WG document.

	The intended audience for this specification are protocol development	The intended audience for this specification are protocol development
	engineers who would implement this specification in products as well	engineers who would implement this specification in products as well
	network engineers who deploy the technology in operational	network engineers who deploy the technology in operational
	environments.	environments.

	This design does not conflict with those designs or contradicts any	This design does not conflict with those designs or contradicts any
	other LISP design principles produced by the working group. This	other LISP design principles produced by the working group. This

	solution makes no fundamental LISP protocol changes and adheres to	solution makes no fundamental LISP changes and adheres to the
	the specifications documented in [RFC9301].	specifications documented in [RFC9301].

	By the nature of this work, this document uses IP addresses as	By the nature of this work, this document uses IP addresses as
	examples. They should not be copied or used outside of a lab	examples. They should not be copied or used outside of a lab
	environment. Deployments should use addresses appropriate for their	environment. Deployments should use addresses appropriate for their
	environment.	environment.


	2. Definition of Terms	2. Definitions of Terms


	Mapping System Provider (MSP): infrastructure service that deploys	Mapping System Provider (MSP): Infrastructure service that deploys
	LISP Map-Resolvers and Map-Servers [RFC9301] and possibly LISP-ALT	LISP Map-Resolvers and Map-Servers [RFC9301] and possibly LISP-ALT
	nodes [RFC6836] or LISP-DDT nodes [RFC8111]. ALT-nodes and DDT-	nodes [RFC6836] or LISP-DDT nodes [RFC8111]. ALT-nodes and DDT-

	nodes use different algorithms for connecting together Map-	nodes use different algorithms for connecting Map-Resolvers and
	Resolvers and Map-Servers. The MSP can be managed by a separate	Map-Servers together. The MSP can be managed by a separate
	organization other than the one that manages xTRs. This model	organization other than the one that manages xTRs. This model
	provides a business separation between who manages and responsible	provides a business separation between who manages and responsible

	for the control-plane versus who manages the data-plane overlay	for the control-plane versus who manages the data plane overlay
	service.	service.


	Decentralized Mapping System (DMS): a mapping system entity that is	Decentralized Mapping System (DMS): A mapping system entity that is
	managed by the xTR nodes that use it and not third-party nodes/	managed by the xTR nodes that use it and not third-party nodes/
	operators. The xTRs themselves are part of the mapping system.	operators. The xTRs themselves are part of the mapping system.
	The state of the mapping system is fully distributed across xTRs,	The state of the mapping system is fully distributed across xTRs,
	decentralized, and the trust relies on the xTRs that use and	decentralized, and the trust relies on the xTRs that use and
	participate in their own mapping system.	participate in their own mapping system.


	Decent-Pull Based Mapping System: the mapping system is pull-based	Decent-Pull-Based Mapping System: The mapping system is pull-based,
	meaning that xTRs will lookup and register mappings by algorithmic	meaning that xTRs will look up and register mappings by
	transformation to locate which Map-Resolvers and Map-Servers are	algorithmic transformation to locate which Map-Resolvers and Map-
	used. It is required that the lookup and registration uses a	Servers are used. It is required that the lookup and registration
	consistent algorithmic transformation function. Map-Registers are	uses a consistent algorithmic transformation function. Map-
	sent to specific Map-Servers. Map-Requests are considered	Registers are sent to specific Map-Servers. Map-Requests are
	external lookups when sent to Map-Resolvers on xTRs that do not	considered external lookups when sent to Map-Resolvers on xTRs
	participate in the mapping system and the Map-Requests are	that do not participate in the mapping system and the Map-Requests
	considered internal lookups when they are sent to Map-Resolvers on	are considered internal lookups when they are sent to Map-
	xTRs that do participate in the mapping system.	Resolvers on xTRs that do participate in the mapping system.


	Modulus Value: this value is used in the Pull-Based Mapping System.	Modulus Value: This value is used in the Pull-based Mapping System.
	It defines the number of map-server sets used for the mapping	It defines the number of map-server sets used for the mapping
	system. The modulus value is used to produce a Name Index used	system. The modulus value is used to produce a Name Index used

	for a DNS lookup. The Modulus Value is chosen based on the	for a Domain Name System (DNS) lookup. The Modulus Value is
	horizontal scale-out width of the map-server cluster the network	chosen based on the horizontal scale-out width of the map-server
	operator chooses to deploy.	cluster the network operator chooses to deploy.


	Name Index: this index value <index> is used in the Pull-Based	Name Index: This index value <index> is used in the Pull-based
	Mapping System. For a mapping system that is configured with a	Mapping System. For a mapping system that is configured with a
	map-server set of DNS names in the form of <name>.example.com, the	map-server set of DNS names in the form of <name>.example.com, the

	name index is prepended to <name> to form the lookup name	Name Index is prepended to <name> to form the lookup name
	<index>.<name>.example.com. If the Modulus Value is 8, then the	<index>.<name>.example.com. If the Modulus Value is 8, then the

	name indexes are 0 through 7.	Name Indexes are 0 through 7.


	Hash Mask: The Hash Mask is used in the Pull-Based Mapping System.	Hash Mask: The Hash Mask is used in the Pull-based Mapping System.
	It is a mask value with 1 bits left justified. The mask is used	It is a mask value with 1 bit left justified. The mask is used to
	to select what high-order bits of an EID-prefix are used in the	select what high-order bits of an EID-prefix are used in the hash
	hash function.	function.


	Decent-Push Based Mapping System: the mapping system is push-based	Decent-Push-Based Mapping System: The mapping system is push-based,
	meaning that xTRs will push registrations via IP multicast to a	meaning that xTRs will push registrations via IP multicast to a
	group of Map-Servers and do local lookups acting as their own Map-	group of Map-Servers and do local lookups acting as their own Map-
	Resolvers.	Resolvers.


	Replication List Entry (RLE): an RLOC-record format that contains a	Replication List Entry (RLE): An RLOC-record format that contains a
	list of RLOCs that an Ingress Tunnel Router (ITR) replicates	list of RLOCs that an Ingress Tunnel Router (ITR) replicates
	multicast packets on a multicast overlay. The RLE format is	multicast packets on a multicast overlay. The RLE format is
	specified in [RFC8060]. RLEs are used with the Decent-Pushed	specified in [RFC8060]. RLEs are used with the Decent-Pushed
	Based mapping system.	Based mapping system.


	Group Address EID: an EID-record format that contains IPv4	Group Address EID: An EID-record format that contains IPv4
	(0.0.0.0/0, G) or IPv6 (0::/0, G) state. This state is encoded as	(0.0.0.0/0, G) or IPv6 (0::/0, G) state. This state is encoded as

	a Multicast Info Type LCAF specified in [RFC8060]. Members of a	a Multicast Info Type LISP Canonical Address Format (LCAF)
	seed-group send Map-Registers for (0.0.0.0/0, G) or (0::/0, G)	specified in [RFC8060]. Members of a seed-group send Map-
	with an RLOC-record that RLE encodes its RLOC address. Details	Registers for (0.0.0.0/0, G) or (0::/0, G) with an RLOC-record
	are specified in [RFC8378].	that RLE encodes its RLOC address. Details are specified in
		[RFC8378].


	Seed-Group: a set of Map-Servers joined to a multicast group for the	Seed-Group: A set of Map-Servers joined to a multicast group for the
	Decent-Push Based Mapping system or are mapped by DNS names in a	Decent-Push-based Mapping System or are mapped by DNS names in a
	Pull-Based Mapping System. A core seed-group is used to bootstrap	Pull-based Mapping System. A core seed-group is used to bootstrap
	a set of LISP-Decent xTRs so they can learn about each other and	a set of LISP-Decent xTRs so they can learn about each other and
	use each other's mapping system service. A seed-group can be	use each other's mapping system service. A seed-group can be

	pull-based to bootstrap the Decent-Push based mapping system.	pull-based to bootstrap the Decent-Push-based Mapping System.
	That is, a set of DNS mapped map-servers can be used to join the	That is, a set of DNS mapped map-servers can be used to join the
	mapping system's IP multicast group.	mapping system's IP multicast group.


		2.1. Requirements Language

		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
		"OPTIONAL" in this document are to be interpreted as described in
		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
		capitals, as shown here.

	3. Overview	3. Overview


	The clients of the Decentralized Mapping System (DMS) are also the	The clients of the DMS are also the providers of mapping state, see
	providers of mapping state, see [RFC9301] for formal details.	[RFC9301] for formal details. Clients are typically Egress Tunnel
	Clients are typically Egress Tunnel Routers (ETRs) that Map-Register	Routers (ETRs) that Map-Register EID-to-RLOC mapping state to the
	EID-to-RLOC mapping state to the mapping database system. ITRs are	mapping database system. ITRs are clients in that they send Map-
	clients in that they send Map-Requests to the mapping database system	Requests to the mapping database system to obtain EID-to-RLOC
	to obtain EID-to-RLOC mappings that are cached for data-plane use.	mappings that are cached for data plane use. When xTRs participate
	When xTRs participate in a DMS, they are also acting as Map-Resolvers	in a DMS, they are also acting as Map-Resolvers and Map-Servers using
	and Map-Servers using the protocol machinery defined in LISP control-	the protocol machinery defined in LISP control plane specifications
	plane specifications [RFC9301], [RFC9303], and	[RFC9301], [RFC9303], and [ECDSA-AUTH]. The xTRs are not required to
	[I-D.ietf-lisp-ecdsa-auth]. The xTRs are not required to run the	run the database mapping transport system protocols specified in
	database mapping transport system protocols specified in [RFC6836] or	[RFC6836] or [RFC8111].
	[RFC8111].

	This document will describe two decentralized and distributed mapping	This document will describe two decentralized and distributed mapping

	system mechanisms. A Decent-Push Based Mapping System uses IP	system mechanisms. A Decent-Push-based Mapping System uses IP
	multicast so xTRs can find each other by locally joining an IP	multicast so xTRs can find each other by locally joining an IP

	multicast group. A Decent-Pull Based Mapping System uses DNS with an	multicast group. A Decent-Pull-based Mapping System uses DNS with an
	algorithmic transformation function so xTRs can find each other.	algorithmic transformation function so xTRs can find each other.

	The document proposes two approaches to provide state/bandwidth, ease	The document proposes two approaches to provide state/bandwidth, ease

	of configurability, and robustness/complexity tradeoffs. When the	of configurability, and robustness/complexity trade-offs. When the
	Decent-Push Based approach is used there is less messaging involved.	Decent-Push-based approach is used, there is less messaging involved.
	xTRs can multicast a single Map-Register message which goes to all	xTRs can multicast a single Map-Register message that goes to all
	Map-Servers joined to the multicast group. When Map-Servers are	Map-Servers joined to the multicast group. When Map-Servers are
	added to or removed from the Map-Server cluster group, the mapping	added to or removed from the Map-Server cluster group, the mapping
	system updates quickly with little human intervention. In the push	system updates quickly with little human intervention. In the push
	model, all mapping state is stored in all Map-Servers so there is	model, all mapping state is stored in all Map-Servers so there is
	robustness achieved through redundancy. However, this requires a	robustness achieved through redundancy. However, this requires a
	multicast underlay in nodes between all xTRs and Map-Servers. When a	multicast underlay in nodes between all xTRs and Map-Servers. When a

	multicast underlay is not available, the Decent-Pull Based approach	multicast underlay is not available, the Decent-Pull-based approach
	can be used with the help of the DNS system. This approach uses less	can be used with the help of the DNS. This approach uses less state
	state overall among the Map-Servers (they each have different mapping	overall among the Map-Servers (they each have different mapping
	system state) and the ITRs know which Map-Server to ask by using the	system state) and the ITRs know which Map-Server to ask by using the
	hashing techniques described later in this document.	hashing techniques described later in this document.

	This document does not describe any compatibility with other mapping	This document does not describe any compatibility with other mapping
	systems. The design is intentional all xTRs and Map-Servers support	systems. The design is intentional all xTRs and Map-Servers support
	this specification. Moreover, all xTRs and Map-Servers MUST support	this specification. Moreover, all xTRs and Map-Servers MUST support

	either the Pull-Based or Push-Based algorithms. They cannot be	either the pull-based or push-based algorithms. They cannot be
	mixed. When both are used, they are completely discrete mapping	mixed. When both are used, they are completely discrete mapping

	systems just like they would be using one of the LISP Working Group	systems just like they would be using one of the LISP WG mapping
	mapping system designs. An implementation can decide to implement	system designs. An implementation can decide to implement only the
	only the Pull-Based approach or the Push-Based approach and still be	pull-based approach or the push-based approach and still be compliant
	compliant with this specification.	with this specification.


	4. Decent-Push Based Mapping System	4. Decent-Push-Based Mapping System

	The xTRs are organized in a mapping-system group. The group is	The xTRs are organized in a mapping-system group. The group is
	identified by an IPv4 or IPv6 multicast group address or using a	identified by an IPv4 or IPv6 multicast group address or using a

	Decent-Pull based approach described in Section 5. When using	Decent-Pull-based approach described in Section 5. When using
	multicast, the xTRs join the same multicast group and receive LISP	multicast, the xTRs join the same multicast group and receive LISP

	control-plane messages addressed to the group. Messages sent to the	control plane messages addressed to the group. Messages sent to the
	multicast group are distributed when the underlay network supports IP	multicast group are distributed when the underlay network supports IP
	multicast [RFC6831] or via the overlay multicast mechanism described	multicast [RFC6831] or via the overlay multicast mechanism described
	in [RFC8378]. When overlay multicast is used and LISP Map-Register	in [RFC8378]. When overlay multicast is used and LISP Map-Register
	messages are sent to the group, they are LISP data encapsulated with	messages are sent to the group, they are LISP data encapsulated with

	a instance-ID set to 0xffffff in the LISP header. The inner header	an instance-ID set to 0xffffff in the LISP header. The inner header
	of the encapsulated packet has the destination address set to the	of the encapsulated packet has the destination address set to the
	multicast group address and the outer header that is prepended has	multicast group address and the outer header that is prepended has
	the destination address set to the RLOC of mapping system group	the destination address set to the RLOC of mapping system group
	member. The members of the mapping system group are kept in the LISP	member. The members of the mapping system group are kept in the LISP

	data-plane map-cache so packets for the group can be replicated to	data plane map-cache so packets for the group can be replicated to
	each member RLOC.	each member RLOC.

	All xTRs in a mapping system group will store the same registered	All xTRs in a mapping system group will store the same registered
	mappings and maintain the state as Map-Servers normally do. The	mappings and maintain the state as Map-Servers normally do. The

	members are not only receivers of the multicast group but also send	members are not only receivers of the multicast group, but they also
	packets to the group.	send packets to the group.

	4.1. Components of a Decent-Pushed Based LISP-Decent xTR	4.1. Components of a Decent-Pushed Based LISP-Decent xTR

	When an xTR is configured to be a LISP-Decent xTR (or PxTR	When an xTR is configured to be a LISP-Decent xTR (or PxTR
	[RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP	[RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP
	network functions.	network functions.

	The following diagram shows 3 LISP-Decent xTRs joined to mapping	The following diagram shows 3 LISP-Decent xTRs joined to mapping
	system group 233.252.1.1. When the ETR function of xTR1 originates a	system group 233.252.1.1. When the ETR function of xTR1 originates a
	Map-Register, it is sent to all xTRs (including itself) synchronizing	Map-Register, it is sent to all xTRs (including itself) synchronizing

	skipping to change at page 8, line 10 ¶	skipping to change at line 290 ¶
	233.252.1.1.	233.252.1.1.

	In this document, there is no special meaning for the multicast group	In this document, there is no special meaning for the multicast group
	address 233.252.1.1. It is used for example purposes only.	address 233.252.1.1. It is used for example purposes only.

	xTR1	xTR1
	Map-Request +--------------------+	Map-Request +--------------------+
	(always local) \| +-----+ +-----+ \|	(always local) \| +-----+ +-----+ \|
	+---------------\| ITR \| \| ETR \|-------------+	+---------------\| ITR \| \| ETR \|-------------+
	\| \| +-----+ +-----+ \| \|	\| \| +-----+ +-----+ \| \|

	\| \| \| \| Map-Register to EID	\| \| \| \| Map-Register to
	\| \| +-------+ \| \| 233.252.1.1 encapsulated to	\| \| +-------+ \| \| EID 233.252.1.1
	+------------------>\| MR/MS \|<---------------+ RLOCs xTR1, xTR2, and xTR3	+------------------>\| MR/MS \|<---------------+ encapsulated to
	\| +-------+ \| \|	\| +-------+ \| \| RLOCs xTR1, xTR2,
	+--------------------+ \|	+--------------------+ \| and xTR3
	\|	\|
	+--------------------+------------+	+--------------------+------------+
	\| \|	\| \|
	\| \|	\| \|
	+----------v---------+ +----------v---------+	+----------v---------+ +----------v---------+
	\| +--------+ \| \| +--------+ \|	\| +--------+ \| \| +--------+ \|
	\| \| MR/MS \| \| \| \| MR/MS \| \|	\| \| MR/MS \| \| \| \| MR/MS \| \|
	\| +--------+ \| \| +--------+ \|	\| +--------+ \| \| +--------+ \|
	\| +-----+ +-----+ \| \| +-----+ +-----+ \|	\| +-----+ +-----+ \| \| +-----+ +-----+ \|
	\| \| ITR \| \| ETR \| \| \| \| ITR \| \| ETR \| \|	\| \| ITR \| \| ETR \| \| \| \| ITR \| \| ETR \| \|
	\| +-----+ +-----+ \| \| +-----+ +-----+ \|	\| +-----+ +-----+ \| \| +-----+ +-----+ \|
	+--------------------+ +--------------------+	+--------------------+ +--------------------+
	xTR2 xTR3	xTR2 xTR3


	Note if any external xTR would like to use a Map-Resolver from the	Note that if any external xTR would like to use a Map-Resolver from
	mapping system group, it only needs to have one of the LISP-Decent	the mapping system group, it only needs to have one of the LISP-
	Map-Resolvers configured. By doing a looking to this Map-Resolver	Decent Map-Resolvers configured. By looking at the Map-Resolver for
	for EID 233.252.1.1, the external xTR could get the complete list of	EID 233.252.1.1, the external xTR could get the complete list of
	members for the mapping system group.	members for the mapping system group.

	For future study, an external xTR could multicast the Map-Request to	For future study, an external xTR could multicast the Map-Request to
	233.252.1.1 and either one of the LISP-Decent Map-Resolvers would	233.252.1.1 and either one of the LISP-Decent Map-Resolvers would
	return a Map-Reply or the external xTR is prepared to receive	return a Map-Reply or the external xTR is prepared to receive
	multiple Map-Replies.	multiple Map-Replies.

	4.2. Implementation Considerations	4.2. Implementation Considerations


	There are no LISP protocol changes required to support the Decent-	There are no LISP changes required to support the Decent-Push-based
	Push based LISP-Decent set of procedures. An implementation that	LISP-Decent set of procedures. An implementation that sends Map-
	sends Map-Register messages to a multicast group versus a specific	Register messages to a multicast group versus a specific Map-Server
	Map-Server unicast address MUST change to call the data-plane	unicast address MUST change to call the data plane component so the
	component so the ITR functionality in the node can encapsulate the	ITR functionality in the node can encapsulate the Map-Register as a
	Map-Register as a unicast packet to each member of the mapping system	unicast packet to each member of the mapping system group.
	group.


	An ITR SHOULD lookup its mapping system group address periodically to	An ITR SHOULD look up its mapping system group address periodically
	determine if the membership has changed. The lookup interval is a	to determine if the membership has changed. The lookup interval is a
	configuration parameter only needed when when the ITR does not use	configuration parameter only needed when the ITR does not use the
	the PubSub capability documented in [RFC9437] to be notified when a	PubSub capability documented in [RFC9437] to be notified when a new
	new member joins or leaves the multicast group. When PubSub is not	member joins or leaves the multicast group. When PubSub is not used,
	used, there needs to be coordination (via configuration management)	there needs to be coordination (via configuration management) among
	among all xTRs so they rendezvous roughly at the same time and to the	all xTRs so they rendezvous roughly at the same time and to the same
	same group address.	group address.

	4.3. Configuration and Authentication	4.3. Configuration and Authentication

	When xTRs are joined to a multicast group, they MUST have their site	When xTRs are joined to a multicast group, they MUST have their site
	registration configuration consistent. Any policy or authentication	registration configuration consistent. Any policy or authentication
	key material MUST be configured consistently among all members. When	key material MUST be configured consistently among all members. When

	[I-D.ietf-lisp-ecdsa-auth] is used to sign Map-Register messages,	[ECDSA-AUTH] is used to sign Map-Register messages, public keys can
	public-keys can be registered to the mapping system group using the	be registered to the mapping system group using the site
	site authentication key mentioned above or using a different	authentication key mentioned above or using a different
	authentication key from the one used for registering EID records. An	authentication key from the one used for registering EID records. An
	out-of-band registration controller, like an ETR dedicated for this	out-of-band registration controller, like an ETR dedicated for this
	function, can send Map-Register messages for public-key encoded EIDs.	function, can send Map-Register messages for public-key encoded EIDs.

	4.4. Core Seed-Group	4.4. Core Seed-Group

	A core seed-group can be discovered using a multicast group in a	A core seed-group can be discovered using a multicast group in a

	Decent-Push based system or a Map-Server set of DNS names in a	Decent-Push-based system or a Map-Server set of DNS names in a
	Decent-Pull based system (see Section 5 for details).	Decent-Pull-based system (see Section 5 for details).

	When using multicast for the mapping system group, a core seed-group	When using multicast for the mapping system group, a core seed-group
	multicast group address can be preconfigured to bootstrap the	multicast group address can be preconfigured to bootstrap the
	decentralized mapping system. The group address (or DNS name that	decentralized mapping system. The group address (or DNS name that
	maps to a group address) can be explicitly configured in a few xTRs	maps to a group address) can be explicitly configured in a few xTRs
	to start building up the registrations. Then as other xTRs come	to start building up the registrations. Then as other xTRs come
	online, they can add themselves to the core seed-group by joining the	online, they can add themselves to the core seed-group by joining the
	seed-group multicast group.	seed-group multicast group.

	Alternatively or additionally, new xTRs can join a new mapping system	Alternatively or additionally, new xTRs can join a new mapping system
	multicast group to form another layer of a decentralized mapping	multicast group to form another layer of a decentralized mapping
	system. The group address and members of this new layer seed-group	system. The group address and members of this new layer seed-group
	would be registered to the core seed-group address and stored in the	would be registered to the core seed-group address and stored in the

	core seed-group mapping system. Note each mapping system layer could	core seed-group mapping system. Note that each mapping system layer
	have a specific function or a specific circle of trust.	could have a specific function or a specific circle of trust.

	This multi-layer mapping system can be illustrated:	This multi-layer mapping system can be illustrated:

	____________ -----------	____________ -----------
	/ core \ 233.252.2.2 / layer-1 \	/ core \ 233.252.2.2 / layer-1 \
	\| seed-group \| ----------> \| I \|	\| seed-group \| ----------> \| I \|
	\| 233.252.1.1 \| \| / \ \|	\| 233.252.1.1 \| \| / \ \|
	\____________/ \| J---K \|	\____________/ \| J---K \|
	\| \___________/	\| \___________/
	\| 233.252.3.3	\| 233.252.3.3

	skipping to change at page 10, line 39 ¶	skipping to change at line 407 ¶
	EID1 -> RLOCs: i(1), j(2)	EID1 -> RLOCs: i(1), j(2)
	...	...
	EIDn -> RLOCs: i(n), j(n)	EIDn -> RLOCs: i(n), j(n)

	layer-2 seed-group DMS (intra-continental), mapping sate in X, Y, Z::	layer-2 seed-group DMS (intra-continental), mapping sate in X, Y, Z::
	EIDa -> RLOCs: x(1), y(2)	EIDa -> RLOCs: x(1), y(2)
	...	...
	EIDz -> RLOCs: x(n), y(n)	EIDz -> RLOCs: x(n), y(n)

	The core seed-group multicast address 233.252.1.1 is configured in	The core seed-group multicast address 233.252.1.1 is configured in

	xTRs A, B and C so when each of them send Map-Register messages, they	xTRs A, B, and C so when each of them send Map-Register messages,
	would all be able to maintain synchronized mapping state. Any EID	they would all be able to maintain synchronized mapping state. Any
	can be registered to this DMS but in this example, seed-group	EID can be registered to this DMS, but in this example, seed-group
	multicast group EIDs are being registered only to find other mapping	multicast group EIDs are being registered only to find other mapping
	system groups.	system groups.


	For example, lets say that xTR I boots up and it wants to find its	For example, xTR I boots up and it wants to find its other peers in
	other peers in its mapping system group 233.252.2.2. Group address	its mapping system group 233.252.2.2. Group address 233.252.2.2 is
	233.252.2.2 is configured so xTR I knows what group to join for its	configured so xTR I knows what group to join for its mapping system
	mapping system group. But xTR I needs a mapping system to register	group. However, xTR I needs a mapping system to register to, so the
	to, so the core seed-group is used and available to receive Map-	core seed-group is used and available to receive Map-Registers. The
	Registers. The other xTRs J and K in the mapping system group do the	other xTRs J and K in the mapping system group do the same so when
	same so when any of I, J or K needs to register EIDs, they can now	any of I, J, or K needs to register EIDs, they can now send their
	send their Map-Register messages to group 233.252.2.2. Examples of	Map-Register messages to group 233.252.2.2. Examples of EIDs being
	EIDs being register are EID1 through EIDn shown above.	registered are EID1 through EIDn shown above.

	When Map-Registers are sent to group 233.252.2.2, they are	When Map-Registers are sent to group 233.252.2.2, they are

	encapsulated by the LISP data-plane by looking up EID 233.252.2.2 in	encapsulated by the LISP data plane by looking up EID 233.252.2.2 in
	the core seed-group mapping system. For the map-cache entry to be	the core seed-group mapping system. For the map-cache entry to be

	populated for 233.252.2.2, the data-plane MUST send a Map-Request so	populated for 233.252.2.2, the data plane MUST send a Map-Request so
	the RLOCs I, J, and K are cached for replication. To use the core	the RLOCs I, J, and K are cached for replication. To use the core

	seed-group mapping system, the data-plane MUST know of at least one	seed-group mapping system, the data plane MUST know of at least one
	of the RLOCs A, B, and/or C.	of the RLOCs A, B, and/or C.


	5. Decent-Pull Based Mapping System	5. Decent-Pull-Based Mapping System

	5.1. Components of a Decent-Pulled Based LISP-Decent xTR	5.1. Components of a Decent-Pulled Based LISP-Decent xTR

	When an xTR is configured to be a LISP-Decent xTR (or PxTR	When an xTR is configured to be a LISP-Decent xTR (or PxTR
	[RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP	[RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP
	network functions.	network functions.


	Unlike the Decent-Push Based Mapping System, the xTRs do not need to	Unlike the Decent-Push-based Mapping System, the xTRs do not need to
	be organized by joining a multicast group. In a Decent-Pull Based	be organized by joining a multicast group. In a Decent-Pull-based
	Mapping System, a hash function over an EID is used to identify which	Mapping System, a hash function over an EID is used to identify which

	xTR is used as the Map-Resolver and Map-Server. The Domain Name	xTR is used as the Map-Resolver and Map-Server. The DNS [RFC1034]
	System (DNS) [RFC1034] [RFC1035] is used as a resource discovery	[RFC1035] is used as a resource discovery mechanism.
	mechanism.

	The RLOC addresses of the xTRs will be A and AAAA records for DNS	The RLOC addresses of the xTRs will be A and AAAA records for DNS
	names that map algorithmically from the hash of the EID. A SHA-256	names that map algorithmically from the hash of the EID. A SHA-256

	hash function [RFC6234] over the following ASCII formatted EID string	hash function [RFC6234] over the following ASCII-formatted EID string
	is used:	is used:

	[<iid>]<eid>/<ml>	[<iid>]<eid>/<ml>
	[<iid>]<group>/<gml>-<source>/<sml>	[<iid>]<group>/<gml>-<source>/<sml>

	In this section, where you see angle brackets, they are replaced with	In this section, where you see angle brackets, they are replaced with
	values in ASCII characters. For example, a unicast EID of 1.1.1.1 in	values in ASCII characters. For example, a unicast EID of 1.1.1.1 in
	instance-id 11 would be encoded as a string "[11]1.1.1.1/32".	instance-id 11 would be encoded as a string "[11]1.1.1.1/32".


	Where <iid> is the instance-ID and <eid> is the EID of any EID-type	<iid> is the instance-ID and <eid> is the EID of any EID-type defined
	defined in [RFC8060]. And then the Modulus Value <mv> is used to	in [RFC8060]. The Modulus Value <mv> is used to produce the Name
	produce the Name Index <index> used to build the DNS lookup name:	Index <index> used to build the DNS lookup name:

	eid = "[<iid>]<eid>/<ml>"	eid = "[<iid>]<eid>/<ml>"
	index = hash.sha_256(eid) MOD mv	index = hash.sha_256(eid) MOD mv

	The Hash Mask is used to select what bits are used in the SHA-256	The Hash Mask is used to select what bits are used in the SHA-256
	hash function. This is required to support longest match lookups in	hash function. This is required to support longest match lookups in
	the mapping system. The same map-server set needs to be selected	the mapping system. The same map-server set needs to be selected
	when looking up a more-specific EID found in the Map-Request message	when looking up a more-specific EID found in the Map-Request message
	with one that could match a less-specific EID-prefix registered and	with one that could match a less-specific EID-prefix registered and
	found in the Map-Register message. For example, if an EID-prefix	found in the Map-Register message. For example, if an EID-prefix

	skipping to change at page 13, line 22 ¶	skipping to change at line 525 ¶
	ITRs SHOULD support configuration of EID prefix ranges and their	ITRs SHOULD support configuration of EID prefix ranges and their
	associated lookup prefix lengths. When an ITR performs a Map-Request	associated lookup prefix lengths. When an ITR performs a Map-Request
	lookup, it SHOULD check if the destination EID matches any configured	lookup, it SHOULD check if the destination EID matches any configured
	range. If a match is found, the ITR MUST use the configured lookup	range. If a match is found, the ITR MUST use the configured lookup
	prefix length instead of the EID's native prefix length when	prefix length instead of the EID's native prefix length when
	computing the hash string. When multiple configured ranges match a	computing the hash string. When multiple configured ranges match a
	given EID, the range with the longest (most-specific) configured	given EID, the range with the longest (most-specific) configured
	prefix length MUST be selected.	prefix length MUST be selected.

	The configuration consists of pairs of EID-prefix (the well-known EID	The configuration consists of pairs of EID-prefix (the well-known EID

	allocation range in CIDR notation, e.g., 240.11.0.0/16) and lookup-	allocation range in Classless Inter-Domain Routing (CIDR) notation,
	length (the prefix length to use for hash computation when EIDs fall	e.g., 240.11.0.0/16) and lookup-length (the prefix length to use for
	within this range, 0-32 for IPv4, 0-128 for IPv6).	hash computation when EIDs fall within this range, 0-32 for IPv4,
		0-128 for IPv6).

	Implementation note: When computing the hash string for a lookup	Implementation note: When computing the hash string for a lookup
	where the EID matches a configured range, the ITR MUST construct the	where the EID matches a configured range, the ITR MUST construct the
	hash string using the configured lookup-length, ensuring that the	hash string using the configured lookup-length, ensuring that the
	bits beyond the lookup-length are zero (i.e., the EID address is	bits beyond the lookup-length are zero (i.e., the EID address is
	masked to the lookup-length before converting to the hash string	masked to the lookup-length before converting to the hash string
	format).	format).

	Example configuration with multiple EID ranges:	Example configuration with multiple EID ranges:


	EID Range Configuration:	EID Range Configuration:
	Range: [0]240.11.0.0/16 -> lookup-length: 24	Range: [0]240.11.0.0/16 -> lookup-length: 24
	Range: [0]240.12.0.0/16 -> lookup-length: 30	Range: [0]240.12.0.0/16 -> lookup-length: 30
	Range: [0]240.13.0.0/16 -> lookup-length: 25	Range: [0]240.13.0.0/16 -> lookup-length: 25


	Lookup Examples:	Lookup Examples:
	EID [0]240.11.1.1/32 -> hash on [0]240.11.1.0/24	EID [0]240.11.1.1/32 -> hash on [0]240.11.1.0/24
	EID [0]240.12.2.5/32 -> hash on [0]240.12.2.4/30	EID [0]240.12.2.5/32 -> hash on [0]240.12.2.4/30
	EID [0]240.13.3.7/32 -> hash on [0]240.13.3.0/25	EID [0]240.13.3.7/32 -> hash on [0]240.13.3.0/25
	EID [0]240.14.1.1/32 -> hash on [0]240.14.1.1/32 (no match, use full EID)	EID [0]240.14.1.1/32 -> hash on [0]240.14.1.1/32
		(no match, use full EID)

	This approach is particularly useful in deployments where the mapping	This approach is particularly useful in deployments where the mapping
	system uses a consistent ETR registration strategy (e.g., all ETRs in	system uses a consistent ETR registration strategy (e.g., all ETRs in

	a region register with /24 prefixes) but ITRs receive packets with	a region register with /24 prefixes), but ITRs receive packets with
	more-specific destinations (/32 addresses). By configuring the	more-specific destinations (/32 addresses). By configuring the
	expected registration prefix length for each allocation range, ITRs	expected registration prefix length for each allocation range, ITRs
	can reliably locate the correct Map-Servers without modifying the	can reliably locate the correct Map-Servers without modifying the
	LISP protocols or introducing complex multi-level lookups.	LISP protocols or introducing complex multi-level lookups.

	5.3. Deployment Example	5.3. Deployment Example


	Here is an example deployment of a Decent-Pull based model. Let's	Here is an example deployment of a Decent-Pull-based model. Let's
	say 4 map-server sets are provisioned for the mapping system.	say that 4 map-server sets are provisioned for the mapping system.
	Therefore 4 distinct DNS names are allocated and a Modulus Value 4 is	Therefore, 4 distinct DNS names are allocated and a Modulus Value 4
	used. Each DNS name is allocated Name Index 0 through 3:	is used. Each DNS name is allocated Name Index 0 through 3:

	0.map-server.lispers.net	0.map-server.lispers.net
	1.map-server.lispers.net	1.map-server.lispers.net
	2.map-server.lispers.net	2.map-server.lispers.net
	3.map-server.lispers.net	3.map-server.lispers.net

	The A records for each name can be assigned as:	The A records for each name can be assigned as:

	0.map-server.lispers.net:	0.map-server.lispers.net:
	A <rloc1-att>	A <rloc1-att>

	skipping to change at page 15, line 24 ¶	skipping to change at line 592 ¶
	3.map-server.lispers.net:	3.map-server.lispers.net:
	A <rloc1-au>	A <rloc1-au>
	A <rloc2-nz>	A <rloc2-nz>

	When an xTR wants to register "[1000]fd::2222", it hashes the EID	When an xTR wants to register "[1000]fd::2222", it hashes the EID
	string to produce, for example, hash value 0x66. Using the modulus	string to produce, for example, hash value 0x66. Using the modulus
	value 4 (0x67 & 0x3) produces index 0x3, so the DNS name 3.map-	value 4 (0x67 & 0x3) produces index 0x3, so the DNS name 3.map-
	server.lispers.net is used and a Map-Register is sent to <rloc1-au>	server.lispers.net is used and a Map-Register is sent to <rloc1-au>
	and <rloc2-nz>.	and <rloc2-nz>.


	Note that the Decent-Pull based method can be used for a core seed-	Note that the Decent-Pull-based method can be used for a core seed-
	group for bootstrapping a Decent-Push based mapping system where	group for bootstrapping a Decent-Push-based Mapping System where
	multicast groups are registered.	multicast groups are registered.

	5.4. Management Considerations	5.4. Management Considerations

	An implementation SHOULD do periodic DNS lookups to determine if A	An implementation SHOULD do periodic DNS lookups to determine if A
	records have changed for a DNS entry. This is a configuration	records have changed for a DNS entry. This is a configuration
	parameter the network operator selects. This specification makes no	parameter the network operator selects. This specification makes no
	recommendation for an interval value.	recommendation for an interval value.

	When xTRs derive Map-Resolver and Map-Server names from the DNS, they	When xTRs derive Map-Resolver and Map-Server names from the DNS, they

	need to use the same Modulus Value otherwise some xTRs will lookup	need to use the same Modulus Value. Otherwise, some xTRs will look
	EIDs to the wrong place they were registered.	up EIDs to the wrong place they were registered.

	The Modulus Value can be configured or pushed to the LISP-Decent	The Modulus Value can be configured or pushed to the LISP-Decent
	xTRs. A future version of this document will describe a push	xTRs. A future version of this document will describe a push
	mechanism so all xTRs use a consistent modulus value.	mechanism so all xTRs use a consistent modulus value.

	6. Security Considerations	6. Security Considerations


	Refer to the Security Considerations section of [RFC9301] for a	Refer to Section 9 of [RFC9301] for a complete list of security
	complete list of security mechanisms as well as pointers to threat	mechanisms as well as pointers to threat analysis documents.
	analysis drafts.


	It is recommended, where DNS is deployed for the Pull-Based Mapping	Where DNS is deployed for the Pull-based Mapping System, it is
	System, DNSSEC [RFC9364] be used to add more security to the DNS	recommended to use DNSSEC [RFC9364] to add more security to the DNS
	lookup system.	lookup system.

	Replay attacks, spoofing, and trust relationships are discussed in	Replay attacks, spoofing, and trust relationships are discussed in
	detail in [RFC9301] and [RFC9303].	detail in [RFC9301] and [RFC9303].

	7. IANA Considerations	7. IANA Considerations


	At this time there are no specific requests for IANA.	This document has no IANA actions.

	8. References	8. References

	8.1. Normative References	8.1. Normative References

	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<https://www.rfc-editor.org/info/rfc1034>.	<https://www.rfc-editor.org/info/rfc1034>.

	[RFC1035] Mockapetris, P., "Domain names - implementation and	[RFC1035] Mockapetris, P., "Domain names - implementation and

	skipping to change at page 17, line 46 ¶	skipping to change at line 710 ¶
	<https://www.rfc-editor.org/info/rfc9364>.	<https://www.rfc-editor.org/info/rfc9364>.

	[RFC9437] Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai,	[RFC9437] Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai,
	S., and M. Boucadair, "Publish/Subscribe Functionality for	S., and M. Boucadair, "Publish/Subscribe Functionality for
	the Locator/ID Separation Protocol (LISP)", RFC 9437,	the Locator/ID Separation Protocol (LISP)", RFC 9437,
	DOI 10.17487/RFC9437, August 2023,	DOI 10.17487/RFC9437, August 2023,
	<https://www.rfc-editor.org/info/rfc9437>.	<https://www.rfc-editor.org/info/rfc9437>.

	8.2. Informative References	8.2. Informative References


	[I-D.ietf-lisp-ecdsa-auth]	[ECDSA-AUTH]
	Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA	Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
	Authentication and Authorization", Work in Progress,	Authentication and Authorization", Work in Progress,
	Internet-Draft, draft-ietf-lisp-ecdsa-auth-16, 29 January	Internet-Draft, draft-ietf-lisp-ecdsa-auth-16, 29 January
	2026, <https://datatracker.ietf.org/doc/html/draft-ietf-	2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
	lisp-ecdsa-auth-16>.	lisp-ecdsa-auth-16>.


	[JUL-WG-PRESO]	[IETF101-PRESO]
	Farinacci, D., "LISP WG July 2019 Presentation",	Farinacci, D. and C. Cantrell, "A Decentralized Mapping
	https://www.dropbox.com/scl/fi/3z7uichvi8x9940xlz6pm/lisp-	System: draft-farinacci-lisp-decent-00", IETF 101
	decent-ietf-prague.pdf?rlkey=4v1lup23zc0j6kpicqfr2npro,	Proceedings, March 2018,
	July 2019.	<https://datatracker.ietf.org/meeting/101/materials/
		slides-101-lisp-lisp-decentralized-mapping-system-00>.


	[MAR-WG-PRESO]	[IETF104-PRESO]
	Farinacci, D., "LISP WG March 2018 Presentation",	Farinacci, D. and C. Cantrell, "A Decentralized Mapping
	https://www.dropbox.com/scl/fi/eqoqestxsoc4w7zh2t8dr/lisp-	System: draft-farinacci-lisp-decent-03", IETF 104
	decent-ietf-london.pdf?rlkey=dw0c96xtbi4c5074a2i90g4qh,	Proceedings, March 2019,
	March 2018.	<https://datatracker.ietf.org/meeting/104/materials/
		slides-104-lisp-a-decent-lisp-mapping-system-00>.


	Appendix A. Acknowledgments	Acknowledgments

	The authors would like to thank the LISP WG for their review and	The authors would like to thank the LISP WG for their review and
	acceptance of this draft.	acceptance of this draft.

	The authors would also like to give a special thanks to Roman	The authors would also like to give a special thanks to Roman

	Shaposhnik for several discussions that occurred before the first	Shaposhnik for several discussions that occurred before the initial
	draft was published.	draft of this document.

	ISE Eliot Lear and Victor Moreno are appreciated for their efforts
	proof reading the draft before Informational RFC publication.

	Appendix B. Document Change Log

	[RFC Editor: Please delete this section on publication as RFC.]

	B.1. Changes to draft-farinacci-lisp-decent-22

	* Posted March 2026.

	* Add section on configuring EID-prefix mask lengths in ITRs so when
	a non /32 or /128 is registered, the lookup hash is consistent
	with the registration hash.

	B.2. Changes to draft-farinacci-lisp-decent-21

	* Posted November 2025.

	* Remove normative references to bis documents for RFC6831, RFC8378,
	and RFC8060 but keep the original RFCs.

	B.3. Changes to draft-farinacci-lisp-decent-20

	* Posted October 2025.

	* Made editorial changes suggested by Eliot.

	B.4. Changes to draft-farinacci-lisp-decent-19

	* Posted October 2025.

	* Victor Moreno completed proof-read and submitted editorial
	comments.

	* Dino completed final proof-read.

	* Updated references to latest working group drafts and RFCs.

	B.5. Changes to draft-farinacci-lisp-decent-18

	* Posted July 2025.

	* Made suggested changes to reflect comments from Joel and Padma per
	ISE (Eliot) distinguished review request. This should be final
	review cycle.

	B.6. Changes to draft-farinacci-lisp-decent-17

	* Posted April 2025.

	* Made suggested changes to reflect second review from ISE (Eliot
	Lear).

	B.7. Changes to draft-farinacci-lisp-decent-16

	* Posted December 2024.

	* Made suggested changes from ISE review.

	B.8. Changes to draft-farinacci-lisp-decent-15

	* Posted June 2024.

	* Making draft an ISE submission as Informational RFC.

	* Update references and document expiry timer.

	B.9. Changes to draft-farinacci-lisp-decent-14

	* Posted April 2024.

	* Update references and document expiry timer.

	B.10. Changes to draft-farinacci-lisp-decent-13

	* Posted October 2023.

	* Make the general definitions of "pull-based" and "push-based" be
	more specific to the way LISP-Decent uses them. Call them Decent-
	Pull and Decent-Push.

	B.11. Changes to draft-farinacci-lisp-decent-12

	* Posted August 2023.

	* Update references and document expiry timer.

	B.12. Changes to draft-farinacci-lisp-decent-11

	* Posted February 2023.

	* Update references and document expiry timer.

	B.13. Changes to draft-farinacci-lisp-decent-10

	* Posted August 2022.

	* Update references and document expiry timer.

	B.14. Changes to draft-farinacci-lisp-decent-09

	* Posted February 2022.

	* Update references and document expiry timer.

	B.15. Changes to draft-farinacci-lisp-decent-08

	* Posted August 2021.

	* Update references and document expiry timer.

	B.16. Changes to draft-farinacci-lisp-decent-07

	* Posted March 2021.

	* Update references and document expiry timer.

	B.17. Changes to draft-farinacci-lisp-decent-06

	* Posted September 2020.

	* Update references and document expiry timer.

	B.18. Changes to draft-farinacci-lisp-decent-05

	* Posted March 2020.

	* Update references and document expiry timer.

	B.19. Changes to draft-farinacci-lisp-decent-04

	* Posted September 2019.

	* Update references and document expiry timer.

	B.20. Changes to draft-farinacci-lisp-decent-03

	* Posted March 2019.

	* Introduce the Hash Mask which is used to grab common bits from a
	registered prefix and a lookup prefix.

	* Spec how multicast lookups are done in the pull-based mapping
	system.

	* Indicate the hash string includes the unicast EID mask-length and
	multicast group and source mask-lengths.

	B.21. Changes to draft-farinacci-lisp-decent-02

	* Posted November 2018.

	* Changed references from peer-group to seed-group to make the
	algorithms in this document more like how blockchain networks
	initialize the peer-to-peer network.

	* Added pull mechanism to complement the push mechanism. The pull
	mechanism could be used as a seed-group to bootstrap the push
	mechanism.

	B.22. Changes to draft-farinacci-lisp-decent-01

	* Posted July 2018.

	* Document timer and reference update.

	B.23. Changes to draft-farinacci-lisp-decent-00


	* Initial draft posted January 2018.	Eliot Lear and Victor Moreno are appreciated for their efforts
		proofreading the draft before publication as an RFC.

	Authors' Addresses	Authors' Addresses

	Dino Farinacci	Dino Farinacci
	lispers.net	lispers.net
	San Jose, CA	San Jose, CA
	United States of America	United States of America
	Email: farinacci@gmail.com	Email: farinacci@gmail.com

	Colin Cantrell	Colin Cantrell

End of changes. 79 change blocks.
	427 lines changed or deleted	233 lines changed or added
This html diff was produced by rfcdiff 1.48.