Re: [pim] Call for adoption of sr-mpls-multicast-framework

[Eric C Rosen <[e-mail]>]

I am opposed to the adoption of this draft.

The document is not very clear, and it is not always possible to tell 
what is actually being proposed.  The parts I think I understand have 
numerous problems which do not appear to have been properly considered.

The document appears to specify a way of setting up P2MP LSPs (let's 
call them "trees") using IGP as the control plane. Every tree is 
associated with an IPv4 or IPv6 group address.  Through some unspecified 
magic, each node determines whether it has "transmit interest" or 
"receive interest" for a given group address.  This interest is 
advertised via the IGP.

It is not clear whether these group addresses have anything to do with 
the group addresses that appear in IP multicast packets.  If they don't, 
it is not clear why a tree has to be associated with an IPv4/IPv6 
address at all.  If they do, it is not clear how multiple user flows can 
be aggregated on a single tree.

The draft seems to explicitly prohibit a tree from having parallel links 
between a given pair of nodes; this means that ECMP load balancing is 
not possible, which suggests that a tree is to carry only one flow. (I'm 
not sure why this prohibition is made, but it does seem to be there in 
rule 2 of section 5.2.2.)  On the other hand, there are a few sentences 
suggesting that these trees can be used to instantiate MVPN/EVPN PMSIs, 
which suggests that the trees aggregate flows and thus could benefit 
from ECMP.

The idea of using IGP to advertise interest in sending or receiving 
particular multicast flows is not new.  It recurs every few years, and 
generally disappears when people start to examine the evident scaling 
problems.  The number of groups, transmitters, and receivers is not 
bounded, and their rate of change is not bounded.  The last thing one 
wants to do is create an unbounded amount of IGP overhead.  
Surprisingly, the impact on IGP scaling is not mentioned at all in the 
draft.  (Imagine if one had to kick the IGP every time MVPN/EVPN 
initiates a new S-PMSI!)

Each <transmitter, group address> pair seems to be assigned a 
domain-wide unique label, or SID.  I think the intention is that the 
transmitter gets configured with this SID, and then advertises it in the 
IGP messages.  Assigning these domain-wide unique identifiers to trees 
that may appear and disappear with some frequency seems like an 
interesting problem.  However, the authors seem to regard this problem 
as out of scope for the document; that's a bit strange for a document 
that purports to be describing a framework.

Whether a given node has transmit and/or receive interest for a given 
group address is, according to the document, determined by management 
configuration.  There is no consideration of having the edge nodes 
support PIM/IGMP/MLD/mLDP, etc.  There is some mention of MVPN/EVPN, but 
only a mention, not an actual proposal.  That also seems strange for a 
framework document.  Surely a framework document should clearly 
delineate the boundary between overlay and underlay, and address the 
interactions between them.

Once the IGP distributes information about who has transmit and/or 
receive interest in each group address, a computation is performed to 
figure out the best tree for a particular <transmitter, group> pair.  
Some rules are sketched out for figuring this out, but the rules are not 
clear or precise enough to result in interoperable implementations.

Once the tree is determined, per-tree state needs to be established at 
each node that is either a transmitter, a receiver, or a replication 
point.  If a node doesn't fall into one of these categories for a 
particular tree, that node will not need the per-tree state.  If a 
particular replication point on a tree is not directly attached to the 
next replication point downstream, unicast tunneling is used to get the 
packets from one replication point to the next.

Much is made of the fact that per-tree data plane state exists only at 
nodes that are transmitters, replication points, or receivers for the 
tree.  This is presented as significant reduction in data plane state 
when compared to, say, PIM or mLDP.  Of course, whether there is any 
signficant reduction in state depends on the size and shape of the 
trees.  No analysis is given to show that the state reduction is 
significant, just a lot of handwaving.

On the other hand, there is an enormous increase in control plane state 
resulting from the fact that every single node in the network is aware 
of every tree and all its members.  Existing multicast protocols do not 
require a node to know about a tree unless the tree passes through it, 
and do not require all nodes along a tree to know about all the leaf 
nodes of the tree.  The large increase in the amount of control plane 
state is not considered at all, for some reason.

To send a data packet along a particular tree, the SID for that tree is 
pushed onto the packet's label stack.  Each node that receives a packet 
and sees a particular SID at the top of the label stack will replicate 
the packet and send (or tunnel) each copy to the next replication point, 
where the same SID will be seen.  Since unicast tunneling is generally 
used to get a packet from one replication point to the next, packets 
traveling along a particular tree may arrive over any interface.  This 
makes it impossible to do a data plane RPF check (such as PIM would 
do).  Since the tree has a domain-wide unique SID, you can't tell from 
the label who the previous node was, so you can't reject packets from 
the "wrong previous node" (such as mLDP would do).  This may lead to 
potentially disastrous multicast loops during periods when a tree is 
being modified, especially if node A was previously upstream of node B, 
but the change puts it downstream of node B.  (Modifications can be 
caused by topology changes or simply by a change in the set of 
receivers.)  These issues do not appear to have been considered.

I do not see how this document can be considered for WG adoption. Given 
the set of signficant issues that have not received proper 
consideration, it is not possible to say that this document is a good 
basis for future work.