



Network Working Group                                          V. Moreno
Internet-Draft                                                Google LLC
Obsoletes: 8378 (if approved)                               D. Farinacci
Intended status: Standards Track                             lispers.net
Expires: 24 July 2026                                        V. Govindan
                                                                   Cisco
                                                         20 January 2026


      Signal-Free Locator/ID Separation Protocol (LISP) Multicast
                     draft-ietf-lisp-rfc8378bis-08

Abstract

   This document describes the design for inter-domain multicast
   overlays using the Locator/ID Separation Protocol (LISP).  The
   document specifies how LISP multicast overlays operate over a unicast
   underlay.

   When multicast sources and receivers are active at Locator/ID
   Separation Protocol (LISP) sites, the core network is required to use
   native multicast so packets can be delivered from sources to group
   members.  When multicast is not available to connect the multicast
   sites together, a signal-free mechanism can be used to allow traffic
   to flow between sites.  The mechanism within here uses unicast
   replication and encapsulation over the core network for the data
   plane and uses the LISP mapping database system so encapsulators at
   the source LISP multicast site can find decapsulators at the receiver
   LISP multicast sites.  This document when approved obsoletes RFC
   8378.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 July 2026.




Moreno, et al.            Expires 24 July 2026                  [Page 1]

Internet-Draft         Signal-Free LISP Multicast           January 2026


Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Definition of Terms . . . . . . . . . . . . . . . . . . .   4
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   6
   3.  Reference Model . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  General Procedures  . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  General Receiver-Site Procedures  . . . . . . . . . . . .   8
       4.1.1.  Multicast Receiver Detection  . . . . . . . . . . . .   9
       4.1.2.  Receiver-Site Registration  . . . . . . . . . . . . .   9
       4.1.3.  Consolidation of the Replication List . . . . . . . .  10
     4.2.  General Source-Site Procedures  . . . . . . . . . . . . .  10
       4.2.1.  Multicast Tree Building at the Source Site  . . . . .  11
       4.2.2.  Multicast Destination Resolution  . . . . . . . . . .  11
     4.3.  General LISP Notification Procedures  . . . . . . . . . .  11
   5.  Source-Specific Multicast Trees . . . . . . . . . . . . . . .  12
     5.1.  Source Directly Connected to Source-ITRs  . . . . . . . .  12
     5.2.  Source Not Directly Connected to Source-ITRs  . . . . . .  13
   6.  Multihoming Considerations  . . . . . . . . . . . . . . . . .  13
     6.1.  Multiple ITRs at a Source Site  . . . . . . . . . . . . .  13
     6.2.  Multiple ETRs at a Receiver Site  . . . . . . . . . . . .  14
     6.3.  Multiple RLOCs for an ETR at a Receiver Site  . . . . . .  14
     6.4.  Multicast RLOCs for an ETR at a Receiver Site . . . . . .  15
   7.  PIM Any-Source Multicast Trees  . . . . . . . . . . . . . . .  15
   8.  Signal-Free Multicast for Replication Engineering . . . . . .  16
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     11.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  21
   Appendix B.  Document Change Log  . . . . . . . . . . . . . . . .  22
     B.1.  Changes to draft-ietf-lisp-rfc8378bis-08  . . . . . . . .  22



Moreno, et al.            Expires 24 July 2026                  [Page 2]

Internet-Draft         Signal-Free LISP Multicast           January 2026


     B.2.  Changes to draft-ietf-lisp-rfc8378bis-06  . . . . . . . .  22
     B.3.  Changes to draft-ietf-lisp-rfc8378bis-05  . . . . . . . .  22
     B.4.  Changes to draft-ietf-lisp-rfc8378bis-04  . . . . . . . .  22
     B.5.  Changes to draft-ietf-lisp-rfc8378bis-03  . . . . . . . .  22
     B.6.  Changes to draft-ietf-lisp-rfc8378bis-00/01/02  . . . . .  23
     B.7.  Changes to draft-ietf-lisp-rfc8378bis-00  . . . . . . . .  23
     B.8.  Changes to draft-farinacci-lisp-rfc8378bis-00 . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1.  Introduction

   When multicast sources and receivers are active at LISP sites, and
   the core network between the sites does not provide multicast
   support, a signal-free mechanism can be used to create an overlay
   that will allow multicast traffic to flow between sites and connect
   the multicast trees at the different sites.

   The signal-free mechanism proposed here does not extend PIM [RFC7761]
   over the overlay as proposed in [I-D.ietf-lisp-rfc6831bis], nor does
   the mechanism utilize direct signaling between the Receiver-ETRs and
   Sender-ITRs as described in [LISP-MULTI-SIGNALING].  The signal-free
   mechanism proposed reduces the amount of signaling required between
   sites to a minimum and is centered around the registration of
   receiver sites for a particular multicast group or multicast channel
   with the LISP mapping system.

   Registrations from the different receiver sites will be merged at the
   mapping system to assemble a multicast-replication-list inclusive of
   all Routing Locators (RLOCs) that lead to receivers for a particular
   multicast group or multicast channel.  The replication list for each
   specific multicast entry is maintained as a database mapping entry in
   the LISP mapping system.

   When the Ingress Tunnel Router (ITR) at the source site receives
   multicast traffic from sources at its site, the ITR can query the
   mapping system by issuing Map-Request messages for the (S,G) source
   and destination addresses in the packets received.  The mapping
   system will return the RLOC replication list to the ITR, which the
   ITR will cache as per standard LISP procedure.  Since the core is
   assumed to not support multicast, the ITR will replicate the
   multicast traffic for each RLOC on the replication list and will
   unicast encapsulate the traffic to each RLOC.  The combined function
   or replicating and encapsulating the traffic to the RLOCs in the
   replication list is referred to as "rep-encapsulation" in this
   document.






Moreno, et al.            Expires 24 July 2026                  [Page 3]

Internet-Draft         Signal-Free LISP Multicast           January 2026


   The document describes general procedures (Section 4) and information
   encoding that are required at the receiver sites and source sites to
   achieve signal-free multicast interconnectivity.  The general
   procedures for mapping system notifications to different sites are
   also described.  A section dedicated to the specific case of Source-
   Specific Multicast (SSM) trees discusses the implications to the
   general procedures for SSM multicast trees over different topological
   scenarios.  A section on Any-Source Multicast (ASM) support is
   included to identify the constraints that come along with supporting
   it using LISP signal-free multicast.

   There is a section dedicated to Replication Engineering, which is a
   mechanism to reduce the impact of head-end replication.  The mapping
   system, via LISP signal-free mechanisms, can be used to build a layer
   of Re-encapsulating Tunnel Routers (RTRs).

2.  Terminology

2.1.  Definition of Terms

   LISP-related terms, notably Map-Request, Map-Reply, Ingress Tunnel
   Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS), and
   Map-Resolver (MR) are defined in the LISP specification [RFC9300].

   Extensions to the definitions in [RFC9300] for their application to
   multicast routing are documented in [I-D.ietf-lisp-rfc6831bis].

   Terms defining interactions with the LISP mapping system are defined
   in [RFC9301].

   The following terms are consistent with the definitions in [RFC9300]
   and [I-D.ietf-lisp-rfc6831bis].  The terms are specific cases of the
   general terms and are defined here to facilitate the descriptions and
   discussions within this particular document.

   Source: Multicast source endpoint.  The host that originates
   multicast packets.

   Receiver: Multicast group member endpoint.  The host joins a
   multicast group as a receiver of multicast packets sent to the group.

   Receiver site: LISP site where multicast receivers are located.

   Source site: LISP site where multicast sources are located.

   RP site: LISP site where an ASM PIM Rendezvous Point (RP) [RFC7761]
   is located.  The RP site and the source site MAY be the same in some
   deployments.



Moreno, et al.            Expires 24 July 2026                  [Page 4]

Internet-Draft         Signal-Free LISP Multicast           January 2026


   Receiver-ETR: LISP decapsulating the Tunnel Router (xTR) at the
   receiver site.  This is a multicast ETR.

   Source-ITR: LISP encapsulating xTR at the source site.  This is a
   multicast ITR.

   RP-xTR: LISP xTR at the RP site.  This is typically a multicast ITR.

   Replication List (RL): Mapping-entry containing the list of RLOCs
   that have registered receivers for a particular multicast entry.

   Replication List Entry (RLE): A LISP Canonical Address Format (LCAF)
   Type detailed in [I-D.ietf-lisp-rfc8060bis] that describes an overlay
   distribution tree as a list of xTRs with associated level values.
   Each entry in the replication list contains an address of an xTR and
   an RTR level value.

   Overlay Distribution Tree: A degree-constrained spanning tree that
   represents the path followed by unicast and/or multicast encapsulated
   multicast packets from the root (ITR) to the leaves (ETRs) through
   intermediary nodes (RTRs).  The ITR and RTRs unicast and/or multicast
   replicate packets to their tree children.

   Multicast entry: A tuple identifying a multicast tree.  Multicast
   entries are in the form of (S-prefix, G-prefix).

   Rep-encapsulation: The process of replicating and then encapsulating
   traffic to multiple RLOCs.

   Re-encapsulating Tunnel Router (RTR): An RTR is a router that
   implements the re-encapsulating tunnel function detailed in Section 8
   of the main LISP specification [RFC9300].

   RTR Level: An RTR level is encoded in a Replication List Entry (RLE)
   LISP Canonical Address Format (LCAF) Type detailed in
   [I-D.ietf-lisp-rfc8060bis].  Each entry in the replication list
   contains an address of an xTR and a level value.  Level values are
   used to create a replication hierarchy so that ITRs at source LISP
   sites replicate to the lowest (smaller value) level number RTRs in an
   RLE.  And then RTRs at a given level replicate to the next higher
   level of RTRs.  The number of RTRs at each level are engineered to
   control the fan-out or replication factor, so a trade-off between the
   width of the level versus the number of levels can be selected.

   ASM: Any-Source Multicast as defined in [RFC3569] where multicast
   distribution trees are built with a Rendezvous Point [RFC7761].





Moreno, et al.            Expires 24 July 2026                  [Page 5]

Internet-Draft         Signal-Free LISP Multicast           January 2026


   SSM: Source-Specific Multicast as defined in [RFC3569] where
   multicast distribution trees are built and rooted at the multicast
   router(s) directly connected to the multicast source.

2.2.  Requirements Language

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

3.  Reference Model


   The reference model that will be used for the discussion of the
   signal-free multicast tree interconnection is illustrated in
   Figure 1.




                                 +-----+
                                 |MS/MR|
             +---+     +---+     +-----+      +---+      +---+
   Src-1 ----| R1|-----|ITR|        |        |ETR|------| R2|----- Rcv-2
             +---+     +---+        |        +---+      +---+
                            \       |       /
             Source-site-1   \      |      /    Receiver-site-2
                              \     |     /
                               \    |    /
                                \   |   /
                                  Core
                                /       \
                               /         \
                              /           \
                             /             \
                            /               \
                       +---+                 +---+
   Src-3 --------------|ITR|                 |ETR|---------------- Rcv-4
                       +---+                 +---+

            Source-site-3                      Receiver-site-4


              Figure 1: LISP Multicast Generic Reference Model

   Sites 1 and 3 are source sites.



