Forgot to copy the NSI mailing list.
Begin forwarded message:
> From: John MacAuley <macauley(a)es.net>
> Subject: ReserveTimeout exposure
> Date: 17 November, 2015 12:39:40 PM EST
> To: Henrik Thostrup Jensen <htj(a)nordu.net>
>
> Henrik,
>
> Thank you for the response. I have copied the nsi-wg to open the reserveTimeout discussion up to the list. I think we may have the incorrect behaviour documented, or we are interpreting it incorrectly, or I might be out to lunch, or all of the above.
>
>> OpenNSA always have an aggregator in it, even when there is only a single-network circuit setup. Since the ReserveTimeout is UPA-only the aggregator should not return it. So AFAICT this _can_ be correct behaviour for the aggregator.
>
>
> All,
>
> I was looking at that state machine and text yesterday since safnari does not model the ReserveTimeout state. I understand the AG not supporting the generation of the reserve_timeout event since it has no local resources, but it does support the propagation of the rsvTimeout.nt. The issue I have now is that the ReserveTimeout state is not showing up in any queries on the schedule. After I get a rsvTimeout.nt from a uPA via my AG, the AG view remains in the ReserveHeld state which is no longer accurate.
>
> Table 101 "RSM transition table" indicates the uPA transitions to ReserveTimeout when the (ReserveTimeout) event is received, generating a rsvtimeout.nt notification. A uPA should therefore expose that state when encountered.
>
> Can I assume the fact that the rsvtimeout.nt notification does not have its own column in table 101 means that it does not impact any AG state machines?
>
> If this is the case then I have an issue. There are uPA in the tree that are no longer holding resources but the parent AG still show the resources as held. I think the AG should expose the ReserveTimeout state. Can anyone remember the specific reason we did not expose this?
>
> Thanks,
> John
>
