Fwd: [omis-wg] Indiana University comments on OMIS use Cases

[Heidi Picher Dempsey-2]

Below are some comments on the OMIS use cases that we posted on the wiki a while ago.  What do folks on this list think about using the term "token" instead of "ticket" for control descriptions to avoid future confusion between the overlapping term "ticket" that ops and control both currently use?

Begin forwarded message:

From: "Williams, James G" <william@...>

Date: May 21, 2008 9:28:10 AM EDT

To: "'omis-wg@...'" <omis-wg@...>

Subject: [omis-wg] Indiana University comments on OMIS use Cases

 Posted on the OMIS-wiki…..

 

 

 

 

 

Comments on OMIS Use Cases (and other OMIS issues)

 

Michael raised several issues in his latest message about OMIS Use Cases.  We would like to add a bit to that discussion in two areas, ticket terminology and notifications and operational data sharing.

 

 

 

 

Ticket Terminology

 

Michael raised a question of terminology confusion between “trouble tickets” and “resource tickets” if both are called “tickets”.   We have a suggestion here.  It seems to us that one way to eliminate this confusion is to talk about tickets and tokens.  A component issues a token (or resource token [RT]) that can be redeemed for services.  These tokens are directed toward a Clearinghouse (and perhaps later used in a conversation between the Clearinghouse and an experiment).  A trouble ticket (TT) would be created by a NOC (Aggregate Ops or GENI Ops), and would describe a problem (current issue) or an event (future issue).  A TT would (could) be shared with a Clearinghouse and experimenters.  But, tokens and tickets would be issued by different entities (components and Ops).

 

 

Notifications and operational data sharing

 

The very pervasive issue of “notifications” and operational data sharing seems to be a crucial area that deserves detailed discussion.  An open question posed by Michael in all Use Cases relates to how interrelated experiments would notify each other about service issues.  The issue of notifications seems one of basic importance to operations, and one which cuts across all of the use cases mentioned.  As Michael states, notification is a difficult and problematic area.  Should notifications come from a myriad of NOCs, or be channeled through some kind of normalizing system to coordinate and standardize the notifications?  Who does Ops (GENI or Aggregate) notify about outages (emergency or scheduled)?  How does an experiment, end user, or aggregate signal its desire to receive notices?  How do notification recipients signal what type of notifications they want to receive, and how they want to receive them?  How does an experiment or an aggregate signal its intention to send out notices reflecting its internal state?  These issues are already complex even for networks that are simpler and less federated, such as the NLR and Internet2 networks.   We’ve already begun to see keen interest in developing a rich mix of push/pull notifications of customized granularity and audience.  Some in the community want to see only a very small set of notifications for very specific things.  Others want to see everything they can.  Some want a simple system to “poll” for network status information.  Others want notifications to be pushed out very aggressively through a number of channels.  Given the diversity of audience for GENI-related notifications, this will only be more complicated (and important) for GENI.

 

Here are some initial ideas based on our experience.

 

1. Any notification feature must be automated as much as possible.  This will have implications for (among other things) the data structure that describes experiments, aggregates and clearinghouses.  This seems obvious.  But, this network will be way too complex for much “operator intervention” at the notification level.
2. For notification information to be exchanged there must be some process for information providers (the ones producing notifications) and information consumers (the ones wanting to see notifications) to opt-in, and authorize the exchange of information.  This process must be strict enough to protect against information flooding or leaking, but must also be simple enough so it doesn’t become a roadblock to research information sharing and so it doesn’t inadvertently slow down operational troubleshooting and maintenance.
3. Standards for notification formats could be very helpful. If notifications can be sent in a standardized format, the Aggregate owners and Experimenters can use the notifications programmatically. This could be to update the aggregates trouble ticketing system or to change the configuration/ suspend an experiment.

 

 

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

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

[Robert P Ricci]

Thus spake Heidi Picher Dempsey on Wed, May 21, 2008 at 09:57:12AM -0400:
> Below are some comments on the OMIS use cases that we posted on the  
> wiki a while ago.  What do folks on this list think about using the  
> term "token" instead of "ticket" for control descriptions to avoid  
> future confusion between the overlapping term "ticket" that ops and  
> control both currently use?

The word "token" is already used in the architecture documents to refer
to a system built on top of tickets by brokers, which might permit
over-booking or other economic models more complex than the simple
semantics of a ticket. So, that name isn't an option.

It seems like a few of the groups that are implementing prototypes are
finding it convenient to treat a ticket as a particular type of
credential. So, it's probably worth considering whether "resource
credential" or something similar would work as an alternate name.

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

Robert is right. For symmetry's sake, we might drop the word
ticket and replace it with "resource credential" (the counterpart
being a "slice credential" issued by a slice authority).

Larry

On Wed, May 21, 2008 at 1:01 PM, Robert P Ricci <ricci@...> wrote:

> Thus spake Heidi Picher Dempsey on Wed, May 21, 2008 at 09:57:12AM -0400:
>> Below are some comments on the OMIS use cases that we posted on the
>> wiki a while ago.  What do folks on this list think about using the
>> term "token" instead of "ticket" for control descriptions to avoid
>> future confusion between the overlapping term "ticket" that ops and
>> control both currently use?
>
> The word "token" is already used in the architecture documents to refer
> to a system built on top of tickets by brokers, which might permit
> over-booking or other economic models more complex than the simple
> semantics of a ticket. So, that name isn't an option.
>
> It seems like a few of the groups that are implementing prototypes are
> finding it convenient to treat a ticket as a particular type of
> credential. So, it's probably worth considering whether "resource
> credential" or something similar would work as an alternate name.
>
> --
> /-----------------------------------------------------------
> | 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
>
>

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

[Ted Faber]

On Wed, May 21, 2008 at 01:32:17PM -0400, Larry Peterson wrote:
> Robert is right. For symmetry's sake, we might drop the word
> ticket and replace it with "resource credential" (the counterpart
> being a "slice credential" issued by a slice authority).

Are tickets credentials?  They don't prove what a resource is or confer
rights to operate on them (other than to allocate them).  I think it
would be more clear to call them "resource promises."

I think slice credentials are credentials, in as much as I understand
them.

--
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG


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