Moreno, et al.            Expires 24 July 2026                  [Page 6]

Internet-Draft         Signal-Free LISP Multicast           January 2026


   Source-site-3 presents a source (Src-3) that is directly connected to
   the Source-ITR.

   Source-site-1 presents a source (Src-1) that is one hop or more away
   from the Source-ITR.

   Receiver-site-2 and -4 are receiver sites with not-directly connected
   and directly connected receiver endpoints, respectively.

   R1 is a multicast router in Source-site-1.

   R2 is a multicast router at the Receiver-site-2.

   Map-Servers and Map-Resolvers are reachable in the RLOC space in the
   core; only one is shown for illustration purposes, but these can be
   many or even part of a distributed mapping system, such as a
   Delegated Database Tree (DDT) [I-D.ietf-lisp-8111bis].

   The procedures for interconnecting multicast trees over an overlay
   can be broken down into three functional areas:

   *  Receiver-site procedures

   *  Source-site procedures

   *  LISP notification procedures

   The receiver-site procedures will be common for most tree types and
   topologies.

   The procedures at the source site can vary depending on the type of
   trees being interconnected as well as the topological relation
   between sources and source-site xTRs.  For ASM trees, a special case
   of the source site is the RP site for which a variation of the
   source-site procedures may be necessary if ASM trees are to be
   supported in future specifications of LISP signal-free multicast.

   The LISP notification procedures between sites are normalized for the
   different possible scenarios.  Certain scenarios may benefit from a
   simplified notification mechanism or no notification requirement at
   all.

4.  General Procedures

   The interconnection of multicast trees across different LISP sites
   involves the following procedures to build the necessary multicast
   distribution trees across sites.




Moreno, et al.            Expires 24 July 2026                  [Page 7]

Internet-Draft         Signal-Free LISP Multicast           January 2026


   1.  The presence of multicast receiver endpoints is detected by the
       Receiver-ETRs at the receiver sites.

   2.  Receiver-ETRs register their RLOCs as part of the replication
       list for the multicast entry the detected receivers subscribe to.

   3.  The mapping system merges all Receiver-ETR or delivery-group
       RLOCs to build a comprehensive replication list inclusive of all
       receiver sites for each multicast entry.

   4.  LISP Map-Notify messages MUST be sent to the Source-ITR informing
       of any changes in the replication list.

   5.  Multicast tree building at the source site is initiated when the
       Source-ITR receives the LISP notification.

   Once the multicast distribution trees are built, the following
   forwarding procedures may take place:

   1.  The source sends multicast packets to the multicast group
       destination address.

   2.  Multicast traffic follows the multicast tree built at the source
       site and makes its way to the Source-ITRs.

   3.  The Source-ITR will issue a Map-Request to resolve the
       replication list for the multicast entry.

   4.  The mapping system responds to the Source-ITR with a Map-Reply
       containing the replication list for the multicast group
       requested.

   5.  The Source-ITR caches the replication list received in the
       map-reply for the multicast entry.

   6.  Multicast traffic is rep-encapsulated.  That is, the packet is
       replicated for each RLOC in the replication list and then
       encapsulated to each one.

4.1.  General Receiver-Site Procedures











Moreno, et al.            Expires 24 July 2026                  [Page 8]

Internet-Draft         Signal-Free LISP Multicast           January 2026


4.1.1.  Multicast Receiver Detection

   When the Receiver-ETRs are directly connected to the receivers (e.g.,
   Receiver-site-4 in Figure 1), the Receiver-ETRs will receive IGMP
   reports from the receivers indicating which group the receivers wish
   to subscribe to.  Based on these IGMP reports, the Receiver-ETR is
   made aware of the presence of receivers as well as which group they
   are interested in.

   When the Receiver-ETRs are several hops away from the receivers
   (e.g., Receiver-site-2 in Figure 1), the Receiver-ETRs will receive
   PIM join messages, which will allow the Receiver-ETR to know that
   there are multicast receivers at the site and also to learn which
   multicast group the receivers are for.


4.1.2.  Receiver-Site Registration

   Once the Receiver-ETRs detect the presence of receivers at the
   receiver site, the Receiver-ETRs MUST issue Map-Register messages to
   include the Receiver-ETR RLOCs in the replication list for the
   multicast entry the receivers joined.

   The Map-Register message MUST use the multicast entry (Source, Group)
   tuple as its Endpoint ID (EID) record type with the Receiver-ETR
   RLOCs conforming the locator set.

   The EID in the Map-Register message MUST be encoded using the
   Multicast Info LCAF Type defined in [I-D.ietf-lisp-rfc8060bis].

   The RLOC in the Map-Register message MUST be encoded using the RLE
   LCAF Type defined in [I-D.ietf-lisp-rfc8060bis] with the Level Value
   fields for all entries set to 128 (decimal) since it is the highest
   level of the multicast replication hierarchy.

   The encoding described above MUST be used consistently for Map-
   Register messages, entries in the mapping system, Map-Reply messages,
   as well as the EID-to-RLOC Map-Cache at the Source-ITRs.

   The Map-Register messages [RFC9301] sent by the Receiver-ETRs MUST
   have the following bits set as specified here:

   1.  merge-request bit set to 1.  The Map-Register messages are sent
       with "Merge Semantics".  The Map-Server will receive
       registrations from a multitude of Receiver-ETRs.  The Map-Server
       will merge the registrations for common EIDs and maintain a
       consolidated replication list for each multicast entry.




Moreno, et al.            Expires 24 July 2026                  [Page 9]

