<?xml version="1.0" encoding="UTF-8"?>
<!--  Edited by Dino Farinacci farinacci@gmail.com --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902" docName="draft-farinacci-lisp-decent-22">

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?> docName="draft-farinacci-lisp-decent-22" number="9962" obsoletes="" updates="" submissionType="independent" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <front>
  <title>A

<!-- [rfced] Title

a) FYI - We have updated the short title of the document as follows to
match the consistent hyphenation of "LISP-Decent". Please let us know any
objections.

Original:
   LISP Decent

Current:
   LISP-Decent

b) How may we update the title of the document to introduce the expansion of
"LISP"?

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

Perhaps:
   A Decent Locator/ID Separation Protocol Mapping System (LISP-Decent)
-->

    <title abbrev="LISP-Decent">A Decent LISP Mapping System (LISP-Decent)</title>
    <seriesInfo name="RFC" value="9962"/>
    <author initials='D' initials="D" surname="Farinacci" fullname='Dino Farinacci'> fullname="Dino Farinacci">
      <organization>lispers.net</organization>
    <address><postal>
      <street></street>
      <address>
        <postal>
          <city>San Jose</city>
          <region>CA</region>
      <code></code>
      <country>USA</country>
          <country>United States of America</country>
        </postal>
    <email>farinacci@gmail.com</email></address>
        <email>farinacci@gmail.com</email>
      </address>
    </author>
    <author initials='C' initials="C" surname="Cantrell" fullname='Colin Cantrell'> fullname="Colin Cantrell">
      <organization>Nexus</organization>
    <address><postal>
      <street></street>
      <address>
        <postal>
          <city>Tempe</city>
          <region>AZ</region>
      <code></code>
      <country>USA</country>
          <country>United States of America</country>
        </postal>
    <email>colin@nexus.io</email></address>
        <email>colin@nexus.io</email>
      </address>
    </author>

  <date></date>

  <abstract>
    <t>This
    <date month="April" year="2026"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

<!--[rfced] Abstract: How may this sentence be rephrased for clarity?
Specifically, the last item ("maintain") doesn't make sense with "can be",
i.e., please clarify "can be distributed, decentralized, and maintain".

Original:
   This draft describes how the LISP mapping system can be distributed
   for scale, decentralized for management and maintain trust among
   data-plane nodes. The intended status

Perhaps:
   This document describes how the Locator/ID Separation Protocol (LISP)
   mapping system can be distributed for this scale and decentralized for
   management, while maintaining trust among data plane nodes.
-->
    <abstract>
      <t>This document describes how the Locator/ID Separation Protocol (LISP) mapping system can be
    distributed for scale, decentralized for management and maintain
    trust among data plane nodes.  This
    is an Informational RFC and should be used by LISP-Decent
    implementations to interoperate with each other.</t>
    </abstract>

  <note title="Requirements Language">
    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
    "MAY", and "OPTIONAL" in
  </front>
  <middle>
<!-- [rfced] Introduction: May we rephrase this document sentence to avoid the
redundancy of "and protocols" since the expansion of "LISP" is "Locator/ID
Separation Protocol"? Additionally, may we rephrase for improved
readability?

Original:
   The LISP architecture and protocols [RFC9300] introduces two new
   numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators
   (RLOCs) that are intended to be interpreted as
    described in BCP 14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, provide overlay network functionality.

Perhaps:
   The LISP architecture [RFC9300] introduces two new numbering spaces that
   are intended to provide overlay network functionality: Endpoint
   Identifiers (EIDs) and only when, they appear in all
    capitals, as shown here.</t>
  </note>
</front>

<middle> Routing Locators (RLOCs).
-->
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The LISP architecture and protocols <xref target="RFC9300" /> format="default"/>
    introduces two new numbering spaces, Endpoint Identifiers (EIDs)
    and Routing Locators (RLOCs) that are intended to provide overlay
    network functionality. To map from EID EIDs to a set of RLOCs, a
    control-plane
    control plane mapping system is used <xref target="RFC6836"/> target="RFC6836" format="default"/>
        <xref target="RFC8111"/>. target="RFC8111" format="default"/>. These mapping systems are naturally distributed
    in their deployment for scalability but are centrally
    managed by a third-party entity, namely a Mapping System Provider
    (MSP). The entities that use the mapping system, such as
    data-plane
    data plane LISP Tunnel Routers (xTRs), depend on and trust the
    MSP. They do not participate in the mapping system other than to
    register and retrieve information <xref target="RFC9301" />.</t> format="default"/>.</t>
      <t>This document introduces a Decentralized Mapping System (DMS)
    so the xTRs can participate in the mapping system as well as use
    it. They can trust each other rather than rely on third-party
    infrastructure. The xTRs act as Map-Servers to maintain
    distributed state for scale and reduce the attack surface. The trust
    relationships between the xTRs are established through
    authentication and authorization procedures in <xref target="RFC9301" /> format="default"/> and <xref target="I-D.ietf-lisp-ecdsa-auth"/>.</t> target="I-D.ietf-lisp-ecdsa-auth" format="default"/>.</t>
<!-- [rfced] FYI - We updated this sentence, as IETF 104 was in Prague
in March 2019, not July 2019.

Original:
It was presented in London March 2018 [MAR-WG-PRESO] and in Prague
July 2019 [JUL-WG-PRESO].

Current:
It was presented in London in March 2018 [IETF101-PRESO] and
in Prague in March 2019 [IETF104-PRESO].-->
      <t>This design was first introduced to the LISP WG Working Group (WG) in January of
    2018. It was presented in London in March 2018 <xref
    target="MAR-WG-PRESO"/> target="IETF101-PRESO" format="default"/> and in Prague July in March 2019 <xref
    target="JUL-WG-PRESO"/>. target="IETF104-PRESO" format="default"/>. This informational Informational document is not a
    standard and did not reach community consensus to make it an IETF
    LISP working group WG document.</t>
      <t>The intended audience for this specification are protocol
    development engineers who would implement this specification in
    products as well network engineers who deploy the technology in
    operational environments.</t>
      <t>This design does not conflict with those designs or contradicts
    any other LISP design principles produced by the working
    group. This solution makes no fundamental LISP protocol changes
    and adheres to the specifications documented in <xref
    target="RFC9301"/>.</t> target="RFC9301" format="default"/>.</t>
      <t>By the nature of this work, this document uses IP addresses as
    examples.  They should not be copied or used outside of a lab
    environment.  Deployments should use addresses appropriate for
    their environment.</t>
    </section>
    <section title="Definition of Terms">
    <t><list style="hanging">
      <t hangText="Mapping numbered="true" toc="default">
      <name>Definitions of Terms</name>
      <dl newline="false" spacing="normal">
        <dt>Mapping System Provider (MSP):">
      infrastructure (MSP):</dt>
        <dd>
<!-- [rfced] May we rephrase this sentence to clarify "who"
as "the organization"?

Current:
The MSP can be managed by a separate organization other than the one
that manages xTRs. This model provides a business separation between
who manages and responsible for the control-plane versus who manages
the data plane overlay service.

Perhaps:
The MSP can be managed by a separate organization other than the one
that manages xTRs. This model provides a business separation between
the organization that manages (and is responsible for) the control
plane versus the organization that manages the data plane overlay
service.
-->
      Infrastructure service that deploys LISP Map-Resolvers and
      Map-Servers <xref target="RFC9301"/> target="RFC9301" format="default"/> and possibly LISP-ALT nodes
      <xref target="RFC6836"/> target="RFC6836" format="default"/> or LISP-DDT nodes <xref
      target="RFC8111"/>. target="RFC8111" format="default"/>. ALT-nodes and DDT-nodes use different
      algorithms for connecting together Map-Resolvers and
      Map-Servers.
      Map-Servers together.  The MSP can be managed by a separate organization
      other than the one that manages xTRs. This model provides a
      business separation between who manages and responsible for
      the control-plane versus who manages the data-plane data plane overlay
      service.</t>

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

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

      <t hangText="Modulus Value:">this
      system.</dd>
        <dt>Modulus Value:</dt>
        <dd>This value is used in the
      Pull-Based
      Pull-based Mapping System. It defines the number of map-server
      sets used for the mapping system. The modulus value is used to
      produce a Name Index used for a DNS Domain Name System (DNS) lookup. The Modulus Value is
      chosen based on the horizontal scale-out width of the map-server
      cluster the network operator chooses to deploy.</t>

      <t hangText="Name Index:">this deploy.</dd>
        <dt>Name Index:</dt>
        <dd>This index value &lt;index&gt; is used in
      the Pull-Based Pull-based Mapping System. For a mapping system that is
      configured with a map-server set of DNS names in the form of
      &lt;name&gt;.example.com, the name index Name Index is prepended to &lt;name&gt; to
      form the lookup name &lt;index&gt;.&lt;name&gt;.example.com. If
      the Modulus Value is 8, then the name indexes Name Indexes are 0 through 7.</t>

      <t hangText="Hash Mask:">The 7.</dd>
        <dt>Hash Mask:</dt>
        <dd>The Hash Mask is used in the Pull-Based Pull-based
      Mapping System. It is a mask value with 1 bits bit left justified.
      The mask is used to select what high-order bits of an EID-prefix are
      used in the hash function.</t>

      <t hangText="Decent-Push Based function.</dd>
        <dt>Decent-Push-Based Mapping System:">the System:</dt>
        <dd>The mapping system is
      push-based
      push-based, meaning that xTRs will push registrations via IP
      multicast to a group of Map-Servers and do local lookups acting
      as their own Map-Resolvers.</t>

      <t hangText="Replication Map-Resolvers.</dd>
        <dt>Replication List Entry (RLE):">an (RLE):</dt>
        <dd>An RLOC-record
      format that contains a list of RLOCs that an Ingress Tunnel
      Router (ITR) replicates multicast packets on a multicast
      overlay. The RLE format is specified in <xref
      target="RFC8060"/>. target="RFC8060" format="default"/>. RLEs are used with the
      Decent-Pushed Based mapping system.</t>

      <t hangText="Group system.</dd>
        <dt>Group Address EID:">an EID:</dt>
        <dd>An EID-record format that
      contains IPv4 (0.0.0.0/0, G) or IPv6 (0::/0, G) state. This
      state is encoded as a Multicast Info Type LCAF LISP Canonical Address Format (LCAF) specified in
      <xref target="RFC8060"/>. target="RFC8060" format="default"/>. Members of a
      seed-group send Map-Registers for (0.0.0.0/0, G) or (0::/0, G)
      with an RLOC-record that RLE encodes its RLOC address. Details
      are specified in <xref target="RFC8378"/>.</t>

      <t hangText="Seed-Group:">a target="RFC8378" format="default"/>.</dd>
        <dt>Seed-Group:</dt>
        <dd>A set of Map-Servers joined to a
      multicast group for the Decent-Push Based Decent-Push-based Mapping system System or are mapped
      by DNS names in a Pull-Based 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 use each other's mapping system service. A seed-group can
      be pull-based to bootstrap the Decent-Push based mapping system. Decent-Push-based Mapping System. That is,
      a set of DNS mapped map-servers can be used to join the mapping
      system's IP multicast group.</t>
   </list></t> group.</dd>
      </dl>
      <section>
      <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
        NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP&nbsp;14 <xref
        target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
        appear in all capitals, as shown here.
        </t>
      </section>

    </section>
    <section title="Overview"> numbered="true" toc="default">
      <name>Overview</name>
      <t>The clients of the Decentralized Mapping System (DMS) DMS are also
    the providers of mapping state, see <xref target="RFC9301"/> target="RFC9301" format="default"/> for
    formal details. Clients are typically Egress Tunnel Routers (ETRs)
    that Map-Register EID-to-RLOC mapping state to the mapping
    database system. ITRs are clients in that they send Map-Requests
    to the mapping database system to obtain EID-to-RLOC mappings that
    are cached for data-plane data plane use. When xTRs participate in a DMS,
    they are also acting as Map-Resolvers and Map-Servers using the
    protocol machinery defined in LISP control-plane control plane specifications
    <xref target="RFC9301"/>, target="RFC9301" format="default"/>, <xref target="RFC9303"/>, target="RFC9303" format="default"/>, and <xref
    target="I-D.ietf-lisp-ecdsa-auth"/>. target="I-D.ietf-lisp-ecdsa-auth" format="default"/>. The xTRs are not required to
    run the database mapping transport system protocols specified in
    <xref target="RFC6836"/> target="RFC6836" format="default"/> or <xref target="RFC8111"/>.</t> target="RFC8111" format="default"/>.</t>
      <t>This document will describe two decentralized and distributed mapping
    system mechanisms. A Decent-Push Based Decent-Push-based Mapping System uses IP multicast so
    xTRs can find each other by locally joining an IP multicast group. A
    Decent-Pull Based
    Decent-Pull-based Mapping System uses DNS with an algorithmic transformation
    function so xTRs can find each other.</t>
      <t>The document proposes two approaches to provide
    state/bandwidth, ease of configurability, and
    robustness/complexity tradeoffs. trade-offs. When the Decent-Push Based Decent-Push-based
    approach is used used, there is less messaging involved. xTRs can
    multicast a single Map-Register message which that goes to all
    Map-Servers joined to the multicast group. When Map-Servers are
    added to or removed from the Map-Server cluster group, the mapping system
    updates quickly with little human intervention. In the push model,
    all mapping state is stored in all Map-Servers so there is
    robustness achieved through redundancy. However, this requires a
    multicast underlay in nodes between all xTRs and Map-Servers.

    When a multicast underlay is not available, the Decent-Pull Based Decent-Pull-based
    approach can be used with the help of the DNS system. DNS. This
    approach uses less state overall among the Map-Servers (they each
    have different mapping system state) and the ITRs know which
    Map-Server to ask by using the hashing techniques described later
    in this document.</t>
