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

[Donald Eastlake <[e-mail]>]

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   [phone] <(508)%20333-2270> (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

On Thu, Jan 19, 2017 at 9:21 AM, Alissa Cooper <[e-mail]> wrote:

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