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

[Donald Eastlake <[e-mail]>]

Hi Alissa,

On Wed, Jan 18, 2017 at 10:58 AM, Alissa Cooper <[e-mail]> 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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]