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

Hi Eric:

Replies in line, prefaced with DA>

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.

DA> Then I'll try to respond to the comments you have, and perhaps we can work our way through them.

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.

DA> If it is magic then clearly you understand the trick and where the wires are. 😊

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.

DA> Good feedback. Personally I do not see adding support for them as being a particularly big deal. Explicit mention of this will be in the next version.

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.)  
DA> There I think you have misunderstood the pruning algorithm. If at some point you have parallel paths you can consider them to be a single path from the point of view of resolving where state is going to end up.  It is certainly not a prohibition against ECMP. The algorithm is specifically designed to make ECMP as painless as possible. What you are commenting on is a simplification of the topology model as an intermediate step in determining where state will need to be installed.

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.
DA> See replies above.

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!)
DA> Deployments of 802.1aq shortest path bridging would provide an existence proof for using the IGP without detrimental effects and I'm aware of some sizeable networks using it. It does have a virtuous circle in that all multicast state exchange is not tied to topology changes, so when a topology change does occur the control plane can simply get on with it with a minimum of messaging.  

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.
DA> Again that is good feedback. We'll address this in the next version.

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.
DA> That is an oversight in the content itself, interactions with IGMP, PIM etc. have been discussed outside the draft content. For the next version.

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.
DA> If you could enumerate where you think it is not clear, that would be very useful input.

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.
DA> Correct

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.
DA> I would have thought it was self evident as described in the PIM and RTGWG presentations where the worst case is that (2xleaf count) nodes need to install state per tree irrespective of network size, and a fairly simple example provided. I don’t recall seeing you there. Paraphrasing a comment of yours from years ago you said that the role of a draft or RFC was to describe "what" and not "why", but if now you think some more "why" is needed we're happy to oblige.

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.
DA> I guess that is a bias where control plane memory is cheaper, and therefore more plentiful than dataplane state, making DP state something to optimize around.  We'll think about how to handle this.

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).  
DA> If PHP is employed, then the multicast SID would be top label, and split horizon filtering would be possible as a form of an RPF check. We'll add this to the draft.   However this is a useful insight to be reminded of when considering what technologies the approach is applicable to as suggested by Toerless's post.  

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.
DA> They were, just not elucidated in the draft itself.

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.
DA> Personally I’m not seeing any show stoppers in your list of concerns. But that is my opinion.

Thanks for the feedback
Dave

_______________________________________________
pim mailing list
pim@ietf.org
https://www.ietf.org/mailman/listinfo/pim