<!-- [rfced] Please clarify; what words are missing in this sentence
between "intentional" and "all"? (The preceding sentence is included for context.)

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

Perhaps:
This document does not describe any compatibility with other mapping
systems.  The design is intentional so that all xTRs and Map-Servers
support this specification.
-->
      <t>This document does not describe any compatibility with other
    mapping systems.  The design is intentional all xTRs and
    Map-Servers support this specification. Moreover, all xTRs and
    Map-Servers MUST <bcp14>MUST</bcp14> support either the Pull-Based pull-based or Push-Based push-based
    algorithms. They cannot be mixed. When both are used, they are
    completely discrete mapping systems just like they would be using
    one of the LISP Working Group WG mapping system designs. An
    implementation can decide to implement only the Pull-Based pull-based approach or the
    Push-Based
    push-based approach and still be compliant with this specification.</t>

    <t><vspace blankLines='40' /></t>
    </section>
    <section title="Decent-Push Based numbered="true" toc="default">
      <name>Decent-Push-Based Mapping System"> System</name>
      <t>The xTRs are organized in a mapping-system group. The group is
    identified by an IPv4 or IPv6 multicast group address or using a
    Decent-Pull based
    Decent-Pull-based approach described in <xref target="PULL"/>. target="PULL" format="default"/>. When
    using multicast, the xTRs join the same multicast group and
    receive LISP control-plane control plane messages addressed to the
    group. Messages sent to the multicast group are distributed when
    the underlay network supports IP multicast <xref
    target="RFC6831"/> target="RFC6831" format="default"/> or via the overlay multicast
    mechanism described in <xref target="RFC8378"/>. target="RFC8378" format="default"/>. When overlay
    multicast is used and LISP Map-Register messages are sent to the
    group, they are LISP data encapsulated with a an instance-ID set to
    0xffffff in the LISP header. The inner header of the encapsulated
    packet has the destination address set to the multicast group
    address and the outer header that is prepended has the destination
    address set to the RLOC of mapping system group member. The members of
    the mapping system group are kept in the LISP data-plane data plane map-cache
    so packets for the group can be replicated to each member
    RLOC.</t>
      <t>All xTRs in a mapping system group will store the same
    registered mappings and maintain the state as Map-Servers normally
    do. The members are not only receivers of the multicast group group, but they
    also send packets to the group.</t>
      <section title="Components numbered="true" toc="default">
        <name>Components of a Decent-Pushed Based LISP-Decent xTR"> xTR</name>
        <t>When an xTR is configured to be a LISP-Decent xTR (or PxTR
      <xref target="RFC6832"/>), target="RFC6832" format="default"/>), it runs the ITR, ETR, Map-Resolver,
      and Map-Server LISP network functions.</t>
        <t>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 Map-Register, it is sent to all xTRs (including
      itself) synchronizing all 3 Map-Servers in xTR1, xTR2, and
      xTR3. The ITR function can populate its map-cache by sending a
      Map-Request locally to its Map-Resolver so it can replicate
      packets to each RLOC for EID 233.252.1.1.</t>
        <t>In this document, there is no special meaning for the
      multicast group address 233.252.1.1.  It is used for example
      purposes only.</t>

    <figure>
      <preamble></preamble>
      <artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
                        xTR1
 Map-Request    +--------------------+
(always local)  |  +-----+  +-----+  |
   +---------------| ITR |  | ETR |-------------+
   |            |  +-----+  +-----+  |          |
   |            |                    |          |  Map-Register to EID
   |            |      +-------+     |          |  EID 233.252.1.1 encapsulated to
   +------------------>| MR/MS |<---------------+  RLOCs xTR1, xTR2, and xTR3  encapsulated to
                |      +-------+     |          | RLOCs xTR1, xTR2,
                +--------------------+          |     and xTR3
                                                |
                           +--------------------+------------+
                           |                                 |
                           |                                 |
                +----------v---------+            +----------v---------+
                |     +--------+     |            |     +--------+     |
                |     |  MR/MS |     |            |     |  MR/MS |     |
                |     +--------+     |            |     +--------+     |
                |  +-----+  +-----+  |            |  +-----+  +-----+  |
                |  | ITR |  | ETR |  |            |  | ITR |  | ETR |  |
                |  +-----+  +-----+  |            |  +-----+  +-----+  |
                +--------------------+            +--------------------+
                         xTR2                              xTR3

      ]]></artwork>
      <postamble />
    </figure>                              xTR3]]></artwork>
<!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
        <t>Note that if any external xTR would like to use a Map-Resolver
      from the mapping system group, it only needs to have one of the
      LISP-Decent Map-Resolvers configured.
<!-- [rfced] FYI, we corrected the phrase "By doing a looking to" as follows.
Please review and let us know if you prefer otherwise.

Original:
By doing a looking to this Map-Resolver for EID 233.252.1.1, the external xTR
could get the complete list of members for the mapping system group.

Current:
By looking at the Map-Resolver for EID 233.252.1.1, the external xTR
could get the complete list of members for the mapping system group.
-->
      By looking at the Map-Resolver for EID 233.252.1.1, the external xTR could get the
      complete list of members for the mapping system group.</t>
        <t>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 return a Map-Reply or the external xTR is
      prepared to receive multiple Map-Replies.</t>
      </section>
      <section title="Implementation Considerations"> numbered="true" toc="default">
        <name>Implementation Considerations</name>
        <t>There are no LISP protocol changes required to support the
      Decent-Push based
      Decent-Push-based LISP-Decent set of procedures. An implementation
      that sends Map-Register messages to a multicast group versus a
      specific Map-Server unicast address MUST <bcp14>MUST</bcp14> change to call the
      data-plane
      data plane component so the ITR functionality in the node can
      encapsulate the Map-Register as a unicast packet to each member
      of the mapping system group.</t>
        <t>An ITR SHOULD lookup <bcp14>SHOULD</bcp14> look up its mapping system group address
      periodically to determine if the membership has changed. The
      lookup interval is a configuration parameter only needed
      when
      when the ITR does not use the PubSub capability documented in
      <xref target="RFC9437"/> target="RFC9437" format="default"/> to be notified when a new
      member joins or leaves the multicast group. When PubSub is not
      used, there needs to be coordination (via configuration
      management) among all xTRs so they rendezvous roughly at the
      same time and to the same group address.</t>
      </section>
      <section title="Configuration numbered="true" toc="default">
        <name>Configuration and Authentication"> Authentication</name>
        <t>When xTRs are joined to a multicast group, they MUST <bcp14>MUST</bcp14> have
      their site registration configuration consistent. Any policy or
      authentication key material MUST <bcp14>MUST</bcp14> be configured consistently
      among all members. When <xref
      target="I-D.ietf-lisp-ecdsa-auth"/> target="I-D.ietf-lisp-ecdsa-auth" format="default"/> is used to sign Map-Register
      messages, public-keys public keys can be registered to the mapping system
      group using the site authentication key mentioned above or using
      a different authentication key from the one used for registering
      EID records. An out-of-band registration controller, like an ETR
      dedicated for this function, can send Map-Register messages for
      public-key encoded EIDs.</t>
      </section>
      <section title="Core Seed-Group"> numbered="true" toc="default">
        <name>Core Seed-Group</name>
        <t>A core seed-group can be discovered using a multicast group in
      a Decent-Push based Decent-Push-based system or a Map-Server set of DNS names in a Decent-Pull based Decent-Pull-based
      system (see <xref target="PULL"/> target="PULL" format="default"/> for details).</t>
        <t>When using multicast for the mapping system group, a core seed-group
      multicast group address can be preconfigured to bootstrap the
      decentralized mapping system. The group address (or DNS name
      that maps to a group address) can be explicitly configured in a
      few xTRs to start building up the registrations. Then as other xTRs
      come online, they can add themselves to the core seed-group by
      joining the seed-group multicast group.</t>
        <t>Alternatively or additionally, new xTRs can join a new
      mapping system multicast group to form another layer of a
      decentralized mapping 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 core seed-group mapping
      system. Note that each mapping system layer could have a specific
      function or a specific circle of trust.</t>

      <t><vspace blankLines='20' /></t>
        <t>This multi-layer mapping system can be illustrated:</t>

    <figure>
      <preamble></preamble>
      <artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
           ____________                 -----------
          /   core     \  233.252.2.2  /  layer-1  \
         | seed-group   | ----------> |      I      |
         |  233.252.1.1 |             |     / \     |
          \____________/              |    J---K    |
               |                       \___________/
               | 233.252.3.3
               |
               v
           ---------
          / layer-2 \
         |     X     |
         |    / \    |
         |   Y---Z   |
          \_________/

Configured in xTRs A, B, and C (they make up the core seed-group):
  233.252.1.1 -> RLE: A, B, C

core seed-group DMS, mapping state in A, B, and C:
  233.252.2.2 -> RLE: I, J, K
  233.252.3.3 -> RLE: X, Y, Z

