Re: [pim] draft-ietf-pim-multicast-lessons-learned-02 & BIDIR-PIM

[Dino Farinacci <[e-mail]>]

> Dino, et al -

Thanks for the comments Jim. Sorry for the delay. The other authors can chime in as well.

> ** additional advantages of BIDIR-PIM to go in section 3.3 **
> 
> My experience is related to military MANETs with wireless networks that support 10s of kbps to single digit Mbps total network capacity that is shared between all nodes in the wireless network where the network can have up to 100s of nodes per wireless network and interconnected networks of wireless networks with thousands of nodes where the multicast groups can have hundreds to thousands of members (where all members are sources and destinations) and nodes can join and leave rapidly.

Yep, can see the motivation for Bidir-PIM.

> Multicast groups are used for tactical messaging such as for situational awareness (SA) in a given unit such as a company or battalion.  In RFC 8815 terminology, these are intradomain multicast groups and the reason that I argued that RFC 8815 should not deprecate intradomain ASM.

And note you don't care about discovering sources and even storing the source addresses, right?

I haven't looked at RFC 8815 recently, but I hope the decprecation statement is not for intra-domain multicast. Can someone on the list comment on this?

> In this scenario, ASM is the preferred choice over SSM because SSM suffers from issues related to scalability with that many sources and the overhead from the sometimes rapidly changing group membership with sources joining and leaving.
> 
> And for ASM, BIDIR-PIM is the preferred routing protocol for these use cases because of
> * it scales to hundreds to thousands of nodes per group with hundreds to thousands of sources per group
> * it has reduced overhead as members (including sources) join and leave
> * it can rapidly converge with stable shared trees as additional members join and leave a wireless network that already has at least one node that is a member of a group

Yes, that was the motivation for us to build Bidir-PIM, plus we removed the data-driven issue of PIM-SM Registers at the same time as avoiding the shared-tree to source-tree swtichover issues.

> Note that for most of these multicast groups, the members are either all in the same wireless network or else in a few directly connected wireless networks. This means that the shared trees are very efficient for routing.  And no PIM-BIDIR

Yes, implements the pure Deering multicast service model.

> routing updates are required as nodes join and leave if there are already members of that group in that wireless network, so that shared trees are stable as members join and leave.  So the only overhead is the IGMP join or leave in that single wireless MANET network, and not further PIM overhead is required in the larger network of networks.

Right.

> The reduced overhead is important to military MANETs where the total network capacity is often low on the order of 100s of Kbps to single digit Mbps.
> 
> Similarly the fact that the shared trees are efficient is also important to keeping overhead down as traffic is delivered
> 
> The rapid convergence and stability are important to ensure that critical multicast traffic is delivered as nodes join and leave
> 
> I don't see the BIDIR-PIM advantages of reduced overhead, rapid convergence, and stability for these types of MANET applications mentioned in any documents, such as this draft RFC or RFC 8815 "deprecating ASM"

So it seems you are suggesting some kinder words about Bidir-PIM. I can certainly go along with that.

> Thus, I recommend that these advantages of BIDIR-PIM be mentioned in section 3.3 " Shared vs Source Trees" next to last paragraph.
> 
> Maybe rewrite the next to last paragraph to something like:
> 
>       PIM Sparse Mode is the most commonly used multicast routing protocol. PIM Dense Mode is also used. Bidirectional PIM is less widely used other than perhaps military tactical MANETs. There has been a lack of vendor support for PIM-BIDIR features such as IPv6 and MVPN along with TCAM scalability limitations.
> 
>       With PIM-BIDIR, there are no source-based trees and no (S,G) state. There is no option for routers to switch from a shared tree to a source-based tree. The forwarding rules are much more simple than in PIM-SM and there are no data-driven events in the control plane. The main advantage of PIM-BIDIR is scaling. It scales well when there are many sources for each group such as with videoconferencing, many to many financial applications, and many to many tactical military message exchanges such as for situational awareness (SA) - also known as blue force tracking. In these latter military MANETs, PIM-BIDIR also has advantages of reduced overhead as nodes join and leave if at least one node in a MANET is already a member of the group and efficient shared trees for closely collocated tactical networks. However, in other applications with a few stable sources that are spread across a larger internet of networks, the traffic may be forced to remain on the inefficient shared tree due t
> o the lack of source-based trees.

Yes, I think this is a good suggestion. Note to the authors, we may want to break up the variants into sections where we title them "PIM-SSM Source-Trees Only", "PIM-SM Shared-Trees Only", "PIM-SM Hybrid Trees" (switching back and forth), and of course, per Jim's comment "PIM-Bidir Shared-Trees Only". And make the clear distinction how share-trees in PIM-SM and PIM-Bidir are very different when it comes to the packet forwarding paradigm.

> ** question on address allocation statement in section 3.3 **
> 
> The last paragraph of section 3.3. states that " address allocation with ASM is much more restrictive than it is with PIM-SSM."  Can you explain how ASM address allocation is more restrictive than with PIM-SSM?

It is because the group address needs to be unique. Where in SSM, a global source address is unique and what is joined is the 2-tuple (S,G). So G could be duplicated form different Ss. And therefore, separate/different distribution trees are built.

We will make this more clear in the specification.

> ** comment on (S,G) is a longer group address in section 3.4 **
> 
> I do agree with the last paragraph of section 3.4 that states that "All an (S,G) is is a longer group address"  In that

Well the Holbrook SSM paper called it a "channel". Maybe that would make it more clear?

> sense, SSM could be added to BIDIR-PIM if the group address were an (S,G) instead of an (*,G) so that the BIDIR tree for an (S,G) group would only have a single source node.  Note that I am not really advocating for creating an SSM variant of BIDIR-PIM because my use cases don't need it, but if someone wanted to, they could easily add it to BIDIR-PIM.

Yes, conceptually it is true, but if you have N (S,G) "groups" and N (*,G) "groups", you still have N pieces of state. All you are conceptualizing is that address can be longer. Well they are longer in IPv6 LOL.

Note also, "the single source node" is the same as the "Bidir RP". Its just a target for the destination of joins and packets that flow upstream (towards that target).

> ** comment on discovering sources in section 3.3 & 3.10 **
> 
> The first two paragraphs of 3.3 and the entire section 3.10 discuss the problems of discovering sources.  I claim that this is only a problem for some, but not applications.  I.e. what is the purpose of discovering sources?  Is it to optimize the routes of PIM-SM?

Its to join them yes. If the apps don't care what sources send to the groups they have joined, then it doesn't need to join the channel but join the group.

But we all have acknowledged an architectural weakness about the app and network layer interacting with source discovery. The app can do it on its own if it wants and the network layer to stay out of it. But a DoS attack to the group would have to be dealt with in the app. 

But going full circle, the app and its security infra, will need and want to authenticate and authorize anyways, so its more clear to me that source discovery SHOULD BE IN and STAY IN the app. Another issue is can source discovery be decentrailized or do we need app level directorys like SD and SDR, or databases like DNS or mapping systems.

These are the issues that are top of mind for me right now. That is, how can we maintain the multicast service model where discovery of any app entity is provided by the network IN A decentralized way. Our efforts with GAAP is trying to get us more intimate with multicast decentralization.

> Section 3.10 states that "In ASM, the network is responsible for discovering all multicast sources. This responsibility leads to massive protocol complexity, which imposes a huge operational cost for designing, operating and troubleshooting multicast."  I claim that this is really only an issue for PIM-SM and not an issue for BIDIR-PIM since BIDIR-PIM does not make a distinction between sources & destinations in the shared tree and does not try to adjust the tree for a given source that is sending traffic.

Agree 100%. We will make it more clear that PIM-SM and PIM-SSM have this complexity. PIM-SSM less so if we are clear that what is discovered is "tree channel state" where the network doesnt really care about the source. However, it needs to use S for selecting the RPF interface.

> The phrase PIM is often used to refer to PIM-SM even when talking about PIM features that are not supported in other PIM modes like PIM-DM and BIDIR-PIM.  

Great point. We will fix this.

> I request that people call out PIM-SM when they mean PIM-SM and not just use PIM without the explicit mode.  This draft RFC does a good job of only using PIM when it refers to something that is relevant to all PIM modes, but still occasionally uses PIM when it should use PIM-SSM such as in the first and last uses of PIM in section 3.10.]

We will fix. Thanks so much for your comments.

Dino