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

From: Tim Chown <[email-masked]>
Date: Mon, 30 Oct 2017 23:23:14 +0000

Hi,

This -02 update on the earlier -01 version today includes some minor comments from two people, and some minor edits and typo corrections.

Hopefully this version can help provoke further discussion in Singapore on what we mean by deprecating inter domain multicast, alongside a strong recommendation to use SSM in general.

Tim

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-acg-mboned-multicast-models-02.txt
Date: 30 October 2017 at 23:20:18 GMT
To: <[email-masked]<mailto:[email-masked]>>
Reply-To: [email-masked]<mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

       Title           : Deprecating ASM for Interdomain Multicast
       Authors         : Mikael Abrahamsson
                         Tim Chown
                         Lenny Giuliano
Filename        : draft-acg-mboned-multicast-models-02.txt
Pages           : 15
Date            : 2017-10-30

Abstract:
  This document provides a high-level overview of more commonly used
  multicast service models, principally the Any-Source Multicast (ASM)
  and Source-Specific Multicast (SSM) models, and discusses the
  applicability of the models to certain scenarios.  As a result, this
  document recommends that ASM is not used for interdomain scenarios,
  and the use of SSM is strongly recommended for all multicast
  scenarios.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-acg-mboned-multicast-models/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-acg-mboned-multicast-models-02
https://datatracker.ietf.org/doc/html/draft-acg-mboned-multicast-models-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-acg-mboned-multicast-models-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 31 Oct 2017 00:45:22 +0000

While I can fully appreciate why in interdomain multicast PIM-SSM is much easier to deal with that PIM-SM, and that therefore in interdomain multicast it makes sense to deprecate ASM, I don't think we should go too far with this. There are uses of multicast that specifically want to avoid having the destinations know the source(s), which is often exactly why multicast is used!

So I do not think the IETF should strongly recommend against ASM, in general. This kind of strong recommendation gets in the hands of the "wrong people," and then the job at hand becomes that much more difficult.

With respect to 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.
   Further, it also strongly recommends the use of SSM for all multicast
   scenarios, be they run inter or intradomain.

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.

For interdomain multicast, more manual schemes, such as proxy IGMP, can be used if necessary, especially when security is an issue. We want to avoid any chance of some unknown multicast entering a domain. The downside of SSM will depend on how multicast is used. So for example, in Section 7.3:

   However, it is strongly recommended that sites using ASM internally
   conduct an audit of the multicast applications used, and begin
   planning a migration to using SSM instead wherever possible.

No, honestly, this is none of the IETF's business? Everything depends on use case. In a control system scenario, ASM may well be used specifically because knowing the source is what one wants to avoid. A bit like using anycast. Sometimes, it's one of the main reasons to use multicast. For instance, many hosts need the information simultaneously, and the source depends on modes of operation, and is likely to change. 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.

In short, my preference would be to avoid string blanket recommendations, against ASM, within a single domain.

Bert

From: MBONED [mailto:[email-masked]] On Behalf Of Tim Chown
Sent: Monday, October 30, 2017 19:23
To: MBONED WG <[email-masked]>
Subject: [MBONED] Fwd: I-D Action: draft-acg-mboned-multicast-models-02.txt

Hi,

Tim

Begin forwarded message:

Abstract:

[email-masked]<mailto:[email-masked]>