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

[Dino Farinacci <[e-mail]>]

> Dino & Michael - thanks for your responses and willingness to consider expounding more on ASM and BIDIR-PIM

Thanks for the quick reply. I have snipped stuff I have no response to otherwise, see inline.

> 
>> 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).
> 
> Agree.  Interesting question.  Is SSM-BIRDIR-PIM where the Source is the RP a simpler PIM protocol that PIM-SM-SSM?

Well there is no such thing as SSM-BIDIR-PIM but to answer your question the source is not the RP because the RP address is never used as a source address in a multicast data pakcet. But in the control-plane they are the target for the path the join takes.

> 
> 
>> 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.
> 
> If concerned about DOS and other security attacks against ASM, then use multicast IPsec

Yes, that protects the application but still uses network resources. Which means, pakets are delivered to all good and bad joiners and then discarded at the endpoints. Pity.

> 
> Here are some comments to Michael's email on Fri, 1 Dec 2023 19:36:43 +0000
> 
>> But, for now, let's discuss interdomain ASM. As you mentioned, you were
>> against deprecating interdomain ASM in 8815 for good reasons. This begs the
>> question whether ASM has been deprecated and what that means.
>> Interdomain ASM hasn't been deprecated even though 8815 recommends
>> doing so. Some protocols are formally deprecated in an RFC, due to security
>> issues for instance,  and the RFCs are then moved to historic. Interdomain
>> ASM has not been formally deprecated. While most of us see the benefits of
>> moving to SSM, and our current lessons learned document is strong on SSM,
>> there are good reasons not to. We should probably mention those reasons as
>> they related to pim history.
> 
> RFC 8815 deprecates ASM for interdomain but not for intradomain
> 
> However, when providing feedback on the draft RFC 8815 I couldn't come up with interdomain ASM examples.  Since then, I've

Well if more than one service provider is willing to share its RP with joiners in another, there is no problem. We do it with DNS but people will argue that is a control-plane function where using another SP's router to launch packets to (when sources are not in the SP with the RP) is a concern.

But I would argue this is theh perfect case to use Bidir-PIM because in Bidir the RP can be a ficitious address and not a real router/server in the network. The address just needs to be routable to their is directionality for upstream packets and joins.

> found interdomain ASM use cases where multiple national militaries operate together and are sharing tactical data using multicast groups - again where many nodes can be sources as well as destinations - so need to be ASM.  These cases typically 

I have implemnented in my lispers.net <http://lispers.net/> LISP overlay implementation to support (*,G) state in the mapping systemm. And this is yet anotehr case where you can use a shared-tree but in this case there is no RP, either fictitious or real, that needs to be planned for. Reason being the overlay solution is not a tree building mechanism.

> operate with IPsec and have similar inter-domain peering like RFC 8313 section 3.2.  So, if RFC 8815 were still in draft, I would argue that ASM shouldn't be deprecated for ASM, but instead have a discussion on when interdomain ASM makes sense and when it doesn't.
> 
> Jim

Cheers,
Dino