Here is a diff. ReservationStateType, ProvisionStateType, and LifecycleStateType all removed since there was only a single state element once version was removed. </xsd:documentation> </xsd:annotation> <xsd:sequence> - <xsd:element name="reservationState" type="tns:ReservationStateType" /> - <xsd:element name="provisionState" type="tns:ProvisionStateType" /> - <xsd:element name="lifecycleState" type="tns:LifecycleStateType" /> + <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> - - <xsd:complexType name="ReservationStateType"> - <xsd:annotation> - <xsd:documentation xml:lang="en"> - Models the current connection reservation state. - - Elements: - - state - The state of the connection reservation state machine. - </xsd:documentation> - </xsd:annotation> - <xsd:sequence> - <xsd:element name="state" type="tns:ReservationStateEnumType" /> - </xsd:sequence> </xsd:complexType> - <xsd:complexType name="ProvisionStateType"> - <xsd:annotation> - <xsd:documentation xml:lang="en"> - Models the current connection lifecycle state. - - Elements: - - state - The state of the connection lifecycle state machine. - </xsd:documentation> - </xsd:annotation> - <xsd:sequence> - <xsd:element name="state" type="tns:ProvisionStateEnumType" /> - </xsd:sequence> - </xsd:complexType> - - <xsd:complexType name="LifecycleStateType"> - <xsd:annotation> - <xsd:documentation xml:lang="en"> - A connection lifecycle is terminated when a terminate request - is received. The Lifecycle State Machine models the termination - state of the reservation, and therefore, if the the terminate - request has been received. - - Elements: - - state - The termination state of the connection state machine. - </xsd:documentation> - </xsd:annotation> - <xsd:sequence> - <xsd:element name="state" type="tns:LifecycleStateEnumType" /> - </xsd:sequence> - </xsd:complexType> - On 2013-05-24, at 4:02 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:

On Thu, 23 May 2013, John MacAuley wrote:

...

I noticed I forgot to collapse the state types when I removed the version attribute. This will simplify things a little bit for Henrik ;-) <xsd:complexType name="ConnectionStatesType">

Not sure what actually change here. Could I get a diff?

I do have a follow-up question, regarding ConnectionStatesType, after hacking on the OpenNSA NSI2 aggregator yesterday:

What is the aggregator supposed to fill in ConnectionStatesType, when sending up notification, such as ErrorEvent? If it gets a single error event, the connection the aggregator represents won't be in a consistent state. There is a similar case with ReservationTimeout. Right now I have a set of state machines in the aggregator, but I am thinking that an RSM might not make an awful lot of sense in there at all.

Best regards, Henrik

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

I do have a follow-up question, regarding ConnectionStatesType, after hacking on the OpenNSA NSI2 aggregator yesterday:

What is the aggregator supposed to fill in ConnectionStatesType, when sending up notification, such as ErrorEvent? If it gets a single error event, the connection the aggregator represents won't be in a consistent state. There is a similar case with ReservationTimeout. Right now I have a set of state machines in the aggregator, but I am thinking that an RSM might not make an awful lot of sense in there at all.

The aggregator sends up the view of its connection states. This will let the parent know what, if any, transitions the aggregator went through as a result of the error. John

I have thought this through and I believe my first response about the aggregator was incorrect. My understand of ErrorEvent is that this error is generated by an NSA (in all cases so far a uPA) and passed up the tree with no aggregation. If this is really the case, then the states modelled are those of the uPA that generated the error event, and not those of the aggregator. Here are the error events we have currently defined: <xsd:enumeration value="activateFailed" /> <xsd:enumeration value="deactivateFailed" /> <xsd:enumeration value="dataplaneError" /> <xsd:enumeration value="forcedEnd" /> If we look at the first two events (activateFailed and deactivateFailed) we could derive the activation state by the failure, however, if we are completing a modification then this can tell us which version of the reservation was associated with the error. With a forcedEnd we could see that the lifecycle state machine was transitioned to terminated for that uPA segment. We could also assume this, but only if we agree this transition to terminated in the uPA is not a local implementation issue as currently discussed. So, there may not be huge value, but at the same time there could be some. John On 2013-05-27, at 3:53 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:

On Fri, 24 May 2013, John MacAuley wrote:

...

...

What is the aggregator supposed to fill in ConnectionStatesType, when sending up notification, such as ErrorEvent? If it gets a single error event, the connection the aggregator represents won't be in a consistent state. There is a similar case with ReservationTimeout. Right now I have a set of state machines in the aggregator, but I am thinking that an RSM might not make an awful lot of sense in there at all.

The aggregator sends up the view of its connection states.

But the view of the aggregator is inconsistent.

...

This will let the parent know what, if any, transitions the aggregator went through as a result of the error.

Does this mean that it is stuck an in -ing state, or does it move back into previous states or into a failed state?

Best regards, Henrik

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

_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg