Changes between Version 3 and Version 4 of ClearinghousePanelSummary


Ignore:
Timestamp:
11/15/11 15:08:02 (12 years ago)
Author:
Adam Slagell
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ClearinghousePanelSummary

    v3 v4  
    77The 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 (CH) 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 a trusted proxy renewal service, such as, MyProxy.
    88
    9 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.
     9Another 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.
     10
     11Most 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.
     12
     13The 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 back 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 aggregate, but about 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 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 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 is, there is no compelling case for what appears to be a lot of work for a non-use case.