Re: feedback for draft-acg-mboned-deprecate-interdomain-asm

Toerless, thanks for your consideration of my suggestions.

My response to  your responses are inline below

Cheers,
Jim Stevens



On Tue, Jul 31, 2018 at 5:29 PM, Toerless Eckert <[email protected]> wrote:

> 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.
>

I understand the difficulty; I think your suggested wording of "if
applicable and feasible to the application developer" is sufficient.

>
> > 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).
>
> I need to check to see if I can provide our MANET Bidir-PIM RP setup
details to the ietf mboned exploder list.



> > 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).
>
I think that that adding the phrase "using PIM-SM" to the end of the
sentence is sufficient.



> > 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
>
> Currently, our users are within a single domain or single over-arching
domain even when they have multiple subdomains, so has not been a problem
for us.

I don't have strong objections to adding Birdir-PIM to this list -
especially if some solution could be added in future - or I'm okay with
leaving the wording as is without Birdir-PIM



> > 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.
>
> I'm okay with leaving this topic of IGMPv3 versus IGMPv2 and ASM using
IGMPv3 out of this document and discussing in a future document.



> Cheers
>     Toerless
>

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned