[Nsi-wg] minutes from today's NSI call

Jerry Sobieski jerry at nordu.net
Thu Apr 21 00:25:46 CDT 2011


Hi All-

I apologize for missing the call today...  The Internet2 Spring meeting 
had me wrapped up, and I just missed the call.

I have read the minutes.  I have two comments:

1.  As much as I want to support the underspecified endpoints thinking, 
I really don't think we can in V1.0 ... To wit:  Define an 
"underspecified" STP.    I know (and the NSA can tell) what a fully 
specified STP is because it is in his local name table.  But how does an 
NSA recognize an "underspecified" stp?   And if the NSA can recognized 
it, how is it to resolve it into a "fully specified" STP?  i.e. what 
does an "underspecified STP" mean?  What are the semantics?   Have we 
just started defining new topology structures?

2. AS for technology specific info in the STP.   IMO, we should avoid 
this religiously - this breaks the NSI abstraction.  Why would this even 
be necessary?    The NSI connection service primitives are technology 
agnostic.   Technology specifics may be found in the Service Request 
that are part of the Service Definition (e.g. MTU), but other than that, 
we should make sure the primitives themselves remain technology agnostic 
- including the names of endpoints.   The Endpoint will always map to 
some topological location - *that* is where the physical or technology 
specific info should be found - not in the stp name itself.   
Admittedly, we can't stop a local NSA from encoding information in the 
local endpoint(s) names (e.g. name:="vlan100") but that is purely a 
local convention and of no significance to the other NSAs.  Doing so may 
have human significance, but not NSI significance.     If you encode 
technology specifics in the WSDL that defines an NSI Message, then you 
are adding information to the NSI message. That information therefore 
should be common to all Connection Services regardless of technology.  
So fundamentally, adding information to the WSDL that defines a NSI 
message is redefining the NSI message and is therefore considered a 
protocol addition.  As a new protocol addition, it should be justified 
within the NSI protocol semantics, or should be expressly forbidden.   
Again - why would this even be necessary?


All- If we keep the NSI-CS protocol faithful to the NSI abstractions, 
(Networks, Endpoints, Connections, and Services) we will be fine. The 
protocol works beautifully as is without last minute hacks.   The CS 
primitives do Reservations and Provisioning.   The issues of pathfinding 
are dependent on Topology - which we have not worked out yet.   Be 
patient, and have confidence - the CS protocol is really well thought 
out as is.  We will find that many of these issues go away or will be 
improved with the ensuing topology discussions...don't panic and try to 
wedge something in at this eleventh hour that we have not considered 
thoroughly.

Thanks!
Jerry

On 4/20/11 1:36 PM, Guy Roberts wrote:
>
> The minutes from today's NSI call are available here:
>
> http://forge.gridforum.org/sf/go/doc16256?nav=1
>
> _____________________________________________________________________
>
>       **       Guy Roberts, PhD     Network Engineering & Planning
>
>     *    *                          Tel:    +44 (0)1223 371300
>
>    *      *    City House           Direct: +44 (0)1223 371316
>
>    *           126-130 Hills Road   Fax:    +44 (0)1223 371371
>
>   *            Cambridge
>
>   *            CB2 1PQ              E-mail: guy.roberts at dante.net 
> <mailto:guy.roberts at dante.org.uk>
>
>   D A N T E    United Kingdom       WWW: http://www.dante.net
>
> _____________________________________________________________________
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110421/1664ee89/attachment.html 


More information about the nsi-wg mailing list