rfc9962xml2.original.xml   rfc9962.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<!-- Edited by Dino Farinacci farinacci@gmail.com -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc category="info" ipr="trust200902" docName="draft-farinacci-lisp-decent-22"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902 " docName="draft-farinacci-lisp-decent-22" number="9962" obsoletes="" updates="" submissionType="independent" xml:lang="en" tocInclude="true" symRefs="true" sor tRefs="true" version="3">
<?rfc toc="yes" ?> <front>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front> <!-- [rfced] Title
<title>A Decent LISP Mapping System (LISP-Decent)</title>
<author initials='D' surname="Farinacci" fullname='Dino Farinacci'> a) FYI - We have updated the short title of the document as follows to
<organization>lispers.net</organization> match the consistent hyphenation of "LISP-Decent". Please let us know any
<address><postal> objections.
<street></street>
<city>San Jose</city> <region>CA</region>
<code></code>
<country>USA</country>
</postal>
<email>farinacci@gmail.com</email></address>
</author>
<author initials='C' surname="Cantrell" fullname='Colin Cantrell'> Original:
<organization>Nexus</organization> LISP Decent
<address><postal>
<street></street>
<city>Tempe</city> <region>AZ</region>
<code></code>
<country>USA</country>
</postal>
<email>colin@nexus.io</email></address>
</author>
<date></date> Current:
LISP-Decent
<abstract> b) How may we update the title of the document to introduce the expansion of
<t>This draft describes how the LISP mapping system can be "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)</titl
e>
<seriesInfo name="RFC" value="9962"/>
<author initials="D" surname="Farinacci" fullname="Dino Farinacci">
<organization>lispers.net</organization>
<address>
<postal>
<city>San Jose</city>
<region>CA</region>
<country>United States of America</country>
</postal>
<email>farinacci@gmail.com</email>
</address>
</author>
<author initials="C" surname="Cantrell" fullname="Colin Cantrell">
<organization>Nexus</organization>
<address>
<postal>
<city>Tempe</city>
<region>AZ</region>
<country>United States of America</country>
</postal>
<email>colin@nexus.io</email>
</address>
</author>
<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.
Perhaps:
This document describes how the Locator/ID Separation Protocol (LISP)
mapping system can be distributed for scale and decentralized for
management, while maintaining trust among data plane nodes.
-->
<abstract>
<t>This document describes how the Locator/ID Separation Protocol (LISP) m
apping system can be
distributed for scale, decentralized for management and maintain distributed for scale, decentralized for management and maintain
trust among data-plane nodes. The intended status for this trust among data plane nodes. This
document is Informational RFC and should be used by LISP-Decent is an Informational RFC and should be used by LISP-Decent
implementations to interoperate with each other.</t> implementations to interoperate with each other.</t>
</abstract> </abstract>
</front>
<middle>
<!-- [rfced] Introduction: May we rephrase this 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?
<note title="Requirements Language"> Original:
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The LISP architecture and protocols [RFC9300] introduces two new
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators
"MAY", and "OPTIONAL" in this document are to be interpreted as (RLOCs) that are intended to provide overlay network functionality.
described in BCP 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.</t>
</note>
</front>
<middle> Perhaps:
<section title="Introduction"> The LISP architecture [RFC9300] introduces two new numbering spaces that
<t>The LISP architecture and protocols <xref target="RFC9300" /> are intended to provide overlay network functionality: Endpoint
Identifiers (EIDs) and Routing Locators (RLOCs).
-->
<section numbered="true" toc="default">
<name>Introduction</name>
<t>The LISP architecture and protocols <xref target="RFC9300" format="defa
ult"/>
introduces two new numbering spaces, Endpoint Identifiers (EIDs) introduces two new numbering spaces, Endpoint Identifiers (EIDs)
and Routing Locators (RLOCs) that are intended to provide overlay and Routing Locators (RLOCs) that are intended to provide overlay
network functionality. To map from EID to a set of RLOCs, a network functionality. To map from EIDs to a set of RLOCs, a
control-plane mapping system is used <xref target="RFC6836"/> control plane mapping system is used <xref target="RFC6836" format="default"
<xref target="RFC8111"/>. These mapping systems are naturally distributed />
<xref target="RFC8111" format="default"/>. These mapping systems are nat
urally distributed
in their deployment for scalability but are centrally 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 (MSP). The entities that use the mapping system, such as
data-plane LISP Tunnel Routers (xTRs), depend on and trust the data plane LISP Tunnel Routers (xTRs), depend on and trust the
MSP. They do not participate in the mapping system other than to MSP. They do not participate in the mapping system other than to
register and retrieve information <xref target="RFC9301" />.</t> register and retrieve information <xref target="RFC9301" format="default"/>.
</t>
<t>This document introduces a Decentralized Mapping System (DMS) <t>This document introduces a Decentralized Mapping System (DMS)
so the xTRs can participate in the mapping system as well as use 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 it. They can trust each other rather than rely on third-party
infrastructure. The xTRs act as Map-Servers to maintain infrastructure. The xTRs act as Map-Servers to maintain
distributed state for scale and reduce the attack surface. The trust distributed state for scale and reduce the attack surface. The trust
relationships between the xTRs are established through relationships between the xTRs are established through
authentication and authorization procedures in <xref authentication and authorization procedures in <xref target="RFC9301" format
target="RFC9301" /> and <xref target="I-D.ietf-lisp-ecdsa-auth"/>.</t> ="default"/> and <xref 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.
<t>This design was first introduced to the LISP WG in January Original:
2018. It was presented in London March 2018 <xref It was presented in London March 2018 [MAR-WG-PRESO] and in Prague
target="MAR-WG-PRESO"/> and in Prague July 2019 <xref July 2019 [JUL-WG-PRESO].
target="JUL-WG-PRESO"/>. This informational document is not a
standard and did not reach community consensus to make it IETF
LISP working group document.</t>
<t>The intended audience for this specification are protocol 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 Working Group (WG) in Janu
ary of
2018. It was presented in London in March 2018 <xref target="IETF101-PRESO"
format="default"/> and in Prague in March 2019 <xref target="IETF104-PRESO" form
at="default"/>. This Informational document is not a
standard and did not reach community consensus to make it an IETF
LISP WG document.</t>
<t>The intended audience for this specification are protocol
development engineers who would implement this specification in development engineers who would implement this specification in
products as well network engineers who deploy the technology in products as well network engineers who deploy the technology in
operational environments.</t> operational environments.</t>
<t>This design does not conflict with those designs or contradicts
<t>This design does not conflict with those designs or contradicts
any other LISP design principles produced by the working any other LISP design principles produced by the working
group. This solution makes no fundamental LISP protocol changes group. This solution makes no fundamental LISP changes
and adheres to the specifications documented in <xref and adheres to the specifications documented in <xref target="RFC9301" forma
target="RFC9301"/>.</t> t="default"/>.</t>
<t>By the nature of this work, this document uses IP addresses as
<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 examples. They should not be copied or used outside of a lab
environment. Deployments should use addresses appropriate for environment. Deployments should use addresses appropriate for
their environment.</t> their environment.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Definitions of Terms</name>
<dl newline="false" spacing="normal">
<dt>Mapping System Provider (MSP):</dt>
<dd>
<!-- [rfced] May we rephrase this sentence to clarify "who"
as "the organization"?
<section title="Definition of Terms"> Current:
<t><list style="hanging"> The MSP can be managed by a separate organization other than the one
<t hangText="Mapping System Provider (MSP):"> that manages xTRs. This model provides a business separation between
infrastructure service that deploys LISP Map-Resolvers and who manages and responsible for the control-plane versus who manages
Map-Servers <xref target="RFC9301"/> and possibly LISP-ALT nodes the data plane overlay service.
<xref target="RFC6836"/> or LISP-DDT nodes <xref
target="RFC8111"/>. ALT-nodes and DDT-nodes use different Perhaps:
algorithms for connecting together Map-Resolvers and The MSP can be managed by a separate organization other than the one
Map-Servers. The MSP can be managed by a separate organization 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" format="default"/> and possibly LISP-AL
T nodes
<xref target="RFC6836" format="default"/> or LISP-DDT nodes <xref target="
RFC8111" format="default"/>. ALT-nodes and DDT-nodes use different
algorithms for connecting Map-Resolvers and
Map-Servers together. The MSP can be managed by a separate organization
other than the one that manages xTRs. This model provides a other than the one that manages xTRs. This model provides a
business separation between who manages and responsible for business separation between who manages and responsible for
the control-plane versus who manages the data-plane overlay the control-plane versus who manages the data plane overlay
service.</t> service.</dd>
<dt>Decentralized Mapping System (DMS):</dt>
<t hangText="Decentralized Mapping System (DMS):">a mapping <dd>A mapping
system entity that is managed by the xTR nodes that use it and system entity that is managed by the xTR nodes that use it and
not third-party nodes/operators. The xTRs themselves are part of not third-party nodes/operators. The xTRs themselves are part of
the mapping system. The state of the mapping system is fully the mapping system. The state of the mapping system is fully
distributed across xTRs, decentralized, and the trust relies on distributed across xTRs, decentralized, and the trust relies on
the xTRs that use and participate in their own mapping the xTRs that use and participate in their own mapping
system.</t> system.</dd>
<dt>Decent-Pull-Based Mapping System:</dt>
<t hangText="Decent-Pull Based Mapping System:">the mapping <dd>The mapping
system is pull-based meaning that xTRs will lookup and register system is pull-based, meaning that xTRs will look up and register
mappings by algorithmic transformation to locate which mappings by algorithmic transformation to locate which
Map-Resolvers and Map-Servers are used. It is required that the Map-Resolvers and Map-Servers are used. It is required that the
lookup and registration uses a consistent algorithmic lookup and registration uses a consistent algorithmic
transformation function. Map-Registers are sent to specific transformation function. Map-Registers are sent to specific
Map-Servers. Map-Requests are considered external lookups when sent to Map-Servers. Map-Requests are considered external lookups when sent to
Map-Resolvers on xTRs that do not participate in the mapping Map-Resolvers on xTRs that do not participate in the mapping
system and the Map-Requests are considered internal lookups when they system and the Map-Requests are considered internal lookups when they
are sent to Map-Resolvers on xTRs that do participate in the mapping are sent to Map-Resolvers on xTRs that do participate in the mapping
system.</t> system.</dd>
<dt>Modulus Value:</dt>
<t hangText="Modulus Value:">this value is used in the <dd>This value is used in the
Pull-Based Mapping System. It defines the number of map-server Pull-based Mapping System. It defines the number of map-server
sets used for the mapping system. The modulus value is used to sets used for the mapping system. The modulus value is used to
produce a Name Index used for a DNS lookup. The Modulus Value is produce a Name Index used for a Domain Name System (DNS) lookup. The Modul us Value is
chosen based on the horizontal scale-out width of the map-server chosen based on the horizontal scale-out width of the map-server
cluster the network operator chooses to deploy.</t> cluster the network operator chooses to deploy.</dd>
<dt>Name Index:</dt>
<t hangText="Name Index:">this index value &lt;index&gt; is used in <dd>This index value &lt;index&gt; is used in
the Pull-Based Mapping System. For a mapping system that is the Pull-based Mapping System. For a mapping system that is
configured with a map-server set of DNS names in the form of configured with a map-server set of DNS names in the form of
&lt;name&gt;.example.com, the name index is prepended to &lt;name&gt; to &lt;name&gt;.example.com, the Name Index is prepended to &lt;name&gt; to
form the lookup name &lt;index&gt;.&lt;name&gt;.example.com. If form the lookup name &lt;index&gt;.&lt;name&gt;.example.com. If
the Modulus Value is 8, then the name indexes are 0 through 7.</t> the Modulus Value is 8, then the Name Indexes are 0 through 7.</dd>
<dt>Hash Mask:</dt>
<t hangText="Hash Mask:">The Hash Mask is used in the Pull-Based <dd>The Hash Mask is used in the Pull-based
Mapping System. It is a mask value with 1 bits left justified. Mapping System. It is a mask value with 1 bit left justified.
The mask is used to select what high-order bits of an EID-prefix are The mask is used to select what high-order bits of an EID-prefix are
used in the hash function.</t> used in the hash function.</dd>
<dt>Decent-Push-Based Mapping System:</dt>
<t hangText="Decent-Push Based Mapping System:">the mapping system is <dd>The mapping system is
push-based meaning that xTRs will push registrations via IP push-based, meaning that xTRs will push registrations via IP
multicast to a group of Map-Servers and do local lookups acting multicast to a group of Map-Servers and do local lookups acting
as their own Map-Resolvers.</t> as their own Map-Resolvers.</dd>
<dt>Replication List Entry (RLE):</dt>
<t hangText="Replication List Entry (RLE):">an RLOC-record <dd>An RLOC-record
format that contains a list of RLOCs that an Ingress Tunnel format that contains a list of RLOCs that an Ingress Tunnel
Router (ITR) replicates multicast packets on a multicast Router (ITR) replicates multicast packets on a multicast
overlay. The RLE format is specified in <xref overlay. The RLE format is specified in <xref target="RFC8060" format="def
target="RFC8060"/>. RLEs are used with the ault"/>. RLEs are used with the
Decent-Pushed Based mapping system.</t> Decent-Pushed Based mapping system.</dd>
<dt>Group Address EID:</dt>
<t hangText="Group Address EID:">an EID-record format that <dd>An EID-record format that
contains IPv4 (0.0.0.0/0, G) or IPv6 (0::/0, G) state. This contains IPv4 (0.0.0.0/0, G) or IPv6 (0::/0, G) state. This
state is encoded as a Multicast Info Type LCAF specified in state is encoded as a Multicast Info Type LISP Canonical Address Format (L
<xref target="RFC8060"/>. Members of a CAF) specified in
<xref target="RFC8060" format="default"/>. Members of a
seed-group send Map-Registers for (0.0.0.0/0, G) or (0::/0, G) 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 with an RLOC-record that RLE encodes its RLOC address. Details
are specified in <xref target="RFC8378"/>.</t> are specified in <xref target="RFC8378" format="default"/>.</dd>
<dt>Seed-Group:</dt>
<t hangText="Seed-Group:">a set of Map-Servers joined to a <dd>A set of Map-Servers joined to a
multicast group for the Decent-Push Based Mapping system or are mapped multicast group for the Decent-Push-based Mapping System or are mapped
by DNS names in a Pull-Based Mapping System. A core seed-group is used by DNS names in a Pull-based Mapping System. A core seed-group is used
to bootstrap a set of LISP-Decent xTRs so they can learn about each 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 other and use each other's mapping system service. A seed-group can
be pull-based to bootstrap the Decent-Push based mapping system. That is, be 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 mapping a set of DNS mapped map-servers can be used to join the mapping
system's IP multicast group.</t> system's IP multicast group.</dd>
</list></t> </dl>
</section> <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 title="Overview"> </section>
<t>The clients of the Decentralized Mapping System (DMS) are also <section numbered="true" toc="default">
the providers of mapping state, see <xref target="RFC9301"/> for <name>Overview</name>
<t>The clients of the DMS are also
the providers of mapping state, see <xref target="RFC9301" format="default"/
> for
formal details. Clients are typically Egress Tunnel Routers (ETRs) formal details. Clients are typically Egress Tunnel Routers (ETRs)
that Map-Register EID-to-RLOC mapping state to the mapping that Map-Register EID-to-RLOC mapping state to the mapping
database system. ITRs are clients in that they send Map-Requests database system. ITRs are clients in that they send Map-Requests
to the mapping database system to obtain EID-to-RLOC mappings that to the mapping database system to obtain EID-to-RLOC mappings that
are cached for data-plane use. When xTRs participate in a DMS, are cached for data plane use. When xTRs participate in a DMS,
they are also acting as Map-Resolvers and Map-Servers using the they are also acting as Map-Resolvers and Map-Servers using the
protocol machinery defined in LISP control-plane specifications protocol machinery defined in LISP control plane specifications
<xref target="RFC9301"/>, <xref target="RFC9303"/>, and <xref <xref target="RFC9301" format="default"/>, <xref target="RFC9303" format="de
target="I-D.ietf-lisp-ecdsa-auth"/>. The xTRs are not required to fault"/>, and <xref target="I-D.ietf-lisp-ecdsa-auth" format="default"/>. The xT
Rs are not required to
run the database mapping transport system protocols specified in run the database mapping transport system protocols specified in
<xref target="RFC6836"/> or <xref target="RFC8111"/>.</t> <xref target="RFC6836" format="default"/> or <xref target="RFC8111" format="
default"/>.</t>
<t>This document will describe two decentralized and distributed mapping <t>This document will describe two decentralized and distributed mapping
system mechanisms. A Decent-Push Based Mapping System uses IP multicast so system mechanisms. A Decent-Push-based Mapping System uses IP multicast so
xTRs can find each other by locally joining an IP multicast group. A xTRs can find each other by locally joining an IP multicast group. A
Decent-Pull Based Mapping System uses DNS with an algorithmic transformation Decent-Pull-based Mapping System uses DNS with an algorithmic transformation
function so xTRs can find each other.</t> function so xTRs can find each other.</t>
<t>The document proposes two approaches to provide
<t>The document proposes two approaches to provide
state/bandwidth, ease of configurability, and state/bandwidth, ease of configurability, and
robustness/complexity tradeoffs. When the Decent-Push Based robustness/complexity trade-offs. When the Decent-Push-based
approach is used there is less messaging involved. xTRs can approach is used, there is less messaging involved. xTRs can
multicast a single Map-Register message which goes to all 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 system added to or removed from the Map-Server cluster group, the mapping system
updates quickly with little human intervention. In the push model, updates quickly with little human intervention. In the push model,
all mapping state is stored in all Map-Servers so there is 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 multicast underlay in nodes between all xTRs and Map-Servers.
a multicast underlay is not available, the Decent-Pull Based
approach can be used with the help of the DNS system. This When a multicast underlay is not available, the Decent-Pull-based
approach can be used with the help of the DNS. This
approach uses less state overall among the Map-Servers (they each approach uses less state overall among the Map-Servers (they each
have different mapping system state) and the ITRs know which have different mapping system state) and the ITRs know which
Map-Server to ask by using the hashing techniques described later Map-Server to ask by using the hashing techniques described later
in this document.</t> 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
.)
<t>This document does not describe any compatibility with other 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 mapping systems. The design is intentional all xTRs and
Map-Servers support this specification. Moreover, all xTRs and Map-Servers support this specification. Moreover, all xTRs and
Map-Servers MUST support either the Pull-Based or Push-Based Map-Servers <bcp14>MUST</bcp14> support either the pull-based or push-based
algorithms. They cannot be mixed. When both are used, they are algorithms. They cannot be mixed. When both are used, they are
completely discrete mapping systems just like they would be using completely discrete mapping systems just like they would be using
one of the LISP Working Group mapping system designs. An one of the LISP WG mapping system designs. An
implementation can decide to implement only the Pull-Based approach or the implementation can decide to implement only the pull-based approach or the
Push-Based approach and still be compliant with this specification.</t> push-based approach and still be compliant with this specification.</t>
</section>
<t><vspace blankLines='40' /></t> <section numbered="true" toc="default">
</section> <name>Decent-Push-Based Mapping System</name>
<t>The xTRs are organized in a mapping-system group. The group is
<section title="Decent-Push Based Mapping System">
<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 identified by an IPv4 or IPv6 multicast group address or using a
Decent-Pull based approach described in <xref target="PULL"/>. When Decent-Pull-based approach described in <xref target="PULL" format="default" />. When
using multicast, the xTRs join the same multicast group and using multicast, the xTRs join the same multicast group and
receive LISP control-plane messages addressed to the receive LISP control plane messages addressed to the
group. Messages sent to the multicast group are distributed when group. Messages sent to the multicast group are distributed when
the underlay network supports IP multicast <xref the underlay network supports IP multicast <xref target="RFC6831" format="de
target="RFC6831"/> or via the overlay multicast fault"/> or via the overlay multicast
mechanism described in <xref target="RFC8378"/>. When overlay mechanism described in <xref target="RFC8378" format="default"/>. When overl
ay
multicast is used and LISP Map-Register messages are sent to the multicast is used and LISP Map-Register messages are sent to the
group, they are LISP data encapsulated with a instance-ID set to group, they are LISP data encapsulated with an instance-ID set to
0xffffff in the LISP header. The inner header of the encapsulated 0xffffff in the LISP header. The inner header of the encapsulated
packet has the destination address set to the multicast group packet has the destination address set to the multicast group
address and the outer header that is prepended has the destination address and the outer header that is prepended has the destination
address set to the RLOC of mapping system group member. The members of address set to the RLOC of mapping system group member. The members of
the mapping system group are kept in the LISP data-plane map-cache the mapping system group are kept in the LISP data plane map-cache
so packets for the group can be replicated to each member so packets for the group can be replicated to each member
RLOC.</t> RLOC.</t>
<t>All xTRs in a mapping system group will store the same
<t>All xTRs in a mapping system group will store the same
registered mappings and maintain the state as Map-Servers normally registered mappings and maintain the state as Map-Servers normally
do. The members are not only receivers of the multicast group but do. The members are not only receivers of the multicast group, but they
also send packets to the group.</t> also send packets to the group.</t>
<section numbered="true" toc="default">
<section title="Components of a Decent-Pushed Based LISP-Decent xTR"> <name>Components of a Decent-Pushed Based LISP-Decent xTR</name>
<t>When an xTR is configured to be a LISP-Decent xTR (or PxTR <t>When an xTR is configured to be a LISP-Decent xTR (or PxTR
<xref target="RFC6832"/>), it runs the ITR, ETR, Map-Resolver, <xref target="RFC6832" format="default"/>), it runs the ITR, ETR, Map-Reso
lver,
and Map-Server LISP network functions.</t> and Map-Server LISP network functions.</t>
<t>The following diagram shows 3 LISP-Decent xTRs joined to
<t>The following diagram shows 3 LISP-Decent xTRs joined to
mapping system group 233.252.1.1. When the ETR function of xTR1 mapping system group 233.252.1.1. When the ETR function of xTR1
originates a Map-Register, it is sent to all xTRs (including originates a Map-Register, it is sent to all xTRs (including
itself) synchronizing all 3 Map-Servers in xTR1, xTR2, and itself) synchronizing all 3 Map-Servers in xTR1, xTR2, and
xTR3. The ITR function can populate its map-cache by sending a xTR3. The ITR function can populate its map-cache by sending a
Map-Request locally to its Map-Resolver so it can replicate Map-Request locally to its Map-Resolver so it can replicate
packets to each RLOC for EID 233.252.1.1.</t> packets to each RLOC for EID 233.252.1.1.</t>
<t>In this document, there is no special meaning for the
<t>In this document, there is no special meaning for the
multicast group address 233.252.1.1. It is used for example multicast group address 233.252.1.1. It is used for example
purposes only.</t> purposes only.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure>
<preamble></preamble>
<artwork><![CDATA[
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]]></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.
]]></artwork> Original:
<postamble /> By doing a looking to this Map-Resolver for EID 233.252.1.1, the external xTR
</figure> could get the complete list of members for the mapping system group.
<t>Note if any external xTR would like to use a Map-Resolver Current:
from the mapping system group, it only needs to have one of the By looking at the Map-Resolver for EID 233.252.1.1, the external xTR
LISP-Decent Map-Resolvers configured. By doing a looking to this could get the complete list of members for the mapping system group.
Map-Resolver for EID 233.252.1.1, the external xTR could get the -->
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> complete list of members for the mapping system group.</t>
<t>For future study, an external xTR could multicast the
<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-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 Map-Resolvers would return a Map-Reply or the external xTR is
prepared to receive multiple Map-Replies.</t> prepared to receive multiple Map-Replies.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Implementation Considerations"> <name>Implementation Considerations</name>
<t>There are no LISP protocol changes required to support the <t>There are no LISP changes required to support the
Decent-Push based LISP-Decent set of procedures. An implementation Decent-Push-based LISP-Decent set of procedures. An implementation
that sends Map-Register messages to a multicast group versus a that sends Map-Register messages to a multicast group versus a
specific Map-Server unicast address MUST change to call the specific Map-Server unicast address <bcp14>MUST</bcp14> change to call the
data-plane component so the ITR functionality in the node can data plane component so the ITR functionality in the node can
encapsulate the Map-Register as a unicast packet to each member encapsulate the Map-Register as a unicast packet to each member
of the mapping system group.</t> of the mapping system group.</t>
<t>An ITR <bcp14>SHOULD</bcp14> look up its mapping system group address
<t>An ITR SHOULD lookup its mapping system group address
periodically to determine if the membership has changed. The periodically to determine if the membership has changed. The
lookup interval is a configuration parameter only needed when lookup interval is a configuration parameter only needed
when the ITR does not use the PubSub capability documented in when the ITR does not use the PubSub capability documented in
<xref target="RFC9437"/> to be notified when a new <xref target="RFC9437" format="default"/> to be notified when a new
member joins or leaves the multicast group. When PubSub is not member joins or leaves the multicast group. When PubSub is not
used, there needs to be coordination (via configuration used, there needs to be coordination (via configuration
management) among all xTRs so they rendezvous roughly at the management) among all xTRs so they rendezvous roughly at the
same time and to the same group address.</t> same time and to the same group address.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Configuration and Authentication"> <name>Configuration and Authentication</name>
<t>When xTRs are joined to a multicast group, they MUST have <t>When xTRs are joined to a multicast group, they <bcp14>MUST</bcp14> h
ave
their site registration configuration consistent. Any policy or their site registration configuration consistent. Any policy or
authentication key material MUST be configured consistently authentication key material <bcp14>MUST</bcp14> be configured consistently
among all members. When <xref among all members. When <xref target="I-D.ietf-lisp-ecdsa-auth" format="de
target="I-D.ietf-lisp-ecdsa-auth"/> is used to sign Map-Register fault"/> is used to sign Map-Register
messages, public-keys can be registered to the mapping system messages, public keys can be registered to the mapping system
group using the site authentication key mentioned above or using group using the site authentication key mentioned above or using
a different authentication key from the one used for registering a different authentication key from the one used for registering
EID records. An out-of-band registration controller, like an ETR EID records. An out-of-band registration controller, like an ETR
dedicated for this function, can send Map-Register messages for dedicated for this function, can send Map-Register messages for
public-key encoded EIDs.</t> public-key encoded EIDs.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Core Seed-Group"> <name>Core Seed-Group</name>
<t>A core seed-group can be discovered using a multicast group in <t>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-Pu a Decent-Push-based system or a Map-Server set of DNS names in a Decent-Pu
ll based ll-based
system (see <xref target="PULL"/> for details).</t> system (see <xref target="PULL" format="default"/> for details).</t>
<t>When using multicast for the mapping system group, a core seed-group
<t>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 decentralized mapping system. The group address (or DNS name
that maps to a group address) can be explicitly configured in a that maps to a group address) can be explicitly configured in a
few xTRs to start building up the registrations. Then as other xTRs few xTRs to start building up the registrations. Then as other xTRs
come online, they can add themselves to the core seed-group by come online, they can add themselves to the core seed-group by
joining the seed-group multicast group.</t> joining the seed-group multicast group.</t>
<t>Alternatively or additionally, new xTRs can join a new
<t>Alternatively or additionally, new xTRs can join a new
mapping system multicast group to form another layer of a mapping system multicast group to form another layer of a
decentralized mapping system. The group address and members of decentralized mapping system. The group address and members of
this new layer seed-group would be registered to the core this new layer seed-group would be registered to the core
seed-group address and stored in the core seed-group mapping seed-group address and stored in the core seed-group mapping
system. Note each mapping system layer could have a specific system. Note that each mapping system layer could have a specific
function or a specific circle of trust.</t> function or a specific circle of trust.</t>
<t>This multi-layer mapping system can be illustrated:</t>
<t><vspace blankLines='20' /></t> <artwork name="" type="" align="left" alt=""><![CDATA[
<t>This multi-layer mapping system can be illustrated:</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
____________ ----------- ____________ -----------
/ 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
| |
v v
--------- ---------
skipping to change at line 422 skipping to change at line 497
233.252.3.3 -> RLE: X, Y, Z 233.252.3.3 -> RLE: X, Y, Z
layer-1 seed-group DMS (inter-continental), mapping state in I, J, K: layer-1 seed-group DMS (inter-continental), mapping state in I, J, K:
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)]]></artwork>
]]></artwork>
<postamble />
</figure>
<t>The core seed-group multicast address 233.252.1.1 is configured <t>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 in xTRs A, B, and C so when each of them send Map-Register
messages, they would all be able to maintain synchronized messages, they would all be able to maintain synchronized
mapping state. Any EID can be registered to this DMS but in this mapping state. Any EID can be registered to this DMS, but in this
example, seed-group multicast group EIDs are being registered example, seed-group multicast group EIDs are being registered
only to find other mapping system groups.</t> only to find other mapping system groups.</t>
<t>For example, xTR I boots up and it wants to
<t>For example, lets say that xTR I boots up and it wants to
find its other peers in its mapping system group 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 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 xTR I needs what group to join for its mapping system group. However, xTR I needs
a mapping system to register to, so the core seed-group is used 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 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 or K in the mapping system group do the same so when any of I, J, or K
needs to register EIDs, they can now send their Map-Register needs to register EIDs, they can now send their Map-Register
messages to group 233.252.2.2. Examples of EIDs being register are messages to group 233.252.2.2. Examples of EIDs being registered are
EID1 through EIDn shown above.</t> EID1 through EIDn shown above.</t>
<t>When Map-Registers are sent to group 233.252.2.2, they are
<t>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
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 in 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 to be populated for 233.252.2.2, the data plane <bcp14>MUST</bcp14> send a
Map-Request so the RLOCs I, J, and K are cached for Map-Request so the RLOCs I, J, and K are cached for
replication. To use the core seed-group mapping system, the replication. To use the core seed-group mapping system, the
data-plane MUST know of at least one of the RLOCs A, B, and/or data plane <bcp14>MUST</bcp14> know of at least one of the RLOCs A, B, and /or
C.</t> C.</t>
</section>
</section> </section>
</section> <section anchor="PULL" numbered="true" toc="default">
<name>Decent-Pull-Based Mapping System</name>
<section title="Decent-Pull Based Mapping System" anchor="PULL"> <section numbered="true" toc="default">
<section title="Components of a Decent-Pulled Based LISP-Decent xTR"> <name>Components of a Decent-Pulled Based LISP-Decent xTR</name>
<t>When an xTR is configured to be a LISP-Decent xTR (or PxTR <t>When an xTR is configured to be a LISP-Decent xTR (or PxTR
<xref target="RFC6832"/>), it runs the ITR, ETR, Map-Resolver, <xref target="RFC6832" format="default"/>), it runs the ITR, ETR, Map-Reso
lver,
and Map-Server LISP network functions.</t> and Map-Server LISP network functions.</t>
<t>Unlike the Decent-Push-based Mapping System, the xTRs do not need to
<t>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 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 which xTR is used as the Map-Resolver and Map-Server. The DNS <xref target
Name System (DNS) <xref target="RFC1034"/> <xref ="RFC1034" format="default"/> <xref target="RFC1035" format="default"/> is used
target="RFC1035"/> is used as a resource discovery mechanism.</t> as a resource discovery mechanism.</t>
<t>The RLOC addresses of the xTRs will be A and AAAA records for
<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 DNS names that map algorithmically from the hash of the EID. A
SHA-256 hash function <xref target="RFC6234"/> over the SHA-256 hash function <xref target="RFC6234" format="default"/> over the
following ASCII formatted EID string is used:</t> following ASCII-formatted EID string is used:</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<preamble></preamble>
<artwork><![CDATA[
[<iid>]<eid>/<ml> [<iid>]<eid>/<ml>
[<iid>]<group>/<gml>-<source>/<sml> [<iid>]<group>/<gml>-<source>/<sml>]]></artwork>
]]></artwork>
<postamble />
</figure>
<t>In this section, where you see angle brackets, they are <t>In this section, where you see angle brackets, they are
replaced with values in ASCII characters. For example, a unicast 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 EID of 1.1.1.1 in instance-id 11 would be encoded as a string
"[11]1.1.1.1/32".</t> "[11]1.1.1.1/32".</t>
<t>&lt;iid&gt; is the instance-ID and &lt;eid&gt; is the EID
<t>Where &lt;iid&gt; is the instance-ID and &lt;eid&gt; is the EID of any EID-type defined in <xref target="RFC8060" format="default"/>. The Mo
of any EID-type defined in <xref dulus Value
target="RFC8060"/>. And then the Modulus Value
&lt;mv&gt; is used to produce the Name Index &lt;index&gt; used to &lt;mv&gt; is used to produce the Name Index &lt;index&gt; used to
build the DNS lookup name:</t> build the DNS lookup name:</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<preamble></preamble>
<artwork><![CDATA[
eid = "[<iid>]<eid>/<ml>" eid = "[<iid>]<eid>/<ml>"
index = hash.sha_256(eid) MOD mv index = hash.sha_256(eid) MOD mv]]></artwork>
]]></artwork>
<postamble />
</figure>
<t>The Hash Mask is used to select what bits are used in the <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 SHA-256 hash function. This is required to support longest match
lookups in the mapping system. The same map-server set needs to be lookups in the mapping system. The same map-server set needs to be
selected when looking up a more-specific EID found in the selected when looking up a more-specific EID found in the
Map-Request message with one that could match a less-specific Map-Request message with one that could match a less-specific
EID-prefix registered and found in the Map-Register message. For 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 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 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 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 the /32 or /24 entries to produce the same hash string bits
of "[0]240.0".</t> of "[0]240.0".</t>
<t>For (*,G) and (S,G) multicast entries in the mapping system,
<t>For (*,G) and (S,G) multicast entries in the mapping system,
the hash strings are:</t> the hash strings are:</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<preamble></preamble>
<artwork><![CDATA[
sg-eid = "[<iid>]<group>/<gml>-<source>/<sml>" sg-eid = "[<iid>]<group>/<gml>-<source>/<sml>"
index = hash.sha_256(sg-eid) MOD mv index = hash.sha_256(sg-eid) MOD mv
starg-eid = "[<iid>]<group>/<gml>-0.0.0.0/0" starg-eid = "[<iid>]<group>/<gml>-0.0.0.0/0"
index = hash.sha_256(starg-eid) MOD mv index = hash.sha_256(starg-eid) MOD mv]]></artwork>
]]></artwork>
<postamble />
</figure>
<t>The Hash Mask MUST include the string <t>The Hash Mask <bcp14>MUST</bcp14> include the string
"[&lt;iid&gt;]&lt;group&gt;" and not string &lt;source&gt;. So "[&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 (*, 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 233.252.1.1/32), the hash string produced with a Hash Mask of 12
bytes is "[0]233.252.1.1".</t> bytes is "[0]233.252.1.1".</t>
<t>When the &lt;index&gt; is computed from a unicast or multicast EID,
<t>When the &lt;index&gt; is computed from a unicast or multicast EID,
the DNS lookup name becomes:</t> the DNS lookup name becomes:</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<preamble></preamble> <index>.map-server.example.com]]></artwork>
<artwork><![CDATA[
<index>.map-server.example.com
]]></artwork>
<postamble />
</figure>
<t>When an xTR does a DNS lookup on the lookup name, it will send <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 Map-Register messages to all A and AAAA records for EID
registrations. For Map-Request messages, xTRs MAY round robin EID registrations. For Map-Request messages, xTRs <bcp14>MAY</bcp14> round robin EID
lookup requests among the A and AAAA records.</t> lookup requests among the A and AAAA records.</t>
</section> </section>
<section title="Configurable EID Prefix Lengths for Lookups"> <section numbered="true" toc="default">
<name>Configurable EID Prefix Lengths for Lookups</name>
<t>In implementations where EID allocations follow a predictable <t>In implementations where EID allocations follow a predictable
pattern, operators MAY configure ITRs to use specific prefix pattern, operators <bcp14>MAY</bcp14> configure ITRs to use specific prefi x
lengths for lookups when the EID falls within well-known lengths for lookups when the EID falls within well-known
allocation ranges. This configuration allows ITRs to compute the allocation ranges. This configuration allows ITRs to compute the
correct hash index even when data packets carry more-specific correct hash index even when data packets carry more-specific
EIDs than the prefix lengths used by ETRs during registration.</t> EIDs than the prefix lengths used by ETRs during registration.</t>
<t>For example, if an operator allocates EIDs in the range <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 [0]240.11.0.0/16 and all ETRs register these EIDs with a /24
prefix length, ITRs receiving data packets for EIDs like 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 [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 correct Map-Server. Without this configuration, the ITR would
hash on the /32 and potentially query the wrong Map-Server.</t> hash on the /32 and potentially query the wrong Map-Server.</t>
<t>ITRs SHOULD support configuration of EID prefix ranges and <t>ITRs <bcp14>SHOULD</bcp14> support configuration of EID prefix ranges a nd
their associated lookup prefix lengths. When an ITR performs a their associated lookup prefix lengths. When an ITR performs a
Map-Request lookup, it SHOULD check if the destination EID Map-Request lookup, it <bcp14>SHOULD</bcp14> check if the destination EID
matches any configured range. If a match is found, the ITR MUST matches any configured range. If a match is found, the ITR <bcp14>MUST</bc
p14>
use the configured lookup prefix length instead of the EID's use the configured lookup prefix length instead of the EID's
native prefix length when computing the hash string. When native prefix length when computing the hash string. When
multiple configured ranges match a given EID, the range with the multiple configured ranges match a given EID, the range with the
longest (most-specific) configured prefix length MUST be longest (most-specific) configured prefix length <bcp14>MUST</bcp14> be
selected.</t> selected.</t>
<t>The configuration consists of pairs of EID-prefix (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., well-known EID allocation range in CIDR notation, e.g.,
240.11.0.0/16) and lookup-length (the prefix length to use for 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 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> IPv4, 0-128 for IPv6).</t>
<t>Implementation note: When computing the hash string for a <t>Implementation note: When computing the hash string for a
lookup where the EID matches a configured range, the ITR MUST lookup where the EID matches a configured range, the ITR <bcp14>MUST</bcp1 4>
construct the hash string using the configured lookup-length, construct the hash string using the configured lookup-length,
ensuring that the bits beyond the lookup-length are zero (i.e., ensuring that the bits beyond the lookup-length are zero (i.e.,
the EID address is masked to the lookup-length before converting the EID address is masked to the lookup-length before converting
to the hash string format).</t> to the hash string format).</t>
<t>Example configuration with multiple EID ranges:</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> elements around
the artwork in this document, the result would be that each figure would
be numbered and (optionally) have a title.
-->
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<preamble></preamble> EID Range Configuration:
<artwork><![CDATA[ Range: [0]240.11.0.0/16 -> lookup-length: 24
EID Range Configuration: Range: [0]240.12.0.0/16 -> lookup-length: 30
Range: [0]240.11.0.0/16 -> lookup-length: 24 Range: [0]240.13.0.0/16 -> lookup-length: 25
Range: [0]240.12.0.0/16 -> lookup-length: 30
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)
]]></artwork> ]]></artwork>
<postamble />
</figure>
<t>This approach is particularly useful in deployments where the <t>This approach is particularly useful in deployments where the
mapping system uses a consistent ETR registration strategy (e.g., mapping system uses a consistent ETR registration strategy (e.g.,
all ETRs in a region register with /24 prefixes) but ITRs receive all ETRs in a region register with /24 prefixes), but ITRs receive
packets with more-specific destinations (/32 addresses). By packets with more-specific destinations (/32 addresses).
configuring the expected registration prefix length for each <!-- [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 allocation range, ITRs can reliably locate the correct Map-Servers
without modifying the LISP protocols or introducing complex without modifying the LISP protocols or introducing complex
multi-level lookups.</t> multi-level lookups.</t>
</section> </section>
<section title="Deployment Example"> <section numbered="true" toc="default">
<t>Here is an example deployment of a Decent-Pull based model. Let's <name>Deployment Example</name>
say 4 map-server sets are provisioned for the mapping system. <t>Here is an example deployment of a Decent-Pull-based model. Let's say
Therefore 4 distinct DNS names are allocated and a Modulus Value 4 that 4 map-server sets are provisioned for the mapping system.
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> is used. Each DNS name is allocated Name Index 0 through 3:</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<preamble></preamble>
<artwork><![CDATA[
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]]></artwork>
]]></artwork>
<postamble />
</figure>
<t>The A records for each name can be assigned as:</t> <t>The A records for each name can be assigned as:</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<preamble></preamble>
<artwork><![CDATA[
0.map-server.lispers.net: 0.map-server.lispers.net:
A <rloc1-att> A <rloc1-att>
A <rloc2-verizon> A <rloc2-verizon>
1.map-server.lispers.net: 1.map-server.lispers.net:
A <rloc1-bt> A <rloc1-bt>
A <rloc2-dt> A <rloc2-dt>
2.map-server.lispers.net: 2.map-server.lispers.net:
A <rloc1-cn> A <rloc1-cn>
A <rloc2-kr> A <rloc2-kr>
3.map-server.lispers.net: 3.map-server.lispers.net:
A <rloc1-au> A <rloc1-au>
A <rloc2-nz> A <rloc2-nz>]]></artwork>
]]></artwork>
<postamble />
</figure>
<t>When an xTR wants to register "[1000]fd::2222", it hashes the <t>When an xTR wants to register "[1000]fd::2222", it hashes the
EID string to produce, for example, hash value 0x66. Using 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 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 3.map-server.lispers.net is used and a Map-Register is sent to
&lt;rloc1-au&gt; and &lt;rloc2-nz&gt;.</t> &lt;rloc1-au&gt; and &lt;rloc2-nz&gt;.</t>
<t>Note that the Decent-Pull-based method can be used for a core
<t>Note that the Decent-Pull based method can be used for a core seed-group for bootstrapping a Decent-Push-based Mapping System where
seed-group for bootstrapping a Decent-Push based mapping system where
multicast groups are registered.</t> multicast groups are registered.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Management Considerations"> <name>Management Considerations</name>
<t>An implementation SHOULD do periodic DNS lookups to determine <t>An implementation <bcp14>SHOULD</bcp14> do periodic DNS lookups to de
termine
if A records have changed for a DNS entry. This is a if A records have changed for a DNS entry. This is a
configuration parameter the network operator selects. This configuration parameter the network operator selects. This
specification makes no recommendation for an interval value.</t> specification makes no recommendation for an interval value.</t>
<t>When xTRs derive Map-Resolver and Map-Server names from the DNS,
<t>When xTRs derive Map-Resolver and Map-Server names from the DNS, they need to use the same Modulus Value. Otherwise, some xTRs will look up
they need to use the same Modulus Value otherwise some xTRs will lookup
EIDs to the wrong place they were registered.</t> EIDs to the wrong place they were registered.</t>
<t>The Modulus Value can be configured or pushed to the LISP-Decent xTRs
<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 A future version of this document will describe a push mechanism so all
xTRs use a consistent modulus value.</t> xTRs use a consistent modulus value.</t>
</section>
</section> </section>
</section> <section numbered="true" toc="default">
<name>Security Considerations</name>
<section title="Security Considerations"> <t>Refer to <xref target="RFC9301" sectionFormat="of" section="9"/> for a
<t>Refer to the Security Considerations section of <xref complete list of security
target="RFC9301"/> for a complete list of security mechanisms as well as pointers to threat analysis documents.</t>
mechanisms as well as pointers to threat analysis drafts.</t> <t>Where DNS is deployed for the Pull-based
Mapping System, it is recommended to use DNSSEC <xref target="RFC9364" forma
<t>It is recommended, where DNS is deployed for the Pull-Based t="default"/> to add
Mapping System, DNSSEC <xref target="RFC9364"/> be used to add
more security to the DNS lookup system.</t> more security to the DNS lookup system.</t>
<t>Replay attacks, spoofing, and trust relationships are discussed in deta
<t>Replay attacks, spoofing, and trust relationships are discussed in detail il in
in <xref target="RFC9301" format="default"/> and <xref target="RFC9303" format=
<xref target="RFC9301"/> and <xref target="RFC9303"/>.</t> "default"/>.</t>
</section>
<section title="IANA Considerations">
<t>At this time there are no specific requests for IANA.</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'?>
</references>
<references title='Informative References'>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf
-lisp-ecdsa-auth.xml'?>
<reference anchor="MAR-WG-PRESO">
<front>
<title>LISP WG March 2018 Presentation</title>
<author fullname="Dino Farinacci"/>
<date year="2018" month="March" />
</front>
<refcontent>https://www.dropbox.com/scl/fi/eqoqestxsoc4w7zh2t8dr/lisp-dece
nt-ietf-london.pdf?rlkey=dw0c96xtbi4c5074a2i90g4qh</refcontent>
</reference>
<reference anchor="JUL-WG-PRESO">
<front>
<title>LISP WG July 2019 Presentation</title>
<author fullname="Dino Farinacci"/>
<date year="2019" month="July" />
</front>
<refcontent>https://www.dropbox.com/scl/fi/3z7uichvi8x9940xlz6pm/lisp-dece
nt-ietf-prague.pdf?rlkey=4v1lup23zc0j6kpicqfr2npro</refcontent>
</reference>
</references>
<section title="Acknowledgments">
<t>The authors would like to thank the LISP WG for their review
and acceptance of this draft.</t>
<t>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 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 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 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 to bis documents for RFC6831, RFC8378,
and RFC8060 but keep 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 and
Padma per ISE (Eliot) distinguished review request. This
should be final review cycle.</t>
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-decent-17">
<t><list style="symbols">
<t>Posted April 2025.</t>
<t>Made suggested changes to reflect second review from ISE (Eliot Lear)
.</t>
</list></t>
</section>
<section title="Changes 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 to draft-farinacci-lisp-decent-15">
<t><list style="symbols">
<t>Posted June 2024.</t>
<t>Making draft an ISE submission as Informational 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>
<section numbered="true" toc="default">
<section title="Changes to draft-farinacci-lisp-decent-13"> <name>IANA Considerations</name>
<t><list style="symbols"> <t>This document has no IANA actions.</t>
<t>Posted October 2023.</t>
<t>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.</t>
</list></t>
</section> </section>
</middle>
<back>
<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.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
300.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
301.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
303.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
364.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
832.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
836.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
111.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
060.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
034.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
035.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
437.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
831.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
378.xml"/>
</references>
<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="I-D.ietf-lisp-ecdsa-auth" target="https://datatracker
.ietf.org/doc/html/draft-ietf-lisp-ecdsa-auth-16">
<front>
<title>LISP Control-Plane ECDSA Authentication and Authorization</ti
tle>
<author fullname="Dino Farinacci" initials="D." surname="Farinacci">
<organization>lispers.net</organization>
</author>
<author fullname="Erik Nordmark" initials="E." surname="Nordmark">
<organization>Zededa</organization>
</author>
<date day="29" month="January" year="2026"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lisp-ecdsa-auth-16
"/>
</reference>
<reference anchor="IETF101-PRESO" target="https://datatracker.ietf.org/m
eeting/101/materials/slides-101-lisp-lisp-decentralized-mapping-system-00">
<front>
<title>A Decentralized Mapping System: draft-farinacci-lisp-decent-0
0</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.
<section title="Changes to draft-farinacci-lisp-decent-12"> Also, we updated the citation tags to [IETF101-PRESO] and [IETF104-PRESO]
<t><list style="symbols"> and updated the URLs to the presentations available on Datatracker.
<t>Posted August 2023.</t>
<t>Update references and document expiry timer.</t>
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-decent-11"> Original:
<t><list style="symbols"> [JUL-WG-PRESO]
<t>Posted February 2023.</t> Farinacci, D., "LISP WG July 2019 Presentation",
<t>Update references and document expiry timer.</t> https://www.dropbox.com/scl/fi/3z7uichvi8x9940xlz6pm/lisp-
</list></t> decent-ietf-prague.pdf?rlkey=4v1lup23zc0j6kpicqfr2npro,
</section> July 2019.
<section title="Changes to draft-farinacci-lisp-decent-10"> Current:
<t><list style="symbols"> [IETF104-PRESO]
<t>Posted August 2022.</t> Farinacci, D. and C. Cantrell, "A Decentralized Mapping
<t>Update references and document expiry timer.</t> System: draft-farinacci-lisp-decent-03", IETF 104
</list></t> Proceedings, March 2019,
</section> <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/m
eeting/104/materials/slides-104-lisp-a-decent-lisp-mapping-system-00">
<front>
<title>A Decentralized Mapping System: draft-farinacci-lisp-decent-0
3</title>
<author fullname="Dino Farinacci"/>
<author fullname="Colin Cantrell"/>
<date year="2019" month="March"/>
</front>
<refcontent>IETF 104 Proceedings</refcontent>
</reference>
</references>
</references>
<section title="Changes to draft-farinacci-lisp-decent-09"> <!-- [rfced] We have rephrased the following in the Acknowledgments
<t><list style="symbols"> to conform with the RFC Style Guide, as to avoid ambiguity with
<t>Posted February 2022.</t> RFC publication. Please let us know if you prefer otherwise.
<t>Update references and document expiry timer.</t>
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-decent-08"> Original:
<t><list style="symbols"> The authors would also like to give a special thanks to
<t>Posted August 2021.</t> Roman Shaposhnik for several discussions that occurred before
<t>Update references and document expiry timer.</t> the first draft was published.
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-decent-07"> Eliot Lear and Victor Moreno are appreciated for their efforts
<t><list style="symbols"> proof reading the draft before Informational RFC publication.
<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"> Current:
<t><list style="symbols"> The authors would also like to give a special thanks to
<t>Posted September 2020.</t> Roman Shaposhnik for several discussions that occurred before
<t>Update references and document expiry timer.</t> the initial draft of this document.
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-decent-05"> Eliot Lear and Victor Moreno are appreciated for their efforts
<t><list style="symbols"> proofreading the draft before publication as an RFC.
<t>Posted March 2020.</t> -->
<t>Update references and document expiry timer.</t> <section numbered="false" toc="default">
</list></t> <name>Acknowledgments</name>
<t>The authors would like to thank the LISP WG for their review and
acceptance of this draft.</t>
<t>The authors would also like to give a special thanks to <contact
fullname="Roman Shaposhnik"/> for several discussions that occurred
before the initial draft 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 an RFC.</t>
</section> </section>
<section title="Changes to draft-farinacci-lisp-decent-04"> <!-- [rfced] Please review the "Inclusive Language" portion of the online
<t><list style="symbols"> Style Guide
<t>Posted September 2019.</t> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us
<t>Update references and document expiry timer.</t> know if any changes are needed. Updates of this nature typically result in
</list></t> more precise language, which is helpful for readers. In particular, please
</section> consider whether "native" should be updated for clarity. A common
replacement in RFCs for "native" is "built-in".
<section title="Changes to draft-farinacci-lisp-decent-03"> Current:
<t><list style="symbols"> If a match is found, the ITR MUST use the configured lookup
<t>Posted March 2019.</t> prefix length instead of the EID's native prefix length when
<t>Introduce the Hash Mask which is used to grab common bits from computing the hash string.
a registered prefix and a lookup prefix.</t>
<t>Spec how multicast lookups are done in the pull-based mapping
system.</t>
<t>Indicate the hash string includes the unicast EID mask-length
and multicast group and source mask-lengths.</t>
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-decent-02"> Perhaps:
<t><list style="symbols"> If a match is found, the ITR MUST use the configured lookup
<t>Posted November 2018.</t> prefix length instead of the EID's built-in prefix length when
<t>Changed references from peer-group to seed-group to make the computing the hash string.
algorithms in this document more like how blockchain networks -->
initialize the peer-to-peer network.</t>
<t>Added pull mechanism to complement the push mechanism. The
pull mechanism could be used as a seed-group to bootstrap the
push mechanism.</t>
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-decent-01"> <!-- [rfced] Please review the form of the following terms and let
<t><list style="symbols"> us know if you prefer one form over the other. If there are no objections,
<t>Posted July 2018.</t> we will use the form on the right.
<t>Document timer and reference update.</t>
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-decent-00"> mapping system vs. Mapping System
<t><list style="symbols"> map-server vs. Map-Server
<t>Initial draft posted January 2018.</t> Group address 233.252.2.2 vs. group 233.252.2.2
</list></t> Decent-Pushed Based vs. Decent-Push-Based
</section> (Updated to lowercase 'b' in running text: Decent-Push-based.)
-->
</section> <!-- [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 ensure correctness.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 150 change blocks. 
617 lines changed or deleted 652 lines changed or added

This html diff was produced by rfcdiff 1.48.