[Nsi-wg] Version 0 question

[John MacAuley]

So to summarize:

1. Version stays in criteria and we are okay with it not being present in special zero case.

2. I make all states but reservationState optional so they do not need to be specified when the state machines do not exist (this was new to me but okay with it).

3. With #2 we avoid the need for additional states.

4. I figure out how to restructure to version children segments.

John

On 2013-05-24, at 4:29 AM, Henrik Thostrup Jensen <htj at nordu.net> wrote:

> 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_______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg