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

Alissa Cooper <alissa@cooperw.in> Wed, 07 March 2018 15:23 UTC

Return-Path: <alissa@cooperw.in>
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 5797A12778D; Wed, 7 Mar 2018 07:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=cooperw.in header.b=LbuSMZlk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Sc1QV3g+
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 70tLHdAH9iIm; Wed, 7 Mar 2018 07:23:52 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB3F1241FC; Wed, 7 Mar 2018 07:23:52 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6367C20964; Wed, 7 Mar 2018 10:23:51 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 07 Mar 2018 10:23:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=XwfQpcHBjmhB7Ej68VPt7dCCFDimk6OuzLe2haBi2Z8=; b=LbuSMZlk GyLdYvJ2sU89jmx337YGYMd+IgBSp4tP1Vt+qMpZHCBkxVmHcKRK6fbelRtTmIa4 bfw8TOuFQIs9akutLGPKRlFjXczOLc4mp64je//YCUdp40ACynPRYt0iMh9cgaYk g4yU0jaAugHv9P2OoLnnlB18+LuwXBOoPWlc7yN6BmvEqj0+eRagN+o2tcS4IEBY e5i44inZX9sM+VrS0ZhXOh1Dl/WOFsb9HQ+HEuv0t3Gnc4+r4NvEKL3NxoyzY63m oDM/JB8CR172LX06n/vbKq3ssZbHfVIGEqeNbHAQ3ie8xO3bNhRX4HWLEtr6P/+D b+sOLrigY3RALQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=XwfQpcHBjmhB7Ej68VPt7dCCFDimk 6OuzLe2haBi2Z8=; b=Sc1QV3g+cDSFBsdbKSOjlkm/QcAqn+SKXjKBD2XLzthui zPL2NUWBxQRNvMgU+lMo7Ho3p56lmhkFFacMhIvlv/o4qe2BQTBK6p+LsX1VXv4p /X79zD3NbM+QU20vkHlLAi0nVjOC+iiGYDt6n8FXoaAyrfuuYEBMTY1YN7aJBMoi TY+NgpL2Nw2lFT6rBiHRxoQHT9VxeJnwr/0fCiRRJseijzP8tfpSxSoA3jihcAKz 3qHFX3u4ez14SCWXy7FZWNREd4tKSsQovkFm2gu3kiNJGLhD4kmANJOxDrBkGpae TJ8CukfagOvMl3CxHYr/LddYznS3iPc8WJhdzpJuw==
X-ME-Sender: <xms:BwSgWhm8PnL6rLZfJXXHg-q_XtX1gCfyHd3l1fL_Mt8ejtkKYIocWQ>
Received: from [10.19.234.245] (unknown [128.107.241.170]) by mail.messagingengine.com (Postfix) with ESMTPA id 59BBD7E5CA; Wed, 7 Mar 2018 10:23:49 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_843E637D-0C48-46E2-B2F2-A5944E8193C9"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <CAF4+nEETihY95U_W4gbZUoJ8h=yg7i1miHoOwTdF11NnP-9k3A@mail.gmail.com>
Date: Wed, 7 Mar 2018 10:23:47 -0500
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>
Message-Id: <D6D46F37-FD60-43EA-9258-7204A4DF4525@cooperw.in>
References: <152036811638.28279.11284897771242295868.idtracker@ietfa.amsl.com> <CAF4+nEETihY95U_W4gbZUoJ8h=yg7i1miHoOwTdF11NnP-9k3A@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/SBBnqRzEpAZBdI8Zdm5oYla1DCA>
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 15:23:54 -0000

> 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 <mailto: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 <mailto:d3e3e3@gmail.com>