[ghpn-wg] Suggestions for draft-ggf-ghpn-netserv-2

Admela Jukan jukan at uiuc.edu
Wed Jun 22 13:23:38 CDT 2005


Michael, I have gone through all your comments and would like to 
respond to some of them.
In general, your comments are going into the right direction - for 
better organizing the structure and the layout of the document. That 
was the main motivation for revising this draft. Below are some 
specific comments.
>
> My question is: an "advanced network reservation" service
> is mentioned in some places in this document. Where is
> this service specified? Is this one of the more concrete
> things that was originally contained in netservices-0
> and was now removed? Then, where will it be contained - is
> a related document in the works?

This is open to discussion. In the current structure it is meant to be 
under the Section 5 - "Service Profiles".

> # pg 5 pa 6, # pg 6 pa 1, 2, 3, 4
> ... all this is a repetition of previous text!
>

Do you mean Section 2.1? If so, do you mean it should be deleted, 
shortened or rephrased?
This text does sound a bit introductory, but it is definitely different 
from the intro itself. (or, I am missing the point.)

> =====
> pg 7 fig 3: I would change (b), as it doesn't reflect the horizontal
> nature of interactions at all - in fact, it looks quite vertical. There
> are no interactions between NS and grid services (or other NS's) shown.
>

Maybe the Figure does not reflect the "horizontal" nature of the 
concept very well, but it is in my opinion needed as an alternative to 
the "vertical" paradigm of Grid-network interactions. Think of it as 
network running internally within the Grid service, e.g. such as 
virtualizing a distributed machine (over network).

> ======
> My answer to the query outlined on pg 10 / 11 / 12: I would vote
> for option 4 (Franco's proposal). It seems like an "information
> service" would be something you query, and the information is not
> supposed to change all the time (things like the topology, and
> link capacities could go in there, I guess). I envision a monitoring
> service as an online tool that I can use to (for instance, manually)
> shift resources from one place to the other on-the-fly when I see
> that something goes wrong.

> Of course, the process could be automatic, but assuming about manual
> operation simplifies things in my opinion. If I were to manually run
> a Grid application, I'd first check the information service to guide
> my scheduling decision, then run it and keep checking the monitoring
> service to make updates while my application is active.
> ======

I like the idea of coupling one service to the application lifetime 
(monitoring) and the other to the off-line analysis of the available 
resources (information).

-- Admela





More information about the ghpn-wg mailing list