clearinghouses (or not)

[Larry Peterson]

We've recently been evaluating our approach to geniwrapper, and
I thought there might be value in getting input from the broader
community.

Our geniwrapper module currently includes an aggregate manager (AM)
that exports the slice interface -- there is (will be) an AM for PlanetLab,
an AM for PlanetLab-Europe, an AM for PlanetLab-Japan, an AM for
VINI, an AM for M-Lab, and so on.

We then have a Slice Manager  (SM) that is configured to know about
a set of Aggregates. It currently runs as a server that happens to be
co-located with the PlanetLab AM. A researcher, using his or her favorite
interface (we currently support a Unix-command line program called
SFI -- Slice Facility Interface) contacts the SM to create/control a slice.
The SM, in turn, contacts one or more AMs carry out the requested
operation. In a nutshell, the SM implements "deals with a slice that
spans multiple aggregates" functionality.

On the one hand, this SM is sort of like the GPO's Clearinghouse -- one
stop shopping for all your slice needs. On the other hand, it has always
been our expectation that there will be multiple SMs, that in the limit,
each user is free to create his or her own private SM. As long as they
have the credentials expected by a given AM, they are free to ask it to
create a slice on their behalf.

As we gain experience with the implementation, we are more and more
coming to realize that there is little value in the shared (server-side) SM.
That each user is better off running the SM-like functionality on his or
her desktop. Each Aggregate announces and enforces its own peering
policy, where the user queries the Registry to learn what Aggregates are
available. The user is free to modify the SM (we assume plenty of open
source SMs are available), and MOST IMPORTANTLY, we remove the
burden of creating a one-size-fits-all SM (and a one-size-fits-all rspec
that describes to that SM exactly what the user wants).

One consequence of having client-side code know about multiple AMs
is that this moves us away from a model where a Clearinghouse
processes credentials on our behalf -- the AMs need to support the full
credential-based authorization mechanism. (I believe this is the right
thing to do in any case, but once you get the Clearinghouse out of the
loop, I think you have to go down this path.)

Anyone care to comment on the general issue of these competing
strategies:

   User manages multiple Aggregates (SM functionality runs on client
   and user requests go directly to the aggregates)

versus

   Clearinghouse manages multiple Aggregates (SM functionality runs
   on server with all user requested funneled through the SM)

Larry

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Robert P Ricci]

Thus spake Larry Peterson on Thu, Apr 16, 2009 at 11:06:43AM -0400:

> Anyone care to comment on the general issue of these competing
> strategies:
>
>    User manages multiple Aggregates (SM functionality runs on client
>    and user requests go directly to the aggregates)
>
> versus
>
>    Clearinghouse manages multiple Aggregates (SM functionality runs
>    on server with all user requested funneled through the SM)

We've been going with the former - the Flash client I've used for demos
at the last two GECs is contacting each AM, with the clearinghouse
merely telling the client where to find AMs. This page describes how it
works today:
    http://www.protogeni.net/trac/protogeni/wiki/SliceCreation

Let me add that I think it is highly likely that there are some SMs that
are run, not on user desktops, but as managed services used by many
clients. Keeping them separate from the clearinghouse is still a good
idea, I think.

> and MOST IMPORTANTLY, we remove the
> burden of creating a one-size-fits-all SM (and a one-size-fits-all rspec
> that describes to that SM exactly what the user wants).

Totally agree - particularly with the RSpec, I've always believed the
story we talked about some time ago that the RSpec is something of a
"machine language", that are about describing resources, not experiments
- and thus it is entirely appropriate for an SM to export some higher
level topology/experiment description language to users (like, say, and
NS file :), and this gets "compiled" in some way to RSpec to request the
resources necessary to run the experiment. (Of course, if the
higher-level language is describing more than just resources, not all of
it will end up in RSpecs)

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Larry Peterson]

I think we're roughly on the same page, but a point of
clarification on this last issue. Even when there's an SM
between the user and the set of aggregates, we also
believe in the machine language model for the rspec.
The only difference is whether the rspec is defined for
a single aggregate or for a set of aggregates.

The SM very broadly defined (i.e., to include layers of
functionality beyond the slice interface) might very well
add capabilities beyond this "machine language" but at
that point I wouldn't call it an rspec any more (just to keep
terminology clear).

