Static Multicast Distribution Trees
draft-nandy-pim-static-mcast-distribution-trees-00

Network Working Group                                           T. Nandy
Internet-Draft                                                    A. Raj
Intended status: Standards Track                          M. Subramanian
Expires: 6 July 2023                                          Aruba, HPE
                                                          2 January 2023

                  Static Multicast Distribution Trees
           draft-nandy-pim-static-mcast-distribution-trees-00

Abstract

   This document specifies the Static Provision of Multicast route as an
   alternate to Layer 3 Multicast protocols like PIM-SM (Protocol
   Independent Multicast - Sparse Mode), PIM SSM (Source-Specific
   Multicast), or PIM BIDI (Bidirectional).  It works like a standalone
   Multicast Route provisioning feature that can interoperate with other
   dynamic Multicast protocols like PIM-SM or with L2 protocols like
   IGMP (Internet Group Management Protocol) and MLD (Multicast Listener
   Discovery).  This feature can function with/without the use of
   Unicast Routing Protocols to build the Multicast tree.

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 6 July 2023.

Copyright Notice

   Copyright (c) 2023 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

Nandy, et al.              Expires 6 July 2023                  [Page 1]
Internet-Draft     Static Multicast Distribution Trees      January 2023

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Null Multicast Route  . . . . . . . . . . . . . . . . . .   4
   4.  Static Multicast Distribution Trees Specifications  . . . . .   4
     4.1.  State Machine . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  HA Considerations . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Interoperability with other Layer 3 Multicast Protocols . . .   7
     5.1.  Interoperability with PIM-SM and PIM SSM  . . . . . . . .   7
       5.1.1.  (S, G) Multicast Routes . . . . . . . . . . . . . . .   8
       5.1.2.  (S, G) Multicast Routes . . . . . . . . . . . . . . .   9
       5.1.3.  Summarized vs Non-Summarized Multicast Routes . . . .  12
       5.1.4.  Static Multicast Route at Rendezvous Point  . . . . .  14
     5.2.  Interoperability with PIM-BIDI  . . . . . . . . . . . . .  14
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   This document specifies a static protocol for efficiently routing
   multicast groups that may span across wide-area (and inter-domain)
   internet as well as small enterprises and Data Center networks that
   use IP Multicast.

   One general issue with Layer 3 multicast protocols is that they can
   become extremely complex to operate as well as debug as they may span
   an entire enterprise network.  They also depend on Unicast Routing
   Protocols for creating the Multicast Tree and performing RPF (Reverse
   Path Forwarding) checks thereby making the operation even more
   complex both configuration-wise as well as from the point of view of
   resolving issues.

   It has been also found that enabling a full-fledged layer 3 protocol
   like PIM-SM or PIM-BIDI might not be an ideal option for relatively
   simpler topologies like a centralized router that is routing

Nandy, et al.              Expires 6 July 2023                  [Page 2]
Internet-Draft     Static Multicast Distribution Trees      January 2023

   multicast traffic across L2 domains.  The nature of tree formation in
   a protocol like PIM-SM also tends in unsuitable for any sort of
   summarization.

   The proposal is to create Static Multicast Route that works very
   similarly to Static Unicast Route.  The Static Multicast Routes in
   theory will look very similar to Dynamic Multicast Routes in the
   Multicast FIB.  The Route will have an incoming Interface (typically
   RPF interface towards the Source or RP), Source address, Group
   address as the Key, and a list of Outgoing Interfaces as Value.  This
   way, Multicast Tree can be formed statically without the requirement
   of any dynamic Protocols like PIM.

   The Static provisioning of Multicast Routes will also be quite handy
   for small-scale enterprises with limited L3 connectivity as well for
   overlay Networks where we don't want PIM to run on top of Tunnels
   like VxLAN.

   This can also be useful if we want to provision the network
   statically through a Centralized SDWAN controller or a Cloud-based
   Network Management System.  The different use cases and detailed
   functions are explained in subsequent sections.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS.  Lower case uses of these words are not to be
   interpreted as carrying significance described in RFC 2119.

