Re: [MBONED] I-D Action: draft-acg-mboned-multicast-models-02.txt

["Manfredi, Albert E" <[e-mail]>]

-----Original Message-----
From: Tim Chown [mailto:[e-mail]] 

>> I think that in practice, interdomain multicast is now being discouraged
>> for security reasons. Conversely, ASM, within a single domain remains very
>> useful. That’s why I’d be uncomfortable with a blanket condemnation of ASM.
>
> I think that’s what the draft currently says, but while also recommending
> SSM in general, esp. for new applications.
>
> The Rationale section

Hi Tim, thanks. Yes, I'd prefer only to reduce the strength of the recommendation against intradomain ASM. Very simple changes to the text.

>> Everything depends on use case. In a control system scenario, ASM may well
>> ... Or, also frequently, multicast is used for status messages from many
>> sources, some or all of which have redundant interfaces. So having every host
>> configured to know all the possible sources, and join all of the possible
>> multicast groups, becomes a huge pain. Hardly “simpler” than ASM.
>
> Well, the point is that source discovery is pushed from the network layer to a
> higher layer, simplifying network state, and putting the responsibility on the
> applications to communicate about or discover appropriate sources.

I agree that source discovery has been pushed to higher layers, but I'm also concerned about complication being added at those upper layers! My point is that it's preferable to avoid all the background chatter that would have to occur, in some multicast scenarios such as the one described above, for every host in the multicast group to keep track the source(s) that might be relevant at any given time. This could become really laborious and unnecessary, whether it's done dynamically, or ahead of time, as a static configuration requirement.

Enforcing SSM only is like doing IP multicast over ATM or any other circuit-switched system. You have to go through the chore of setting up pt-mpt SVCs before you can use multicast, which implies knowledge of every potential source. The approach removes one really appealing aspect of the leaf join model possible when using frame switching schemes like Ethernet. I get that for interdomain use, it's a way simpler approach, but it would be a shame for everything to have to be done that way, always.

> We could add some text along the lines you’ve written above to section 7.3.  Care to draft a paragraph?

I'd start by removing entirely, or at least softening, the last sentence of Section 7.

7.  Recommendations on ASM and SSM deployment

   This document recommends that the use of interdomain ASM is
   deprecated, i.e., only SSM is to be used for interdomain multicast.
   Intradomain multicast may still benefit from ASM, however security
   considerations may potentially make intradomain SSM preferable.

And then in Section 7.3, just a minor change, and remove the last sentence:

7.3.  Intradomain ASM

   The use of ASM within a single multicast domain, such as an
   enterprise or campus, is relatively common today. Such sites may
   configure an RP for the site, and may choose to use Anycast-RP or MSDP
   for RP resilience. Alternatively, such sites may deploy multicast
   routing algorithms that do not require any RP, within the domain.
   Regardless, this document does not preclude continued use of ASM in
   the intradomain scenario.

Some other wording, in Sections 7.5 and 7.6, could also be softened. For instance, in 7.6, it says:

   Thus, in theory, it should be possible to port ASM-only applications
   to be able to run using SSM, if an appropriate out-of-band mechanism
   can be chosen to convey the participant source addresses.

True enough. Point being, having to create this other "out of band mechanism" becomes an extra complication imposed by an SSM-only regime. In no way can this be called simplification. Moving the complexity up the protocol ladder does not mean the complexity has been eliminated. It's much like IP multicast over ATM, where now something extra has to be programmed, to set up the multiple necessary circuits.

Bert