Re: [trill] Alissa Cooper's Discuss on draft-ietf-trill-vendor-channel-00: (with DISCUSS and COMMENT)

Donald Eastlake <d3e3e3@gmail.com> Wed, 07 March 2018 17:12 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8506812711D; Wed, 7 Mar 2018 09:12:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 WS47pw7OBr6b; Wed, 7 Mar 2018 09:12:56 -0800 (PST)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 3B450126D45; Wed, 7 Mar 2018 09:12:56 -0800 (PST)
Received: by mail-io0-x235.google.com with SMTP id v6so3824207iog.7; Wed, 07 Mar 2018 09:12:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sw/xtuNAbbLMYqJnB4P4qwEH3WInIx3o8cvU6iX4H5c=; b=cryZ0Kh7rV+8GW6VWbLtgOf5rOjqxxkxPvVMvzXZXVnCXw3KUd7P8fZQt8YEn/nMA5 kHPOrj5I0uIfwu/cE8RyeGRmqk8CPfI4rzUGqthAAGvfWbtS58I6cNpMdjs+gadqddWz DJde709vg6gm8RGCdhDjY/PZsa2tb8sQYPy1vLUA5NjOEWIURqzCvcm7fXHQ2rNDWYuN gMEB3byJIetcYPo8SlKCL5S4cabJ41IIubeSy1eezrbaUnXFy5RgBpQXpT2L9+9B6dRy 285QLfHR7fwVFq98ZfxyCajtqAMssK8KntdPsc1hwm335l1FnLKzdWnH414d1xRmNyUI C/kA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sw/xtuNAbbLMYqJnB4P4qwEH3WInIx3o8cvU6iX4H5c=; b=VVC/fxuFJEbCd0TDCWEvUIATMWXFO+Ebx+ofkPi1BfclOyanwaqGxCwCfCIl9E7a5e SwkdcLwqa8Sw1vyzsci/yHUzzjyGHCB8MrA8eFOkPblFPPUhLGkrvtlTR6wkQQJ+/STN L/812xGVqRzdqMDzYOctJwgNk165WNVF9y6hBqs5In4bJclcqn6mm3E/B6tbigiAnyGg gN+sCeftdq4DTS0+S29o9RpE18bbf0dltMK0lwzQ1Ccgx1zVE5vIYlyJS+rQYMXgN4yP 2kLwL+gwut3if9ZYubT2dwY+awAlfhOYluYZxO7btLMuqfM2SS5n51kh0eEiuZgIZ+jw ZUDQ==
X-Gm-Message-State: AElRT7G4O4vfgDD0ErxNvuFP6wkCkHnC785ZCTaLBiKUNky4daGgeTk4 WUAQaVXzVApuHXwkcoQuLUbX4GJaNkPELyOiVCo=
X-Google-Smtp-Source: AG47ELsB4vybgQrdc0/9gU+r3+d1KuMR21YMNh55WNKDrKQk3EDfMHbxOFbUZIyh064fddiQPjLmTUzqaTupwfeAj7w=
X-Received: by 10.107.3.37 with SMTP id 37mr28617560iod.66.1520442775349; Wed, 07 Mar 2018 09:12:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.58.193 with HTTP; Wed, 7 Mar 2018 09:12:39 -0800 (PST)
In-Reply-To: <D6D46F37-FD60-43EA-9258-7204A4DF4525@cooperw.in>
References: <152036811638.28279.11284897771242295868.idtracker@ietfa.amsl.com> <CAF4+nEETihY95U_W4gbZUoJ8h=yg7i1miHoOwTdF11NnP-9k3A@mail.gmail.com> <D6D46F37-FD60-43EA-9258-7204A4DF4525@cooperw.in>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 7 Mar 2018 12:12:39 -0500
Message-ID: <CAF4+nEH2ikcjHyHsp-UWc2bsA0j2O8=J8wKCtRnZVkMPSqqXBg@mail.gmail.com>
To: Alissa Cooper <alissa@cooperw.in>
Cc: IESG <iesg@ietf.org>, draft-ietf-trill-vendor-channel@ietf.org, Susan Hares <shares@ndzh.com>, trill-chairs@ietf.org, trill IETF mailing list <trill@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/CRocUqtCgipPdWzz0vN5Z8eHc_U>
Subject: Re: [trill] Alissa Cooper's Discuss on draft-ietf-trill-vendor-channel-00: (with DISCUSS and COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2018 17:12:58 -0000

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Wed, Mar 7, 2018 at 10:23 AM, Alissa Cooper <alissa@cooperw.in> wrote:
>
> On Mar 6, 2018, at 11:11 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
>
> Hi Alissa,
>
> On Tue, Mar 6, 2018 at 3:28 PM, Alissa Cooper <alissa@cooperw.in> wrote:
>
> Alissa Cooper has entered the following ballot position for
> draft-ietf-trill-vendor-channel-00: Discuss
>
> ...
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I'm having trouble understanding what function this specification serves
> given
> that the RBridge Channel Protocol registry has a range reserved already for
> private use and that the document doesn't specify any requirements around
> vendor-specific protocol semantics. So any implementation of this that needs
> to
> interoperate with another implementation will need to do so according to
> some
> specification generated by the vendor, and that specification can select a
> code
> point from the private use range. What does allocating a single code point
> for
> all such vendor-specific protocols achieve, aside from specifying a
> structured
> way of conveying the OUI/CID (which seems superfluous anyway for multiple
> implementations from a single vendor interoperating with each other)?
>
>
> What if two TRILL campuses using the same private code point for
> incompatible purposes are accidentally interconnected?
>
> What if someone wants to use TRILL switches from two different vendors
> each of which uses the same private code point for incompatible
> purposes? Say one vendor makes highly flexible/desirable edge TRILL
> switches while the other make particularly cost effective core TRILL
> switches or particularly nifty Level 1 / Level 2 border TRILL
> switches, or whatever.
>
> "private" code points seem pretty flakey compared with the more robust
> mechanism in this draft.
>
> Maybe this document should also depredate the use of private code points.
>
>
> Right, both of those examples make it sound like the purpose of having this
> document specify a code point is because the existing private use range is
> problematic. Your first example seems to directly contradict the guidance in
> RFC 7178 about the use of the private range, so if that is a real concern
> and it outweighs the utility of having the private range for private network
> use, then it seems like deprecation of the private range might make sense.
>
> The second example I see is the compelling use case for this. I will clear.
>
> Thanks,
> Alissa
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I agree with the Gen-ART reviewer that the text in the Acknowledgements
> section
> is not appropriate. See RFC 7322.
>
>
> OK.
>
> Thanks,
> Donald
> ===============================
> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> d3e3e3@gmail.com
>
>