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

The terms "deprecating" and "not deploying" say different things, where the former is stronger than the latter. Does the lessons-learned document want to make a stronger statement or just be compatible with RFC 8815?

And notice the verb "recommending" keeps it light as well. I guess to avoid mandates.

Dino

> On Dec 6, 2023, at 11:56 AM, Michael McBride <michael.mcbride@futurewei.com> wrote:
> 
>> Correct, RFC8815 deprecates Interdomain ASM
> 
> But does it? It certainly recommends doing so. This is what I've been trying to get at. 8815 recommends not deploying interdomain ASM. But is that deprecation? The protocols involved certainly are not deprecated. Maybe it's just semantics. When I think of deprecation I think of formal deprecation like TLS 1.0/1 deprecation in 8996.
> 
> So to be accurate in our future drafts, like lessons-learned, I would rather say RFC8815 recommends deprecating Interdomain ASM.
> 
> mike
> 
> 
> 
> -----Original Message-----
> From: pim <pim-bounces@ietf.org> On Behalf Of Leonard Giuliano
> Sent: Tuesday, December 5, 2023 4:52 PM
> To: Stevens, Jim A Collins <James.A.Stevens=40collins.com@dmarc.ietf.org>
> Cc: pim@ietf.org
> Subject: Re: [pim] draft-ietf-pim-multicast-lessons-learned-02 & BIDIR-PIM
> 
> 
> On Fri, 1 Dec 2023, Stevens, Jim A Collins wrote:
> 
> <snipped>
> |
> | 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 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 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.
> 
> Correct, RFC8815 deprecates Interdomain ASM.  The doc is very clear about not applying to Intradomain, in large part to Jim's input.  And indeed, section 4.8 could certainly cover the scenario listed above.
> 
> That said, it's worth remembering that the WG's do not have a police force to enforce BCPs and that these recommendations are just that.  It's also worth remembering the purpose of RFC8815 in the first place.  Namely, to give clear direction to the rest of the industry, and in particular to app devs, to focus on SSM.  Two+ decades after IGMPv3/SSM were specified, we still have many devices like set-top boxes that do not support IGMPv3, and operators had nothing to point to for guidance to those folks.  Does there exist some apps out there that might be better suited to ASM? Certainly, but a solid consensus agreed those were exceptions that were not applicable to interdomain deployments and not worth the cost of supporting from a network ops perspective.  We must always balance tradeoffs, and the motivation behind RFC8815 was that a lack of clear direction from the community on the preferred service model going forward was hindering mcast deployment.  We could have riddled the doc wit
> h exceptions, but we felt that would have watered it down and made it meaningless.  So we drew a firm line at interdomain ASM deprecation.
> 
> On another note, thanks @Jim for the observation in this draft about "PIM"
> and how Bidir doesn't fit so neatly into the SPT-RPT discussion with regard to PIM-SM.  I know I am guilty of lazily referring to "PIM" when I really mean "PIM-SM."
> 
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim
> 
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim