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

Toerless Eckert <tte@cs.fau.de> Wed, 20 December 2017 18:10 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48902124C27 for <mboned@ietfa.amsl.com>; Wed, 20 Dec 2017 10:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.96
X-Spam-Level:
X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRUogY7A9gxT for <mboned@ietfa.amsl.com>; Wed, 20 Dec 2017 10:10:08 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0251241FC for <mboned@ietf.org>; Wed, 20 Dec 2017 10:10:08 -0800 (PST)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0DCD158C4B7; Wed, 20 Dec 2017 19:10:04 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id EEA4DB0D4F4; Wed, 20 Dec 2017 19:10:03 +0100 (CET)
Date: Wed, 20 Dec 2017 19:10:03 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Leonard Giuliano <lenny@juniper.net>
Cc: MBONED WG <mboned@ietf.org>
Message-ID: <20171220181003.GB19446@faui40p.informatik.uni-erlangen.de>
References: <alpine.DEB.2.02.1712041144230.20715@svl-jtac-lnx02.juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1712041144230.20715@svl-jtac-lnx02.juniper.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/tVoK77tqOZelSqI1UgjCbKsfRWs>
Subject: [MBONED] Evolution to SSM... how... (was: Re: call for adoption of draft-acg-mboned-multicast-models)
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Dec 2017 18:10:11 -0000

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