Re: [MBONED] feedback for draft-acg-mboned-deprecate-interdomain-asm

[Toerless Eckert <[e-mail]>]

Sorry for the delau

Thanks a lot James for the input,

before whipping up a rev with fixes, let me run what i think
would be appropriate fixes by you.

On Sat, Jul 07, 2018 at 10:06:08PM -0500, James A. (Jim) Stevens wrote:
> In response to Leonard Giuliano's
> Fri, 6 Jul 2018 13:53:11 -0700 [MBONED] call for adoption of
> draft-acg-mboned-deprecate-interdomain-asm
> 
> I still support the purpose of the draft ""Deprecating ASM for Interdomain
> Multicast" , but recommend the following changes:
> 
> 1.  With respect to the following sentence in the last paragraph of section
> 1:  "Therefore, this document recommends making applications support SSM,
> even when they are initially meant to be just used intradomain."  Please
> deleted the work "making" since SSM is not appropriate for some intradomain
> many-to-many multicast applications and it would be inappropriate to make
> such an application use SSM..

Right. So, what i had in mind was the type of applications that already has
static or dynamic signalling of multicast groups to receivers and senders that
can be well-known. In that case it would be often quite easy to add the
source address(es) of the senders to the signaling to the receivers. FOr
example, this has been done often in SDP in SIP or the like.

Unfortunately, its hard to write this down well, so i was hoping that
a term like "if applicable and feasible to the application developer"
would be sufficient. And then i'd like to detail the idea above in a separate
indepednent draft we suggested (when/how to write apps for SSM). We could
even add that as an upcoming draft and non-normative point to it from the
above text to at least put a stake in the ground that we need that.

Any better text suggestions of course welcome.

> Also, this is consistent with the last
> sentence of the previous paragraph "Indeed, there are application contexts
> for which ASM is currently still widely considered well-suited within a
> single domain."

Right.

> 2. We use Bidrectional PIM (BIDIR-PIM) [RFC 5015], instead of PIM-SM for
> our many-to-many ASM multicast because it scales to hundreds or even
> thousands of sources and destinations  coming and going

Definitely.

> in MANET networks without the significant overhead of PIM-SM.

Hah! So how do you set up Bidir-PIM RP in MANET environments if i may ask
(we designed/brainstormed a lot of options, but i think three was never
 an IETF recommendation).

> Thus I think that the first
> sentence of Section 3.2, "A significant benefit of SSM is its reduced
> complexity through eliminating the network-based source discovery required
> in ASM." is incorrect. I recommend that the sentence be edited to "....
> required in ASM using PIM-SM."

That is definitely true, and we should add the notion that this does
not apply to Bidir-PI because it does not have any signaling or state chances
for source discovery. (WHich actually is not true if you look into bad
vendor implementations, but it is true for our IETF Bidir-PIM RFC. Hope that's
enough).

> 3. Section 4.1 states that the recommendation to deprecate use of ASM for
> interdomain multicast ".... applies to the use of ASM between domains
> where either
> MSDP (IPv4) or Embedded-RP (IPv6) is used for sharing knowledge of remote
> sources (MSDP) or RPs (Embedded-RP)."  Does this mean that the
> recommendation does not apply to the use of ASM between domains using
> BIDIR-PIM?

I specifically didn't add Bidir-PIM because i thought it would not make
sense to argue this point without any more persons (beside me) knowing
and having opinions about Bidir-PIM.

yes, unless you object, i would suggest to add Bidir-PIM to this suggestion.
A lot of initial SP PIM-SM offering provided PIM-SM RPs to their IP multicast
Internet and/or L3VPN customers. But its really a nightmare to
troubleshoot PIM-SM into another domain because you don't own the RP
but its in another domain.

For Bidir-PIM the tree building troubleshooting is less an issue than the
third party dependency problems. Domain 1 and 2 want to share a Bidir-Group,
but RP is in domain 3 and thats dead.  And setting up interdomain prioritycast-RP
policies... I just have not seen actual deployment cases operationally
happy with that approach so we could recommend it from IETF.

There is IMHO actually a pretty good interdomain Bidir-PIM solution,
which happens to be just extending Bidir-PIM in multiple domains
via SSM across the Internet between the RPs, so if Interdomain Bidir-PIM ASM
is of interest, thats what i would suggest to put into a protocol standard.
There's a patent on it though:

https://patents.google.com/patent/US7936702

> 4. Section 4.3 states "There is a wide range of applications today that
> only support ASM (mostly for historic reasons), ..."  Since there are some
> many-to-many multicast applications that cannot efficiently run SSM (as
> discussed in Section 1), I recommend either (a) changing the test to "...
> (mostly for historic reasons but some for many-to-many scalability reasons)
> ...." or else (b) delete the parenthetical comment.

Ack.

> 5. The second paragaph of section 4.3 states "The recommendation to use
> SSM for interdomain multicast means that applications should use SSM, and
> operate correctly in an SSM   environment, triggering IGMPv3/MLDv2 messages
> to signal use of SSM."  How about something like the following instead?  ' The
> recommendation to use SSM for interdomain multicast means that applications
> should,* if possible*, use SSM, and operate correctly in an SSM environment,
> triggering IGMPv3/MLDv2 messages to signal use of SSM.

> *In addition
> applications that use ASM instead should use IGMPv3/MLDv2 triggering
> messages to signal use of ASM to ensure that a routers on a link do not
> have to fall back to IGMPv2 (or even IGMPv1) and thus become unable to
> support SSM.*' Note that the topic of raising standards track level of
> IGMPv3/MLDv2 looks like it is on the agenda for the upcoming MBONED agenda
> in Montreal.

Right. So this additional text you're suggesting is one that i very much
support, i just don't think it does not belong into this document - we're already
stretching the documents payload by discussing intradomain SSM, but we can argue
that i think well.

So a sentence like you propose would get into an informational mboned doc
in conjunction with fixing up the standard track levels of IGMP/MLD
(IGMPv2//MLDv1 downgrade/obsolete), IGMPv3/MLDv2 upgrade or create revision
and upgrade (full standard).

Given how fast IETF is this will take a while, so lets hopefully first finish up
this hopefully simple recommendation re. interdomain to help SPs.

Cheers
    Toerless