Re: [ghpn-wg] Netservices document

[Franco Travostino <travos@nortelnetworks.com>]

Peter,
thank you for making such a thorough review, and offering your thoughts
in the attached document. As a reminder to you and everyone else, we plan
to discuss Net Services during the better part of the 2nd GHPN-RG
Session, on Fri 12th 4:00-5:30pm. 

Some thoughts, co-chair hat off ...

Our brainstorming is akin to designing a suspension bridge, sometimes the
span turns out to be unattainable, sometimes the anchor point is plain
wrong. Or both. We will need to iterate several (many) times to get it
right.

If we had a couple of solid pillars to lean on, it would have helped us
greatly. The WS-Agreement could be one such a pillar IMO.   We ought
to be leveraging it more as a design principle and enabling technology to
abstract things out, rather being just a standard document for portTypes
and other useful "macros". Right now, WS-A is not a fully
developed pillar though, because there are no networking-specific
derivations to it yet. I see us (be it GHPN or spinoff WGs) doing this
type of work ...

... and a CIM schema for network services would the other key and
complementary pillar (i.e., to put our hands on an official OO hierarchy
akin to the one that Peter is referring to). On the standards front, this
might very well be a zero-height pillar still (e.g., within DMTF, the
published schemas stop at the "box and feeds" level). In
considering whether new WGs are in order, we should ask ourselves whether
GGF would the best place to attack the definition of a CIM-like schema
for services, or whether it would be more naturally housed within DMTF
(or elsewhere).

Echoing Peter's opening statement, these big-picture questions and
discussion points validate the usefulness of the brainstorming activity.
I'm very glad that we had this started. 

-franco


At 05:28 AM 3/2/2004, Peter Clarke wrote:

> George et al
>
> [This mail is as a GHPN group member responding to the 
> draft netservices document, not as an AD] 
>
> I have read through the net services document and 
> I think this will be a really useful document. 
> I thought it put its finger on many of the "pressing" issues in 
> formulating Network resources as services available to the Grid, 
> and can potentially lead to defining some WGs to take things forward. 
>
> Some comments: 
>
> 1) I think that it is long overdue to get a comprehensive 
> and well written set of USE CASES for network services written down and 
> published. In the early part of the document this is started (Case Studies 
> section). I would like to strongly endorse the importance of this section. 
>
> I would also like to strongly suggest that we produce formal USE CASES in 
> due course. 
> By this I mean USE CASES as one would understand in a canonical 
> software design process, as opposed to just the descriptive text in the 
> draft. 
> I am not suggesting the text in the draft where it is wrong, but rather that 
> we should either 
>   (i) prepare a separate formal USE CASES & requirements document (and I 
>        would seek to find some effort for that) 
>                  or 
>  (ii)  this document is expanded to contain such in an appendix 
>
> 2) I had lots of problems with section 3 im afraid 
>
> The general comment is that it seemed confused, and did not convey a clear 
> and coherent 
> picture of what the message was that it intended to convey in terms of 
> service architecture. 
> Sorry, but on first reading that was my impression - so i have to say it now 
> or later. 
>
> More specifically: 
>
> - Section 3.3.  I think disagree a lot with fig 2 as it mixes functionality 
> and 
> implementation far to explicitly. In other words I think it needs more 
> thought out 
> structure. However I did not really understand it in detail as there is not 
> enough 
> description of the idea the figure embodies. 
>
> - I felt that in several sections  (3.3.1 and 3.3.2.1 in particular) there 
> is an 
> implicit mixing of "functionality" with "implementation technology". By this 
> I mean that (imho) the concept of a "fixed width pipe" as a network resource 
> should not 
> be instantly tied to the idea of a "light path" or "MPLS+Qos" 
> implementation. 
> Although the document doesnt say this explicitly, it comes across as if the 
> actual services to be advertised to the grid might be "Diffserv Qos", "MPLS 
> tunnel"..etc.., 
> whereas (imho) these are merely implementation possibilities way down the 
> service stack which should not appear anywhere near the user. 
>
> I would like to suggest that this is wrong, and that a very explicit 
> abstraction layer 
> should be introduced. I have tried to encapsulate this in the attached 
> document which 
> I submit to provoke discussion at the GGF meeting in Berlin, and perhaps 
> even some contributed 
> text to the document. 
>
> - In fact section 3.3.2.1 talks a lot about the abstraction which I would 
> think is correct 
> (the "Path"  abstraction) and management thereof. I liked this up to the 
> point that 
> it tied paths too explicitly to implementation. See my further comments in 
> the 
> attached document. 
>
> 3) Finally, a very positive factorisation jumped out at me, which I would 
> like to 
> suggest is discussed (and possibly incorporated in the document) 
>
> Whilst I can see that agreeing an entire network services architecture is 
> complex 
> and must necessarily take some time, I feel that at the very lowest level of 
> Network Resources 
> which can be offered at the edge of a single domain, then life ought to be 
> much simpler. 
>
> Specifically, if the idea of defining a hierarchy of simple "Primitive 
> Network Resources" 
> is  widely agreed, then a WG could be started now to work on these. This WG 
> would define the meaning and Network Resource Service description required 
> to 
> advertise them into some information service. 
>
> As I have made lots of comments here, some inside the scope of the draft, 
> some outside, I have as mentioned, tried to encapsulate my thoughts more 
> clearly in the enclosed document, 
> which should be seen as 
>   (i) not claiming any original thought - but merely a synthesis of things 
> read 
>      and seen 
>   (ii) contributed wording to the draft if it is useful. I couldn't suggest 
> paragraphs 
>     directly as im in effect clearly suggesting a more abstract and 
> systematic approach 
>     to the service stack which I dont think can be reached incrementally 
> from what already 
>     appears in the draft. 
>
>    Peter 
>
>