Internet-Draft         Signal-Free LISP Multicast           January 2026


   2.  want-map-notify bit (M) set to 0.  This tells the mapping system
       that the Receiver-ETR does not expect to receive Map-Notify
       messages as it does not need to be notified of all changes to the
       replication list.

   3.  proxy-reply bit (P) set to 1.  The merged replication list is
       kept in the Map-Servers.  By setting the proxy-reply bit, the
       Receiver-ETRs instruct the mapping system to proxy reply to Map-
       Requests issued for the multicast entries.

   Map-Register messages for a particular multicast entry MAY be sent
   for every receiver detected, even if previous receivers have been
   detected for the particular multicast entry.  This allows the
   replication list to remain up to date.

   Receiver-ETRs MUST be configured to know what Map-Servers Map-
   Register messages are sent to.  The configuration is likely to be
   associated with an S-prefix that multiple (S,G) entries match to and
   are more specific for.  Therefore, the S-prefix determines the Map-
   Server set in the least number of configuration statements.

4.1.3.  Consolidation of the Replication List

   The Map-Server will receive registrations from a multitude of
   Receiver-ETRs.  The Map-Server will merge the registrations for
   common EIDs and consolidate a replication list for each multicast
   entry.

   When an ETR sends an RLE RLOC-record in a Map-Register and the RLE
   already exists in the Map-Server's RLE-merged list, the Map-Server
   will replace the single RLE with the information from the Map-
   Register RLOC-record.  The Map-Server MUST NOT merge duplicate RLOCs
   in the consolidated replication list.

4.2.  General Source-Site Procedures

   Source-ITRs MUST register the unicast EIDs of any sources or
   Rendezvous Points that may be present on the source site.  In other
   words, it is assumed that the sources and RPs are LISP EIDs.

   The registration of the unicast EIDs for the sources or Rendezvous
   Points allows the Map-Server to know where to send Map-Notify
   messages to.  Therefore, the Source-ITR MUST register the unicast
   S-prefix EID with the want-map-notify bit set in order to receive
   Map-Notify messages whenever there is a change in the replication
   list.





Moreno, et al.            Expires 24 July 2026                 [Page 10]

Internet-Draft         Signal-Free LISP Multicast           January 2026


4.2.1.  Multicast Tree Building at the Source Site

   When the source site receives the Map-Notify messages from the
   mapping system as described in Section 4.3, it will initiate the
   process of building a multicast distribution tree that will allow the
   multicast packets from the source to reach the Source-ITR.

   The Source-ITR MUST issue a PIM join for the multicast entry for
   which it received the Map-Notify message.  The join will be issued in
   the direction of the source or in the direction of the RP for the SSM
   and ASM cases, respectively.

4.2.2.  Multicast Destination Resolution

   On reception of multicast packets, the Source-ITR obtains the
   replication list for the (S,G) addresses in the packets.

   In order to obtain the replication list, the Source-ITR MUST issue a
   Map-Request message in which the EID is the (S,G) multicast tuple,
   which is encoded using the Multicast Info LCAF Type defined in
   [I-D.ietf-lisp-rfc8060bis].

   The mapping system (most likely the Map-Server) will Map-Reply with
   the merged replication list maintained in the mapping system.  The
   Map-Reply message MUST follow the format defined in [RFC9301]; its
   EID is encoded using the Multicast Info LCAF Type, and the
   corresponding RLOC-records are encoded using the RLE LCAF Type.  Both
   LCAF Types are defined in [I-D.ietf-lisp-rfc8060bis].

4.3.  General LISP Notification Procedures

   The Map-Server will issue LISP Map-Notify messages to inform the
   source site of the presence of receivers for a particular multicast
   group over the overlay.

   Updated Map-Notify messages MUST be issued every time a new
   registration is received from a receiver site.  This guarantees that
   the source sites are aware of any potential changes in the multicast-
   distribution-list membership.

   The Map-Notify messages carry (S,G) multicast EIDs encoded using the
   Multicast Info LCAF Type defined in [I-D.ietf-lisp-rfc8060bis].









Moreno, et al.            Expires 24 July 2026                 [Page 11]

Internet-Draft         Signal-Free LISP Multicast           January 2026


   Map-Notify messages will be sent by the Map-Server to the RLOCs with
   which the unicast S-prefix EID was registered.  In the case when
   sources are discovered dynamically [I-D.ietf-lisp-eid-mobility], xTRs
   MUST register sources explicitly with the want-map-notify bit set.
   This is so the ITR in the site the source has moved to can get the
   most current replication list.

   When both the receiver sites and the source sites register to the
   same Map-Server, the Map-Server has all the necessary information to
   send the Map-Notify messages to the source site.

   When the Map-Servers are distributed (when using LISP-DDT
   [I-D.ietf-lisp-8111bis]), the receiver sites may register to one Map-
   Server while the source site registers to a different Map-Server.  In
   this scenario, the Map-Server for the receiver sites MUST resolve the
   unicast S-prefix EID across a distributed mapping transport system,
   per standard LISP lookup procedures, and obtain the necessary
   information to send the Map-Notify messages to the source site.  The
   Map-Notify messages are sent with an authentication length of 0 as
   they would not be authenticated.  While as a general guideline, it is
   recommended to use authetication but in some cases, it might be
   useful to accept Map-Notify messages anyway.

   When the Map-Servers are distributed, different receiver sites may
   register to different Map-Servers.  However, this is not supported
   with the currently defined mechanisms.

5.  Source-Specific Multicast Trees

   The interconnection of SSM trees across sites will follow the general
   receiver-site procedures described in Section 4.1 on the receiver
   sites.

   The source-site procedures will vary depending on the topological
   location of the source within the source site as described in
   Sections 5.1 and 5.2.

5.1.  Source Directly Connected to Source-ITRs

   When the source is directly connected to the Source-ITR, it is not
   necessary to trigger signaling to build a local multicast tree at the
   source site.  Therefore Map-Notify messages are not required to
   initiate building of the multicast tree at the source site.

   Map-Notify messages are still required to ensure that any changes to
   the replication list are communicated to the source site so that the
   map-cache at the Source-ITRs is kept updated.




Moreno, et al.            Expires 24 July 2026                 [Page 12]

Internet-Draft         Signal-Free LISP Multicast           January 2026


5.2.  Source Not Directly Connected to Source-ITRs

   The general LISP notification procedures described in Section 4.3
   MUST be followed when the source is not directly connected to the
   Source-ITR.  On reception of Map-Notify messages, local multicast
   signaling MUST be initiated at the source site per the general
   source-site procedures for multicast tree building described in
   Section 4.2.1.

   In the SSM case, the IP address of the source is known, and it is
   also registered with the LISP mapping system.  Thus, the mapping
   system MAY resolve the mapping for the source address in order to
   send Map-Notify messages to the correct Source-ITR.

   In the ASM case, for (*,G) state when the source is not known, the
   ITR cannot receive any Map-Notify messages.

6.  Multihoming Considerations

6.1.  Multiple ITRs at a Source Site

   When multiple ITRs exist at a source multicast site, care must be
   taken that more than one ITR does not head-end replicate packets;
   otherwise, receiver multicast sites will receive duplicate packets.
   The following procedures will be used for each topology scenario:

   *  When more than one ITR is directly connected to the source host,
      either the PIM Designated Router (DR) or the IGMP querier (when
      PIM is not enabled on the ITRs) is responsible for packet
      replication.  All other ITRs silently drop the packet.  In the
      IGMP querier case, one or more ITRs on the source LAN MUST be IGMP
      querier candidates.  Therefore, it is REQUIRED that they be
      configured as such.

   *  When more than one ITR is multiple hops away from the source host
      and one of the ITRs is the PIM Rendezvous Point, then the PIM RP
      is responsible for packet replication.

   *  When more than one ITR is multiple hops away from the source host
      and the PIM Rendezvous Point is not one of the ITRs, then one of
      the ITRs MUST join to the RP.  When a Map-Notify is received from
      the Map-Server by an ITR, only the highest RLOC addressed ITR
      (numerically largest value) will join toward the PIM RP or toward
      the source.







Moreno, et al.            Expires 24 July 2026                 [Page 13]

Internet-Draft         Signal-Free LISP Multicast           January 2026


6.2.  Multiple ETRs at a Receiver Site

   When multiple ETRs exist in a receiver multicast site and each one
   creates a multicast join state, each Map-Registers its RLOC address
   to the mapping system.  In this scenario, the replication happens on
   the overlay causing multiple ETR entry points to replicate to all
   receivers instead of a single ETR entry point replicating to all
   receivers.  If an ETR does not create join state, because it has not
   received PIM joins or IGMP reports, it will not Map-Register its RLOC
   addresses to the mapping system.  The same procedures in Section 4.1
   are followed.

   When multiple ETRs exist on the same LAN as a receiver host, then the
   PIM DR (when PIM is enabled) or the IGMP querier is responsible for
   sending a Map-Register for its RLOC.  In the IGMP case, one or more
   ETRs on a LAN MUST be IGMP querier candidates.  Therefore, it is
   REQUIRED that they be configured as such.

6.3.  Multiple RLOCs for an ETR at a Receiver Site

   It may be desirable to have multiple underlay paths to an ETR for
   multicast packet delivery.  This can be done by having multiple RLOCs
   assigned to an ETR and having the ETR send Map-Registers for all its
   RLOCs.  By doing this, an ITR can choose a specific path based on
   underlay performance and/or RLOC reachability.

   It is recommended that an ETR send a Map-Register with a single RLOC-
   record that uses the Explicit Locator Path (ELP) LCAF Type
   [I-D.ietf-lisp-rfc8060bis] that is nested inside the RLE LCAF.  For
   example, say ETR1 has assigned RLOC1 and RLOC2 for a LISP receiver
   site.  Also, there is ETR2 in another LISP receiver site that has
   RLOC3.  The two receiver sites have the same (S,G) being joined.
   Here is how the RLOC-record is encoded on each ETR:

   ETR1: EID-record: (S,G)
         RLOC-record: RLE[ ELP{ (RLOC1,s,p), (RLOC2,s,p) } ]

   ETR2: EID-record: (S,G)
         RLOC-record: RLE[ RLOC3 ]

   And here is how the entry is merged and stored on the Map-Server
   since the Map-Registers have an RLE-encoded RLOC-record:


   MS: EID-record: (S,G)
       RLOC-record: RLE[ RLOC3, ELP{ (RLOC1,s,p), (RLOC2,s,p) } ]





Moreno, et al.            Expires 24 July 2026                 [Page 14]

Internet-Draft         Signal-Free LISP Multicast           January 2026


   When the ITR receives a packet from a multicast source S for group G,
   it uses the merged RLOC-record returned from the Map-Server.  The ITR
   replicates the packet to (RLOC3 and RLOC1) or (RLOC3 and RLOC2).
   Since it is required for the S-bit to be set for RLOC1, the ITR MUST
   replicate to RLOC1 if it is reachable.  When the required P-bit is
   also set, the RLOC-reachability mechanisms from [RFC9300] are
   followed.  If the ITR determines that RLOC1 is unreachable, it uses
   RLOC2, as long as RLOC2 is reachable.

6.4.  Multicast RLOCs for an ETR at a Receiver Site

   This specification is focused on underlays without multicast support,
   but it does not preclude the use of multicast RLOCs in RLEs.  ETRs
   MAY register multicast EID entries using multicast RLOCs.  In such
   cases, the ETRs will be joined to underlay multicast distribution
   trees by using IGMP as a multicast host using mechanisms in [RFC2236]
   and [RFC9776].

7.  PIM Any-Source Multicast Trees

   LISP signal-free multicast can support ASM trees in limited but
   acceptable topologies.  It is RECOMMENDED, for the simplification of
   building ASM trees across the LISP overlay, to have PIM-ASM run
   independently in each LISP site.  What this means is that a PIM RP is
   configured in each LISP site so PIM Register procedures and (*,G)
   state maintenance is contained within the LISP site.

   The following procedure will be used to support ASM in each LISP
   site:

   1.  In a receiver site, the RP is co-located with the ETR.  RPs for
       different groups can be spread across each ETR, but is not
       required.

   2.  When (*,G) state is created in an ETR, the procedures in
       Section 4.1.2 are followed.  In addition, the ETR registers
       (S-prefix,G), where S-prefix is 0/0 (the respective unicast
       default route for the address-family) to the mapping system.

   3.  In a source site, the RP is co-located with the ITR.  RPs for
       different groups can be spread across each ITR, but is not
       required.

   4.  When a multicast source sends a packet, a PIM Register message is
       delivered to the ITR, and the procedures in Section 4.2 are
       followed.





Moreno, et al.            Expires 24 July 2026                 [Page 15]

Internet-Draft         Signal-Free LISP Multicast           January 2026


   5.  When the ITR sends a Map-Request for (S,G) and no receiver site
       has registered for (S,G), the mapping system will return the
       (0/0,G) entry to the ITR so it has a replication list of all the
       ETRs that have received (*,G) state.

   6.  The ITR stores the replication list in its map-cache for (S,G).
       It replicates packets to all ETRs in the list.

   7.  ETRs decapsulate packets and forward based on (*,G) state in
       their site.

   8.  When last-hop PIM routers join the newly discovered (S,G), the
       ETR will store the state and follow the procedures in
       Section 4.1.2.

8.  Signal-Free Multicast for Replication Engineering

   The mechanisms in this specification can be applied to the "LISP
   Replication Engineering" [LISP-RE] design.  Rather than have the
   layered LISP-RE RTR hierarchy use signaling mechanisms, the RTRs can
   register their availability for multicast tree replication via the
   mapping database system.

   As stated in [LISP-RE], the RTR-layered hierarchy is used to avoid
   head-end replication in replicating nodes closest to a multicast
   source.  Rather than have multicast ITRs replicate to each ETR in an
   RLE of an (S,G) mapping database entry, it could replicate to one or
   more layer 0 RTRs in the LISP-RE hierarchy.

   This document specifies how the RTR hierarchy is determined but not
   the optimal layers of RTRs to be used.  Methods for determining
   optimal paths or RTR topological closeness are out of scope for this
   document.

   There are two formats an (S,G) mapping database entry could have.
   One format is a 'complete-format', and the other is a 'filtered-
   format'.  A 'complete-format' entails an (S,G) entry having multiple
   RLOC-records that contain both ETRs that have registered as well as
   the RTRs at the first level of the LISP-RE hierarchy for the ITR to
   replicate to.  When using 'complete-format', the ITR has the ability
   to select if it replicates to RTRs or to the registered ETRs at the
   receiver sites.  A 'filtered-format' (S,G) entry is one where the
   Map-Server returns the RLOC-records that it decides the ITR SHOULD
   use.  So replication policy is shifted from the ITRs to the mapping
   system.  The Map-Servers can also decide for a given ITR if it uses a
   different set of replication targets per (S,G) entry for which the
   ITR is replicating for.




Moreno, et al.            Expires 24 July 2026                 [Page 16]

Internet-Draft         Signal-Free LISP Multicast           January 2026


   The procedure for the LISP-RE RTRs to make themselves available for
   replication can occur before or after any receivers join an (S,G)
   entry or any sources send for a particular (S,G) entry.  Therefore,
   newly configured RTR state will be used to create new (S,G) state and
   will be inherited into existing (S,G) state.  A set of RTRs can
   register themselves to the mapping system or a third party can do so
   on their behalf.  When RTR registration occurs, it is done with an
   (S-prefix, G-prefix) entry so it can advertise its replication
   services for a wide range of source/group combinations.

   When a Map-Server receives (S,G) registrations from ETRs and
   (S-prefix, G-prefix) registrations from RTRs, it has the option of
   merging the RTR RLOC-records for each (S,G) that is more specific for
   the (S-prefix, G-prefix) entry or keeping them separate.  When
   merging, a Map-Server is ready to return a 'complete-format' Map-
   Reply.  When keeping the entries separate, the Map-Server can decide
   what to include in a Map-Reply when a Map-Request is received.  It
   can include a combination of RLOC-records from each entry or decide
   to use one or the other depending on policy configured.

                         +---+                 +----+
   Src-1 --------------|ITR|                 |ETR1|--------------- Rcv-1
                       +---+                 +----+
                           \                 /
            Source-site-1   \               /    Receiver-site-1
                             \             /
                              \           /
                   +----+      \         /     +----+
                   |RTR1|       \       /      |RTR2|     Level-0
                   +----+        \     /       +----+
                         \  <^^^^^^^^^^^^^^>  /
                          \ <              > /
                            < Core Network >
                            <              >
                            <vvvvvvvvvvvvvv>
                            /     /   \    \
                           /     /     \    \
                   +----+ /     /       \    \ +----+
                   |RTR3|      /         \     |RTR4|     Level-1
                   +----+     /           \    +----+
                             /             \
                            /               \
                       +----+                +----+
   Rcv-2 --------------|ETR2|                |ETR3|--------------- Rcv-3
                       +----+                +----+

            Receiver-site-2                      Receiver-site-3




