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. > 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 [email protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
