[Nsi-wg] Version 0 question

[Henrik Thostrup Jensen]

On Thu, 23 May 2013, John MacAuley wrote:

> I was closing off the WSDL documentation last night when I stumbled upon 
> something I think we need to clarify.  The agreement so far as I 
> understand it is that when the initial reservation sequence is in 
> progress any queries to of that schedule will return version 0 with no 
> associated criteria.

I thought we agreed, that query would only show the latest committed 
version, and that this would also remove a lot of "specialness" of version 
0.

Furthermore I believe agreed that a query for a non-committed initial 
version, would only show the shell, but I can see the problem with this.


> Here is the XSD segment in question (I have expanded the element group 
> in line for readability):
> 
>     <xsd:complexType name="QuerySummaryResultType">
>         <xsd:sequence>
>             <xsd:element name="connectionId"        type="tns:ConnectionIdType" />
>             <xsd:element name="globalReservationId" type="tns:GlobalReservationIdType" minOccurs="0" />
>             <xsd:element name="description"         type="xsd:string" minOccurs="0" />
>             <xsd:element name="criteria"            type="tns:ReservationConfirmCriteriaType"
> minOccurs="0" maxOccurs="unbounded" />
>             <xsd:element name="requesterNSA"       type="ftypes:NsaIdType" />
>             <xsd:element name="connectionStates"   type="tns:ConnectionStatesType" />
>             <xsd:element name="children"           type="tns:ChildSummaryListType" minOccurs="0" />
>         </xsd:sequence>
>     </xsd:complexType>
> 
> So in the case of a query of a version 0 reservation I have a bit of an issue based on the current
> structural layout:



> 1. The "criteria" element was made optional to allow for version 0 and no committed criteria.  The
> version attribute is in the criteria element (see below), so it will not be available for version 0 in
> the current form.  Are we okay with that?

I don't see the problem with that. In fact, I think it plays rather well, 
with the "don't show non-committed resources". IMO the problem is more 
with what to show in connectionStates and children (though the latter can 
be left out).

> If we agree then when querying a version 0 reservation there will be no 
> version number.

I think this is good. I don't care much for the special version number 0.

> 2. The "connectionStates" element is not optional, however, there is an "unknown" state in each SM to
> allow for this initial undefined state.  Are we okay with this as well?

Hmm. I think the current mantra is that the PSM and LSM (and maybe 
dataPlaneStatus as well), does not exist until a connection has actually 
been committed. However that could also be a special state (and I'd 
strongly prefer that over unknown, as it makes it clear what is going on).

I am also unsure of what to put in dataPlaneStatus version and 
versionConsistent before activation and after teardown, as those values 
don't really make any sense when the data plane is down.

> 3. The "children" element that models the child NSA connections associated with this reservation would
> not be present for version 0, however, I only model the current version of the child connection
> information.  Did we agree that this should be versioned as well and tracked for each reservation
> version made available?

In theory the children could be different for each version. If we want to 
allow for re-routing/changes after the initial version it has to be moved 
into ReservationConfirmCriteriaType (which would probably have to 
deplicated or grouped out somehow, but I'll leave that to you). IMHO we 
should do this, but I am not sure if we actually decided on anything.

> Finally, we will need to clearly document this somewhere in the core of the document.  In the initial
> version 0 case we would have something like this (minimal):
>
> <reservation>
> <connectionId>connid-000001</connectionId>
> <requesterNSA>urn:ogf:network:netherlight.net:2012:nsa</requesterNSA>
> <connectionStates>
> <reservationState>ReserveHeld</reservationState>
> < provisionState>Unknown</provisionState >
> <lifecycleState>Unknown</lifecycleState>
> <dataPlaneStatus>
> <active>false</active>
> <version>0</version>
> <versionConsistent>true</versionConsistent >
> </dataPlaneStatus >
> </connectionStates>
> </reservation>

I think some other values (which actually state what is going on) in 
provisionState and lifecycleState would be good. I cannot help thinking 
that the PSM and LSM actually need an initial state, that transits into 
their current initial state after the first commit.

I dislike the notion of having a version and versionConsistent info on a 
data plane that isn't active. It does not make sense IMO.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet