Subject: [MBONED] call for adoption of draft-acg-mboned-multicast-models

From: Leonard Giuliano <[email-masked]>
Date: Mon, 4 Dec 2017 11:46:16 -0800

We would like to initiate a call for adoption of the "Deprecating ASM for 
Interdomain Multicast" draft in MBONED: 
https://datatracker.ietf.org/doc/draft-acg-mboned-multicast-models/

Please respond by Dec 18 if you do/do not support adoption of this draft.

If you are listed as a document author, please respond to this email whether or 
not you are aware of any relevant IPR. If you are not listed as an author and 
are aware of any relevant IPR, please respond as well.

-Lenny and Greg

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 4 Dec 2017 20:18:42 +0000

I remain somewhat disturbed by this underlying thinking (Section 7.6):

   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.

Most of the document is fine by me, as is its title, "Deprecating ASM for Interdomain Multicast." The problem is when the wording strays from that interdomain scenario. Specifically, in the quote above, "if an appropriate out-of-band mechanism" is a big "if." Almost like saying, it's not an IETF problem, so we'll pretend it's not a problem. Use SSM, create whatever new and previously unnecessary out-of-band mechanism you might need now, and trust us, this will be better.

There are intra-domain use cases in which ASM is by far the simplest approach, and there are no downsides to it. I'm not sure why the IETF should be making "strong" recommendations against such specific applications of ASM. How about at least remove the word "strong," and remove the "deprecate" in intra-domain cases?

I'll go back to my previous comment. SSM is very much like IP multicast over ATM networks. The model is based on having to create those separate pt-mpt connections, which at the time, were an artifact caused by the ATM way of doing things. At the time, having to accommodate ATM in this way was more or less of a nuisance, especially in intra-domain cases. Yes, it required this extra step of knowing all of the possible sources, in a model that was happily purely leaf-initiated. Now the IETF is expanding that intra-domain nuisance even for Ethernet networks, where it's not needed.

Bert

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Leonard Giuliano
Sent: Monday, December 04, 2017 14:46
To: MBONED WG <[email-masked]>
Subject: [MBONED] call for adoption of draft-acg-mboned-multicast-models

-Lenny and Greg

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: <[email-masked]>
Date: Wed, 13 Dec 2017 08:55:35 +0800 (CST)

Support the adoption of this draft.

Thanks,

Sandy

原始邮件

发件人： <[email-masked]>;
收件人： <[email-masked]>;
日 期 ：2017年12月05日 03:46
主 题 ：[MBONED] call for adoption of draft-acg-mboned-multicast-models

-Lenny and Greg

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 13 Dec 2017 00:52:14 -0800

Inline:

On Mon, Dec 4, 2017 at 12:18 PM, Manfredi, Albert E <
[email-masked]> wrote:

> Most of the document is fine by me, as is its title, "Deprecating ASM for
> Interdomain Multicast." The problem is when the wording strays from that
> interdomain scenario. Specifically, in the quote above, "if an appropriate
> out-of-band mechanism" is a big "if." Almost like saying, it's not an IETF
> problem, so we'll pretend it's not a problem. Use SSM, create whatever new
> and previously unnecessary out-of-band mechanism you might need now, and
> trust us, this will be better.
>

How did the application learn about the group? The port? The codec? No new
mechanism required, just an additional field to your mechanism of choice.

> There are intra-domain use cases in which ASM is by far the simplest
> approach, and there are no downsides to it. I'm not sure why the IETF
> should be making "strong" recommendations against such specific
> applications of ASM. How about at least remove the word "strong," and
> remove the "deprecate" in intra-domain cases?
>

I agree with softening the intra-domain wording.

> I'll go back to my previous comment. SSM is very much like IP multicast
> over ATM networks. The model is based on having to create those separate
> pt-mpt connections, which at the time, were an artifact caused by the ATM
> way of doing things. At the time, having to accommodate ATM in this way was
> more or less of a nuisance, especially in intra-domain cases. Yes, it
> required this extra step of knowing all of the possible sources, in a model
> that was happily purely leaf-initiated. Now the IETF is expanding that
> intra-domain nuisance even for Ethernet networks, where it's not needed.
>

Well, that hurt. ;-) SSM was about simplification when the source was
well-known. Any similarity to ATM is a painful and unintended coincidence.
:)

Greg

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Dec 2017 08:40:28 +0100 (CET)

> Please respond by Dec 18 if you do/do not support adoption of this draft.

As co-author, I support adoption of this draft.

> If you are listed as a document author, please respond to this email whether 
> or not you are aware of any relevant IPR. If you are not listed as an author 
> and are aware of any relevant IPR, please respond as well.

I am not aware of any IPR related to this draft.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Thu, 14 Dec 2017 09:22:07 +0000

> On 14 Dec 2017, at 07:40, Mikael Abrahamsson <[email-masked]> wrote:
> 
>> We would like to initiate a call for adoption of the "Deprecating ASM for Interdomain Multicast" draft in MBONED: https://datatracker.ietf.org/doc/draft-acg-mboned-multicast-models/
>> 

Likewise, though it’s not clear from the very brief IETF 100 minutes whether the draft retains its current structure or is pruned down to focus on the SSM recommendation and inter-domain ASM deprecation.  What was the outcome of that discussion?

>> If you are listed as a document author, please respond to this email whether or not you are aware of any relevant IPR. If you are not listed as an author and are aware of any relevant IPR, please respond as well.
> 

Likewise.

Tim

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 14 Dec 2017 07:45:31 -0800

Likewise, as a coauthor, I am not aware of any IPR.  And I would love to 
see it pruned to focus on the interdomain ASM deprecation/strong SSM 
recommendation.  And some softening of the intradomain verbiage also seems 
reasonable.

-Lenny

On Thu, 14 Dec 2017, Tim Chown wrote:

| >> Please respond by Dec 18 if you do/do not support adoption of this draft.
| 
| > 
| 
| > As co-author, I support adoption of this draft.
| 
| Likewise, though it’s not clear from the very brief IETF 100 minutes 
| whether the draft retains its current structure or is pruned down to 
| focus on the SSM recommendation and inter-domain ASM deprecation.  What 
| was the outcome of that discussion?
| 
| >> If you are listed as a document author, please respond to this email whether or not you are aware of any relevant IPR. If you are not listed as an author and are aware of any relevant IPR, please respond as well.
| 
| > I am not aware of any IPR related to this draft.
| 
| 
| 
| Likewise.
| 
| 
| 
| Tim
|

---

From: Tim Chown <[email-masked]>
Date: Thu, 14 Dec 2017 16:20:00 +0000

> On 14 Dec 2017, at 15:45, Leonard Giuliano <[email-masked]> wrote:
> 

I’d agree with that.

Tim

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Dec 2017 19:10:03 +0100

I didn't respond to the call for adoption because even though i tink 
all the text in the doc is interesting, i still struggle figuring out
what really would be the best thing to make progress here.

Let me bring up 3 points.

1) Do the authors consider a typical walled-garden IPTV deployment between an
ISP and its subscribers to be intradomain or interdomain ? I always think
of it as PIM-SM intradomain because there is no interdomain PIM-SM/MSDP setup.
Just a single ISP with some intradomain PIM-SM setup (maybe anycast RP), and
the subs are all just simple stub-IGMP networks. And i guess ISPs would not
call unicast traffic between their network and their residential subs "interdomain"
either.

If this use case is considered by the authors to be "interdomain" and therefore
target for ASM deprecation, that would make the call for deprecation a lot
more useful to me. But some better definition of what consistitutes
"interdomain" in the doc might then be in order.  

Heck, i would want ASM to be deprecated in this use case however inter/intra-domain
we call it. So if we call this use-case intradomain, then what document do we
need to deprecate ASM for this use case ? This document or another ?

2) As self-satisfying calls for deprecation are for all of us in the "PIM-SM
victim self-help group",the question is really whether its the most important
work to really make SSM successful.

For example: Would it not be more important to close any gaps we have in
the SSM architecture to really make it easy to migrate old apps or
build new apps on SSM only ?

I am reminded a bit how we tried to use all type of randomn tunneling
options for two decades to overcome non-multicast transit until it dawned on us
that we neede dot create a standard for it - AMT.

Maybe we should try to define a standard app-layer source discovery mechnism
as well. For apps where "clients" can send. Not for the simple "natural"
SSM apps (like IPTV).

But even for the natural SSM apps, we have AFAIK not done a good job
describing or standardizing source redundancy schemes. Whats the
standard recommended source to network signaling for SSM anycast source addresses ? 

(and i'd be happy if i overlooked/missed some recent year work/RFC here,
 i won't claim to be on top of all recent work..).

The work on AMT and peering BCP i think is productive towards interdomain
SSM. And there are IMHO some more advanced open SSM questions arising from
that work.

3) But lets talk deprecation: like IPTV, IMHO most intradomain ASM
application should also be moved to SSM because management of RPs
in enterprises is not any easier than in SPs. And Multicast in enterprises
is more and more reduced to business critical apps because of its
(perceived or real) cost of operations (no value in doing multicast unless
the business depends on it is often the conclusion).

a) They are natural SSM candidates (like IPTV).
b) They are more dynamic - require app-layer rendesvous server.
c) They are doing ASM service discovery (like network wide mDNS)
   (yuck yuck yuck yuck).

The only apps i have seen that IMHO are natural ASM are really
only intra-DC eg: distributed apps with a lot of short-term multi-party
group-transactions. And those are best with Bidir-PIM.

Aka: Why stop with "interdomain ASM". I'd go all the way and
discuss whats required to deprecate PIM-SM. (oh wait, we need
a PIM-SSM RFC ;-).

Cheers
    Toerless

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Dec 2017 09:05:11 +0100 (CET)

> ISP and its subscribers to be intradomain or interdomain ? I always think

Good question. For me personally, it's more about the control plane. If 
you need to set up inter-administrative-domain MSDP sessions, then you're 
definitely in the "don't do that" category. If all you have is someone 
"blindly" sending you multicast packets (for instance from an IPTV 
headend) without any control plane connection to them, then I don't think 
it's inter-domain anymore, at least I don't consider it as much of an 
operational problem.

> of it as PIM-SM intradomain because there is no interdomain PIM-SM/MSDP setup.

Exactly.

> Heck, i would want ASM to be deprecated in this use case however 
> inter/intra-domain we call it. So if we call this use-case intradomain, 
> then what document do we need to deprecate ASM for this use case ? This 
> document or another ?

My personal view is that we should strongly advocate towards not using 
ASM, unless ASM is the only way things can be done realistically.

> as well. For apps where "clients" can send. Not for the simple "natural"

Sounds good to me.

> c) They are doing ASM service discovery (like network wide mDNS)

Is there a document somewhere that has examples of things people use ASM 
for? I know of a few examples, but I'm sure there are others I do not know 
about.

> The only apps i have seen that IMHO are natural ASM are really only 
> intra-DC eg: distributed apps with a lot of short-term multi-party 

I am all for a document (I think it should be separate from the currently 
discussed document) that lists types of applications that use multicast, 
and how these could be made to use anything but ASM.

The result from that might also yield some strategies how we could 
implement a discovery mechanism suitable for these applications, that make 
them not require ASM anymore.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 21 Dec 2017 15:01:00 -0800

Hi

I probably support adoption... However, I don't like the title of the
document. I don't mind the deprecation, but the document has a lot of
text explaining different models and guidance. It's much more than
just that deprecation. I prefer the version 00 title.

I would like to know, is the main goal deprecation, as in the title,
or to provide information and guidance about service models? I would
potentially like to see two documents. One with the original title and
scope, and a second document focusing on the deprecation and why.

Stig

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 22 Dec 2017 11:55:32 -0800

Stig- indeed, the doc did start out as a description of the service 
models, but evolved to become a BCP/recommendation doc to more clearly 
give guidance to those outside of the WG what those inside of it always 
believed, mentioned, but never seemed to document: "use SSM bc it does 
everything you need and is vastly simpler and more robust, unless you 
absolutely need something in ASM (and in most cases you won't)".

So the doc does have somewhat of a split personality now.  This was one of 
the questions from the presentation in Singapore- should we remove the 
service model description stuff (and maybe make it a sep doc) to focus on 
the recommendation to use SSM/Deprecate ASM for interdomain?

As I mentioned below, IMO, we should prune it to focus on the 
recommendation as this would provide needed clarity and value.  

As for the descriptions of the service models, if folks believe it can 
provide more info than what's been done in the past (eg, RFCs 5110, 3569), 
I think this could go into a sep doc.

-Lenny

On Thu, 21 Dec 2017, Stig Venaas wrote:

| Hi
| 
| I probably support adoption... However, I don't like the title of the
| document. I don't mind the deprecation, but the document has a lot of
| text explaining different models and guidance. It's much more than
| just that deprecation. I prefer the version 00 title.
| 
| I would like to know, is the main goal deprecation, as in the title,
| or to provide information and guidance about service models? I would
| potentially like to see two documents. One with the original title and
| scope, and a second document focusing on the deprecation and why.
| 
| Stig
| 
| 
| On Thu, Dec 14, 2017 at 8:20 AM, Tim Chown <[email-masked]> wrote:
| >> On 14 Dec 2017, at 15:45, Leonard Giuliano <[email-masked]> wrote:
| >>
| >> Likewise, as a coauthor, I am not aware of any IPR.  And I would love to
| >> see it pruned to focus on the interdomain ASM deprecation/strong SSM
| >> recommendation.  And some softening of the intradomain verbiage also seems
| >> reasonable.
| >
| > I’d agree with that.
| >
| > Tim
| >
| >>
| >> -Lenny
| >>
| >> On Thu, 14 Dec 2017, Tim Chown wrote:
| >>
| >> | >> Please respond by Dec 18 if you do/do not support adoption of this draft.
| >> |
| >> | >
| >> |
| >> | > As co-author, I support adoption of this draft.
| >> |
| >> | Likewise, though it’s not clear from the very brief IETF 100 minutes
| >> | whether the draft retains its current structure or is pruned down to
| >> | focus on the SSM recommendation and inter-domain ASM deprecation.  What
| >> | was the outcome of that discussion?
| >> |
| >> | >> If you are listed as a document author, please respond to this email whether or not you are aware of any relevant IPR. If you are not listed as an author and are aware of any relevant IPR, please respond as well.
| >> |
| >> | > I am not aware of any IPR related to this draft.
| >> |
| >> |
| >> |
| >> | Likewise.
| >> |
| >> |
| >> |
| >> | Tim
| >> |
| >>
| >
| > _______________________________________________
| > MBONED mailing list
| > [email-masked]
| > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=ZVEDb191EVgbzMRQBAzr5IvKS2PEyEovsxKQbjQ9eMw&s=enTfeUn1TmWZuTKlSxO2nyvHN2XIeRPdow525eWKyd8&e=
|