>
>> and MOST IMPORTANTLY, we remove the
>> burden of creating a one-size-fits-all SM (and a one-size-fits-all rspec
>> that describes to that SM exactly what the user wants).
>
> Totally agree - particularly with the RSpec, I've always believed the
> story we talked about some time ago that the RSpec is something of a
> "machine language", that are about describing resources, not experiments
> - and thus it is entirely appropriate for an SM to export some higher
> level topology/experiment description language to users (like, say, and
> NS file :), and this gets "compiled" in some way to RSpec to request the
> resources necessary to run the experiment. (Of course, if the
> higher-level language is describing more than just resources, not all of
> it will end up in RSpecs)
>
> --
> /-----------------------------------------------------------
> | Robert P Ricci <ricci@...> | <ricci@...>
> | Research Associate, University of Utah Flux Group
> | www.flux.utah.edu | www.emulab.net
> \-----------------------------------------------------------
>

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[David Irwin-3]

> Anyone care to comment on the general issue of these competing
> strategies:
>
>   User manages multiple Aggregates (SM functionality runs on client
>   and user requests go directly to the aggregates)
>
> versus
>
>   Clearinghouse manages multiple Aggregates (SM functionality runs
>   on server with all user requested funneled through the SM)

Orca doesn't really view these strategies as necessarily competing,
since it effectively separates "management" into two functions:
allocation and control.   So using your words:

User **controls** (resources from) multiple Aggregates (SM
functionality runs on the client and user **control** requests go
directly to the aggregates)

Clearinghouse **allocates** (resources from) multiple Aggregates (SM
functionality runs on the server with all user **allocation** requests
funneled through the SM)

So the SM functionality that does control resides with the user, while
the SM functionality that does allocation resides with the
Clearinghouse.

That said, we often compose users, clearinghouses, and AMs together to
produce similar divisions of function as you propose for your SM.  To
do the first approach, we have each aggregate manager run its own
personal clearinghouse, so it incorporates all the Clearinghouse
authorization functions (this is how we often run Orca in practice).
To do the second approach,  a single Clearinghouse allocates resources
from multiple AMs (this is our approach in Cluster D) that the user
then controls.   In both cases, we assume some persistent server runs
under the auspices of the user (whether on the desktop or a remote
server), so it can receive asynchronous callbacks/notifications from
the Clearinghouse and/or AM about its resources.

So from an architectural standpoint, I view this as maybe a false
choice between two extremes in a spectrum of possibilities.  However,
from an implementation standpoint, I agree with Rob, in that your
first choice is probably best.  Despite our focus on Clearinghouses
managing multiple AMs, this was a first step in our development and
remains in practice a useful way to organize our system (especially
when coordinated allocation of resources across aggregates is not
necessary).

-David

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Larry Peterson]

I accept your distinction between controls and allocates, but
I disagree with how you apply them. Ultimately, the aggregates
make allocation decisions, not the the SM. It makes no difference
whether the client talks directly to an aggregate (initially to request
resources and later to control the resources it was allocated) or
funnels those allocation-requests/control-requests through an
intermediate SM (which is really serving an aggregation function...
to overload that term).

Larry

On Thu, Apr 16, 2009 at 1:46 PM, David Irwin <irwin@...> wrote:

>> Anyone care to comment on the general issue of these competing
>> strategies:
>>
>>   User manages multiple Aggregates (SM functionality runs on client
>>   and user requests go directly to the aggregates)
>>
>> versus
>>
>>   Clearinghouse manages multiple Aggregates (SM functionality runs
>>   on server with all user requested funneled through the SM)
>
> Orca doesn't really view these strategies as necessarily competing,
> since it effectively separates "management" into two functions:
> allocation and control.   So using your words:
>
> User **controls** (resources from) multiple Aggregates (SM
> functionality runs on the client and user **control** requests go
> directly to the aggregates)
>
> Clearinghouse **allocates** (resources from) multiple Aggregates (SM
> functionality runs on the server with all user **allocation** requests
> funneled through the SM)
>
> So the SM functionality that does control resides with the user, while
> the SM functionality that does allocation resides with the
> Clearinghouse.
>
> That said, we often compose users, clearinghouses, and AMs together to
> produce similar divisions of function as you propose for your SM.  To
> do the first approach, we have each aggregate manager run its own
> personal clearinghouse, so it incorporates all the Clearinghouse
> authorization functions (this is how we often run Orca in practice).
> To do the second approach,  a single Clearinghouse allocates resources
> from multiple AMs (this is our approach in Cluster D) that the user
> then controls.   In both cases, we assume some persistent server runs
> under the auspices of the user (whether on the desktop or a remote
> server), so it can receive asynchronous callbacks/notifications from
> the Clearinghouse and/or AM about its resources.
>
> So from an architectural standpoint, I view this as maybe a false
> choice between two extremes in a spectrum of possibilities.  However,
> from an implementation standpoint, I agree with Rob, in that your
> first choice is probably best.  Despite our focus on Clearinghouses
> managing multiple AMs, this was a first step in our development and
> remains in practice a useful way to organize our system (especially
> when coordinated allocation of resources across aggregates is not
> necessary).
>
> -David
>

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Robert P Ricci]

Thus spake Larry Peterson on Thu, Apr 16, 2009 at 01:29:37PM -0400:
> I think we're roughly on the same page, but a point of
> clarification on this last issue. Even when there's an SM
> between the user and the set of aggregates, we also
> believe in the machine language model for the rspec.
> The only difference is whether the rspec is defined for
> a single aggregate or for a set of aggregates.

In our case, each aggregate is advertised using a separate RSpec, and
when tickets are requested, one hands a separate request RSpec to each
AM. However, the RSpecs can have "external references" to describe how
aggregates and slices are connected to each other. In the current
implementation, these are pretty simple (tunnels that can have endpoints
in different aggregates), and we're working on making them more
sophisticated.

> The SM very broadly defined (i.e., to include layers of
> functionality beyond the slice interface) might very well
> add capabilities beyond this "machine language" but at
> that point I wouldn't call it an rspec any more (just to keep
> terminology clear).

I agree, I wouldn't call it an RSpec at that point either.

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[David Irwin-3]

> I disagree with how you apply them. Ultimately, the aggregates
> make allocation decisions, not the the SM. It makes no difference
> whether the client talks directly to an aggregate (initially to request
> resources and later to control the resources it was allocated) or
> funnels those allocation-requests/control-requests through an
> intermediate SM (which is really serving an aggregation function...
> to overload that term).

I disagree with this.  It does matter, since in the former case the
Clearinghouse cannot control allocation decisions, and in the latter
case it can.   I am assuming that your SM serves some Clearinghouse
function.  I also partially disagree with the assertion that only
aggregates make allocation decisions.

In Orca, AMs delegate partial control over allocation decisions to
Clearinghouses.  So, while AMs may have the final say about who gets
resources and when, when they delegate some of this power to a
Clearinghouse we assume that they are trustworthy (e.g., they aren't
lying to the Clearinghouse; if they are they get punished).  In this
case the user goes through the Clearinghouse for allocation decisions
(e.g., requests tickets), and then redeems tickets at an AM (e.g., to
control resources through an API exposed by the AM).  So requests here
do not go directly to the AM.

-David

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Larry Peterson]

If you believe in a centralized clearinghouse making allocation
decisions, then yes, you need a clearinghouse. If you believe
the root/source of those decisions reside with the aggregates
(and for me, each aggregate likely has a different "owner"), then
the most a clearinghouse can do is aggregate tickets for
redistribution (and the least useful thing it can do is re-route
requests to sets of aggregates).

Larry

On Thu, Apr 16, 2009 at 2:04 PM, David Irwin <irwin@...> wrote:

>> I disagree with how you apply them. Ultimately, the aggregates
>> make allocation decisions, not the the SM. It makes no difference
>> whether the client talks directly to an aggregate (initially to request
>> resources and later to control the resources it was allocated) or
>> funnels those allocation-requests/control-requests through an
>> intermediate SM (which is really serving an aggregation function...
>> to overload that term).
>
> I disagree with this.  It does matter, since in the former case the
> Clearinghouse cannot control allocation decisions, and in the latter
> case it can.   I am assuming that your SM serves some Clearinghouse
> function.  I also partially disagree with the assertion that only
> aggregates make allocation decisions.
>
> In Orca, AMs delegate partial control over allocation decisions to
> Clearinghouses.  So, while AMs may have the final say about who gets
> resources and when, when they delegate some of this power to a
> Clearinghouse we assume that they are trustworthy (e.g., they aren't
> lying to the Clearinghouse; if they are they get punished).  In this
> case the user goes through the Clearinghouse for allocation decisions
> (e.g., requests tickets), and then redeems tickets at an AM (e.g., to
> control resources through an API exposed by the AM).  So requests here
> do not go directly to the AM.
>
> -David
>

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Larry Peterson]

Sure, you can always have a "clearinghouse broker" that
manages credentials so the AM doesn't have to...

So we have a set of functionality that can be bundled in
a clearinghouse (or not). They include (at least):

1) Credential manager (so aggregates don't have do deal
    with credentials);

2) Resource manger (collects tickets from aggregates and
    redistributes to users based on some allocation policy);

3) Aggregate aggregator (or virtual aggregate that "hides"
    multiple aggregates behind a unified front-end); and

4) A slice manager (that offers users some nicer abstraction
    than the "machine language" provided by the slice interface
    and rspecs).

