> On Jan 18, 2017, at 2:02 PM, Donald Eastlake <[email protected]> wrote: > > Hi Alissa, > > On Wed, Jan 18, 2017 at 10:58 AM, Alissa Cooper <[email protected]> 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 +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
