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

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 21 December 2017 08:05 UTC

Return-Path: <swmike@swm.pp.se>
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 950C5120227 for <mboned@ietfa.amsl.com>; Thu, 21 Dec 2017 00:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 fmVsl_KT2D4I for <mboned@ietfa.amsl.com>; Thu, 21 Dec 2017 00:05:14 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7771200FC for <mboned@ietf.org>; Thu, 21 Dec 2017 00:05:14 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 60AA0AF; Thu, 21 Dec 2017 09:05:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1513843511; bh=nq8sT9ByqmfM/mZCnO8ki1X3h/i0KjSbg78wEztlbsc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=selny9bldF87mDXutakpLGVpXHAJgwVh26dr0FMVC0uhpOIvgc/bqEFKli75xsi+W 8YjdxlazpPYrjOTJWnpcpK+XHter4x4bilkNKLsgvp+96mQwSlrX2a+40xI88oQQoj 6AvxUuQS+iwpWn0WiOsmNCQuZ3l/ytgfGCk/V3kg=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5E6A29F; Thu, 21 Dec 2017 09:05:11 +0100 (CET)
Date: Thu, 21 Dec 2017 09:05:11 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Toerless Eckert <tte@cs.fau.de>
cc: Leonard Giuliano <lenny@juniper.net>, MBONED WG <mboned@ietf.org>
In-Reply-To: <20171220181003.GB19446@faui40p.informatik.uni-erlangen.de>
Message-ID: <alpine.DEB.2.20.1712210854310.8884@uplift.swm.pp.se>
References: <alpine.DEB.2.02.1712041144230.20715@svl-jtac-lnx02.juniper.net> <20171220181003.GB19446@faui40p.informatik.uni-erlangen.de>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/nctaUwwEJFQHGd3k2aC-KTYc7yk>
Subject: Re: [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: Thu, 21 Dec 2017 08:05:16 -0000

On Wed, 20 Dec 2017, Toerless Eckert wrote:

> 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

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.

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

Sounds good to me.

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

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

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.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se