Hi Guy -

This is a really nice aggregation of what we have from before.  I think we can get this worked out over the next couple months if people have time.

 I am not sure how we want to proceed with editing this - I am not sure it is quite ready for online editing, but it is close.  I have some comments below - let me know if  you would like them in the doc instead.  

In Section 2 -  

doc says " The protocol includes a set of defined primitives that are a intended to provide the control necessary to manage Connections."
I think primitive is not quite the right word - perhaps command sequences or something like that.  Also, control might be replaced with "ability".

and the command sequences might be ReserveConnection/ProvisionConnection/CancelConnection (replace "Request" with "Connection"
Also, I think we need a Notify message/ sequence.  Perhaps there is a way around this - I am not sure.

The connection state doesn't seem right.  I think there should be state for reservation sequence, for provision sequence and cancel sequence.  I think a state for the connection as a whole is also a good idea.  -- I think the intent of this sequence is for a single network (i.e. not multi-NSA), so a multi-NSA state is also needed at some (probably later) point.

Section 3 -

I think we decided (though not without lots of discussion, so I may be wrong) that connection was not necessarily data, that it could be done by switching waves, or fibers (with mirrors).  If so we need to define connection a bit more abstractly.  If not we need to be clear in the group about what we think this service supports.   I am happy either way.

In relation to this, saying data stream must be preserved would not be correct in the more abstract interpretation of connection.

Section 4 

I like the lifecycle diagram for the connection as a whole.  Some edits to bring it closer to the front of the section might be good.

Section 9 (path object)

I think this would be better after section 10 which describes mutli-network pathfinding (which presumably generates paths).

---
A couple subjects that I think should be in this doc

some specifics of delegation of resources from one NSA to another

maintenance of resource state in NSAs, particularly broker NSAs, during lifecycle of a connection

tiyng authorization sequence to path sequence [authorization is tied to trust, path to topology]

description of how federated networks relate to each other 

description of topology of federated network

describe what is in a path object and how it relates to NSAs

--


I hope this helps --

John







On Aug 9, 2010, at 11:51 AM, Guy Roberts wrote:

Hello All,
 
I have tidied up the remaining parts of the NSI architecture document and created a new ‘Connection Service’ document:
 
 
Please take a look in preparation for Wednesday’s call.
 
 
 
The following is dial-in information for Wednesday’s NSI call:
 
Time:  7:30 PDT  10:30 EDT, 15:30 BST,  16:30 CEST,  23:30 JST
 
Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0155180
 
Agenda,
 
Review the draft Connection Service Informational document.
 
 
Guy
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg