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

["James A. (Jim) Stevens" <[e-mail]>]

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