layer-1 seed-group DMS (inter-continental), mapping state in I, J, K:
   EID1 -> RLOCs: i(1), j(2)
   ...
   EIDn -> RLOCs: i(n), j(n)

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

      ]]></artwork>
      <postamble />
    </figure> y(n)]]></artwork>

        <t>The core seed-group multicast address 233.252.1.1 is configured
      in xTRs A, B B, and C so when each of them send Map-Register
      messages, they would all be able to maintain synchronized
      mapping state. Any EID can be registered to this DMS DMS, but in this
      example, seed-group multicast group EIDs are being registered
      only to find other mapping system groups.</t>
        <t>For example, lets say that xTR I boots up and it wants to
      find its other peers in its mapping system group
      233.252.2.2. Group address 233.252.2.2 is configured so xTR I knows
      what group to join for its mapping system group. But However, xTR I needs
      a mapping system to register to, so the core seed-group is used
      and available to receive Map-Registers. The other xTRs J and K
      in the mapping system group do the same so when any of I, J J, or K
      needs to register EIDs, they can now send their Map-Register
      messages to group 233.252.2.2. Examples of EIDs being register registered are
      EID1 through EIDn shown above.</t>
        <t>When Map-Registers are sent to group 233.252.2.2, they are
      encapsulated by the LISP data-plane data plane by looking up EID 233.252.2.2
      in the core seed-group mapping system. For the map-cache entry
      to be populated for 233.252.2.2, the data-plane MUST data plane <bcp14>MUST</bcp14> send a
      Map-Request so the RLOCs I, J, and K are cached for
      replication. To use the core seed-group mapping system, the
      data-plane MUST
      data plane <bcp14>MUST</bcp14> know of at least one of the RLOCs A, B, and/or
      C.</t>
      </section>
    </section>
    <section title="Decent-Pull Based anchor="PULL" numbered="true" toc="default">
      <name>Decent-Pull-Based Mapping System" anchor="PULL"> System</name>
      <section title="Components numbered="true" toc="default">
        <name>Components of a Decent-Pulled Based LISP-Decent xTR"> xTR</name>
        <t>When an xTR is configured to be a LISP-Decent xTR (or PxTR
      <xref target="RFC6832"/>), target="RFC6832" format="default"/>), it runs the ITR, ETR, Map-Resolver,
      and Map-Server LISP network functions.</t>
        <t>Unlike the Decent-Push Based Decent-Push-based Mapping System, the xTRs do not need to
      be organized by joining a multicast group. In a Decent-Pull Based Decent-Pull-based
      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 System (DNS) DNS <xref target="RFC1034"/> target="RFC1034" format="default"/> <xref
      target="RFC1035"/> target="RFC1035" format="default"/> is used as a resource discovery mechanism.</t>
        <t>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 hash function <xref target="RFC6234"/> target="RFC6234" format="default"/> over the
      following ASCII formatted ASCII-formatted EID string is used:</t>

    <figure>
      <preamble></preamble>
      <artwork><![CDATA[

        <artwork name="" type="" align="left" alt=""><![CDATA[
    [<iid>]<eid>/<ml>
    [<iid>]<group>/<gml>-<source>/<sml>
      ]]></artwork>
      <postamble />
    </figure>
    [<iid>]<group>/<gml>-<source>/<sml>]]></artwork>

        <t>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 instance-id 11 would be encoded as a string
    "[11]1.1.1.1/32".</t>

    <t>Where &lt;iid&gt;
        <t>&lt;iid&gt; is the instance-ID and &lt;eid&gt; is the EID
    of any EID-type defined in <xref
    target="RFC8060"/>. And then the target="RFC8060" format="default"/>. The Modulus Value
    &lt;mv&gt; is used to produce the Name Index &lt;index&gt; used to
    build the DNS lookup name:</t>

    <figure>
      <preamble></preamble>
      <artwork><![CDATA[

        <artwork name="" type="" align="left" alt=""><![CDATA[
    eid = "[<iid>]<eid>/<ml>"
    index = hash.sha_256(eid) MOD mv
      ]]></artwork>
      <postamble />
    </figure> mv]]></artwork>

        <t>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 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 with one that could match a less-specific
    EID-prefix registered and found in the Map-Register message. For
    example, if an EID-prefix [0]240.0.1.0/24 is registered to the
    mapping system and EID [0]240.0.1.1/32 is looked up to match the
    registered prefix, a Hash Mask of 8 bytes can be used to AND both
    the /32 or /24 entries to produce the same hash string bits
    of "[0]240.0".</t>
        <t>For (*,G) and (S,G) multicast entries in the mapping system,
    the hash strings are:</t>

    <figure>
      <preamble></preamble>
      <artwork><![CDATA[

        <artwork name="" type="" align="left" alt=""><![CDATA[
    sg-eid = "[<iid>]<group>/<gml>-<source>/<sml>"
    index = hash.sha_256(sg-eid) MOD mv

    starg-eid = "[<iid>]<group>/<gml>-0.0.0.0/0"
    index = hash.sha_256(starg-eid) MOD mv
      ]]></artwork>
      <postamble />
    </figure> mv]]></artwork>

        <t>The Hash Mask MUST <bcp14>MUST</bcp14> include the string
    "[&lt;iid&gt;]&lt;group&gt;" and not string &lt;source&gt;. So
    when looking up [0](2.2.2.2, 233.252.1.1) that will match a (*,
    233.252.1.1/32), the hash string produced with a Hash Mask of 12
    bytes is "[0]233.252.1.1".</t>
        <t>When the &lt;index&gt; is computed from a unicast or multicast EID,
    the DNS lookup name becomes:</t>

    <figure>
      <preamble></preamble>
      <artwork><![CDATA[
    <index>.map-server.example.com
      ]]></artwork>
      <postamble />
    </figure>

        <artwork name="" type="" align="left" alt=""><![CDATA[
    <index>.map-server.example.com]]></artwork>

        <t>When an xTR does a DNS lookup on the lookup name, it will send
    Map-Register messages to all A and AAAA records for EID
    registrations. For Map-Request messages, xTRs MAY <bcp14>MAY</bcp14> round robin EID
    lookup requests among the A and AAAA records.</t>
      </section>

      <section title="Configurable numbered="true" toc="default">
        <name>Configurable EID Prefix Lengths for Lookups"> Lookups</name>
      <t>In implementations where EID allocations follow a predictable
      pattern, operators MAY <bcp14>MAY</bcp14> configure ITRs to use specific prefix
      lengths for lookups when the EID falls within well-known
      allocation ranges. This configuration allows ITRs to compute the
      correct hash index even when data packets carry more-specific
      EIDs than the prefix lengths used by ETRs during registration.</t>

      <t>For example, if an operator allocates EIDs in the range
      [0]240.11.0.0/16 and all ETRs register these EIDs with a /24
      prefix length, ITRs receiving data packets for EIDs like
      [0]240.11.1.1/32 will still hash on the /24 prefix to locate the
      correct Map-Server. Without this configuration, the ITR would
      hash on the /32 and potentially query the wrong Map-Server.</t>

      <t>ITRs SHOULD <bcp14>SHOULD</bcp14> support configuration of EID prefix ranges and
      their associated lookup prefix lengths. When an ITR performs a
      Map-Request lookup, it SHOULD <bcp14>SHOULD</bcp14> check if the destination EID
      matches any configured range. If a match is found, the ITR MUST <bcp14>MUST</bcp14>
      use the configured lookup prefix length instead of the EID's
      native prefix length when computing the hash string. When
      multiple configured ranges match a given EID, the range with the
      longest (most-specific) configured prefix length MUST <bcp14>MUST</bcp14> be
      selected.</t>

      <t>The

      <!-- [rfced] May we update "EID-prefix" to "EID-prefixes" to match the
      plural form of "pairs"? Additionally, may we clarify the unit of
      measurement for the prefix lengths?

      Original:
      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-length (the prefix length to use for
      hash computation when EIDs fall within this range, 0-32 for
      IPv4, 0-128 for IPv6).

      Perhaps:
      The configuration consists of pairs of EID-prefixes (the well-known EID
      allocation range in  Classless Inter-Domain Routing (CIDR) notation, e.g.,
      240.11.0.0/16) and lookup-length (the prefix length to use for hash
      computation when EIDs fall within this range, 0-32 bytes for IPv4 and
      0-128 bytes for IPv6).
      -->

      <t>The configuration consists of pairs of EID-prefix (the
      well-known EID allocation range in  Classless Inter-Domain Routing (CIDR)  notation, e.g.,
      240.11.0.0/16) and lookup-length (the prefix length to use for
      hash computation when EIDs fall within this range, 0-32 for
      IPv4, 0-128 for IPv6).</t>

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

      <t>Example configuration with multiple EID ranges:</t>
<!-- [rfced] FYI - We have removed the <figure> element from the artwork in
Section 5.2 for consistency with other artwork elements in this
document, as they do not use this element. Please let us know if you
prefer otherwise. If you would like to add <figure>
      <preamble></preamble>
      <artwork><![CDATA[ elements around
the artwork in this document, the result would be that each figure would
be numbered and (optionally) have a title.
-->

        <artwork name="" type="" align="left" alt=""><![CDATA[
EID Range Configuration:
  Range: [0]240.11.0.0/16  -> lookup-length: 24
  Range: [0]240.12.0.0/16  -> lookup-length: 30
  Range: [0]240.13.0.0/16  -> lookup-length: 25

Lookup Examples:
  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.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)
]]></artwork>
      <postamble />
    </figure>

    <t>This approach is particularly useful in deployments where the
    mapping system uses a consistent ETR registration strategy (e.g.,
    all ETRs in a region register with /24 prefixes) prefixes), but ITRs receive
    packets with more-specific destinations (/32 addresses).
    <!-- [rfced] We have removed "protocol" from instances of "LISP
    protocol" since the expansion would read as "Locator/ID Separation Protocol
    protocol". How can we rephrase the sentence below to avoid "LISP
    protocols"?

    Current:
    By configuring the expected registration prefix length for each
    allocation range, ITRs can reliably locate the correct Map-Servers
    without modifying the LISP protocols or introducing complex
    multi-level lookups.

    Perhaps:
    By configuring the expected registration prefix length for each
    allocation range, ITRs can reliably locate the correct Map-Servers
    without modifying LISP or introducing complex
    multi-level lookups.
    -->
    By configuring the expected registration prefix length for each
    allocation range, ITRs can reliably locate the correct Map-Servers
    without modifying the LISP protocols or introducing complex
    multi-level lookups.</t>
  </section>

      <section title="Deployment Example"> numbered="true" toc="default">
        <name>Deployment Example</name>
        <t>Here is an example deployment of a Decent-Pull based Decent-Pull-based model. Let's say that 4 map-server sets are provisioned for the mapping system.
      Therefore
      Therefore, 4 distinct DNS names are allocated and a Modulus Value 4
      is used. Each DNS name is allocated Name Index 0 through 3:</t>

    <figure>
      <preamble></preamble>
      <artwork><![CDATA[

        <artwork name="" type="" align="left" alt=""><![CDATA[
    0.map-server.lispers.net
    1.map-server.lispers.net
    2.map-server.lispers.net
    3.map-server.lispers.net
      ]]></artwork>
      <postamble />
    </figure>
    3.map-server.lispers.net]]></artwork>

        <t>The A records for each name can be assigned as:</t>

    <figure>
      <preamble></preamble>
      <artwork><![CDATA[

        <artwork name="" type="" align="left" alt=""><![CDATA[
    0.map-server.lispers.net:
        A <rloc1-att>
        A <rloc2-verizon>
    1.map-server.lispers.net:
        A <rloc1-bt>
        A <rloc2-dt>
    2.map-server.lispers.net:
        A <rloc1-cn>
        A <rloc2-kr>
    3.map-server.lispers.net:
        A <rloc1-au>
        A <rloc2-nz>
      ]]></artwork>
      <postamble />
    </figure> <rloc2-nz>]]></artwork>

        <t>When an xTR wants to register "[1000]fd::2222", it hashes the
      EID string to produce, for example, hash value 0x66. Using the
      modulus value 4 (0x67 &amp; 0x3) produces index 0x3, so the DNS name
      3.map-server.lispers.net is used and a Map-Register is sent to
      &lt;rloc1-au&gt; and &lt;rloc2-nz&gt;.</t>
        <t>Note that the Decent-Pull based Decent-Pull-based method can be used for a core
      seed-group for bootstrapping a Decent-Push based mapping system Decent-Push-based Mapping System where
      multicast groups are registered.</t>
      </section>
      <section title="Management Considerations"> numbered="true" toc="default">
        <name>Management Considerations</name>
        <t>An implementation SHOULD <bcp14>SHOULD</bcp14> do periodic DNS lookups to determine
      if A records have changed for a DNS entry. This is a
      configuration parameter the network operator selects. This
      specification makes no recommendation for an interval value.</t>
        <t>When xTRs derive Map-Resolver and Map-Server names from the DNS,
      they need to use the same Modulus Value otherwise Value. Otherwise, some xTRs will lookup look up
      EIDs to the wrong place they were registered.</t>
        <t>The Modulus Value can be configured or pushed to the LISP-Decent xTRs.
      A future version of this document will describe a push mechanism so all
      xTRs use a consistent modulus value.</t>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Refer to the Security Considerations section of <xref
    target="RFC9301"/> target="RFC9301" sectionFormat="of" section="9"/> for a complete list of security
    mechanisms as well as pointers to threat analysis drafts.</t>

    <t>It is recommended, where documents.</t>
      <t>Where DNS is deployed for the Pull-Based Pull-based
    Mapping System, it is recommended to use DNSSEC <xref target="RFC9364"/> be used target="RFC9364" format="default"/> to add
    more security to the DNS lookup system.</t>
      <t>Replay attacks, spoofing, and trust relationships are discussed in detail in
    <xref target="RFC9301"/> target="RFC9301" format="default"/> and <xref target="RFC9303"/>.</t> target="RFC9303" format="default"/>.</t>
    </section>
    <section title="IANA Considerations">
    <t>At this time there are numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no specific requests for IANA.</t> IANA actions.</t>
    </section>
  </middle>
  <back>
  <references title='Normative References'>
    <?rfc include="reference.RFC.2119'?>
    <?rfc include="reference.RFC.8174'?>
    <?rfc include="reference.RFC.9300'?>
    <?rfc include="reference.RFC.9301'?>
    <?rfc include="reference.RFC.9303'?>
    <?rfc include="reference.RFC.9364'?>
    <?rfc include="reference.RFC.6832'?>
    <?rfc include="reference.RFC.6836'?>
    <?rfc include="reference.RFC.8111'?>
    <?rfc include="reference.RFC.8060'?>
    <?rfc include="reference.RFC.1034'?>
    <?rfc include="reference.RFC.1035'?>
    <?rfc include="reference.RFC.6234'?>
    <?rfc include="reference.RFC.9437'?>
    <?rfc include="reference.RFC.6831'?>
    <?rfc include="reference.RFC.8378'?>
    <displayreference target="I-D.ietf-lisp-ecdsa-auth" to="ECDSA-AUTH"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9300.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9301.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9303.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6832.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6836.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8111.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8060.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9437.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6831.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8378.xml"/>
      </references>

  <references title='Informative References'>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-ecdsa-auth.xml'?>
      <references>
        <name>Informative References</name>
