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

Tim Chown <Tim.Chown@jisc.ac.uk> Mon, 26 February 2018 10:52 UTC

Return-Path: <tim.chown@jisc.ac.uk>
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 21591126DCA for <mboned@ietfa.amsl.com>; Mon, 26 Feb 2018 02:52:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.311
X-Spam-Level:
X-Spam-Status: No, score=-5.311 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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 vXNIrCTpvA-3 for <mboned@ietfa.amsl.com>; Mon, 26 Feb 2018 02:52:14 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59720126CB6 for <mboned@ietf.org>; Mon, 26 Feb 2018 02:52:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1519642332; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=hwG83+eaft46Pi7bpGC1hc8u5ZZDJLrquKSxk+X/hU8=; b=Rldwna4/lVD+uBztA2lxsEmjw+GF3KrZk/e47ZXjeduNKQus/ImYQynfYO2eTS3ZfCamwBVSIe4Ckb/qtPYtcpRDIr2ASiQmjGPiLZ5msV+iu004/6E1ss+52ELMHN5mJiswY27rW3NxfQjqm603mH18BLzBWMaNULqE1e6az2Q=
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0118.outbound.protection.outlook.com [213.199.154.118]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-46-6JjSeyrTNPOzUiwmvQjFrg-1; Mon, 26 Feb 2018 10:52:07 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0679.eurprd07.prod.outlook.com (10.160.5.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.548.6; Mon, 26 Feb 2018 10:52:05 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9d1c:b9f:44ab:d6cd]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9d1c:b9f:44ab:d6cd%6]) with mapi id 15.20.0548.011; Mon, 26 Feb 2018 10:52:05 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: Mikael Abrahamsson <swmike@swm.pp.se>, Toerless Eckert <tte@cs.fau.de>, MBONED WG <mboned@ietf.org>
Thread-Topic: [MBONED] Evolution to SSM... how... (was: Re: call for adoption of draft-acg-mboned-multicast-models)
Thread-Index: AQHTeb3TDcTK5HSAVUqRpwU1b7aScKNNcV2AgGl60wA=
Date: Mon, 26 Feb 2018 10:52:05 +0000
Message-ID: <1DB210C1-C194-46D3-8229-4A2B74A0C0FD@jisc.ac.uk>
References: <alpine.DEB.2.02.1712041144230.20715@svl-jtac-lnx02.juniper.net> <20171220181003.GB19446@faui40p.informatik.uni-erlangen.de> <alpine.DEB.2.20.1712210854310.8884@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.20.1712210854310.8884@uplift.swm.pp.se>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.5.20)
x-originating-ip: [2001:a88:d510:1101:7ceb:a14d:8946:f28c]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB0679; 7:rkJwk0pOA2sPIvMEVdZ7BsigWvusguVNdXQXJOHYsm/dywnFkVArZz9ZhxEqQRgwr8PEOw9xKM9RjY+s7Ev5GDtaWuKIpVZvNrt9FxWoDqQBxBebm5YAXR8SJFzvHkxhYGJdcTJ3/5vczL3Av3oup3YEnE6hZC70u4E4E3k5oNZI4zszf29AM4A2WDZS2kWS/yaMM1KaiIi22ANTbYueVneSp/NbiO6UXgWanMEgczOcT2YpWp7GVAcD91XGw0nb; 20:iCX4NlfCk8yMOgqFe+XPUSfSxGh0QFJgRJvEGJ/g0XkWdKFWGFbhsXIcK7vIqc/gd7+kcpjr/w97hDF8WAtY8wS8fJ99PdGFlSICt6Z+e9eDSKTNJVRnAZ/Yw6oGWG963fUCbqf8uYVYsfAhN6OaqnGcfeyye4b1rT1DXmPZGsA=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: b47bc532-29fb-42c5-2b2a-08d57d06f9e6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:AM3PR07MB0679;
x-ms-traffictypediagnostic: AM3PR07MB0679:
x-microsoft-antispam-prvs: <AM3PR07MB0679659F077A74F969C9CFB5D6C10@AM3PR07MB0679.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278428928389397);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231220)(944501187)(52105095)(93006095)(93001095)(6041288)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:AM3PR07MB0679; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB0679;
x-forefront-prvs: 05954A7C45
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(39850400004)(39380400002)(396003)(252514010)(57704003)(189003)(199004)(51444003)(6486002)(786003)(6506007)(5250100002)(53936002)(74482002)(68736007)(102836004)(25786009)(36756003)(53546011)(110136005)(97736004)(76176011)(6436002)(2950100002)(42882006)(105586002)(186003)(3660700001)(316002)(99286004)(106356001)(6116002)(6246003)(72206003)(50226002)(7736002)(14454004)(6346003)(33656002)(5660300001)(3280700002)(2900100001)(2906002)(57306001)(229853002)(478600001)(86362001)(82746002)(305945005)(83716003)(966005)(8936002)(8676002)(81156014)(6512007)(6306002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0679; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-microsoft-antispam-message-info: sdGGkft6N2tK+Vjbc2uKTY6cczOhjHcZCHnH6n1Y5Zx4uaOE+xofvwjjqwVkgXiareEBvbNIaK5aTShlMzM40Sylt4hMdRo39y7hGOB1+3bRZ+0z0j96qWmavERc4sXu4O+xaWNI9YKA7gRvO4nwHUwzJ7gLcSsOnPF7s3Hx244=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <B5DA2C948016844685BF46318D0789D4@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: b47bc532-29fb-42c5-2b2a-08d57d06f9e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2018 10:52:05.8359 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0679
X-MC-Unique: 6JjSeyrTNPOzUiwmvQjFrg-1
Content-Type: text/plain; charset="WINDOWS-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/TQI1UzfmAd8tje2PNG8uIngpVss>
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: Mon, 26 Feb 2018 10:52:17 -0000

Hi,

We have one week to hot the London draft cutoff - comments in-line...

> On 21 Dec 2017, at 08:05, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> 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.

I'd agree.

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

Indeed, and its that latter complexity that I think is the main thrust of what we're targeting with the deprecation of inter-domain. 

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

I think previous discussion said 'no' to a total ASM deprecation.  And I think that remains the pragmatic option.  Sites can still use MSDP, or whatever, internally.  Instead, we focus on inter-domain deprecation and give guidance for how you might migrate to SSM within a domain, or an application domain.

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

That could be a recommendation from a 'how to move to ssm' document.

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

So what I plan to do is carve out the 'deprecate inter-domain ASM' text from the multicast models draft, with the same authors (at least for now).

But then what is the other document?  Is it 

a) the remainder of the multicast models draft, and tips for how to run SSM wherever you can, plus identifing missing pieces that need to be standardised

b) just a document describing how applications - local or broader scope - can be migrated towards SSM, leaving out much of what is left in the multicast models draft ?

c) something else?

Tim

> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
> 
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned
>