Hi all,

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

Thanks to John Vollbrecht for the agenda:

1) Do we agree that Modify primitive for Connections will not be in V.1 

      - I agree, though I think it could (maybe should) be in the architecture V1 doc and not in the protocol V1.

2) Do we agree that Notify will be in V1

        - I agree, the question is whether Notify is a service (for NSA as a whole) or a primitive (for connection service) or both.  I vote for it being a service but could be either and changed in public comment time if we so decide.

3) How do we handle start and end time?

      - this is a  trickier issue.  Seems to me there are two users of time  - the application using the network, and the network allocating resources to the connection.  Whatever we decide needs to be usable by both classes of users. 

- for applications they need to know when the connection is available for them. 

-an argument is that the network should send a notify to the user when the network is "available" .  My take is that this is good, and many applications will use it.

regardless of whether a notify is sent, one must decide whether time in a request is for available time, or time to start making the connection.  I am not sure there is a good answer unless one were to somehow include both, which has not been discussed before.

--------------------------

A new issue:

The proposed connection service has two fields (see sec 3 in the attached doc), that describe the connection.  One field, the serviceInstance-attribute describes the performance characteristics of the connection, and is use by the application to define the characteristics it needs in the connection.  The other field describes the topology of the connection and is used by network providers to reserve and provision the network.

The issue I think worth discussing is what is in the topology or path field.

My thinking is is that in the confirm message at least, the path field has information about the connection itself and any sub-connections.  It contains the ingress of the network  and potentially segments in between.  Segments may not be included for several reasons, including that networks may not want their information exported beyond the original requestor, or because there are no subnetworks.

A path field then would contain something like

[NSA1:CID-1, Ingress1[ [NSAa:CID-a, Ingress-1,Egress-a] [NSAb:CID-b, Ingress-b, Egress-b] [NSAc:CID-c, Ingress-c,Egress-1], Egress1]

This is not well defined, the intent is that it MUST contain CID, Ingress and Egress.  It MAY contain segments that are connections in their own right.  This could be nested as well.  The CIDs include the id of the NSA that authorized the connection.  One could imagine other elements in this field, like time.  This might be used to carry network reservation time, while the service attribute would carry available time.  This is something to think about.