Internet DRAFT - draft-nandy-pim-static-mcast-distribution-trees
draft-nandy-pim-static-mcast-distribution-trees
Network Working Group T. Nandy
Internet-Draft A. Raj
Intended status: Standards Track M. Subramanian
Expires: 10 July 2024 Aruba, HPE
7 January 2024
Static Multicast Distribution Trees
draft-nandy-pim-static-mcast-distribution-trees-02
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 10 July 2024.
Copyright Notice
Copyright (c) 2024 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 10 July 2024 [Page 1]
Internet-Draft Static Multicast Distribution Trees January 2024
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 10 July 2024 [Page 2]
Internet-Draft Static Multicast Distribution Trees January 2024
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 10 July 2024 [Page 3]
Internet-Draft Static Multicast Distribution Trees January 2024
[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 10 July 2024 [Page 4]
Internet-Draft Static Multicast Distribution Trees January 2024
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 10 July 2024 [Page 5]
Internet-Draft Static Multicast Distribution Trees January 2024
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 10 July 2024 [Page 6]
Internet-Draft Static Multicast Distribution Trees January 2024
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 10 July 2024 [Page 7]
Internet-Draft Static Multicast Distribution Trees January 2024
+----------------------------+
+------+ | +------+ 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 10 July 2024 [Page 8]
Internet-Draft Static Multicast Distribution Trees January 2024
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 10 July 2024 [Page 9]
Internet-Draft Static Multicast Distribution Trees January 2024
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 10 July 2024 [Page 10]
Internet-Draft Static Multicast Distribution Trees January 2024
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 10 July 2024 [Page 11]
Internet-Draft Static Multicast Distribution Trees January 2024
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 10 July 2024 [Page 12]
Internet-Draft Static Multicast Distribution Trees January 2024
+-----------------------------+
| |
+---------+ | +------+ 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 10 July 2024 [Page 13]
Internet-Draft Static Multicast Distribution Trees January 2024
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 10 July 2024 [Page 14]
Internet-Draft Static Multicast Distribution Trees January 2024
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 10 July 2024 [Page 15]
Internet-Draft Static Multicast Distribution Trees January 2024
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 10 July 2024 [Page 16]
