[Fwd: Re: [services-wg] questions on RSpecs from GEC2 meeting]

[Peter Steenkiste]

I sent this earlier, but since I was not on the control-wg, it bounced.

The first paragraph, I believe, is consistent with John's later message,

Peter

-------- Original Message --------
Subject: Re: [services-wg] [cwg] questions on RSpecs from GEC2 meeting
Date: Tue, 04 Mar 2008 09:33:01 -0500
From: Peter Steenkiste <prs@...>
To: chase@...
CC: Aaron Falk <falk@...>, control-wg@...,
services-wg@..., Peter Steenkiste <prs@...>
References: <36CF4919-88AA-4FC6-9C4D-94DFD45A99E1@...>
<47CC819D.3090305@...>



Hello Jeff,
Your two extremes do look scary.  I have always assumed that the Rspec
would pick an intermediate point in your spectrum: if two parties need
to exchange some information other than the "standard" information in
the Rspec, they would just be able to do that.   "Standardizatin" or at
least rough consensus would be needed if information field became widely
used.

I think that the issues of time, duty cycle, scheduling unit, isolation,
etc. are harder.  When creating a slice, you will need to make sure that
these properties of your slivers "line up" so you get the right behavior
at the slice level.  That looks like a hard problem.  Clearly it will
require consensus over how to represent this information and what
various values mean for different substrates.  This issue exists
independent of whether you include the information in the Rspec or not.

Peter

Jeffrey Chase wrote:

> Aaron Falk wrote:
>  
>> I took a few notes on the questions that came up during Ted & Rob's  
>> talks:
>>
>> Where is time expressed?
>>
>> How are duty-cycles expressed?
>>
>> How are probabilistic constraints expressed?
>>
>> (something about elemental actuators....?)
>>
>> c.f. sensorML, ontology for services, network markup languages from  
>> OGF, resource descriptor framework
>>
>> How is isolation expressed?
>>
>> _______________________________________________
>> control-wg mailing list
>> control-wg@...
>> http://lists.geni.net/mailman/listinfo/control-wg
>>  
>>    
>
> It seems to me that there's a larger core question here that came up
> about the role of rspec as a language (format?) for representing
> information about resources and slivers in the GENI architecture.   How
> do we balance the tension between standardization and extensibility?
>
> There are a couple of options that bracket a continuum:
>
> 1. Exactly one: Rspec is the standard specification.  It can be extended
> through various consensus processes defined by GENI governance.
>
> 2. At least one: Rspec is an initial standard for representing some
> information, but there may be other alternatives for representing other
> information.    If the various actors (component manager, clearinghouse,
> researcher tools) understand some other language, then they can
> negotiate for resources using that language instead of or in addition to
> Rspec.
>
> Strategy #1 has several risks.  It means we have to invest a lot in
> trying to agree on an specification for what GENI actors say to other
> actors about resources and slivers, and their topology and
> capabilities.  What does it mean for Rspec to be "extensible"?  Can it
> incorporate information represented in NDL, or DCML, or sensorML, or
> various other languages that other related communities might use?  Or
> will we build "our" own language, borrowing from these "other"
> communities as we see fit?  Can the Rspec standard evolve quickly enough
> to avoid being a barrier to innovation?
>
> The risk of strategy #2 is that we later degenerate into a jello-nailing
> exercise of some sort.  But I hope we can keep GENI open enough to
> encompass multiple ways of talking about resources, just as the Web has
> multiple formats for representing content.  If we can do that, then we
> will have a more evolvable result and better inclusion of other groups
> who have thought hard about these problems for a long time (e.g.,
> http://www.science.uva.nl/research/sne/ndl).  We should at least ask the
> question of whether we can get where we want to go in some other way,
> e.g., by extending NDL.
>
> Jeff
>
>
> _______________________________________________
> services-wg mailing list
> services-wg@...
> http://lists.geni.net/mailman/listinfo/services-wg
>
>  

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