Hi Alissa, The -12 version of this draft, just posted, has a paragraph about ephemeral MAC addresses in Section 1 and some text about protecting directory information added to Section 6, which is now divided into subsections. This is intended to resolve your comments.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 <(508)%20333-2270> (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] On Thu, Jan 19, 2017 at 9:21 AM, Alissa Cooper <[email protected]> wrote: > > > 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
