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

[Alissa Cooper <[e-mail]>]

> On Jan 18, 2017, at 2:02 PM, Donald Eastlake <[e-mail]> wrote:
> 
> 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.

Sounds good.

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

I think that would be helpful.

Thanks,
Alissa

> 
> Thanks,
> Donald
> ===============================
> Donald E. Eastlake 3rd   [phone] (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> [e-mail]