| Internet-Draft | LISP Deployments | February 2025 |
| Govindan, et al. | Expires 1 September 2025 | [Page] |
We present our experiences in supporting deployments of LISP Multicast using unicast and multicast underlays. This document details design considerationsi that can be useful for anyone interested in deploying LISP multicast services over IP networks.¶
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 1 September 2025.¶
Copyright (c) 2025 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.¶
This document describes deployment experiences of inter domain multicast routing function in a network where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture as described in [RFC6831] and [I-D.ietf-lisp-rfc6831bis]¶
All of the terminology used in this document comes from [RFC6831] and [I-D.ietf-lisp-rfc6831bis].¶
This document covers the following aspects:¶
This document does not cover the following aspects:¶
The deployment experiences outlined in this document capture learnings from various industry segments listed below (not exhaustive:)¶
There are both advantages and costs in using a "PIM-over-PIM" design outlined in [I-D.ietf-lisp-rfc6831bis]:¶
A small but significant subset of deployments have been observed using the Ingress Replication (Unicast). This is primarily done for low-volume multicast or for deployments where there are restrictions in implementations for supporting an underlay with native multicast.¶
Another category of the deployments were early adopters of the technology when the software releases were limited to unicast underlay.¶
The primary characteristic of such networks is the presence of a limited number of LISP sites in which receivers are present. Please note that this does not necessarily mean that only a limited number of hosts receive the multicast.¶
Since the ASICs that form the data plane have very efficient methods to replicate multicast packets to local receivers, any deployment that has a good localization of receivers to a limited number of LISP sites can still use a unicast underlay with high efficiency.¶
On the positive side, there are widely deployed mechanisms for both traffic-engineering (e.g. Load balancing) and fast convergence due to link/ node failures in unicast that can be reused for overlay routed multicast when using a unicast underlay.¶
Another very important use-case for considering a unicast underlay is to have migration done from (say) IPv4 to IPv6.¶
Native multicast underlay presents notable advantages over ingress replication, particularly in network topologies where traffic replication occurs at multiple layers between the Last Hop Router (LHR) and First Hop Router (FHR). Despite advancements in modern ASICs designed for high-performance multicast packet replication at ingress, bandwidth consumption remains a critical factor favoring the adoption of native multicast underlay.¶
An essential consideration when selecting an underlay multicast mode is the placement of sources and receivers. If the source is external to the LISP domain, the majority of traffic is typically North-South.¶
Given the transport capabilities, it may be practical to implement native multicast in the underlay between xTRs and ITRs.¶
In native multicast mode, there is a mapping between the overlay multicast group address and the underlay multicast group. This mapping must be consistent across network devices within a LISP domain to ensure uniformity. The conventional method involves a 1:1 mapping between the overlay LISP group address and the underlay multicast group address. To maintain uniqueness in this mapping process, implementations may incorporate additional parameters, such as the source IP address and LISP instance ID, providing sufficient entropy to ensure uniqueness across LISP instances.¶
This forms the majority of the deployments known.¶
There are three deployment options that can be considered here for deployment:¶
One of the most critical design element is the choice of the RP Design. We have the following options:¶
LISP overlays extend ASM to networks lacking native multicast support traditionally. Native multicast in the core boosts ASM resilience and optimizes traffic distribution.¶
Head-end replication requires tuning to avoid ITR overload with many receivers or high traffic. LISP overlays enable ASM resilience by rerouting around underlay failures dynamically.¶
ASM deployments scale receiver counts flexibly without requiring underlay redesigns. Troubleshooting ASM demands monitoring both LISP overlay and underlay states concurrently.¶
Pre-validating underlay multicast capabilities ensures reliable ASM performance consistently. Using native multicast complicates failure diagnosis despite enhancing overall resilience.¶
In a Layer-3 overlay, the placement of RPs is critical for ensuring robust multicast service delivery. Unlike traditional PIM-ASM, LISP multicast relies on static Rendezvous Point (RP) configurations due to the lack of support for dynamic RP discovery mechanisms like Auto-RP or Bootstrap Router (BSR).¶
RPs can be positioned both inside and outside the LISP domain. The typical configuration involves static RP setup and redundancy through the Anycast RP concept, which allows multiple RPs to share the same IP address, providing load balancing and fault tolerance. This setup requires synchronization between RPs using the MSDP to exchange information about active sources.¶
In some deployments, RP placements are a combination of RPs placed inside together with RPs placed outside the LISP domains. This configuration leverages advanced MSDP peering or group mesh peering to enhance multicast service resilience and efficiency.¶
The RP placement significantly affects the convergence between the shared and source trees. It is essential that all xTRs within a given LISP instance use a consistent address scheme with identical mapping to ensure efficient multicast routing. The RP facilitates the initial setup of the sharedi tree, allowing sources and receivers to establish direct multicast data flows.¶
When working with short lived streams (e.g. PA systems for airports) it was observed that using the shared tree was optimal. The cost of switching to the shortest-path tree can be avoided in such scenarios. However such choices are better done on a case-by-case basis e.g. based on the range of group addresses.¶
SSM services over a Layer-3 LISP domain connect multicast sources and receivers via the overlay. Receivers join source trees (S,G) by signalling IGMPv3, which then is transported as PIM packets over the LISP overlay. The typical SSM services would be represented by Financial Data, IPTV and Live streaming.¶
The traffic within a LISP domain, similar to the ASM would be subject to encapsulation and depending on the multicast mode it would be either head-end replication or native (overlay to underlay multicast mapping).¶
The sources and receivers can be connected to the LISP site or be located outside of the LISP domain. LISP overlay provides a resiliency by rerouting traffic dynamically.¶
SSM services eliminate RPs and shared trees, simplifying tree management. Direct (S,G) trees enhance scalability and reduce latency for one-to-many uses.¶
Receivers must support IGMPv3 (or MLDv2) to specify sources, avoiding ASM fallback. Replication strategies need tuning to balance ITR load and underlay bandwidth.¶
One of the primary deployment use cases involves delivering multicast services across multiple LISP domains. There are several methods for routing multicast packets when sources and recievers are connected to LISP sites that are connected through VPNs. Two most common methods are given below:¶
Choosing between these options has significant design implications for both unicast and multicast flows. In the native forwarding approach, traffic leaving a LISP domain is decapsulated at the xTRs and placed into the appropriate VRF. This scenario creates considerable overhead in deploying multicast configurations across multiple sites, as each LISP instance must be mapped to an individual VRF in transit. The overlay scenario, which involves an overlay between LISP domains, offers advantages by extending the LISP overlay between different LISP domains. In this case, xTRs in each LISP domain are responsible for encapsulating and decapsulating traffic between overlays (transit and intra-site). Similar to intra-domain multicast communication, multicast traffic spanning multiple LISP domains requires mapping between the overlay and underlay multicast groups.¶
In a scenario with two separate LISP domains, where the multicast source is connected to LISP domain #1 and the receiver is at LISP domain #2, the multicast traffic traverses over the LISP transit overlay. The mapping from the overlay to the underlay group occurs at the ingress of LISP domain #1, where the xTR decapsulates the traffic and re-encapsulates it for transit, creating a separate mapping. This mapping might utilize the same input parameters to determine the underlay group; however, this could lead to undesired behavior within the transit. Specifically, it might cause multiple LISP instances to map to the same underlay multicast group, resulting in a loop between the individual xTRs of LISP domains #1 and #2. This can be mitigated by using disjoint underlay multicast groups in the different domains and can be signaled using the PIM Join/ Prune attributes described in [RFC8059]¶
To mitigate potential issues in transit, a new group mapping should be introduced that provides a unique overlay-to-underlay mapping for intra-LISP domain communication and transit between LISP domains. There are scenarios where a LISP domain extends across a transport network that is unable to handle multicast. In such cases, similar to intra-domain communication, head-end replication would be necessary to replicate multicast packets on the xTRs as they exit a given LISP domain. Another design consideration involves the placement of the Rendezvous Point (RP) in a multidomain environment. For multicast traffic confined to a LISP domain, the RP can be positioned within the domain either as a standalone role or co-located on a LISP site xTR. Depending on the LISP multidomain architecture, there may also be a dedicated LISP site aggregating multiple LISP sites, serving as an exit point from the entire domain. In this scenario, xTRs within the aggregation LISP site could be suitable candidates for RP placement. There is also a common scenario of implementing a set of additional, redundant RPs within LISP domain (in addition to the external RPs). In such a scenario, there needs to be an appropriate MSDP configuration in order to exchange information about multicast sources. If the multicast source flow originates from outside the LISP domain, considering an external RP for the entire LISP domain could also be a viable option.¶
This feature is beyond the scope of this document.¶
This memo includes no request to IANA.¶
This informational document does not introduce any new security considerations.¶
The authors would like to acknowledge Stig Venaas for his review. Many individuals also contributed to the discussions for the material of this draft including Arunkumar Nandakumar, Aswin Kuppusami, Rajavel Ganesamoorthy, Sankar S and Sundara Moorthy. All contributions are gratefully acknowledged.¶
TBD¶