[Planetlab-devel] whitelists and federation

[Larry Peterson]

On 10/5/07, Thierry Parmentelat <thierry.parmentelat at sophia.inria.fr> wrote:
> Larry Peterson wrote:
> > I think this falls out of the "peering policy" work in a nice way.
> > When a site brings up nodes that it wants to allocate to some
> > specific purpose, it says so in it's local policy, when results in
> > PLC knowing what nodes it can advertise to its peers, and
> > which it should not advertise. This is an example of a PLC-level
> > enforcement mechanism.
> >
> As I said, I do not find that this solution quite fits, in this
> particular case at least; if the nodes do not get advertised at all,
> then federation is artificially impedded

Yes, but there will be cases where this is the right thing.

> > Also, rather than a binary "available bit", this allows a fraction of
> > such a node to be assigned to some special slice, but the rest
> > to be made available for wider use. Such a node is advertized at
> > the PLC level, with the policy enforced at the node level, when
> > it is asked to provision a slice. (Well, maybe this means PLC
> > approves the resource attributes associated with the slice, but
> > the point is that our standard attributes work.)
> >
> Now this is more interesting.
> The question however is, where does the node get the policies from ?
> in your example you're kind of cheating: are you suggesting that the
> node will be provided this policy from the site directly ?
> Otherwise, which plc does this policy come from ?
> But it's getting late and I have the hazy feeling that I am missing
> something :-)

This is where I haven't told you enough yet.  In short, each principal
states its local policy: this is true for sites and for PLCs. These policies
are then aggregated, resulting (logically) in a global policy. Finally,
relevant pieces of the policy are"routed" to enforcement points: both
PLCs and end nodes. If that doesn't make sense, I'm afraid you'll need
to wait for the unabridged version (soon now).

Larry

>
> -- Thierry
>
> > Larry
> >
> > On 10/5/07, Reid Moran <rmoran at cs.princeton.edu> wrote:
> >
> >> White lists should find a better way to be implemented for sure!
> >> However, for now I think the right thing for a PLC to do, if something
> >> like white lists comes up, is to filter those nodes from being federated
> >> at that local PLC rather than share everything and rely on the partner
> >> to do the right thing.  This is a research project and various specific
> >> exceptions are made to further testing in some ways and this event has
> >> brought to light how that impacts federation.  This is a good learning
> >> experience and I think for now, filtering the refresh peer call to not
> >> include white listed nodes is the proper solution until we come up with
> >> a better model for dealing with this type of thing is a federated PL.
> >>
> >> -Reid
> >>
> >> Thierry Parmentelat wrote:
> >>
> >>> Larry Peterson wrote:
> >>>
> >>>> On 10/5/07, Thierry Parmentelat <thierry.parmentelat at sophia.inria.fr>
> >>>> wrote:
> >>>>
> >>>>
> >>>>> Larry
> >>>>>
> >>>>> This is great news. I am looking forward to reading more about this
> >>>>> "engine", even if the changes I am describing are still needed in the
> >>>>> short term IMO, unless this new approach is ready to get deployed. The
> >>>>> current model has its known deficiencies, and the road you are showing
> >>>>> will be invaluable in addressing them, but this is no reason for
> >>>>> running
> >>>>> - rather badly - broken code :-)
> >>>>>
> >>>>>
> >>>> Agreed. Tony is also looking at filtering "getnodes" so it doesn't
> >>>> return
> >>>> the white-listed nodes (as a stop-gap).
> >>>>
> >>>>
> >>> I've heard about that.
> >>> To be honest I have also considered the same kind of hack for working
> >>> around not caching the whitelists. I could e.g. chop off whitelisted
> >>> nodes from the list of nodes exposed to the federating plc. But the
> >>> drawback is, TP could for instance not run PLC-native slices on a
> >>> whitelisted node on PLE, which I think is unacceptable.
> >>>
> >>> Now it could also be argued that the whitelist idea, or at least this
> >>> implementation, was a wrong move in the first place; it sounded to me
> >>> that having to hide some nodes away from some callers at the GetNodes
> >>> level was not entirely right, but that's a personal opinion.
> >>> Naturally, I also understand the practical issues and the impact
> >>> another approach would have had.
> >>>
> >>> In a longer term perspective, are we starting to feel the need for
> >>> NodeAttributes, that could provide a more generic data model for
> >>> handling such things as whitelists ?
> >>>
> >>> -- Thierry
> >>>
> >>> _______________________________________________
> >>> Devel mailing list
> >>> Devel at lists.planet-lab.org
> >>> https://lists.planet-lab.org/mailman/listinfo/devel
> >>>
> >> _______________________________________________
> >> Devel mailing list
> >> Devel at lists.planet-lab.org
> >> https://lists.planet-lab.org/mailman/listinfo/devel
> >>
> >>
> >>
> >
> > _______________________________________________
> > Devel mailing list
> > Devel at lists.planet-lab.org
> > https://lists.planet-lab.org/mailman/listinfo/devel
> >
>
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel
>
>