The geniwrapper implementation really only does (3), although
our arm is being twisted to do (1) as well. We don't do (2) -- each
individual aggregate makes resource allocation decisions on its
own behalf -- and we push (4) to the client front-end (currently a
set of Unix command line tools).

My original posting observed that practical issues suggest (3)
and (4) can be bundled and located on the client's desktop; and
that if you do this, (1) is orphaned (and personally, I don't see
why it's a big deal for an AM to decode and check a credential).

Larry

On Thu, Apr 16, 2009 at 2:06 PM, Schwab, Stephen
<Stephen.Schwab@...> wrote:

> Hi Larry,
> This is a very useful (and clear) message, so thank you for sending it.
>
> I think you may have painted too sharp of a contrast between doing
> things one-way-or-the-other.
>
> For example, the user's SM may sign some request and bundle with that
> request all the necessarily credentials and attributes to entail
> authorization of that request at an AM.  But that doesn't mean there
> can't be a "clearinghouse-like broker" in the path.  So the request
> would flow from:
>
> SM --> Clearinghouse broker --> AM.
>
> What would the Clearinghouse broker do?  It might check the request
> itself, and then add an "endorsement" attribute to it, before forwarding
> it on to the AM.  Nothing in the architecture restricts (or requires)
> this sort of thing -- but it would afford a place for "centralized
> policy" to be applied.
>
> Of course, the policy could be bypassed: if the AM wants to service
> requests that don't have a clearinghouse endorsement attribute, that is
> the AM's business. (And so the GENI environment would not be limited to
> one sort of AM that respected one centralized Clearinghouse policy.)
>
> I don't think there is much additional complexity in supporting this
> approach.  Essentially a clearinghouse would just interpose, acting as a
> proxy w.r.t. the AM interface in this situation.
>
> --Steve
>
> -----Original Message-----
> From: control-wg-bounces@... [mailto:control-wg-bounces@...]
> On Behalf Of Larry Peterson
> Sent: Thursday, April 16, 2009 11:07 AM
> To: control-wg@...
> Subject: [cwg] clearinghouses (or not)
>
> We've recently been evaluating our approach to geniwrapper, and
> I thought there might be value in getting input from the broader
> community.
>
> Our geniwrapper module currently includes an aggregate manager (AM)
> that exports the slice interface -- there is (will be) an AM for
> PlanetLab,
> an AM for PlanetLab-Europe, an AM for PlanetLab-Japan, an AM for
> VINI, an AM for M-Lab, and so on.
>
> We then have a Slice Manager  (SM) that is configured to know about
> a set of Aggregates. It currently runs as a server that happens to be
> co-located with the PlanetLab AM. A researcher, using his or her
> favorite
> interface (we currently support a Unix-command line program called
> SFI -- Slice Facility Interface) contacts the SM to create/control a
> slice.
> The SM, in turn, contacts one or more AMs carry out the requested
> operation. In a nutshell, the SM implements "deals with a slice that
> spans multiple aggregates" functionality.
>
> On the one hand, this SM is sort of like the GPO's Clearinghouse -- one
> stop shopping for all your slice needs. On the other hand, it has always
> been our expectation that there will be multiple SMs, that in the limit,
> each user is free to create his or her own private SM. As long as they
> have the credentials expected by a given AM, they are free to ask it to
> create a slice on their behalf.
>
> As we gain experience with the implementation, we are more and more
> coming to realize that there is little value in the shared (server-side)
> SM.
> That each user is better off running the SM-like functionality on his or
> her desktop. Each Aggregate announces and enforces its own peering
> policy, where the user queries the Registry to learn what Aggregates are
> available. The user is free to modify the SM (we assume plenty of open
> source SMs are available), and MOST IMPORTANTLY, we remove the
> burden of creating a one-size-fits-all SM (and a one-size-fits-all rspec
> that describes to that SM exactly what the user wants).
>
> One consequence of having client-side code know about multiple AMs
> is that this moves us away from a model where a Clearinghouse
> processes credentials on our behalf -- the AMs need to support the full
> credential-based authorization mechanism. (I believe this is the right
> thing to do in any case, but once you get the Clearinghouse out of the
> loop, I think you have to go down this path.)
>
> Anyone care to comment on the general issue of these competing
> strategies:
>
>   User manages multiple Aggregates (SM functionality runs on client
>   and user requests go directly to the aggregates)
>
> versus
>
>   Clearinghouse manages multiple Aggregates (SM functionality runs
>   on server with all user requested funneled through the SM)
>
> Larry
>
> _______________________________________________
> control-wg mailing list
> control-wg@...
> http://lists.geni.net/mailman/listinfo/control-wg
>

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[David Irwin-3]

