rfc9962v1.txt   rfc9962.txt 
Independent Submission D. Farinacci Independent Submission D. Farinacci
Request for Comments: 9962 lispers.net Request for Comments: 9962 lispers.net
Category: Informational C. Cantrell Category: Informational C. Cantrell
ISSN: 2070-1721 Nexus ISSN: 2070-1721 Nexus
April 2026 April 2026
A Decent LISP Mapping System (LISP-Decent) A Decentralized Locator/ID Separation Protocol Mapping System (LISP-
Decent)
Abstract Abstract
This document describes how the Locator/ID Separation Protocol (LISP) This document describes how the Locator/ID Separation Protocol (LISP)
mapping system can be distributed for scale, decentralized for Mapping System can be distributed for scale and decentralized for
management and maintain trust among data plane nodes. This is an management, while maintaining trust among data plane nodes. This is
Informational RFC and should be used by LISP-Decent implementations an Informational RFC and should be used by LISP-Decent
to interoperate with each other. implementations to interoperate with each other.
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for informational purposes. published for informational purposes.
This is a contribution to the RFC Series, independently of any other This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by implementation or deployment. Documents approved for publication by
skipping to change at line 53 skipping to change at line 54
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Definitions of Terms 2. Definitions of Terms
2.1. Requirements Language 2.1. Requirements Language
3. Overview 3. Overview
4. Decent-Push-Based Mapping System 4. Decent-Push-Based Mapping System
4.1. Components of a Decent-Pushed Based LISP-Decent xTR 4.1. Components of a Decent-Push-Based LISP-Decent xTR
4.2. Implementation Considerations 4.2. Implementation Considerations
4.3. Configuration and Authentication 4.3. Configuration and Authentication
4.4. Core Seed-Group 4.4. Core Seed-Group
5. Decent-Pull-Based Mapping System 5. Decent-Pull-Based Mapping System
5.1. Components of a Decent-Pulled Based LISP-Decent xTR 5.1. Components of a Decent-Pulled Based LISP-Decent xTR
5.2. Configurable EID Prefix Lengths for Lookups 5.2. Configurable EID Prefix Lengths for Lookups
5.3. Deployment Example 5.3. Deployment Example
5.4. Management Considerations 5.4. Management Considerations
6. Security Considerations 6. Security Considerations
7. IANA Considerations 7. IANA Considerations
8. References 8. References
8.1. Normative References 8.1. Normative References
8.2. Informative References 8.2. Informative References
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
The LISP architecture and protocols [RFC9300] introduces two new The LISP architecture [RFC9300] introduces two new numbering spaces
numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators that are intended to provide overlay network functionality: Endpoint
(RLOCs) that are intended to provide overlay network functionality. Identifiers (EIDs) and Routing Locators (RLOCs). To map from EIDs to
To map from EIDs to a set of RLOCs, a control plane mapping system is a set of RLOCs, a control plane Mapping System is used [RFC6836]
used [RFC6836] [RFC8111]. These mapping systems are naturally [RFC8111]. These Mapping Systems are naturally distributed in their
distributed in their deployment for scalability but are centrally deployment for scalability but are centrally managed by a third-party
managed by a third-party entity, namely a Mapping System Provider entity, namely a Mapping System Provider (MSP). The entities that
(MSP). The entities that use the mapping system, such as data plane use the Mapping System, such as data plane LISP Tunnel Routers
LISP Tunnel Routers (xTRs), depend on and trust the MSP. They do not (xTRs), depend on and trust the MSP. They do not participate in the
participate in the mapping system other than to register and retrieve Mapping System other than to register and retrieve information
information [RFC9301]. [RFC9301].
This document introduces a Decentralized Mapping System (DMS) so the This document introduces a Decentralized Mapping System (DMS) so the
xTRs can participate in the mapping system as well as use it. They xTRs can participate in the Mapping System as well as use it. They
can trust each other rather than rely on third-party infrastructure. can trust each other rather than rely on third-party infrastructure.
The xTRs act as Map-Servers to maintain distributed state for scale The xTRs act as Map-Servers to maintain distributed state for scale
and reduce the attack surface. The trust relationships between the and reduce the attack surface. The trust relationships between the
xTRs are established through authentication and authorization xTRs are established through authentication and authorization
procedures in [RFC9301] and [ECDSA-AUTH]. procedures in [RFC9301] and [ECDSA-AUTH].
This design was first introduced to the LISP Working Group (WG) in This design was first introduced to the LISP Working Group (WG) in
January of 2018. It was presented in London in March 2018 January of 2018. It was presented in London in March 2018
[IETF101-PRESO] and in Prague in March 2019 [IETF104-PRESO]. This [IETF101-PRESO] and in Prague in March 2019 [IETF104-PRESO]. This
Informational document is not a standard and did not reach community Informational document is not a standard and did not reach community
skipping to change at line 121 skipping to change at line 122
environment. environment.
2. Definitions of Terms 2. Definitions of Terms
Mapping System Provider (MSP): Infrastructure service that deploys Mapping System Provider (MSP): Infrastructure service that deploys
LISP Map-Resolvers and Map-Servers [RFC9301] and possibly LISP-ALT LISP Map-Resolvers and Map-Servers [RFC9301] and possibly LISP-ALT
nodes [RFC6836] or LISP-DDT nodes [RFC8111]. ALT-nodes and DDT- nodes [RFC6836] or LISP-DDT nodes [RFC8111]. ALT-nodes and DDT-
nodes use different algorithms for connecting Map-Resolvers and nodes use different algorithms for connecting Map-Resolvers and
Map-Servers together. The MSP can be managed by a separate Map-Servers together. The MSP can be managed by a separate
organization other than the one that manages xTRs. This model organization other than the one that manages xTRs. This model
provides a business separation between who manages and responsible provides a business separation between the organization that
for the control-plane versus who manages the data plane overlay manages (and is responsible for) the control plane versus the
service. organization that manages the data plane overlay service.
Decentralized Mapping System (DMS): A mapping system entity that is Decentralized Mapping System (DMS): A mapping system entity that is
managed by the xTR nodes that use it and not third-party nodes/ managed by the xTR nodes that use it and not third-party nodes/
operators. The xTRs themselves are part of the mapping system. operators. The xTRs themselves are part of the Mapping System.
The state of the mapping system is fully distributed across xTRs, The state of the Mapping System is fully distributed across xTRs,
decentralized, and the trust relies on the xTRs that use and decentralized, and the trust relies on the xTRs that use and
participate in their own mapping system. participate in their own mapping system.
Decent-Pull-Based Mapping System: The mapping system is pull-based, Decent-Pull-Based Mapping System: The mapping system is pull-based,
meaning that xTRs will look up and register mappings by meaning that xTRs will look up and register mappings by
algorithmic transformation to locate which Map-Resolvers and Map- algorithmic transformation to locate which Map-Resolvers and Map-
Servers are used. It is required that the lookup and registration Servers are used. It is required that the lookup and registration
uses a consistent algorithmic transformation function. Map- uses a consistent algorithmic transformation function. Map-
Registers are sent to specific Map-Servers. Map-Requests are Registers are sent to specific Map-Servers. Map-Requests are
considered external lookups when sent to Map-Resolvers on xTRs considered external lookups when sent to Map-Resolvers on xTRs
that do not participate in the mapping system and the Map-Requests that do not participate in the mapping system and the Map-Requests
are considered internal lookups when they are sent to Map- are considered internal lookups when they are sent to Map-
Resolvers on xTRs that do participate in the mapping system. Resolvers on xTRs that do participate in the mapping system.
Modulus Value: This value is used in the Pull-based Mapping System. Modulus Value: This value is used in the Pull-based Mapping System.
It defines the number of map-server sets used for the mapping It defines the number of Map-Server sets used for the Mapping
system. The modulus value is used to produce a Name Index used System. The modulus value is used to produce a Name Index used
for a Domain Name System (DNS) lookup. The Modulus Value is for a Domain Name System (DNS) lookup. The Modulus 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. cluster the network operator chooses to deploy.
Name Index: This index value <index> is used in the Pull-based Name Index: This index value <index> is used in the Pull-based
Mapping System. For a mapping system that is configured with a Mapping System. For a Mapping System that is configured with a
map-server set of DNS names in the form of <name>.example.com, the Map-Server set of DNS names in the form of <name>.example.com, the
Name Index is prepended to <name> to form the lookup name Name Index is prepended to <name> to form the lookup name
<index>.<name>.example.com. If the Modulus Value is 8, then the <index>.<name>.example.com. If the Modulus Value is 8, then the
Name Indexes are 0 through 7. Name Indexes are 0 through 7.
Hash Mask: The Hash Mask is used in the Pull-based Mapping System. Hash Mask: The Hash Mask is used in the Pull-based Mapping System.
It is a mask value with 1 bit left justified. The mask is used to 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 used in the hash select what high-order bits of an EID-prefix are used in the hash
function. function.
Decent-Push-Based Mapping System: The mapping system is push-based, Decent-Push-Based Mapping System: The Mapping System is push-based,
meaning that xTRs will push registrations via IP multicast to a meaning that xTRs will push registrations via IP multicast to a
group of Map-Servers and do local lookups acting as their own Map- group of Map-Servers and do local lookups acting as their own Map-
Resolvers. Resolvers.
Replication List Entry (RLE): An RLOC-record format that contains a Replication List Entry (RLE): An RLOC-record format that contains a
list of RLOCs that an Ingress Tunnel Router (ITR) replicates list of RLOCs that an Ingress Tunnel Router (ITR) replicates
multicast packets on a multicast overlay. The RLE format is multicast packets on a multicast overlay. The RLE format is
specified in [RFC8060]. RLEs are used with the Decent-Pushed specified in [RFC8060]. RLEs are used with the Decent-Push-based
Based mapping system. Mapping System.
Group Address EID: An EID-record format that contains IPv4 Group Address EID: An EID-record format that contains IPv4
(0.0.0.0/0, G) or IPv6 (0::/0, G) state. This state is encoded as (0.0.0.0/0, G) or IPv6 (0::/0, G) state. This state is encoded as
a Multicast Info Type LISP Canonical Address Format (LCAF) a Multicast Info Type LISP Canonical Address Format (LCAF)
specified in [RFC8060]. Members of a seed-group send Map- specified in [RFC8060]. Members of a seed-group send Map-
Registers for (0.0.0.0/0, G) or (0::/0, G) with an RLOC-record 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 that RLE encodes its RLOC address. Details are specified in
[RFC8378]. [RFC8378].
Seed-Group: A set of Map-Servers joined to a multicast group for the Seed-Group: A set of Map-Servers joined to a multicast group for the
Decent-Push-based Mapping System or are mapped by DNS names in a Decent-Push-based Mapping System or are mapped by DNS names in a
Pull-based Mapping System. A core seed-group is used to bootstrap Pull-based Mapping System. A core seed-group is used to bootstrap
a set of LISP-Decent xTRs so they can learn about each other and a set of LISP-Decent xTRs so they can learn about each other and
use each other's mapping system service. A seed-group can be use each other's Mapping System service. A seed-group can be
pull-based to bootstrap the Decent-Push-based Mapping System. pull-based to bootstrap the Decent-Push-based Mapping System.
That is, a set of DNS mapped map-servers can be used to join the That is, a set of DNS mapped Map-Servers can be used to join the
mapping system's IP multicast group. mapping system's IP multicast group.
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at line 223 skipping to change at line 224
system mechanisms. A Decent-Push-based Mapping System uses IP system mechanisms. A Decent-Push-based Mapping System uses IP
multicast so xTRs can find each other by locally joining an IP multicast so xTRs can find each other by locally joining an IP
multicast group. A Decent-Pull-based Mapping System uses DNS with an multicast group. A Decent-Pull-based Mapping System uses DNS with an
algorithmic transformation function so xTRs can find each other. algorithmic transformation function so xTRs can find each other.
The document proposes two approaches to provide state/bandwidth, ease The document proposes two approaches to provide state/bandwidth, ease
of configurability, and robustness/complexity trade-offs. When the of configurability, and robustness/complexity trade-offs. When the
Decent-Push-based approach is used, there is less messaging involved. Decent-Push-based approach is used, there is less messaging involved.
xTRs can multicast a single Map-Register message that goes to all xTRs can multicast a single Map-Register message that goes to all
Map-Servers joined to the multicast group. When Map-Servers are Map-Servers joined to the multicast group. When Map-Servers are
added to or removed from the Map-Server cluster group, the mapping added to or removed from the Map-Server cluster group, the Mapping
system updates quickly with little human intervention. In the push System updates quickly with little human intervention. In the push
model, all mapping state is stored in all Map-Servers so there is model, all mapping state is stored in all Map-Servers so there is
robustness achieved through redundancy. However, this requires a robustness achieved through redundancy. However, this requires a
multicast underlay in nodes between all xTRs and Map-Servers. When a multicast underlay in nodes between all xTRs and Map-Servers. When a
multicast underlay is not available, the Decent-Pull-based approach multicast underlay is not available, the Decent-Pull-based approach
can be used with the help of the DNS. This approach uses less state can be used with the help of the DNS. This approach uses less state
overall among the Map-Servers (they each have different mapping overall among the Map-Servers (they each have different Mapping
system state) and the ITRs know which Map-Server to ask by using the System state) and the ITRs know which Map-Server to ask by using the
hashing techniques described later in this document. hashing techniques described later in this document.
This document does not describe any compatibility with other mapping This document does not describe any compatibility with other mapping
systems. The design is intentional all xTRs and Map-Servers support systems. The design is intentional so that all xTRs and Map-Servers
this specification. Moreover, all xTRs and Map-Servers MUST support support this specification. Moreover, all xTRs and Map-Servers MUST
either the pull-based or push-based algorithms. They cannot be support either the pull-based or push-based algorithms. They cannot
mixed. When both are used, they are completely discrete mapping be mixed. When both are used, they are completely discrete Mapping
systems just like they would be using one of the LISP WG mapping Systems just like they would be using one of the LISP WG Mapping
system designs. An implementation can decide to implement only the System designs. An implementation can decide to implement only the
pull-based approach or the push-based approach and still be compliant pull-based approach or the push-based approach and still be compliant
with this specification. with this specification.
4. Decent-Push-Based Mapping System 4. Decent-Push-Based Mapping System
The xTRs are organized in a mapping-system group. The group is The xTRs are organized in a mapping-system group. The group is
identified by an IPv4 or IPv6 multicast group address or using a identified by an IPv4 or IPv6 multicast group address or using a
Decent-Pull-based approach described in Section 5. When using Decent-Pull-based approach described in Section 5. When using
multicast, the xTRs join the same multicast group and receive LISP multicast, the xTRs join the same multicast group and receive LISP
control plane messages addressed to the group. Messages sent to the control plane messages addressed to the group. Messages sent to the
multicast group are distributed when the underlay network supports IP multicast group are distributed when the underlay network supports IP
multicast [RFC6831] or via the overlay multicast mechanism described multicast [RFC6831] or via the overlay multicast mechanism described
in [RFC8378]. When overlay multicast is used and LISP Map-Register in [RFC8378]. When overlay multicast is used and LISP Map-Register
messages are sent to the group, they are LISP data encapsulated with messages are sent to the group, they are LISP data encapsulated with
an instance-ID set to 0xffffff in the LISP header. The inner header an instance-ID set to 0xffffff in the LISP header. The inner header
of the encapsulated packet has the destination address set to the of the encapsulated packet has the destination address set to the
multicast group address and the outer header that is prepended has multicast group address and the outer header that is prepended has
the destination address set to the RLOC of mapping system group the destination address set to the RLOC of Mapping System group
member. The members of the mapping system group are kept in the LISP member. The members of the Mapping System group are kept in the LISP
data plane map-cache so packets for the group can be replicated to data plane map-cache so packets for the group can be replicated to
each member RLOC. each member RLOC.
All xTRs in a mapping system group will store the same registered All xTRs in a Mapping System group will store the same registered
mappings and maintain the state as Map-Servers normally do. The mappings and maintain the state as Map-Servers normally do. The
members are not only receivers of the multicast group, but they also members are not only receivers of the multicast group, but they also
send packets to the group. send packets to the group.
4.1. Components of a Decent-Pushed Based LISP-Decent xTR 4.1. Components of a Decent-Push-Based LISP-Decent xTR
When an xTR is configured to be a LISP-Decent xTR (or PxTR When an xTR is configured to be a LISP-Decent xTR (or PxTR
[RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP [RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP
network functions. network functions.
The following diagram shows 3 LISP-Decent xTRs joined to mapping The following diagram shows 3 LISP-Decent xTRs joined to Mapping
system group 233.252.1.1. When the ETR function of xTR1 originates a System group address 233.252.1.1. When the ETR function of xTR1
Map-Register, it is sent to all xTRs (including itself) synchronizing originates a Map-Register, it is sent to all xTRs (including itself)
all 3 Map-Servers in xTR1, xTR2, and xTR3. The ITR function can synchronizing all 3 Map-Servers in xTR1, xTR2, and xTR3. The ITR
populate its map-cache by sending a Map-Request locally to its Map- function can populate its map-cache by sending a Map-Request locally
Resolver so it can replicate packets to each RLOC for EID to its Map-Resolver so it can replicate packets to each RLOC for EID
233.252.1.1. 233.252.1.1.
In this document, there is no special meaning for the multicast group In this document, there is no special meaning for the multicast group
address 233.252.1.1. It is used for example purposes only. address 233.252.1.1. It is used for example purposes only.
xTR1 xTR1
Map-Request +--------------------+ Map-Request +--------------------+
(always local) | +-----+ +-----+ | (always local) | +-----+ +-----+ |
+---------------| ITR | | ETR |-------------+ +---------------| ITR | | ETR |-------------+
| | +-----+ +-----+ | | | | +-----+ +-----+ | |
skipping to change at line 309 skipping to change at line 310
+----------v---------+ +----------v---------+ +----------v---------+ +----------v---------+
| +--------+ | | +--------+ | | +--------+ | | +--------+ |
| | MR/MS | | | | MR/MS | | | | MR/MS | | | | MR/MS | |
| +--------+ | | +--------+ | | +--------+ | | +--------+ |
| +-----+ +-----+ | | +-----+ +-----+ | | +-----+ +-----+ | | +-----+ +-----+ |
| | ITR | | ETR | | | | ITR | | ETR | | | | ITR | | ETR | | | | ITR | | ETR | |
| +-----+ +-----+ | | +-----+ +-----+ | | +-----+ +-----+ | | +-----+ +-----+ |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
xTR2 xTR3 xTR2 xTR3
Figure 1
Note that if any external xTR would like to use a Map-Resolver from 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- the Mapping System group, it only needs to have one of the LISP-
Decent Map-Resolvers configured. By looking at the Map-Resolver for Decent Map-Resolvers configured. By looking at the Map-Resolver for
EID 233.252.1.1, the external xTR could get the complete list of EID 233.252.1.1, the external xTR could get the complete list of
members for the mapping system group. members for the Mapping System group.
For future study, an external xTR could multicast the Map-Request to For future study, an external xTR could multicast the Map-Request to
233.252.1.1 and either one of the LISP-Decent Map-Resolvers would 233.252.1.1 and either one of the LISP-Decent Map-Resolvers would
return a Map-Reply or the external xTR is prepared to receive return a Map-Reply or the external xTR is prepared to receive
multiple Map-Replies. multiple Map-Replies.
4.2. Implementation Considerations 4.2. Implementation Considerations
There are no LISP changes required to support the Decent-Push-based There are no LISP changes required to support the Decent-Push-based
LISP-Decent set of procedures. An implementation that sends Map- LISP-Decent set of procedures. An implementation that sends Map-
Register messages to a multicast group versus a specific Map-Server Register messages to a multicast group versus a specific Map-Server
unicast address MUST change to call the data plane component so the unicast address MUST change to call the data plane component so the
ITR functionality in the node can encapsulate the Map-Register as a ITR functionality in the node can encapsulate the Map-Register as a
unicast packet to each member of the mapping system group. unicast packet to each member of the Mapping System group.
An ITR SHOULD look up its mapping system group address periodically An ITR SHOULD look up its Mapping System group address periodically
to determine if the membership has changed. The lookup interval is a to determine if the membership has changed. The lookup interval is a
configuration parameter only needed when the ITR does not use the configuration parameter only needed when the ITR does not use the
PubSub capability documented in [RFC9437] to be notified when a new PubSub capability documented in [RFC9437] to be notified when a new
member joins or leaves the multicast group. When PubSub is not used, member joins or leaves the multicast group. When PubSub is not used,
there needs to be coordination (via configuration management) among there needs to be coordination (via configuration management) among
all xTRs so they rendezvous roughly at the same time and to the same all xTRs so they rendezvous roughly at the same time and to the same
group address. group address.
4.3. Configuration and Authentication 4.3. Configuration and Authentication
When xTRs are joined to a multicast group, they MUST have their site When xTRs are joined to a multicast group, they MUST have their site
registration configuration consistent. Any policy or authentication registration configuration consistent. Any policy or authentication
key material MUST be configured consistently among all members. When key material MUST be configured consistently among all members. When
[ECDSA-AUTH] is used to sign Map-Register messages, public keys can [ECDSA-AUTH] is used to sign Map-Register messages, public keys can
be registered to the mapping system group using the site be registered to the Mapping System group using the site
authentication key mentioned above or using a different authentication key mentioned above or using a different
authentication key from the one used for registering EID records. An authentication key from the one used for registering EID records. An
out-of-band registration controller, like an ETR dedicated for this out-of-band registration controller, like an ETR dedicated for this
function, can send Map-Register messages for public-key encoded EIDs. function, can send Map-Register messages for public-key encoded EIDs.
4.4. Core Seed-Group 4.4. Core Seed-Group
A core seed-group can be discovered using a multicast group in a A core seed-group can be discovered using a multicast group in a
Decent-Push-based system or a Map-Server set of DNS names in a Decent-Push-based system or a Map-Server set of DNS names in a
Decent-Pull-based system (see Section 5 for details). Decent-Pull-based system (see Section 5 for details).
When using multicast for the mapping system group, a core seed-group When using multicast for the Mapping System group, a core seed-group
multicast group address can be preconfigured to bootstrap the multicast group address can be preconfigured to bootstrap the
decentralized mapping system. The group address (or DNS name that decentralized Mapping System. The group address (or DNS name that
maps to a group address) can be explicitly configured in a few xTRs maps to a group address) can be explicitly configured in a few xTRs
to start building up the registrations. Then as other xTRs come to start building up the registrations. Then as other xTRs come
online, they can add themselves to the core seed-group by joining the online, they can add themselves to the core seed-group by joining the
seed-group multicast group. seed-group multicast group.
Alternatively or additionally, new xTRs can join a new mapping system Alternatively or additionally, new xTRs can join a new Mapping System
multicast group to form another layer of a decentralized mapping multicast group to form another layer of a decentralized Mapping
system. The group address and members of this new layer seed-group System. The group address and members of this new layer seed-group
would be registered to the core seed-group address and stored in the would be registered to the core seed-group address and stored in the
core seed-group mapping system. Note that each mapping system layer core seed-group mapping system. Note that each Mapping System layer
could have a specific function or a specific circle of trust. could have a specific function or a specific circle of trust.
This multi-layer mapping system can be illustrated: This multi-layer Mapping System can be illustrated:
____________ ----------- ____________ -----------
/ core \ 233.252.2.2 / layer-1 \ / core \ 233.252.2.2 / layer-1 \
| seed-group | ----------> | I | | seed-group | ----------> | I |
| 233.252.1.1 | | / \ | | 233.252.1.1 | | / \ |
\____________/ | J---K | \____________/ | J---K |
| \___________/ | \___________/
| 233.252.3.3 | 233.252.3.3
| |
v v
skipping to change at line 406 skipping to change at line 409
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)
Figure 2
The core seed-group multicast address 233.252.1.1 is configured in The core seed-group multicast address 233.252.1.1 is configured in
xTRs A, B, and C so when each of them send Map-Register messages, xTRs A, B, and C so when each of them send Map-Register messages,
they would all be able to maintain synchronized mapping state. Any they would all be able to maintain synchronized mapping state. Any
EID can be registered to this DMS, but in this example, seed-group EID can be registered to this DMS, but in this example, seed-group
multicast group EIDs are being registered only to find other mapping multicast group EIDs are being registered only to find other Mapping
system groups. System groups.
For example, xTR I boots up and it wants to find its other peers in For example, 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 its Mapping System group address 233.252.2.2. Group address
configured so xTR I knows what group to join for its mapping system 233.252.2.2 is configured so xTR I knows what group to join for its
group. However, xTR I needs a mapping system to register to, so the Mapping System group. However, xTR I needs a Mapping System to
core seed-group is used and available to receive Map-Registers. The register to, so the core seed-group is used and available to receive
other xTRs J and K in the mapping system group do the same so when Map-Registers. The other xTRs J and K in the Mapping System group do
any of I, J, or K needs to register EIDs, they can now send their the same so when any of I, J, or K needs to register EIDs, they can
Map-Register messages to group 233.252.2.2. Examples of EIDs being now send their Map-Register messages to group address 233.252.2.2.
registered are EID1 through EIDn shown above. Examples of EIDs being registered are EID1 through EIDn shown above.
When Map-Registers are sent to group 233.252.2.2, they are When Map-Registers are sent to group address 233.252.2.2, they are
encapsulated by the LISP data plane by looking up EID 233.252.2.2 in encapsulated by the LISP data plane by looking up EID 233.252.2.2 in
the core seed-group mapping system. For the map-cache entry to be the core seed-group Mapping System. For the map-cache entry to be
populated for 233.252.2.2, the data plane MUST send a Map-Request so populated for 233.252.2.2, the data plane MUST send a Map-Request so
the RLOCs I, J, and K are cached for replication. To use the core the RLOCs I, J, and K are cached for replication. To use the core
seed-group mapping system, the data plane MUST know of at least one seed-group Mapping System, the data plane MUST know of at least one
of the RLOCs A, B, and/or C. of the RLOCs A, B, and/or C.
5. Decent-Pull-Based Mapping System 5. Decent-Pull-Based Mapping System
5.1. Components of a Decent-Pulled Based LISP-Decent xTR 5.1. Components of a Decent-Pulled Based LISP-Decent xTR
When an xTR is configured to be a LISP-Decent xTR (or PxTR When an xTR is configured to be a LISP-Decent xTR (or PxTR
[RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP [RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP
network functions. network functions.
skipping to change at line 466 skipping to change at line 471
<iid> is the instance-ID and <eid> is the EID of any EID-type defined <iid> is the instance-ID and <eid> is the EID of any EID-type defined
in [RFC8060]. The Modulus Value <mv> is used to produce the Name in [RFC8060]. The Modulus Value <mv> is used to produce the Name
Index <index> used to build the DNS lookup name: Index <index> used to build the DNS lookup name:
eid = "[<iid>]<eid>/<ml>" eid = "[<iid>]<eid>/<ml>"
index = hash.sha_256(eid) MOD mv index = hash.sha_256(eid) MOD mv
The Hash Mask is used to select what bits are used in the SHA-256 The Hash Mask is used to select what bits are used in the SHA-256
hash function. This is required to support longest match lookups in hash function. This is required to support longest match lookups in
the mapping system. The same map-server set needs to be selected the Mapping System. The same Map-Server set needs to be selected
when looking up a more-specific EID found in the Map-Request message when looking up a more-specific EID found in the Map-Request message
with one that could match a less-specific EID-prefix registered and with one that could match a less-specific EID-prefix registered and
found in the Map-Register message. For example, if an EID-prefix found in the Map-Register message. For example, if an EID-prefix
[0]240.0.1.0/24 is registered to the mapping system and EID [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 [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 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". produce the same hash string bits of "[0]240.0".
For (*,G) and (S,G) multicast entries in the mapping system, the hash For (*,G) and (S,G) multicast entries in the Mapping System, the hash
strings are: strings are:
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
The Hash Mask MUST include the string "[<iid>]<group>" and not string The Hash Mask MUST include the string "[<iid>]<group>" and not string
<source>. So when looking up [0](2.2.2.2, 233.252.1.1) that will <source>. So when looking up [0](2.2.2.2, 233.252.1.1) that will
skipping to change at line 519 skipping to change at line 524
[0]240.11.0.0/16 and all ETRs register these EIDs with a /24 prefix [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 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. will still hash on the /24 prefix to locate the correct Map-Server.
Without this configuration, the ITR would hash on the /32 and Without this configuration, the ITR would hash on the /32 and
potentially query the wrong Map-Server. potentially query the wrong Map-Server.
ITRs SHOULD support configuration of EID prefix ranges and their ITRs SHOULD support configuration of EID prefix ranges and their
associated lookup prefix lengths. When an ITR performs a Map-Request associated lookup prefix lengths. When an ITR performs a Map-Request
lookup, it SHOULD check if the destination EID matches any configured lookup, it SHOULD check if the destination EID matches any configured
range. If a match is found, the ITR MUST use the configured lookup range. If a match is found, the ITR MUST use the configured lookup
prefix length instead of the EID's native prefix length when prefix length instead of the EID's registered prefix length when
computing the hash string. When multiple configured ranges match a computing the hash string. When multiple configured ranges match a
given EID, the range with the longest (most-specific) configured given EID, the range with the longest (most-specific) configured
prefix length MUST be selected. prefix length MUST be selected.
The configuration consists of pairs of EID-prefix (the well-known EID The configuration consists of pairs of EID-prefix (the well-known EID
allocation range in Classless Inter-Domain Routing (CIDR) notation, 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 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, hash computation when EIDs fall within this range, 0-32 bytes for
0-128 for IPv6). IPv4 and 0-128 bytes for IPv6).
Implementation note: When computing the hash string for a lookup Implementation note: When computing the hash string for a lookup
where the EID matches a configured range, the ITR MUST construct the where the EID matches a configured range, the ITR MUST construct the
hash string using the configured lookup-length, ensuring that the hash string using the configured lookup-length, ensuring that the
bits beyond the lookup-length are zero (i.e., the EID address is bits beyond the lookup-length are zero (i.e., the EID address is
masked to the lookup-length before converting to the hash string masked to the lookup-length before converting to the hash string
format). format).
Example configuration with multiple EID ranges: Example configuration with multiple EID ranges:
skipping to change at line 551 skipping to change at line 556
Range: [0]240.12.0.0/16 -> lookup-length: 30 Range: [0]240.12.0.0/16 -> lookup-length: 30
Range: [0]240.13.0.0/16 -> lookup-length: 25 Range: [0]240.13.0.0/16 -> lookup-length: 25
Lookup Examples: Lookup Examples:
EID [0]240.11.1.1/32 -> hash on [0]240.11.1.0/24 EID [0]240.11.1.1/32 -> hash on [0]240.11.1.0/24
EID [0]240.12.2.5/32 -> hash on [0]240.12.2.4/30 EID [0]240.12.2.5/32 -> hash on [0]240.12.2.4/30
EID [0]240.13.3.7/32 -> hash on [0]240.13.3.0/25 EID [0]240.13.3.7/32 -> hash on [0]240.13.3.0/25
EID [0]240.14.1.1/32 -> hash on [0]240.14.1.1/32 EID [0]240.14.1.1/32 -> hash on [0]240.14.1.1/32
(no match, use full EID) (no match, use full EID)
This approach is particularly useful in deployments where the mapping This approach is particularly useful in deployments where the Mapping
system uses a consistent ETR registration strategy (e.g., all ETRs in System uses a consistent ETR registration strategy (e.g., all ETRs in
a region register with /24 prefixes), but ITRs receive packets with a region register with /24 prefixes), but ITRs receive packets with
more-specific destinations (/32 addresses). By configuring the more-specific destinations (/32 addresses). By configuring the
expected registration prefix length for each allocation range, ITRs expected registration prefix length for each allocation range, ITRs
can reliably locate the correct Map-Servers without modifying the can reliably locate the correct Map-Servers without modifying LISP or
LISP protocols or introducing complex multi-level lookups. introducing complex multi-level lookups.
5.3. Deployment Example 5.3. Deployment Example
Here is an example deployment of a Decent-Pull-based model. Let's Here is an example deployment of a Decent-Pull-based model. Let's
say that 4 map-server sets are provisioned for the mapping system. say that 4 Map-Server sets are provisioned for the Mapping System.
Therefore, 4 distinct DNS names are allocated and a Modulus Value 4 Therefore, 4 distinct DNS names are allocated and a Modulus Value 4
is used. Each DNS name is allocated Name Index 0 through 3: is used. Each DNS name is allocated Name Index 0 through 3:
0.map-server.lispers.net 0.map-server.lispers.net
1.map-server.lispers.net 1.map-server.lispers.net
2.map-server.lispers.net 2.map-server.lispers.net
3.map-server.lispers.net 3.map-server.lispers.net
The A records for each name can be assigned as: The A records for each name can be assigned as:
skipping to change at line 586 skipping to change at line 591
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>
When an xTR wants to register "[1000]fd::2222", it hashes the EID When an xTR wants to register "[1000]fd::2222/128", it hashes the EID
string to produce, for example, hash value 0x66. Using the modulus string to produce, for example, hash value 0x67. Using the modulus
value 4 (0x67 & 0x3) produces index 0x3, so the DNS name 3.map- value 4 (0x67 & 0x3) produces index 0x3, so the DNS name 3.map-
server.lispers.net is used and a Map-Register is sent to <rloc1-au> server.lispers.net is used and a Map-Register is sent to <rloc1-au>
and <rloc2-nz>. and <rloc2-nz>.
Note that the Decent-Pull-based method can be used for a core seed- Note that the Decent-Pull-based method can be used for a core seed-
group for bootstrapping a Decent-Push-based Mapping System where group for bootstrapping a Decent-Push-based Mapping System where
multicast groups are registered. multicast groups are registered.
5.4. Management Considerations 5.4. Management Considerations
 End of changes. 47 change blocks. 
91 lines changed or deleted 96 lines changed or added

This html diff was produced by rfcdiff 1.48.