3.  Overview

   Static multicast route works similar to the static unicast route
   where the user explicitly specifies the incoming interface, source
   address, group address and the set of downstream interfaces to
   replicate the traffic.  In a typical multicast network, source and
   group addresses are learnt from the data traffic and the set of
   downstream interfaces are derived from IGMP joins from clients or PIM
   joins from the adjacent multicast routers.  However, with increasing
   number of clients and routers, these dynamic protocols pose some
   processing overhead on the routers.  With static multicast route,
   this can be avoided.

   Typical static multicast route looks like

Nandy, et al.              Expires 6 July 2023                  [Page 3]
Internet-Draft     Static Multicast Distribution Trees      January 2023

   [Incoming Interface, Source, Group].  [Set of downstream interfaces]

   where, Incoming Interface is the l3 interface from where the traffic
   is received on the router.  User can choose not to explicitly specify
   the incoming interface, but choose the interface based on RPF checks
   based on the unicast routes.

   Source is the source ip address of the streaming device.  It can be *
   also, which indicates any source ip address.

   Group is the multicast ip address of the group for which the traffic
   is streamed.

   Downstream interface is an L3 interface on which a PIM join is
   received or to which the receivers are connected.

   Source/Group address can also be configured with subnet mask.  If
   there are multicast sources/groups falling in the same subnet range
   and having the same set of downstream interfaces to send the traffic
   to, then the static multicast route can be configured with subnet
   mask for source/group.

   When a static multicast route is configured, it will stay until the
   user removes it.  However, static multicast route can also be
   configured with an expiry time so that it will be removed
   automatically from the MFIB after the expiry time.

3.1.  Null Multicast Route

   A null multicast route is a multicast route which drops the traffic
   at the incoming port without replicating traffic to any of the
   downstream interfaces.  It can be configured statically by specifying
   null interface as downstream for a specific multicast flow.

4.  Static Multicast Distribution Trees Specifications

4.1.  State Machine

   The states of a static multicast route are straight forward as it is
   user configured.  A static multicast route will be considered active
   as far as the incoming interface and the port(s) on which the
   incoming traffic is replicated is operational.  The interfaces that
   are down will not be included in the forwarding port list of the
   multicast entry programmed.  Static multicast route will not timeout
   based on traffic inactivity, but can be configured with an expiry-
   time so that the entry will be automatically removed after the expiry
   time.

Nandy, et al.              Expires 6 July 2023                  [Page 4]
Internet-Draft     Static Multicast Distribution Trees      January 2023

   An important case that needs to be considered here is when a
   statically configured multicast route is also learnt by the dynamic
   multicast routing protocol, say PIM-SM.  In such cases, the user
   configured multicast routes should take precedence over the PIM
   learnt routes by default.  If the set of downstream interfaces learnt
   from PIM/IGMP are different from the statically configured downstream
   interfaces, a choice can be given to the administrator to program the
   combination of both statically and dynamically learnt downstream
   interfaces for the mroute (multicast route).  Also, dynamically
   learnt multicast routes can be preferred over the matching static
   multicast entries by associating administrative distance with the
   static and dynamic mroutes.  Likewise, a backup static multicast
   route can be supported by associating a higher administrative
   distance value with the static multicast routes.  A backup route will
   be considered for programming when the primary static multicast
   becomes inactive.

   A static multicast route can also be configured without explicitly
   mentioning the incoming interface, in which case the incoming
   interface is derived from the unicast route to reach the source
   address.  The advantage of this approach is that if the primary path
   to the multicast source goes down, the corresponding static multicast
   route can still be operational through the alternate path selected by
   unicast routing protocols.  If the source address is not reachable
   via any path, the static multicast route should not be programmed
   into the multicast route table and should be considered inactive.

   Interoperation of static multicast routes with dynamic multicast
   protocols is mentioned in Section 5 below.

4.2.  HA Considerations

   A static multicast route can stay on the forwarding path even as its
   multicast software is restarted or during a Management Module
   failover.

   A restarting router can adjust its forwarding in a timely manner
   after the restart if it detects that the static multicast route is no
   more operational.  In such cases, the inactive static multicast
   routes should be cleared from the forwarding table and backup routes
   should be programmed as applicable.

Nandy, et al.              Expires 6 July 2023                  [Page 5]
Internet-Draft     Static Multicast Distribution Trees      January 2023

4.3.  Use Cases

   Multicast routing protocols like PIM and IGMP are responsible for
   construction of the multicast delivery tree on overlay networks.
   These traditional multicast routing protocols achieve this by
   exchanging mroutes in control packets along with configuring policies
   across all devices in the overlay.  Coupling ip mobility and ip
   multicast in Overlay networks can induce issues like network
   inactivity due to overhead of encapsulation/decapsulation, large
   bandwidth consumption, multicast routing state maintenance, latency
   and frequent recalculation and construction of multicast delivery
   tree in many devices in the overlay.  For a multicast network managed
   by centralized controllers, we need to address requirements such as:
   separate multicast flow calculation on behalf of each node in the
   Overlay Network, application aware traffic forwarding with flow-based
   priorities, and dynamically respond to network changes.  Similar
   requirements arise in multi-fabric deployments running VxLAN overlay
   or IPsec based SD-WAN overlay networks.

Nandy, et al.              Expires 6 July 2023                  [Page 6]
Internet-Draft     Static Multicast Distribution Trees      January 2023

   In such network deployments, the border gateway router, which is part
   of the fabric as well as the overlay network, can function as the
   hybrid   router   running   both   legacy   for   intra-fabric   and
   static/controller  programmed  multicast  routing  for  overlay.  The
   IGMP/PIM joins originated from the receivers/clients in the customer
   network through legacy multicast routing protocols (PIM, IGMP, MLD
   etc) are learnt on the border gateway routers and these joins, along
   with  the  path  to  source  through  the  overlay,  are  used
   derive/configure the static multicast route. A multicast distribution
   tree is formed for each flow on every border router based on the
   overlay  interfaces  through  which  the  Source  is  reachable.  As
   mentioned above, source reachability information is either available
   in the Unicast Routing table or can be statically configured.
   Multiple distribution trees may be formed per border router if there
   are multiple sources that the clients are interested in.

   The Simple Service Discovery Protocol (SSDP) is an application layer
   protocol and one of the key protocols that implement Universal Plug
   and Play (UPnP). SSDP enables network devices to discover and
   advertise  network  services  by  sending  multicast  discovery  and
   advertisement   messages   to   multicast   IPv4   group   address
   239.255.255.250:1900 or multicast IPv6 group address FF0x::C[1].
   Because of the nature of the way UPnP works, each device will
   generate a unique multicast flow (Source IP, SSDP Group IP). In a
   multicast network with a large number of end user devices, this can
   bloat up the multicast hardware/software resources as each device
   will create a unique (S, G) flow and the resources are limited. In
   networks, where there is a need to control/drop/minimize SSDP
   traffic, summarized static multicast routes can be configured to save
   network resources and to avoid denial of services.

   Static Multicast Distribution Trees can be used in cases where there
   is a fixed source and set of clients like video conferencing where
   interruptions due to route updates can be avoided.

5.  Interoperability with other Layer 3 Multicast Protocols

5.1.  Interoperability with PIM-SM and PIM SSM

   The Static Multicast Route feature will interop with the PIM-SM and
   PIM-SSM protocol features.  The Static Multicast Route will mostly be
   in the last Hops/Client-side to be interoperated by the PIM-SM
   protocol.  The section below describes the interoperability with PIM-
   SM/PIM-SSM.

Nandy, et al.              Expires 6 July 2023                  [Page 7]
Internet-Draft     Static Multicast Distribution Trees      January 2023

                                        +----------------------------+

          +------+                      |   +------+ iface3 +------+ |

          |Source|                      |   |  R4  +--------+Client| |

          +------+                      |   +--+---+        +------+ |

         | | |iface2 |

             |              RP          |      |                     |

          +--+---+       +------+ iface1|   +--+---+    STATIC       |

          |  R1  +-------+  R2  +-------|---+  R3  |    MROUTES      |

          +------+       +------+       |   +------+                 |

                                        +----------------------------+

                                    Fig. 1

   Static multicast routes give the flexibility to the user to program a
   specific path for multicast traffic from the source till the client
   without having to rely on the underlying protocols to build a
   multicast route.  They can be configured on all the routers in the
   path or on a specific section of routers.  The remaining section of
   routers can be configured to run the native PIM protocol.  In Fig. 1,
   static multicast routes are configured on routers R3 and R4 whereas
   PIM protocol builds the multicast routes on routers R1 and R2.  R3
   acts as a gateway where the static multicast routes terminate.

   There are two ways of programming a static mroute.  One is (S, G)
   based and the other is (*, G) based as explained in the next
   sections.

5.1.1.  (S, G) Multicast Routes

   This section describes the non summarized multicast routes where the
   flow contains a specific source.  In Fig 1, on R3, a static mroute is
   programmed as follows.

Nandy, et al.              Expires 6 July 2023                  [Page 8]
Internet-Draft     Static Multicast Distribution Trees      January 2023

        Flow     Incoming     Outgoing
                 Interface    Interface
        S,G      Iface 1      Iface 2

   Similarly on R4, a static mroute is programmed as follows.

        Flow     Incoming     Outgoing
                 Interface    Interface
        S,G      Iface 2      Iface 3

   It is to be noted that PIM protocol is enabled on R3 but not on R4.

   The source would have registered to R2 (RP) via the native PIM path.
   So R1 and R2 will contain the multicast routes.

   On R3, where the static multicast routes terminate, a redistribute
   command is configured to inform PIM about the static mroute.  This
   will ensure that PIM creates an Upstream (S, G) state and sends an S,
   G join to R2 via iface 1.  This join reaches R1 which forwards the
   source traffic to R2 which in turn starts routing the (S, G) traffic
   to iface 1.  This traffic will be routed on R3 and R4 based on the
   static mroutes programmed and will eventually reach the clients.  It
   is to be noted that on R3, PIM immediately switches to Source
   specific Tree (SPT) without having to go via RP Tree since the Source
   is already known.

   The difference from the conventional PIM protocol is the trigger to
   create the Upstream (S, G) state.  In general, it is created only
   when multicast data packet is received.  But in case of static
   mroutes, the redistribute option can also create the Upstream (S, G)
   state.

5.1.2.  (S, G) Multicast Routes

   On an incoming interface I1, when there are multiple sources S1..n, ,
   sending multicast traffic to a single group G, and if the outgoing
   interfaces are also the same, then instead of having individual
   mroutes for every (I1, Si, G) where i = 1..n, a single summarized
   (*,G) mroute entry on interface I1 is programmed which will help in
   saving hardware resources.

   There are two types of summarizations.

   i) Implicit Summarization - The network administrator configures
   multiple static mroutes with same group address, same incoming and
   outgoing interfaces but different source addresses.  These routes are
   implicitly summarized into a single (*, G) mroute entry.

Nandy, et al.              Expires 6 July 2023                  [Page 9]
Internet-Draft     Static Multicast Distribution Trees      January 2023

   ii) Explicit Summarization - The network administrator explicitly
   configures a summarized (*, G) static mroute without specifying the
   source ip.

                                        +----------------------------+

         +---------+                    |   +------+ iface3 +------+ |

         |Source S1|                    |   |  R4  +--------+Client| |

         +---------+                    |   +--+---+        +------+ |

         | | |iface2 |

             |              RP          |      |                     |

          +--+---+       +------+ iface1|   +--+---+    STATIC       |

          |  R1  +-------+  R2  +-------|---+  R3  |    MROUTES      |

          +------+       +------+       |   +------+                 |

             |                          +----------------------------+

             |

         +---------+

         |Source S2|

         +---------+

                                   Fig. 2

5.1.2.1.  Implicit Summarization

   In Fig. 2, On R3, two static mroutes are programmed for different
   sources but for same group, with same incoming and outgoing interface
   as follows:

        Flow     Incoming     Outgoing
                 Interface    Interface
        S1,G     Iface 1      Iface 2
        S2,G     Iface 1      Iface 2

Nandy, et al.              Expires 6 July 2023                 [Page 10]
Internet-Draft     Static Multicast Distribution Trees      January 2023

   This implies that multicast traffic incoming on interface 1, destined
   to group G from sources S1 and S2, will be routed to interface 2.
   These multicast routes are implicitly summarized into a single
   multicast route entry as follows:

        Flow     Incoming     Outgoing
                 Interface    Interface
        *,G      Iface 1      Iface 2

   Similarly on R4, two static multicast routes are programmed as
   follows.

        Flow     Incoming     Outgoing
                 Interface    Interface
        S1,G     Iface 2      Iface 3
        S2,G     Iface 2      Iface 3

   which will be summarized as

        Flow     Incoming     Outgoing
                 Interface    Interface
        *,G      Iface 2      Iface 30

   On R3, where the static multicast routes terminate, a redistribute
   command is configured for PIM.  Since the source ip addresses are
   specified, PIM will create Upstream (S, G) states for S1 and S2 and
   sends (S, G) joins towards both the sources on iface 1.

   The joins reach R1, which forwards multicast traffic from sources S1
   and S2 to R2 which in turn starts routing the traffic to iface 1.
   This traffic will be routed on R3 and R4 based on the static mroutes
   programmed and will eventually reach the clients.  Like in the
   earlier case, PIM immediately switches to Source Specific Tree (SPT)
   for all the specified sources without having to go via RP Tree since
   the source ip addresses are already known.

5.1.2.2.  Explicit Summarization

   On R3, a static mroute can be programmed without mentioning the
   source ip as follows:

        Flow     Incoming     Outgoing
                 Interface    Interface
        *,G      Iface 1      Iface 2

   This implies that multicast traffic incoming on interface 1, destined
   to group G from any source, will be routed to interface 2.  Similarly
   on R4, a static mroute is programmed as follows:

Nandy, et al.              Expires 6 July 2023                 [Page 11]
Internet-Draft     Static Multicast Distribution Trees      January 2023

        Flow     Incoming     Outgoing
                 Interface    Interface
        *,G      Iface 2      Iface 3

   On R3, where the static multicast routes terminate, redistribute
   command is configured for PIM.  Since the source ip is not known in
   this case, PIM creates an Upstream (*, G) state and sends a (*, G)
   PIM join towards the RP router .R2 on iface 1.  RP will be aware of
   all the sources since they would have registered to it via the native
   PIM protocol.

   Once the (*, G) join is received, R2 starts routing the traffic to
   iface 1.  This traffic will be routed on R3 and R4 based on the
   static mroutes programmed and will eventually reach the clients.  It
   is to be noted that the traffic continues to flow via the RP-Tree
   path and there will not be a source tree switch.

5.1.3.  Summarized vs Non-Summarized Multicast Routes

   For a same group address, it is possible to have both summarized and
   non-summarized multicast routes.  Consider the following scenario:

Nandy, et al.              Expires 6 July 2023                 [Page 12]
Internet-Draft     Static Multicast Distribution Trees      January 2023

                                        +-----------------------------+
                                        |                             |
         +---------+                    |   +------+ iface4 +-------+ |
         |         |                    |   |      |        |       | |
         |Source S1|                    |   |  R4  +--------+Client1| |
         |         |                    |   |      |        |       | |
         +---------+                    |   +--+---+        +-------+ |
             |                          |      |                      |
             |                          |      |iface2                |
             |                          |      |                      |
             |              RP          |      |                      |
             |                          |      |                      |
          +--+---+       +------+ iface1|   +--+---+ iface3 +-------+ |
          |      |       |      |       |   |      |        |       | |
          |  R1  +-------+  R2  +-------|---+  R3  +--------+Client2| |
          |      |       |      |       |   |      |        |       | |
          +------+       +------+       |   +------+        +-------+ |
             |                          |                             |
             |                          +-----------------------------+
             |
        -------------
        |           |
        |           |
        |           |
   +---------+  +---------+
   |         |  |         |
   |Source S2|  |Source S3|
   |         |  |         |
   +---------+  +---------+

                                   Fig. 3

   Client 1 is interested in traffic from Sources S1 and S2 traffic
   whereas Client 2 is interested in traffic from Source S3.  The
   following static multicast routes will be programmed in R3:

        Flow     Incoming     Outgoing
                 Interface    Interface
        *,G      Iface 1      Iface 2
        S3,G     Iface 1      Iface 3

   It can be seen that there is a summarized multicast route to cater to
   Sources S1 and S2 traffic and a specific S, G mroute entry to cater
   to Source S3 traffic.  Since the outgoing interface is different for
   S3, G it cannot be summarized into the (*, G) entry.

Nandy, et al.              Expires 6 July 2023                 [Page 13]
Internet-Draft     Static Multicast Distribution Trees      January 2023

   When lookup happens in the multicast routing table, (S, G) entries
   are given precedence over (*, G) entry.  If a matching (S, G) entry
   is not found, then a summarized (*, G) entry for that group (if
   present) will be selected for forwarding.  In this case when the
   traffic streamed from Source S3 lands on R3, the (S3, and G) mroute
   entry will be used for forwarding the traffic. (*, G) entry will be
   used for all other sources (other than S3) which stream to group G on
   Iface 1.

5.1.4.  Static Multicast Route at Rendezvous Point

   In a typical network with Static Multicast Routes, we will not be
   requiring RP.  The Network that Requires RP will be either exporting
   Static Multicast Routes from downstream or will be a pure PIM-SM/PIM
   BIDI-based network.

   The RP router by itself will never require a Static Multicast Route
   to be configured for any Sources that are registering on it.  We do
   not want to have the RPT path from RP to Client be static.

5.2.  Interoperability with PIM-BIDI

   Static Multicast Route both summarized and non-summarized can interop
   with PIM-BIDI.  The Designated Forwarded for that particular subnet
   can pick up the Summarized Multicast Route and forward it towards the
   RP.

   The router in a subnet that is not a DF will actually export the
   Static Multicast Route towards the DF for it forward the same towards
   the RP.

   In the same way, any traffic hitting southbound to a Router that is
   both PIM BIDI and Static Multicast Route enabled, the protocol can
   simply program the entry as per the Static Multicast Route if that is
   configured.

6.  Security Considerations

   The Static Multicast Route option can be used to misdirect network
   traffic by providing incorrect downstream interfaces.  This can be
   either a Denial of Service attack, where the downstream interface
   configured has no active clients connected or configuring multiple
   invalid static multicast routes to use up system resources.  Care
   should be taken to explicitly remove stale static multicast routes to
   avoid traffic drops, and duplications and to optimize resource usage.
   Static multicast routes should be configured in a manageable manner
   and scale.  This is also significant as the static multicast route
   configuration can impact the way PIM control packets are handled, as

Nandy, et al.              Expires 6 July 2023                 [Page 14]
Internet-Draft     Static Multicast Distribution Trees      January 2023

   explained in section 5.

7.  IANA Considerations

   This document does not contain any IANA actions.

8.  References

8.1.  Normative References

   [1]        Bradner, S., "Keywords for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>. [2] Cain, B.,
              Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan,
              "Internet Group Management Protocol, Version 3", RFC 3376,
              DOI 10.17487/RFC3376, October 2002,
              <http://www.rfc-editor.org/info/rfc3376>. [3] Deering, S.,
              "Host extensions for IP multicasting", STD 5, RFC 1112,
              DOI 10.17487/RFC1112, August 1989,
              <http://www.rfc-editor.org/info/rfc1112>. [4] Holbrook, H.
              and B. Cain, "Source-Specific Multicast for IP", RFC 4607,
              DOI 10.17487/RFC4607, August 2006,
              <http://www.rfc-editor.org/info/rfc4607>.

8.2.  Informative References

   [2]        Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
              <http://www.rfc-editor.org/info/rfc5015>. [6] Savola, P.,
              Lehtonen, R., and D. Meyer, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM) Multicast Routing
              Security Issues and Enhancements", RFC 4609, DOI 10.17487/
              RFC4609, October 2006,
              <http://www.rfc-editor.org/info/rfc4609>. [7] Zheng, L.,
              Zhang, J., and R. Parekh, "Survey Report on Protocol
              Independent Multicast - Sparse Mode (PIM-SM)
              Implementations and Deployments", RFC 7063,
              DOI 10.17487/RFC7063, December 2013,
              <http://www.rfc-editor.org/info/rfc7063>.

Appendix A.  Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

Nandy, et al.              Expires 6 July 2023                 [Page 15]
Internet-Draft     Static Multicast Distribution Trees      January 2023

   Tathagata Nandy
   Aruba, Hewlett Packard Enterprise Ltd.
   Sy No. 192, Mahadevapura
   Bangalore-48.
   Phone: +91-961189857
   Email: tathagata.nandy@hpe.com

   Anil Raj
   Aruba, Hewlett Packard Enterprise Ltd.
   Sy No. 192, Mahadevapura
   Bangalore-48.
   Phone: +91-7760071000
   Email: anil.raj2@hpe.com

   Muthukumar, Subramanian
   Aruba, Hewlett Packard Enterprise Ltd.
   Sy No.192, Mahadevapura,
   Bangalore-48
   Phone: +91-9632122377
   Email: subramanian.muthukumar@hpe.com

Nandy, et al.              Expires 6 July 2023                 [Page 16]