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

From: Tim Chown <[email-masked]>
Date: Fri, 10 Nov 2017 10:01:12 +0000

Hi Bert,

Many thanks for the comments; responses in-line...

> On 31 Oct 2017, at 00:45, Manfredi, Albert E <[email-masked]> wrote:
> 
> 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.

Mikael is presenting the draft in the WG meeting in Singapore; we’ll raise the question there as to the wording of the general recommendation(s), i.e., on deprecating interdomain ASM, and promoting use of SSM.

The wording is currently "this document recommends that ASM is not used for interdomain scenarios, and the use of SSM is strongly recommended for all multicast scenarios”; what wording would you use?

I suspect some might like 2119 language to be used, and that NOT RECOMMENDED and RECOMMENDED are used above.

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

The draft says words to the effect of “use of ASM within an organisation is a matter for that organisation”.

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

I think that’s what the draft currently says, but while also recommending SSM in general, esp. for new applications.

The Rationale section 

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

Well, there are IETF documents that use similar language for IPv6 (vs IPv4).  But this text could be removed.

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

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.

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

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

Tim

> 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, 
>  
> 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]
> Subject: I-D Action: draft-acg-mboned-multicast-models-02.txt
> Date: 30 October 2017 at 23:20:18 GMT
> To: <[email-masked]>
> Reply-To: [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: Fri, 10 Nov 2017 20:09:48 +0000

-----Original Message-----
From: Tim Chown [mailto:[email-masked]] 

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

   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

---

From: Tim Chown <[email-masked]>
Date: Mon, 13 Nov 2017 13:37:50 +0000

Hi Bert,

> On 10 Nov 2017, at 20:09, Manfredi, Albert E <[email-masked]> wrote:
> 

OK, we’ll get a feel for the room in the WG session this week, and take your comment into account.  I won’t be there in person, but Mikael will present the draft.

> 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 backgr…

So an interesting question is how this is done at present for multi-party SSM-based applications.

The “any cast” source you described previously is interesting. The draft could capture such use cases, and perhaps describe how such use cases could be met in a non-ASM environment (if possible).

>   the intradomain scenario.

OK, thanks, we’ll see what other feedback we get.  I don’t object to the above, the question is how firm the consensus is to push SSM intradomain.

> 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 co…

I agree, but it’s pushed the issue to the application layer, so it’s no longer a concern for the network operator, directly.  The recent thrust for this draft was the I2 proposal to deprecate ASM on their backbone to reduce network operation complexity.  But someone else pays...

Tim

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 13 Nov 2017 11:24:14 -0800

On Mon, 13 Nov 2017, Tim Chown wrote:

| > Hi Tim, thanks. Yes, I'd prefer only to reduce the strength of the recommendation against intradomain ASM. Very simple changes to the text.
| 
| OK, we’ll get a feel for the room in the WG session this week, and take your comment into account.  I won’t be there in person, but Mikael will present the draft.

I think it's important that we don't water down the recommendation so much 
that the message gets lost.  My pref would be to strongly recommend SSM 
(and thus, no-ASM) for interdomain and provide some gentle nudging for SSM 
in intradomain, while recognizing that what one does in his own network is 
his own business.  We can't really mandate/decree, but it is our 
role/responsibility to provide guidance and recommendations based on our 
expertise.

There certainly are use cases for ASM (eg, many-to-many device discovery).  
So we can mention this in the text.  But the fact is that the vast 
majority of mcast apps (interdomain and intradomain) can handle source 
discovery in the app layer.  As an operational WG tasked with providing 
guidance on issues of mcast operation, I think it's very appropriate to 
mention this.  I'm not quite following the concern that the recommendation 
gets in the hands of the "wrong people"- not sure who those wrong people 
are?  IMO, the bigger problem we've always had is that these 
recommendations never got in the hands of the "right people" bc we've 
never come out with clear guidance.  What seems so obvious to all of us in 
the WG never got messaged out well to those outside of this WG.  
Hopefully, we can fix that here.

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

Agree that moving complexity doesn't eliminate it.  But it's also quite 
true that the application layer provide much greater flexibility for 
innovation, experimentation and scale when it comes to the task of source 
discovery.