Re: MBONED Digest, Vol 138, Issue 3
"James A. (Jim) Stevens" <[email protected]>
| Newsgroups | gmane.ietf.mboned |
|---|---|
| Message-ID | <CAH8Jh6BmYFnor7h1DAS_0VvG3VHBHrVm=iFFe=_vAyj+0QvX9w@mail.gmail.com> |
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 _______________________________________________ MBONED mailing list [email protected] https://www.ietf.org/mailman/listinfo/mboned