[Nsi-wg] Version 0 question

[John MacAuley]

Peoples,

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.  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?  If we agree then when querying a version 0 reservation there will be no version number.

    <xsd:complexType name="ReservationConfirmCriteriaType">
        <xsd:sequence>
            <xsd:element name="schedule"            type="tns:ScheduleType" />
            <xsd:element name="bandwidth"           type="xsd:int" />
            <xsd:element name="serviceAttributes"   type="ftypes:TypeValuePairListType" />
            <xsd:element name="path"                type="tns:PathType" />
        </xsd:sequence>
        <xsd:attribute   name="version"             type="xsd:int" use="required" />
    </xsd:complexType>

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?

    <xsd:complexType name="ConnectionStatesType">
        <xsd:sequence>
            <xsd:element name="reservationState"   type="tns:ReservationStateEnumType" />
            <xsd:element name="provisionState"     type="tns:ProvisionStateEnumType" />
            <xsd:element name="lifecycleState"     type="tns:LifecycleStateEnumType" />
            <xsd:element name="dataPlaneStatus"    type="tns:DataPlaneStatusType" />
        </xsd:sequence>
    </xsd:complexType>  

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?


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>

Comments?

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20130523/765d0410/attachment-0001.html>