Moreno, et al.            Expires 24 July 2026                 [Page 17]

Internet-Draft         Signal-Free LISP Multicast           January 2026


                     Figure 2: LISP-RE Reference Model

   Here is a specific example, illustrated in Figure 2, of (S,G) and
   (S-prefix, G-prefix) mapping database entries when a source S is
   behind an ITR, and there are receiver sites joined to (S,G) via ETR1,
   ETR2, and ETR3.  And there exists a LISP-RE hierarchy of RTR1 and
   RTR2 at level-0 and RTR3 and RTR4 at level-1:

       EID-record: (S,G)
          RLOC-record: RLE: (ETR1, ETR2, ETR3), p1
       EID-record: (S-prefix, G-prefix)
          RLOC-record: RLE: (RTR1(L0), RTR2(L0), RTR3(L1), RTR4(L1)), p1

   The above entries are in the form in which they were registered and
   are stored in a Map-Server.  When a Map-Server uses 'complete-
   format', the Map-Reply it originates has the mapping record encoded
   as:

          EID-record: (S,G)
              RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1
              RLOC-record: RLE: (ETR1, ETR2, ETR3), p1

   The above Map-Reply allows the ITR to decide if it replicates to the
   ETRs or if it SHOULD replicate only to level-0 RTR1.  This decision
   is left to the ITR since both RLOC-records have priority 1.  If the
   Map-Server wanted to force the ITR to replicate to RTR1, it would set
   the ETRs RLOC-record to a priority greater than 1.

   When a Map_server uses "filtered-format", the Map-Reply it originates
   has the mapping record encoded as:

          EID-record: (S,G)
              RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1

   An (S,G) entry can contain alternate RTRs.  So rather than
   replicating to multiple RTRs, one RTR set MAY be used based on the
   RTR reachability status.  An ITR can test reachability status to any
   layer 0 RTR using RLOC-probing, so it can choose one RTR from a set
   to replicate to.  When this is done, the RTRs are encoded in
   different RLOC-records instead of together in one RLE RLOC-record.
   This moves the replication load off the ITRs at the source site to
   the RTRs inside the network infrastructure.  This mechanism can also
   be used by level-n RTRs to level-n+1 RTRs.

   The following mapping would be encoded in a Map-Reply sent by a Map-
   Server and stored in the ITR.  The ITR would use RTR1 until it went
   unreachable and then switch to use RTR2:




Moreno, et al.            Expires 24 July 2026                 [Page 18]

Internet-Draft         Signal-Free LISP Multicast           January 2026


          EID-record: (S,G)
              RLOC-record: RTR1, p1
              RLOC-record: RTR2, p2

9.  Security Considerations

   The security concerns for LISP-Multicast are mainly the same as for
   the base LISP specification [RFC9300] and [RFC9301].  LISP-SEC
   [RFC9303] defines a set of security mechanisms that provide origin
   authentication, integrity, and anti-replay protection to LISP's EID-
   to-RLOC mapping data conveyed via the mapping lookup process.  LISP-
   SEC also enables verification of authorization on EID-prefix claims
   in Map-Reply messages.

   The security of the mapping system infrastructure depends on the
   particular mapping database used.  As an example,
   [I-D.ietf-lisp-8111bis] defines a public-key-based mechanism that
   provides origin authentication and integrity protection to the LISP
   DDT protocol.

   Map-Replies received by the Source-ITR can be signed (by the Map-
   Server), so the ITR knows the replication list is from a legitimate
   source.

   Data-plane encryption can be used when doing unicast rep-
   encapsulation as described in [RFC8061].

10.  IANA Considerations

   This document has no IANA actions.

11.  References

11.1.  Normative References

   [I-D.ietf-lisp-8111bis]
              Iannone, L. and L. Jakab, "Locator/ID Separation Protocol
              Delegated Database Tree (LISP-DDT)", Work in Progress,
              Internet-Draft, draft-ietf-lisp-8111bis-00, 3 September
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              lisp-8111bis-00>.










Moreno, et al.            Expires 24 July 2026                 [Page 19]

Internet-Draft         Signal-Free LISP Multicast           January 2026


   [I-D.ietf-lisp-rfc6831bis]
              Farinacci, D., Meyer, D., Zwiebel, J., Venaas, S., and V.
              P. Govindan, "The Locator/ID Separation Protocol (LISP)
              for Multicast Environments", Work in Progress, Internet-
              Draft, draft-ietf-lisp-rfc6831bis-05, 18 November 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
              rfc6831bis-05>.

   [I-D.ietf-lisp-rfc8060bis]
              Retana, A., Farinacci, D., Snijders, J., and A. Rodriguez-
              Natal, "LISP Canonical Address Format (LCAF)", Work in
              Progress, Internet-Draft, draft-ietf-lisp-rfc8060bis-03, 7
              January 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-lisp-rfc8060bis-03>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
              <https://www.rfc-editor.org/info/rfc2236>.

   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
              2016, <https://www.rfc-editor.org/info/rfc7761>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9300]  Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
              Cabellos, Ed., "The Locator/ID Separation Protocol
              (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
              <https://www.rfc-editor.org/info/rfc9300>.

   [RFC9301]  Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
              Ed., "Locator/ID Separation Protocol (LISP) Control
              Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
              <https://www.rfc-editor.org/info/rfc9301>.

   [RFC9303]  Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
              "Locator/ID Separation Protocol Security (LISP-SEC)",
              RFC 9303, DOI 10.17487/RFC9303, October 2022,
              <https://www.rfc-editor.org/info/rfc9303>.



Moreno, et al.            Expires 24 July 2026                 [Page 20]

Internet-Draft         Signal-Free LISP Multicast           January 2026


   [RFC9776]  Haberman, B., Ed., "Internet Group Management Protocol,
              Version 3", STD 100, RFC 9776, DOI 10.17487/RFC9776, March
              2025, <https://www.rfc-editor.org/info/rfc9776>.

11.2.  Informative References

   [I-D.ietf-lisp-eid-mobility]
              Portoles-Comeras, M., Ashtaputre, V., Maino, F., Moreno,
              V., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
              Unified Control Plane", Work in Progress, Internet-Draft,
              draft-ietf-lisp-eid-mobility-17, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
              eid-mobility-17>.

   [LISP-MULTI-SIGNALING]
              Farinacci, D. and M. Napierala, "LISP Control-Plane
              Multicast Signaling", Work in Progress, draft-farinacci-
              lisp-mr-signaling-06, February 2015.

   [LISP-RE]  Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
              Maino, F., and D. Farinacci, "LISP Replication
              Engineering", Work in Progress, draft-coras-lisp-re-08,
              November 2015.

   [RFC3569]  Bhattacharyya, S., Ed., "An Overview of Source-Specific
              Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July
              2003, <https://www.rfc-editor.org/info/rfc3569>.

   [RFC8061]  Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
              (LISP) Data-Plane Confidentiality", RFC 8061,
              DOI 10.17487/RFC8061, February 2017,
              <https://www.rfc-editor.org/info/rfc8061>.

   [RFC8378]  Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
              Separation Protocol (LISP) Multicast", RFC 8378,
              DOI 10.17487/RFC8378, May 2018,
              <https://www.rfc-editor.org/info/rfc8378>.

Appendix A.  Acknowledgements

   The authors want to thank Greg Shepherd, Joel Halpern, and Sharon
   Barkai for their insightful contribution to shaping the ideas in this
   document.  A special thanks to Luigi Iannone, LISP WG co-chair, for
   shepherding this working group document.  Thanks also goes to Jimmy
   Kyriannis, Paul Vinciguerra, Florin Coras, and Yan Filyurin for
   testing an implementation of this document.





Moreno, et al.            Expires 24 July 2026                 [Page 21]

Internet-Draft         Signal-Free LISP Multicast           January 2026


Appendix B.  Document Change Log

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

B.1.  Changes to draft-ietf-lisp-rfc8378bis-08

   *  Posted January 2026 (Dino).

   *  Fixed editorial issues from review comments.

   *  Fixed typo: "underlays" to "underlay" in abstract.

   *  Fixed typo: "obosletes" to "obsoletes RFC 8378" in abstract.

   *  Removed space after comma in "(*,G)" in Section 5.2.

   *  Fixed mismatched quotes for "filtered-format" in Section 8.

B.2.  Changes to draft-ietf-lisp-rfc8378bis-06

   *  Posted December 2025 (Prasad).

   *  Update document text based on review comments from LI.

B.3.  Changes to draft-ietf-lisp-rfc8378bis-05

   *  Posted December 2025 (Dino).

   *  Update document timer and references.

   *  Add Prasad as co-author as he will be editor as we move forward
      with this document.

B.4.  Changes to draft-ietf-lisp-rfc8378bis-04

   *  Posted August 2025 (Dino).

   *  Update document timer and references.

B.5.  Changes to draft-ietf-lisp-rfc8378bis-03

   *  Posted February 2025 (Mike McBride).

   *  Modified the definition of RLE

   *  Added a definition for Overlay Distribution Tree





Moreno, et al.            Expires 24 July 2026                 [Page 22]

Internet-Draft         Signal-Free LISP Multicast           January 2026


B.6.  Changes to draft-ietf-lisp-rfc8378bis-00/01/02

   *  Posted February 2025 (Mike McBride).

   *  Dropped "architecture and protocols" from Abstract.

   *  Replaced "situations" with "deployments".

   *  Added definition for Replication List Entry (RLE).

   *  Dropped "architecture and protocols" from Abstract.

   *  Removed unnecessary sentences.

   *  Reorg'd Table of Contents to include Terminology, Definitions, and
      Requirements Language.

   *  Cleaned up Figure 1.

   *  Replaced "receiver site" with "Receiver-site 2"

   *  Added a reference to RFC 8111.

   *  Changed a few MAYs to may.

   *  Corrected Map-Register and Map-Reply RFC from 9300 to 9301.

   *  Replaced PIM DR with PIM Designated Router (DR).

   *  Changed a couple of "required" to "REQUIRED".

   *  Replaced "p-bit" with "P-bit".

   *  Replaced "suggested" with "RECOMMENDED".

   *  Added a new first sentence to the security section and dropped
      another sentence.

   *  Replaced references to LISP-SEC with RFC9303 normative reference.

B.7.  Changes to draft-ietf-lisp-rfc8378bis-00

   *  Posted August 2024.

   *  Make draft-farinacci-lisp-rfc8378bis-00 working group document
      draft-ietf-lisp-rfc8378bis-00.





Moreno, et al.            Expires 24 July 2026                 [Page 23]

Internet-Draft         Signal-Free LISP Multicast           January 2026


B.8.  Changes to draft-farinacci-lisp-rfc8378bis-00

   *  Posted May 2024.

   *  Starting with [RFC8378] to move it to a bis document for standards
      track.

   *  Changed references to standards track RFCs.

Authors' Addresses

   Victor Moreno
   Google LLC
   1600 Amphitheatre Pkwy
   Mountain View, CA 94043
   United States of America
   Email: vimoreno@google.com


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


   Vengada Prasad Govindan
   Cisco
   San Jose, CA
   United States of America
   Email: venggovi@cisco.com




















Moreno, et al.            Expires 24 July 2026                 [Page 24]
