Re: [trill] Alissa Cooper's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)

Donald Eastlake <d3e3e3@gmail.com> Wed, 18 January 2017 19:02 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 3BA421294C6; Wed, 18 Jan 2017 11:02:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 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] 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 XVOlq0OjZ0le; Wed, 18 Jan 2017 11:02:28 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 AD66F120725; Wed, 18 Jan 2017 11:02:28 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id j18so19575788ioe.2; Wed, 18 Jan 2017 11:02:28 -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=B5bGZgYANwLHkdGoDzwmpn9KnrfugB0zTBMubfO6yb8=; b=UPpgkvcaogdRD2viuY2v/7dwx1T24WI8G6VBYnPKmmEho5hhjLSqtwL6475yD70dDs JM8lpI7++gEsgqaM1TWJg2L2+/Yfuh+I8a0Iq3Zl+8Y/jBx/v7ueIfjGNt2mINERvxdz o43iVmWgBhSDJ5wFXOzTrBcreSfzZ34efjqkRtvm0Onb9HDm1JkjQ+S3qtNfQmAsm1SO xWEya+xFh/vRnDxswB2T4DPq/9cYWwTLDNVS0ugqjYl/kg42gLNnyksPG6MpYSLfCaNW PJYfEjkC7riACq+O963wcYYjfR1z/fhGLPw9fFqPlEJnc9mbJTM+oVzNlCGsdc9tfQ1D UfIA==
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=B5bGZgYANwLHkdGoDzwmpn9KnrfugB0zTBMubfO6yb8=; b=drDyrVXD5nb2Au2BW05GvnXcVZTs4tfJAzAmo2o7KI9wsrHszhDzPuMEKCNsvuFnDO c6eTpgccaiObz14Jn9SRcda7xaUqrqT8ccK42CKxwdPkqSxZ3SWz3nmDkAnpG1f16fSh FImBZWKlkfTJEWEv0Z23WBxioGpwLgQki0b8iJLCI7UjH716Lj7dU4iapogIV8h/Noq7 m6F86b4uKJIW3V3i40lMAD+i8i2LRvLx/tCyeSAj4Edh0CkJheXkchWwanF8JTEmzolD mJcBGn8oXjsOye80AUHjwx5whQkYK1jNz3DUd+PpWnTGUR66tnllZdkZjp7qVUCwfsb6 F+Bw==
X-Gm-Message-State: AIkVDXKz7q6qiEiC6QiBJ5qAguzt5apvpfr4tZWbYNcrcK42UOXDKka1aBoBjiaWife4krbnGSUji2ziZZ3+jA==
X-Received: by 10.107.141.80 with SMTP id p77mr5126428iod.97.1484766147934; Wed, 18 Jan 2017 11:02:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.41.72 with HTTP; Wed, 18 Jan 2017 11:02:12 -0800 (PST)
In-Reply-To: <148475513653.2001.17665625207200773811.idtracker@ietfa.amsl.com>
References: <148475513653.2001.17665625207200773811.idtracker@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 18 Jan 2017 14:02:12 -0500
Message-ID: <CAF4+nEFwpQAf6d25RooBrXHUO-_vk0zD4zbFb0yu_N54ARJ3qQ@mail.gmail.com>
To: Alissa Cooper <alissa@cooperw.in>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/-4Cqc46_y7zUnJWteF1WXve3WiA>
Cc: "trill-chairs@ietf.org" <trill-chairs@ietf.org>, draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG <iesg@ietf.org>, "shares@ndzh.com" <shares@ndzh.com>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] Alissa Cooper's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
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, 18 Jan 2017 19:02:30 -0000

Hi Alissa,

On Wed, Jan 18, 2017 at 10:58 AM, Alissa Cooper <alissa@cooperw.in> wrote:
>
> Alissa Cooper has entered the following ballot position for
> draft-ietf-trill-directory-assist-mechanisms-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Since this document implies the creation of centralized databases of
> addressing information, I think it would help to call out in Section 6

Yes, although such centralized databases are quite common currently in
terms of data center management and orchestration system databases.

> the need to secure the directory contents themselves, not just against
> abuses of the push or pull services but in general against unauthorized
> access.

OK.

I'm not sure the need to secure directories resident on TRILL switches
is that much different from the need to secure the routing function
and routing data of TRILL switches. But the draft also supports Pull
Directories hosted on end stations and I think something should be
said about end station security in connection with the end station
hosting a directory.

> Also, I recall in prior evaluations of TRILL documents some discussion
> about how TRILL deals with ephemeral MAC addresses and my recollection is
> that they are likely prohibited by policy on TRILL networks. But if there

The payload of a TRILL Data packet looks like an Ethernet frame. TRILL
delivers it to end station(s) based on the destination MAC address
and, by default, learns about MAC reachability by observing the source
MAC address. So, while I would not say ephemeral or frequently
changing MAC addresses are prohibited by "policy", they would reduce
the efficiency of a TRILL campus by frequently obsoleting learned MAC
reachability information.

> is some interaction between ephemeral MAC addresses and the services
> described in this document that would be good for implementors to be
> aware of, those are probably worth mentioning.

Directories need not be complete. If, for example, there were servers
with fixed MACs and clients with mostly ephemeral MACs, I think it
would still be reasonable to have the reachability (edge attachment
point) information for the fixed MACs in a directory. Something about
this could be added to the draft.

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