Version 5 (modified by Adam Slagell, 10 years ago) (diff)


On Nov. 2, 2011, during the GEC 12, Adam Slagell moderated a panel on defining the clearinghouse roles and responsibilities. Ilia Baldine, Ted Faber and Andy Bavier were there in person as well as Jeff Chase and 2 ProtoGENI representatives over the phone. The slides based on the draft Clearinghouse Policy, (both drafted by Adam Slagell and attached to this page), served as a starting point for discussion.

The conversation and slides began with a brief description of common definitions. Some of these were fairly new when Aaron Falk presented them at the previous GEC 11, but folks had mostly converged on common language before the GEC 12 panel. Some of the changes included a renaming of Management Authority to Aggregate Authority. Others changes were focused on separating identity portals out from identity providers. New concepts were mostly related to the notion of projects. The only contentious topic was what to call the oversight group and who should make up its constituents. On the slides it was referred to as the GENI Oversight Group or GOG. All of these are defined in the attached clearinghouse policy document.

Next discussed was the whole notion of project leader and why such a role was desired. It seemed as if most people agreed on the presented reasons for having project leaders. Questions of how to implement the concept (e.g., as an ABAC role or a separate credential) remain, as well as whether or not the aggregate managers (AMs) need to be aware of this concept. Another open question is whether or not a project member role is useful or needed. Project leaders and members could serve similar purposes to groups in ORCA/BEN. The only thing that needs immediate decision is how to implement this concept of projects and project leaders. Project leaders seem to make most sense as an additional attribute, especially if GENI goes with ABAC. Still, we need to settle on a vocabulary as well as who can be project leaders. Ted Faber is working on that. It was strongly noted that the clearinghouse (CH) should delegate who could be assigning principals to the role of project leader. That seems workable as long as project leaders are required to register an account with the CH when creating a project, and those delegatees agree to share contact info for project leaders with the CH. Of course, the clearinghouse does not need any info about those with project leader attributes who have not registered a project yet with the CH.

The primary and secondary purposes were discussed next on the panel. There seemed to be no opposition to the primary functions of the clearinghouse: endorsing agreements, registering project leaders, and registering projects. As a quasi-legal entity, the clearinghouse would serve as a trust anchor to minimize the number of pairwise agreements between GENI actors. Through some mechanism of endorsement, the CH would attest to official GENI identity portals, identity providers, slice authorities and aggregate authorities. A decision about mechanism was not made but should be soon. Two basic approaches are available: a trusted directory service or PMI-like asynchronous solution (e.g., ABAC). There was strong opposition to anything that would insert the CH into every resource allocation process in a blocking way, and there was general consensus that ABAC could solve this more elegantly. The big question that would remain is how to handle revocation then. Preferably short term credentials would be used with a trusted proxy renewal service, such as, MyProxy.

Another big decision that needs to be made is regarding who can bind projects to slices. It is at this step that it is verified that all the actors involved (e.g., slice owner, slice authority, identity portal of the slice authority) are all GENI endorsed actors because this is when a slice becomes a true CH-endorsed GENI slice. However, if implemented in ABAC, a slice authority (SA) could check all of these things as well as check that the slice owner has the rights to bind slices to to a given project registered at the CH. If it is implemented this way, there would have to be some agreement with SAs that they would perform these same checks as well as answer questions from the CH or GMOC regarding the project a given slice is associated with. This decision should be made soon so proper agreements and processes can be drafted.

Most of the secondary services were not contentious as long as it was clear that the clearinghouse would not have exclusivity on those services. In particular, people were apathetic as to whether or not the the CH acted as an additional identity portal and slice authority. No one seemed to care whether or not the CH provided a resource discovery service as long as it was not "in the way", i.e. optionally used.

The most contentious service discussed was a slice tracker or broker in the nomenclature of ORCA/BEN. The main idea here is that there would be some global service at the clearinghouse that would track resource allocations to every registered (i.e., bound to a project) slice. As long as the response back on resource allocations to the CH were asynchronous, after-the-fact and non-blocking, people didn't care too much. However, no one could really come up with a good use case to argue for the need. Three types of global policies were discussed, but none of these seem to need a centralized slice tracker at the clearinghouse. In the first case, we could maybe imagine the NSF making some sort of global policy based upon the attributes of a slice owner, (e.g., students can create slices with at most X hosts). As long as it isn't a limit on how many slices an actor could create but just about a single slice, this could be verified and enforced at the SAs were slices are created. Agreements to enforce these common policies would just need to be made, and the CH could delegate their enforcement. Another type of policy might be whether a slice has too many key resources or is not acting like the size of slice it registered as. This could be handled in the same way as above, by the SAs in a distributed manner. A third type might be about all GENI slices in total, but still only regarding a particular aggregate. For example, an agreement with FIRE might not allow the sum of all GENI slices to use more than a certain percent of their transatlantic link. Of course, this can just be handled as a local component or aggregate manager policy. The only types of things we could not check without involving an omniscient, centralized slice tracker are policies about usage of all GENI slices in aggregate across multiple AMs. So we could not check a general policy like FIRE slices can only use X number of hosts in GENI. However, it is not clear why such a policy would ever be needed as it really up to the aggregates operators themselves. It was thought that maybe some key resources like backbone connectivity and GENI racks might both need to be considered (e.g., a policy that FIRE users get at most Z resources *total* from either Internet2 or GENI Racks), and that spurred a discussion of whether aggregate authorities might have multiple aggregates and how they could enforce a global policy across multiple AMs. Regardless, a decision needs to be made whether or not such a slice tracker is required at the CH. If so, there should be clear use cases and requirements, and it should be implemented in a non-blocking way. As it stands, there is no compelling case for what appears to be a lot of work tom implement.

Attachments (2)

Download all attachments as: .zip