> My original posting observed that practical issues suggest (3)
> and (4) can be bundled and located on the client's desktop; and
> that if you do this, (1) is orphaned (and personally, I don't see
> why it's a big deal for an AM to decode and check a credential).

I agree with this.  This question was raised in our Cluster D meeting
at the last GEC.  If the Clearinghouse does not serve in role (2) as
the Resource Manager, then what is the value of it only serving in
role (1) as the Credential manager?  If you abandon (1), the value of
the Clearinghouse is unclear to me.

-David

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[David Irwin-3]

Typo:  If you abandon (2), the value of the Clearinghouse is unclear to me.

-David

On Thu, Apr 16, 2009 at 3:05 PM, David Irwin <irwin@...> wrote:

>> My original posting observed that practical issues suggest (3)
>> and (4) can be bundled and located on the client's desktop; and
>> that if you do this, (1) is orphaned (and personally, I don't see
>> why it's a big deal for an AM to decode and check a credential).
>
> I agree with this.  This question was raised in our Cluster D meeting
> at the last GEC.  If the Clearinghouse does not serve in role (2) as
> the Resource Manager, then what is the value of it only serving in
> role (1) as the Credential manager?  If you abandon (1), the value of
> the Clearinghouse is unclear to me.
>
> -David
>

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Robert P Ricci]

I think the two things our clearinghouse does are not in Larry's list,
so let me add two more:

 (5) Help resource providers and resource users find each other, by
     hosting registries of AMs and users (for example, our simple
     resource discovery has the client contact the CH to get a list of
     AMs)
 (6) Act as a trust anchor - in the federation we have running, every
     federate establishes direct trust with only one party, the CH,
     which then distributes signing certs, CRLs, etc. to all members of
     the federation

     http://www.protogeni.net/trac/protogeni/wiki/ClearingHouseDesc

We don't really do any of 1,2,3 or 4 from the original list.

Thus spake David Irwin on Thu, Apr 16, 2009 at 03:05:58PM -0400:

> Typo:  If you abandon (2), the value of the Clearinghouse is unclear to me.
>
> -David
>
> On Thu, Apr 16, 2009 at 3:05 PM, David Irwin <irwin@...> wrote:
> >> My original posting observed that practical issues suggest (3)
> >> and (4) can be bundled and located on the client's desktop; and
> >> that if you do this, (1) is orphaned (and personally, I don't see
> >> why it's a big deal for an AM to decode and check a credential).
> >
> > I agree with this.  This question was raised in our Cluster D meeting
> > at the last GEC.  If the Clearinghouse does not serve in role (2) as
> > the Resource Manager, then what is the value of it only serving in
> > role (1) as the Credential manager?  If you abandon (1), the value of
> > the Clearinghouse is unclear to me.
> >
> > -David
> >
>
> _______________________________________________
> control-wg mailing list
> control-wg@...
> http://lists.geni.net/mailman/listinfo/control-wg

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Larry Peterson]

Yes, that's additional functionality that can be bundled,
but to complete the story about not bundling...

Registries are clearly a separate function (so much so
that we've called them out in the architecture), so they
obviously can stand on their own.

As for trust anchor, I guess that's bundled too, but there
are other ways of making that information (trusted root)
known without a full-blown clearinghouse.

Larry

On Thu, Apr 16, 2009 at 3:33 PM, Robert P Ricci <ricci@...> wrote:

> I think the two things our clearinghouse does are not in Larry's list,
> so let me add two more:
>
>  (5) Help resource providers and resource users find each other, by
>     hosting registries of AMs and users (for example, our simple
>     resource discovery has the client contact the CH to get a list of
>     AMs)
>  (6) Act as a trust anchor - in the federation we have running, every
>     federate establishes direct trust with only one party, the CH,
>     which then distributes signing certs, CRLs, etc. to all members of
>     the federation
>
>     http://www.protogeni.net/trac/protogeni/wiki/ClearingHouseDesc
>
> We don't really do any of 1,2,3 or 4 from the original list.
>
> Thus spake David Irwin on Thu, Apr 16, 2009 at 03:05:58PM -0400:
>> Typo:  If you abandon (2), the value of the Clearinghouse is unclear to me.
>>
>> -David
>>
>> On Thu, Apr 16, 2009 at 3:05 PM, David Irwin <irwin@...> wrote:
>> >> My original posting observed that practical issues suggest (3)
>> >> and (4) can be bundled and located on the client's desktop; and
>> >> that if you do this, (1) is orphaned (and personally, I don't see
>> >> why it's a big deal for an AM to decode and check a credential).
>> >
>> > I agree with this.  This question was raised in our Cluster D meeting
>> > at the last GEC.  If the Clearinghouse does not serve in role (2) as
>> > the Resource Manager, then what is the value of it only serving in
>> > role (1) as the Credential manager?  If you abandon (1), the value of
>> > the Clearinghouse is unclear to me.
>> >
>> > -David
>> >
>>
>> _______________________________________________
>> control-wg mailing list
>> control-wg@...
>> http://lists.geni.net/mailman/listinfo/control-wg
>
> --
> /-----------------------------------------------------------
> | Robert P Ricci <ricci@...> | <ricci@...>
> | Research Associate, University of Utah Flux Group
> | www.flux.utah.edu | www.emulab.net
> \-----------------------------------------------------------
>

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Robert P Ricci]

Thus spake Larry Peterson on Thu, Apr 16, 2009 at 03:40:02PM -0400:
> Registries are clearly a separate function (so much so
> that we've called them out in the architecture), so they
> obviously can stand on their own.
>
> As for trust anchor, I guess that's bundled too, but there
> are other ways of making that information (trusted root)
> known without a full-blown clearinghouse.

And to make it clear, our clearinghouse is pretty simple - it's more or
less a thin wrapper around some database tables.

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[David Irwin-3]

Fair enough.  To be clear, Orca's Clearinghouse serves in roles (1),
(2), (5), and (6), as defined.  Roles (3) and (4) are served by User
experiment tools.

-David

On Thu, Apr 16, 2009 at 3:33 PM, Robert P Ricci <ricci@...> wrote:

> I think the two things our clearinghouse does are not in Larry's list,
> so let me add two more:
>
>  (5) Help resource providers and resource users find each other, by
>     hosting registries of AMs and users (for example, our simple
>     resource discovery has the client contact the CH to get a list of
>     AMs)
>  (6) Act as a trust anchor - in the federation we have running, every
>     federate establishes direct trust with only one party, the CH,
>     which then distributes signing certs, CRLs, etc. to all members of
>     the federation
>
>     http://www.protogeni.net/trac/protogeni/wiki/ClearingHouseDesc
>
> We don't really do any of 1,2,3 or 4 from the original list.
>
> Thus spake David Irwin on Thu, Apr 16, 2009 at 03:05:58PM -0400:
>> Typo:  If you abandon (2), the value of the Clearinghouse is unclear to me.
>>
>> -David
>>
>> On Thu, Apr 16, 2009 at 3:05 PM, David Irwin <irwin@...> wrote:
>> >> My original posting observed that practical issues suggest (3)
>> >> and (4) can be bundled and located on the client's desktop; and
>> >> that if you do this, (1) is orphaned (and personally, I don't see
>> >> why it's a big deal for an AM to decode and check a credential).
>> >
>> > I agree with this.  This question was raised in our Cluster D meeting
>> > at the last GEC.  If the Clearinghouse does not serve in role (2) as
>> > the Resource Manager, then what is the value of it only serving in
>> > role (1) as the Credential manager?  If you abandon (1), the value of
>> > the Clearinghouse is unclear to me.
>> >
>> > -David
>> >
>>
>> _______________________________________________
>> control-wg mailing list
>> control-wg@...
>> http://lists.geni.net/mailman/listinfo/control-wg
>
> --
> /-----------------------------------------------------------
> | Robert P Ricci <ricci@...> | <ricci@...>
> | Research Associate, University of Utah Flux Group
> | www.flux.utah.edu | www.emulab.net
> \-----------------------------------------------------------
>

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Leigh Stoller]

Sounding less like a ClearingHouse and more like an Exchange.
The Geni Exchange.

Lbs


_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Aaron Falk]

Larry Peterson wrote:

> So we have a set of functionality that can be bundled in
> a clearinghouse (or not). They include (at least):
>
> 1) Credential manager (so aggregates don't have do deal
>     with credentials);
>
> 2) Resource manger (collects tickets from aggregates and
>     redistributes to users based on some allocation policy);
>
> 3) Aggregate aggregator (or virtual aggregate that "hides"
>     multiple aggregates behind a unified front-end); and
>
> 4) A slice manager (that offers users some nicer abstraction
>     than the "machine language" provided by the slice interface
>     and rspecs).

