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

[Leonard Giuliano <[e-mail]>]

By leaving source discovery up the app layer ;)

Whatever RPs, FHRs and MSDP speakers can do, the app layer (+DNS) can do 
much better.  NB, I would think Jim's MANET/Bidir use case is vastly 
different than Internet based expanding ring search.


On Wed, 6 Dec 2023, Dino Farinacci wrote:

| 
| So how does an app do an Internet based expanding ring search on top of multicast routing?
| 
| Dino
| 
| > On Dec 6, 2023, at 3:13 PM, Leonard Giuliano <[e-mail]> wrote:
| >
| >
| > I think the definition of "deprecate" meaning to "discourage the use of"
| > here is applicable (https://urldefense.com/v3/__https://www.merriam-webster.com/dictionary/deprecate__;!!NEt6yMaO-gk!B2z7C4NQiSC8i1TwH2MOcO5pn0GtucTnlkCmP3Tffk_XympN714vNK2W8gSK7QzxWNlkycwRDP8A7VKi$ ).
| > And a BCP is basically a formal recommendation.  So I think these things
| > all mean the same thing.  But I think the Abstract for RFC8815 articulates
| > the intention of this doc pretty clearly:
| >
| > Abstract
| >
| > This document recommends deprecation of the use of Any-Source Multicast
| > (ASM) for interdomain multicast. It recommends the use of Source-Specific
| > Multicast (SSM) for interdomain multicast applications and recommends that
| > hosts and routers in these deployments fully support SSM. The
| > recommendations in this document do not preclude the continued use of ASM
| > within a single organization or domain and are especially easy to adopt in
| > existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM).
| >
| >
| > On Wed, 6 Dec 2023, Dino Farinacci wrote:
| >
| > |
| > | 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 <[e-mail]> 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 <[e-mail]> On Behalf Of Leonard Giuliano
| > | > Sent: Tuesday, December 5, 2023 4:52 PM
| > | > To: Stevens, Jim A Collins <James.A.Stevens=[e-mail]>
| > | > Cc: [e-mail]
| > | > 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
| > | > [e-mail]
| > | > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!Fvdjxb83v2LdetnnWv3ifyy0XcJm1TO2V9A8G-mNucjx6t2cJ5m661EdX6f_7la7H06c6XD4IjPiOkgq$
| > | >
| > | > _______________________________________________
| > | > pim mailing list
| > | > [e-mail]
| > | > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!Fvdjxb83v2LdetnnWv3ifyy0XcJm1TO2V9A8G-mNucjx6t2cJ5m661EdX6f_7la7H06c6XD4IjPiOkgq$
| > |
| > |
| 
|