Evolution to SSM... how... (was: Re: call for adoption of draft-acg-mboned-multicast-models)

Toerless Eckert <[email protected]>
Newsgroups gmane.ietf.mboned
Message-ID <[email protected]>
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

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.