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