Forgot to copy the NSI mailing list. Begin forwarded message:

From: John MacAuley <macauley@es.net> Subject: ReserveTimeout exposure Date: 17 November, 2015 12:39:40 PM EST To: Henrik Thostrup Jensen <htj@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