<!--[I-D.ietf-lisp-ecdsa-auth]
draft-ietf-lisp-ecdsa-auth-15
IESG State: I-D Exists as of 12/12/25
-->
        <reference anchor="MAR-WG-PRESO"> anchor="I-D.ietf-lisp-ecdsa-auth" target="https://datatracker.ietf.org/doc/html/draft-ietf-lisp-ecdsa-auth-16">
          <front>
            <title>LISP WG March 2018 Presentation</title> Control-Plane ECDSA Authentication and Authorization</title>
            <author fullname="Dino Farinacci"/> Farinacci" initials="D." surname="Farinacci">
              <organization>lispers.net</organization>
            </author>
            <author fullname="Erik Nordmark" initials="E." surname="Nordmark">
              <organization>Zededa</organization>
            </author>
            <date year="2018" month="March" /> day="29" month="January" year="2026"/>
          </front>
      <refcontent>https://www.dropbox.com/scl/fi/eqoqestxsoc4w7zh2t8dr/lisp-decent-ietf-london.pdf?rlkey=dw0c96xtbi4c5074a2i90g4qh</refcontent>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-ecdsa-auth-16"/>
        </reference>
        <reference anchor="JUL-WG-PRESO"> anchor="IETF101-PRESO" target="https://datatracker.ietf.org/meeting/101/materials/slides-101-lisp-lisp-decentralized-mapping-system-00">
          <front>
	    <title>LISP
            <title>A Decentralized Mapping System: draft-farinacci-lisp-decent-00</title>
            <author fullname="Dino Farinacci"/>
            <author fullname="Colin Cantrell"/>
            <date year="2018" month="March"/>
          </front>
          <refcontent>IETF 101 Proceedings</refcontent>
        </reference>
<!-- [rfced] FYI, this reference has been updated to March 2019 (IETF 104)
because the URL provided shows March 2019.  However, if July 2019 (IETF 105)
was intended, please let us know.

Also, we updated the citation tags to [IETF101-PRESO] and [IETF104-PRESO]
and updated the URLs to the presentations available on Datatracker.

Original:
   [JUL-WG-PRESO]
              Farinacci, D., "LISP WG July 2019 Presentation</title> Presentation",
              https://www.dropbox.com/scl/fi/3z7uichvi8x9940xlz6pm/lisp-
              decent-ietf-prague.pdf?rlkey=4v1lup23zc0j6kpicqfr2npro,
              July 2019.

Current:
   [IETF104-PRESO]
              Farinacci, D. and C. Cantrell, "A Decentralized Mapping
              System: draft-farinacci-lisp-decent-03", IETF 104
              Proceedings, March 2019,
              <https://datatracker.ietf.org/meeting/104/materials/
              slides-104-lisp-a-decent-lisp-mapping-system-00>.
-->
        <reference anchor="IETF104-PRESO" target="https://datatracker.ietf.org/meeting/104/materials/slides-104-lisp-a-decent-lisp-mapping-system-00">
          <front>
            <title>A Decentralized Mapping System: draft-farinacci-lisp-decent-03</title>
            <author fullname="Dino Farinacci"/>
            <author fullname="Colin Cantrell"/>
            <date year="2019" month="July" /> month="March"/>
          </front>
      <refcontent>https://www.dropbox.com/scl/fi/3z7uichvi8x9940xlz6pm/lisp-decent-ietf-prague.pdf?rlkey=4v1lup23zc0j6kpicqfr2npro</refcontent>
<refcontent>IETF 104 Proceedings</refcontent>
        </reference>
      </references>

  <section title="Acknowledgments">
    <t>The authors would like
    </references>

<!-- [rfced] We have rephrased the following in the Acknowledgments
to thank conform with the LISP WG for their review
    and acceptance of this draft.</t>

    <t>The RFC Style Guide, as to avoid ambiguity with
RFC publication. Please let us know if you prefer otherwise.

Original:
   The authors would also like to give a special thanks to
   Roman Shaposhnik for several discussions that occurred before
   the first draft was published.</t>

    <t>ISE published.

   Eliot Lear and Victor Moreno are appreciated for their efforts
   proof reading the draft before Informational RFC publication.</t>
  </section>

  <section title="Document Change Log">
    <t>[RFC Editor: Please delete this section on publication as RFC.]</t>

    <section title="Changes publication.

Current:
   The authors would also like to draft-farinacci-lisp-decent-22">
      <t><list style="symbols">
        <t>Posted March 2026.</t>
        <t>Add section on configuring EID-prefix mask lengths in ITRs
        so when give a non /32 or /128 is registered, the lookup hash is
        consistent with the registration hash.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-21">
      <t><list style="symbols">
        <t>Posted November 2025.</t>
        <t>Remove normative references special thanks to bis documents
   Roman Shaposhnik for RFC6831, RFC8378,
        and RFC8060 but keep several discussions that occurred before
   the original RFCs.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-20">
      <t><list style="symbols">
        <t>Posted October 2025.</t>
        <t>Made editorial changes suggested by Eliot.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-19">
      <t><list style="symbols">
        <t>Posted October 2025.</t>
        <t>Victor Moreno completed proof-read and submitted editorial comments.</t>
        <t>Dino completed final proof-read.</t>
        <t>Updated references to latest working group drafts and RFCs.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-18">
      <t><list style="symbols">
        <t>Posted July 2025.</t>
        <t>Made suggested changes to reflect comments from Joel initial draft of this document.

   Eliot Lear and
        Padma per ISE (Eliot) distinguished review request. This
        should be final review cycle.</t>
      </list></t>
    </section> Victor Moreno are appreciated for their efforts
   proofreading the draft before publication as an RFC.
-->
    <section title="Changes to draft-farinacci-lisp-decent-17">
      <t><list style="symbols">
        <t>Posted April 2025.</t>
        <t>Made suggested changes numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to reflect second thank the LISP WG for their review from ISE (Eliot Lear).</t>
      </list></t>
    </section>

    <section title="Changes and
      acceptance of this draft.</t>
      <t>The authors would also like to draft-farinacci-lisp-decent-16">
      <t><list style="symbols">
        <t>Posted December 2024.</t>
        <t>Made suggested changes from ISE review.</t>
      </list></t>
    </section>

    <section title="Changes give a special thanks to draft-farinacci-lisp-decent-15">
      <t><list style="symbols">
        <t>Posted June 2024.</t>
        <t>Making <contact
      fullname="Roman Shaposhnik"/> for several discussions that occurred
      before the initial draft an ISE submission of this document.</t>
      <t><contact fullname="Eliot Lear"/> and <contact fullname="Victor
      Moreno"/> are appreciated for their efforts proofreading the draft
      before publication as Informational an RFC.</t>
        <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-14">
      <t><list style="symbols">
        <t>Posted April 2024.</t>
        <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-13">
      <t><list style="symbols">
        <t>Posted October 2023.</t>
        <t>Make

<!-- [rfced] Please review the general definitions "Inclusive Language" portion of "pull-based" and
        "push-based" be more specific to the way LISP-Decent uses
        them. Call them Decent-Pull and Decent-Push.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-12">
      <t><list style="symbols">
        <t>Posted August 2023.</t>
        <t>Update references online
Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-11">
      <t><list style="symbols">
        <t>Posted February 2023.</t>
        <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-10">
      <t><list style="symbols">
        <t>Posted August 2022.</t>
        <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-09">
      <t><list style="symbols">
        <t>Posted February 2022.</t>
        <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-08">
      <t><list style="symbols">
        <t>Posted August 2021.</t>
        <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-07">
      <t><list style="symbols">
        <t>Posted March 2021.</t>
        <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-06">
      <t><list style="symbols">
        <t>Posted September 2020.</t>
        <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-05">
      <t><list style="symbols">
        <t>Posted March 2020.</t>
        <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-04">
      <t><list style="symbols">
        <t>Posted September 2019.</t>
        <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-03">
      <t><list style="symbols">
        <t>Posted March 2019.</t>
        <t>Introduce the Hash Mask let us
know if any changes are needed.  Updates of this nature typically result in
more precise language, which is used to grab helpful for readers. In particular, please
consider whether "native" should be updated for clarity. A common bits from
replacement in RFCs for "native" is "built-in".

Current:
If a registered match is found, the ITR MUST use the configured lookup
prefix and length instead of the EID's native prefix length when
computing the hash string.

Perhaps:
If a match is found, the ITR MUST use the configured lookup prefix.</t>
        <t>Spec how multicast lookups are done in
prefix length instead of the pull-based mapping
        system.</t>
        <t>Indicate EID's built-in prefix length when
computing the hash string includes string.
-->

<!-- [rfced] Please review the unicast EID mask-length
        and multicast group form of the following terms and source mask-lengths.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-02">
      <t><list style="symbols">
        <t>Posted November 2018.</t>
        <t>Changed references from peer-group to seed-group to make let
us know if you prefer one form over the
        algorithms in this document more like how blockchain networks
        initialize the peer-to-peer network.</t>
        <t>Added pull mechanism to complement other. If there are no objections,
we will use the push mechanism. The
        pull mechanism could be used as a seed-group to bootstrap form on the
        push mechanism.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-decent-01">
      <t><list style="symbols">
        <t>Posted July 2018.</t>
        <t>Document timer and reference update.</t>
      </list></t>
    </section>

    <section title="Changes right.

   mapping system vs. Mapping System
   map-server vs. Map-Server
   Group address 233.252.2.2 vs. group 233.252.2.2
   Decent-Pushed Based vs. Decent-Push-Based
       (Updated to lowercase 'b' in running text: Decent-Push-based.)
-->

<!-- [rfced] FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to draft-farinacci-lisp-decent-00">
      <t><list style="symbols">
        <t>Initial draft posted January 2018.</t>
      </list></t>
    </section>

  </section> ensure correctness.
-->

  </back>
</rfc>