Subject: Re: [MBONED] MBONED Digest, Vol 138, Issue 3

From: "James A. (Jim) Stevens" <[email-masked]>
Date: Sat, 7 Jul 2018 22:06:08 -0500

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

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 in MANET networks
without the significant overhead of PIM-SM.  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."

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?

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.

5. The second paragarph 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.

Jim Stevens

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 1 Aug 2018 00:29:46 +0200

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

Right.

> 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

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

> recommendation does not apply to the use of ASM between domains using

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

> ...." or else (b) delete the parenthetical comment.

Ack.

> 5. The second paragaph of section 4.3 states "The recommendation to use
> triggering IGMPv3/MLDv2 messages to signal use of SSM.

> *In addition

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

---

From: "James A. (Jim) Stevens" <[email-masked]>
Date: Tue, 31 Jul 2018 19:06:35 -0500

Toerless, thanks for your consideration of my suggestions.

My response to  your responses are inline below

Cheers,
Jim Stevens

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

> I need to check to see if I can provide our MANET Bidir-PIM RP setup
details to the ietf mboned exploder list.

> vendor implementations, but it is true for our IETF Bidir-PIM RFC. Hope
I think that that adding the phrase "using PIM-SM" to the end of the
sentence is sufficient.

> 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

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