Experiences with LISP Multicast deployments
draft-vgovindan-lisp-multicast-deploy-00

LISP Working Group                                           V. Govindan
Internet-Draft                                                 M. Hamroz
Intended status: Informational                                 J. Gawron
Expires: 1 September 2025                                          Cisco
                                                        28 February 2025

              Experiences with LISP Multicast deployments
                draft-vgovindan-lisp-multicast-deploy-00

Abstract

   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.

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 1 September 2025.

Copyright Notice

   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.

Govindan, et al.        Expires 1 September 2025                [Page 1]
Internet-Draft              LISP Deployments               February 2025

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Scope of this document  . . . . . . . . . . . . . . . . . . .   2
   4.  Scope not covered by this document  . . . . . . . . . . . . .   3
   5.  Industry segments/ use-cases covered  . . . . . . . . . . . .   3
   6.  Advantages and Cost of using "PIM-over-PIM" . . . . . . . . .   3
   7.  Underlay Deployment considerations  . . . . . . . . . . . . .   4
     7.1.  Ingress Replication . . . . . . . . . . . . . . . . . . .   4
     7.2.  Native Multicast Underlay . . . . . . . . . . . . . . . .   4
   8.  Layer-2 BUM overlay deployment considerations . . . . . . . .   5
     8.1.  RP for Layer-2 BUM Multicast Underlay . . . . . . . . . .   6
   9.  Layer-3 overlay Multicast deployment considerations . . . . .   6
     9.1.  Layer-3 Routed Any-Source Multicast (ASM) services  . . .   6
       9.1.1.  Layer-3 overlay ASM RP placement and redundancy . . .   6
       9.1.2.  Optimisation for short-lived streams  . . . . . . . .   7
     9.2.  Layer-3 Routed SSM services . . . . . . . . . . . . . . .   7
   10. Mobility considerations for LISP multicast  . . . . . . . . .   8
   11. Multicast flows spanning multiple LISP domains  . . . . . . .   8
   12. Extranet Multicast (Route leaking)  . . . . . . . . . . . . .   9
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   14. Security Considerations . . . . . . . . . . . . . . . . . . .   9
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     15.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     15.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   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]

2.  Terminology

   All of the terminology used in this document comes from [RFC6831] and
   [I-D.ietf-lisp-rfc6831bis].

3.  Scope of this document

   This document covers the following aspects:

   *  Deployments based on the procedures of [RFC6831] and
      [I-D.ietf-lisp-rfc6831bis].

Govindan, et al.        Expires 1 September 2025                [Page 2]
Internet-Draft              LISP Deployments               February 2025

   *  When using a multicast based underlay, LISP sites can provide
      support to forward Layer-2 Broadcast, Unknown Unicast and
      Multicast packets.
   *  Layer3 routed multicast services (ASM, SSM and BiDir) are provided
      by such LISP sites.
   *  Both IPv4 and IPv6 overlays are covered by this document.
      Similarly, both IPv4 and IPv6 underlays are covered.

4.  Scope not covered by this document

   This document does not cover the following aspects:

   *  This document does not cover L3 routed Unicast forwarding or L2
      forwarding between LISP sites.
   *  This document does not address services implemented using
      underlays such as BIER.
   *  Procedures and considerations required for migrating non-LISP
      based networks to LISP based networks are not covered here.
   *  Extranet Multicast (Route Leaking) is not covered in this document

5.  Industry segments/ use-cases covered

   The deployment experiences outlined in this document capture
   learnings from various industry segments listed below (not
   exhaustive:)

   *  Educational Institutions (e.g. Universities with multiple
      campuses, school districts)
   *  Public Utilities like Airports, Stadiums and Ports
   *  Hospitals and Healthcare providers
   *  Enterprises including Financial Institutions spread across
      continents and large geographical regions
   *  Technology vendors and factories
   *  Events like Expos, Tradeshows, Sporting events

6.  Advantages and Cost of using "PIM-over-PIM"

   There are both advantages and costs in using a "PIM-over-PIM" design
   outlined in [I-D.ietf-lisp-rfc6831bis]:

   *  PIM [RFC7761] is a well-understood and deployed protocol in many
      types of networks (Enterprise, Global Internet etc.).
   *  For the specific case of deploying PIM in the overlay in a LISP
      network, merely encapsulating the PIM protocol packet into a
      Unicast LISP packet and directing it towards the xTR that is
      chosen as the Upstream Multicast NH worked very well.

Govindan, et al.        Expires 1 September 2025                [Page 3]
Internet-Draft              LISP Deployments               February 2025

   *  Usage of PIM Join Attributes for LISP is a very useful method for
      the receiver ETR to signal underlay transport attributes to the
      ITR [RFC8059].  The motivations for doing so are explained in the
      later sections of this document.
   *  The PIM neighborship was not fully established as exchange of PIM
      hellos were considered chatty.
   *  A simple but powerful optimization was done to use only SSM in the
      underlay for supporting overlay Layer-3 multicast routing.

7.  Underlay Deployment considerations

7.1.  Ingress Replication

   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.

7.2.  Native Multicast Underlay

   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

Govindan, et al.        Expires 1 September 2025                [Page 4]
Internet-Draft              LISP Deployments               February 2025

   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.

   *  Underlays in most deployments were homogenous e.g. IPv6 Unicast
      based underlay.
   *  Upgrading from one underlay to another is a process that requires
      a lot of planning.  This is not covered in this document.

8.  Layer-2 BUM overlay deployment considerations

   There are three deployment options that can be considered here for
   deployment:

   *  Ingress Replication: Each L2 BUM packet is replicated by the ITR
      so each ETR receives a copy of the L2 packet encapsulated as
      unicast in the underlay.
   *  Use ASM underlay: Since any xTR does not know the list of ITRs
      that can potentially send L2 BUM packets, it subscribes to an
      underlay multicast group based on the L2 LISP instance.  There can
      be a m:n mapping of 'm' LISP instances to 'n' Underlay Multicast
      groups with m>n or m>>n.  We have also seen many customers use
      n=1.
   *  Use BIDIR underlay: Since BIDIR is a commonly supported mode we
      can simply reduce the multicast state in the underlay to O(n)
      instead of O(n*no.of ITRs) by choosing BIDIR over ASM.  This mode
      is particularly popular when IPv6 underlay is used as the
      forwarding path resources (e.g. TCAM entries) required to support
      IPv6 multicast routing is double that of IPv4.

Govindan, et al.        Expires 1 September 2025                [Page 5]
Internet-Draft              LISP Deployments               February 2025

8.1.  RP for Layer-2 BUM Multicast Underlay

   *  When using a Multicast underlay for L2 BUM, we use ASM based
      underlay or a BIDIR based underlay.
   *  This can be achieved by having an m LISP L2 service instances are
      mapped to n multicast groups where m > n or m >> n since the
      number of LISP L2 instances are larger than the number of
      designated multicast groups to carry BUM traffic.
   *  Since this is done flexibly, heavy users of BUM can be allocated
      separate underlay groups for isolation.
   *  One of the most critical design element is the choice of the RP
      Design.  We have the following options:
      -  Configuring static RPs: Use of anycast IP addresses with static
         RP is a popular choice observed in deployments.
      -  Electing RPs through mechanisms like PIM-BSR [RFC5059] has been
         adopted by customers as well.

9.  Layer-3 overlay Multicast deployment considerations

9.1.  Layer-3 Routed Any-Source Multicast (ASM) services

   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.

9.1.1.  Layer-3 overlay ASM RP placement and redundancy

   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

Govindan, et al.        Expires 1 September 2025                [Page 6]
Internet-Draft              LISP Deployments               February 2025

   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.

9.1.2.  Optimisation for short-lived streams

   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.

9.2.  Layer-3 Routed SSM services

   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.

Govindan, et al.        Expires 1 September 2025                [Page 7]
Internet-Draft              LISP Deployments               February 2025

10.  Mobility considerations for LISP multicast

   TBD

11.  Multicast flows spanning multiple LISP domains

   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:

   *  Forwarding the traffic natively, without any encapsulation, which
      typically results in extending the VRF segmentation beyond a
      specific LISP site
   *  Implementing an overlay across the transit network.

   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]

Govindan, et al.        Expires 1 September 2025                [Page 8]
Internet-Draft              LISP Deployments               February 2025

   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.

12.  Extranet Multicast (Route leaking)

   This feature is beyond the scope of this document.

13.  IANA Considerations

   This memo includes no request to IANA.

14.  Security Considerations

   This informational document does not introduce any new security
   considerations.

15.  References

15.1.  Normative References

   [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-01, 29 January 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
              rfc6831bis-01>.

Govindan, et al.        Expires 1 September 2025                [Page 9]
Internet-Draft              LISP Deployments               February 2025

   [RFC5059]  Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
              "Bootstrap Router (BSR) Mechanism for Protocol Independent
              Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January
              2008, <https://www.rfc-editor.org/info/rfc5059>.

   [RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
              Locator/ID Separation Protocol (LISP) for Multicast
              Environments", RFC 6831, DOI 10.17487/RFC6831, January
              2013, <https://www.rfc-editor.org/info/rfc6831>.

   [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>.

   [RFC8059]  Arango, J., Venaas, S., Kouvelas, I., and D. Farinacci,
              "PIM Join Attributes for Locator/ID Separation Protocol
              (LISP) Environments", RFC 8059, DOI 10.17487/RFC8059,
              January 2017, <https://www.rfc-editor.org/info/rfc8059>.

15.2.  Informative References

Acknowledgements

   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.

Contributors

   TBD

Authors' Addresses

   Vengada Prasad Govindan
   Cisco
   Email: venggovi@cisco.com

   Marcin Hamroz
   Cisco
   Email: mhamroz@cisco.com

Govindan, et al.        Expires 1 September 2025               [Page 10]
Internet-Draft              LISP Deployments               February 2025

   Jaroslaw Gawron
   Cisco
   Email: jagawron@cisco.com

Govindan, et al.        Expires 1 September 2025               [Page 11]