Robert P Ricci wrote:

> I think the two things our clearinghouse does are not in Larry's list,
> so let me add two more:
>
>  (5) Help resource providers and resource users find each other, by
>      hosting registries of AMs and users (for example, our simple
>      resource discovery has the client contact the CH to get a list of
>      AMs)
>  (6) Act as a trust anchor - in the federation we have running, every
>      federate establishes direct trust with only one party, the CH,
>      which then distributes signing certs, CRLs, etc. to all members of
>      the federation

Hi All-

Thank you Larry for starting an interesting thread.  You and Rob have
listed several candidate functions for Clearinghouses that don't really
match the clearinghouse functions that Chip described at GEC4 (slide
15-21 of [1]).  Those functions really revolve around accountability:

    1. User log-in.  A place for a user to create an account; it needs
    to be capable of validating there is an organization accountable for
    their actions.  It's not clear whether this validation is included
    in the credential manager you mentioned.

    2. Transaction Logging.  A reliable record of all resources a user
    consumed.  Needed to determine accountability if something bad happens.

    3. An ability to enforce global policies.


Note that there is nothing here about discovery, slice management, local
policy enforcement, or understanding or manipulating resource
descriptions.  Why centralize these functions?  Mostly pragmatics.  1.
and 2. are centralized to limit the number of trust relationships needed
for researchers from many institutions to acquire diverse or numerous
resources (for 1) or to get an authoritative record of who is using what
resources at a particular time (for 2).  3. is centralized because it's
harder to do distributed global policy enforcement.

So, I'd be interested in a discussion on whether and how to support
these functions.

Cheers,

--aaron

ps. Oh, and just to be clear: I'm not advocating that there can be only
one clearinghouse.  Indeed, I would think that an aggregate could
affiliate with multiple.  For example, aggregates could join alternate
clearinghouses with different identity policies.


[1]
http://groups.geni.net/geni/attachment/wiki/Gec4presentations/GEC%204%20-%201.%20Chip%20intro%20-%20draft%201%20Apr%2009.ppt?format=raw



_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Larry Peterson]

Preferably you would know about the registry and
get the Aggregate records from there, but you have
to walk the entire registry tree to make sure you come
across all the records of type AM... or do you see
another way? If you could ask a registry to return all
records of a particular type, then we could use that.

Larry

On Thu, Apr 16, 2009 at 6:25 PM, Aaron Falk <falk@...> wrote:

> Larry Peterson wrote:
>> So we have a set of functionality that can be bundled in
>> a clearinghouse (or not). They include (at least):
>>
>> 1) Credential manager (so aggregates don't have do deal
>>     with credentials);
>>
>> 2) Resource manger (collects tickets from aggregates and
>>     redistributes to users based on some allocation policy);
>>
>> 3) Aggregate aggregator (or virtual aggregate that "hides"
>>     multiple aggregates behind a unified front-end); and
>>
>> 4) A slice manager (that offers users some nicer abstraction
>>     than the "machine language" provided by the slice interface
>>     and rspecs).
>
> Robert P Ricci wrote:
>> I think the two things our clearinghouse does are not in Larry's list,
>> so let me add two more:
>>
>>  (5) Help resource providers and resource users find each other, by
>>      hosting registries of AMs and users (for example, our simple
>>      resource discovery has the client contact the CH to get a list of
>>      AMs)
>>  (6) Act as a trust anchor - in the federation we have running, every
>>      federate establishes direct trust with only one party, the CH,
>>      which then distributes signing certs, CRLs, etc. to all members of
>>      the federation
>
>
> Hi All-
>
> Thank you Larry for starting an interesting thread.  You and Rob have
> listed several candidate functions for Clearinghouses that don't really
> match the clearinghouse functions that Chip described at GEC4 (slide
> 15-21 of [1]).  Those functions really revolve around accountability:
>
>    1. User log-in.  A place for a user to create an account; it needs
>    to be capable of validating there is an organization accountable for
>    their actions.  It's not clear whether this validation is included
>    in the credential manager you mentioned.
>
>    2. Transaction Logging.  A reliable record of all resources a user
>    consumed.  Needed to determine accountability if something bad happens.
>
>    3. An ability to enforce global policies.
>
>
> Note that there is nothing here about discovery, slice management, local
> policy enforcement, or understanding or manipulating resource
> descriptions.  Why centralize these functions?  Mostly pragmatics.  1.
> and 2. are centralized to limit the number of trust relationships needed
> for researchers from many institutions to acquire diverse or numerous
> resources (for 1) or to get an authoritative record of who is using what
> resources at a particular time (for 2).  3. is centralized because it's
> harder to do distributed global policy enforcement.
>
> So, I'd be interested in a discussion on whether and how to support
> these functions.
>
> Cheers,
>
> --aaron
>
> ps. Oh, and just to be clear: I'm not advocating that there can be only
> one clearinghouse.  Indeed, I would think that an aggregate could
> affiliate with multiple.  For example, aggregates could join alternate
> clearinghouses with different identity policies.
>
>
> [1]
> http://groups.geni.net/geni/attachment/wiki/Gec4presentations/GEC%204%20-%201.%20Chip%20intro%20-%20draft%201%20Apr%2009.ppt?format=raw
>
>
>

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Larry Peterson]

I don't think those are the right functions.

1) A place for a user to "log in" -- that's what we have
    registries for. You just need to get your university's
    authority (PI in PlanetLab-speak) to vouch for you.
    Then you acquire the credential(s) you need and
    you're off and running.

2) Transaction logging -- implies a global "red button".
     I don't think you have that feature in a truly
     federated world. At the end of the day, each
     aggregate has to protect itself.

3) Global allocation policy -- to the extent anything
    is global, then yes, you need something like this.
    It corresponds to one of the functions I named
    earlier (Resource Manager... I forget which number
    I gave it). But again, I think allocation rights originate
    with the owner of the aggregate; they may or may
    not delegate to a global entity.

Larry

On Thu, Apr 16, 2009 at 6:25 PM, Aaron Falk <falk@...> wrote:

> Larry Peterson wrote:
>> So we have a set of functionality that can be bundled in
>> a clearinghouse (or not). They include (at least):
>>
>> 1) Credential manager (so aggregates don't have do deal
>>     with credentials);
>>
>> 2) Resource manger (collects tickets from aggregates and
>>     redistributes to users based on some allocation policy);
>>
>> 3) Aggregate aggregator (or virtual aggregate that "hides"
>>     multiple aggregates behind a unified front-end); and
>>
>> 4) A slice manager (that offers users some nicer abstraction
>>     than the "machine language" provided by the slice interface
>>     and rspecs).
>
> Robert P Ricci wrote:
>> I think the two things our clearinghouse does are not in Larry's list,
>> so let me add two more:
>>
>>  (5) Help resource providers and resource users find each other, by
>>      hosting registries of AMs and users (for example, our simple
>>      resource discovery has the client contact the CH to get a list of
>>      AMs)
>>  (6) Act as a trust anchor - in the federation we have running, every
>>      federate establishes direct trust with only one party, the CH,
>>      which then distributes signing certs, CRLs, etc. to all members of
>>      the federation
>
>
> Hi All-
>
> Thank you Larry for starting an interesting thread.  You and Rob have
> listed several candidate functions for Clearinghouses that don't really
> match the clearinghouse functions that Chip described at GEC4 (slide
> 15-21 of [1]).  Those functions really revolve around accountability:
>
>    1. User log-in.  A place for a user to create an account; it needs
>    to be capable of validating there is an organization accountable for
>    their actions.  It's not clear whether this validation is included
>    in the credential manager you mentioned.
>
>    2. Transaction Logging.  A reliable record of all resources a user
>    consumed.  Needed to determine accountability if something bad happens.
>
>    3. An ability to enforce global policies.
>
>
> Note that there is nothing here about discovery, slice management, local
> policy enforcement, or understanding or manipulating resource
> descriptions.  Why centralize these functions?  Mostly pragmatics.  1.
> and 2. are centralized to limit the number of trust relationships needed
> for researchers from many institutions to acquire diverse or numerous
> resources (for 1) or to get an authoritative record of who is using what
> resources at a particular time (for 2).  3. is centralized because it's
> harder to do distributed global policy enforcement.
>
> So, I'd be interested in a discussion on whether and how to support
> these functions.
>
> Cheers,
>
> --aaron
>
> ps. Oh, and just to be clear: I'm not advocating that there can be only
> one clearinghouse.  Indeed, I would think that an aggregate could
> affiliate with multiple.  For example, aggregates could join alternate
> clearinghouses with different identity policies.
>
>
> [1]
> http://groups.geni.net/geni/attachment/wiki/Gec4presentations/GEC%204%20-%201.%20Chip%20intro%20-%20draft%201%20Apr%2009.ppt?format=raw
>
>
>

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Robert P Ricci]

Thus spake Larry Peterson on Thu, Apr 16, 2009 at 07:17:59PM -0400:
> 1) A place for a user to "log in" -- that's what we have
>     registries for. You just need to get your university's
>     authority (PI in PlanetLab-speak) to vouch for you.
>     Then you acquire the credential(s) you need and
>     you're off and running.

Yeah, I'd like to push back on this one too - while we use the
clearinghouse as a trust anchor, it's not the place where a user's
account "exists". The user's account "exists" at an authority (in our
case a slice authority).

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg