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

Greg Shepherd <gjshep@gmail.com> Wed, 13 December 2017 08:52 UTC

Return-Path: <gjshep@gmail.com>
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 676101270A7 for <mboned@ietfa.amsl.com>; Wed, 13 Dec 2017 00:52:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 GTKyRMrsOxze for <mboned@ietfa.amsl.com>; Wed, 13 Dec 2017 00:52:16 -0800 (PST)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD51120726 for <mboned@ietf.org>; Wed, 13 Dec 2017 00:52:16 -0800 (PST)
Received: by mail-it0-x229.google.com with SMTP id r6so2767264itr.3 for <mboned@ietf.org>; Wed, 13 Dec 2017 00:52:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TYbe2z6k6fR4NXVeEI5WGuntA+xXkpZBKgVVq41Jq8U=; b=ojcAoH7uI1SMdO3FoO8FiuQ8FXix8o4a8ncy9sIeThF8cT+JIHHbFaakroutQI5Non 6YgDru+IiJdQgnAsKS4XEv+WLovUdE1R08rBa4kNL2bjzJfcm+1GoI/SZ7r/CDSR3zAp LXfYIXhyZObo1/iOUyou+kYJJhlGEs3IUo132MxPuzA1wfIiM+V0AFnykjFEuShVYBfA d3r2M2SAtGXx9ykM1ahkY0hCKc/a1eWPOG+A+yJoTko2Rk7buVVteJ5sr2281KSWzzYa E2gdagOfStKvzZUVW5vlhi5y9815REvfKMDwDXS6WIlCdsHih3cZvyPowwjhM1RvVwlY KCPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=TYbe2z6k6fR4NXVeEI5WGuntA+xXkpZBKgVVq41Jq8U=; b=qybLQ5Zk6FhJpoJHo0p1nQVctiyDPMjE4AcCseWVEjPTNS/++e6cOGEcoCe03bZJbo lxpiY03DEB8o/qJYhscGKYEeJBD71W018axxKvfnc0XYPWbFX40/2t/w6hctD4OjhmzB jspF1ro+p9PxfZ3OYHEPO6FMwkMfXwmuWZaiNHHNtfWmyfe38Nfw4ZpnSwE4X+/cDTH6 0Zbkj8N/XK/ulIm4hMkxVZxAP4PpjUusofW3FJakigZ2hlEi0OPVsyryRY5jE+vK8ryl 6IYqQRbR2DfchK59vAPCAWlwAuRStc0ao7a6Opq9vuiUY/7ZTvl5XTiQOdDHKm4RZnVG 7PLQ==
X-Gm-Message-State: AKGB3mKSbkIIVbeWUBT7UKHsW796XWlQ0w66p9AYIEP72VCkmqMPG609 IznR1S8v0GXdzX5IyUhj9BJdxXoESC1vTxNbB0k=
X-Google-Smtp-Source: ACJfBotfSOvJzLV+jFmLdF1Ic+LZgYjG/HGXXSsPFkUS51SPaDtp5e4IL1DBD7ABM0mWRwi8/wst5GxkfSkJgmKDTEg=
X-Received: by 10.36.192.2 with SMTP id u2mr2004305itf.119.1513155135428; Wed, 13 Dec 2017 00:52:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.92.209 with HTTP; Wed, 13 Dec 2017 00:52:14 -0800 (PST)
Reply-To: gjshep@gmail.com
In-Reply-To: <9e110b7703fe4e2db56da32afc16b68e@XCH15-06-11.nw.nos.boeing.com>
References: <alpine.DEB.2.02.1712041144230.20715@svl-jtac-lnx02.juniper.net> <9e110b7703fe4e2db56da32afc16b68e@XCH15-06-11.nw.nos.boeing.com>
From: Greg Shepherd <gjshep@gmail.com>
Date: Wed, 13 Dec 2017 00:52:14 -0800
Message-ID: <CABFReBrgjd8K16kdJEv7PVpF_rU_73Hwm1e10JgbcGqSisxt6g@mail.gmail.com>
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
Cc: Leonard Giuliano <lenny@juniper.net>, MBONED WG <mboned@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c05b8ce565eef056034e283"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/hqp4QifoA--fy_jBu3D6olW6tw4>
Subject: Re: [MBONED] 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, 13 Dec 2017 08:52:18 -0000

Inline:

On Mon, Dec 4, 2017 at 12:18 PM, Manfredi, Albert E <
albert.e.manfredi@boeing.com> wrote:

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

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


> Bert
>
> -----Original Message-----
> From: MBONED [mailto:mboned-bounces@ietf.org] On Behalf Of Leonard
> Giuliano
> Sent: Monday, December 04, 2017 14:46
> To: MBONED WG <mboned@ietf.org>
> Subject: [MBONED] call for adoption of draft-acg-mboned-multicast-models
>
>
> 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
>
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned
>
>
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned
>