[Nsi-wg] Issue 49 in ogf-nsi-project: Missing information in detailed query?

[ogf-nsi-project at googlecode.com]

Comment #7 on issue 49 by jmacau... at gmail.com: Missing information in  
detailed query?
http://code.google.com/p/ogf-nsi-project/issues/detail?id=49

Time to update this open issue with additional notes.

Description of Issue:
The QueryConfirmed response for Summary results needs to return the list of  
child connectionId and the associated providerNSA for the connections if  
this reservation was broken down further.

Discussion of Issue:
The current reservationSummary type retuned in the QueryConfirmed response  
contains the target NSA's view of a connection reservation.  This includes  
basic reservation parameters (ReservationInfoGroup), the connectionState as  
known by the target NSA, and the simple path the reservation took also  
based on the target NSA's view.  There are three problems with the data  
returned:

1. The reservationSummary does not indicate if the target NSA is the root  
of the reservation, or a child in a reservation tree (i.e. the parent  
(requester) NSA is not identified if it exists.  Issue 63 was created to  
track this defect.

2. There is no indication if the reservation was further broken down into  
child NSA requests, and if it was, the connectionId and providerNSA  
associated with each child reservation.  This issue was created to track  
this specific defect.

3. The path object is ambiguous and may not clearly describe the true  
direction of the path used in the reservation.  We will need a new issue to  
track this one.

There are three proposals for a solution to this issue:
1. Enhance the existing QuerySummaryResultType to include the local view of  
the reservation and the local view of the child connections (providerNSA,  
connectionId, and perhaps derived connectionState).
2. Introduce a third message that would provide this additional local  
detail.
3. Support one message and specify a depth for the query.  Depth 0 would be  
the local NSA. Depth 1 would be local NSA plus one level of children deep  
in the tree.

Solution #1 provides desired information, but makes the summary query for  
simple state a bit more complex by including the additional child summary  
connection information.  Can we accept the additional overhead?

Solution #2 provides the additional local connection information similar to  
#1 but in a new QueryConfirmed response.  Do we want to introduce another  
query result type?

Solution #3 reduces the number of responses to a single message, however,  
it will require the additional local information to be included even when  
doing a recursive query down the tree since we are using a single result  
structure, and the information needs to be included when depth is 0.