[Nsi-wg] Notifications

John MacAuley john.macauley at surfnet.nl
Thu Jun 20 11:26:53 EDT 2013


Hello Allan,

In the end I realized that the notificationId only need be unique in the context of a conectionId, since we are retrieving using the connectionId for additional context.

The DataPlaneStateChange notification was left out of the queryNotification since the current state can be determined by querying the state machine.  At least, this was my justification for leaving them out.  Do you see a use case that would require these notifications to be included?  It definitely would make the solution complete around notifications.

John

On 2013-06-20, at 11:15 AM, Alan van Dam <avandam at zilverline.com> wrote:

> HiHi,
> 
> The last couple of days we implemented the two new notification query operations in our UPA, BandwidthOnDemand.
> Doing this we had a few questions:
> 
> * Sending a DataPlaneStateChange to the requester requires a notificationId. (A DataPlaneStateChangeRequestType extends a NotificationBaseType which has a notificationId.) Which suggests it is a notification that can be queried.
> When doing a notificationQuery the response (queryNotificationConfirmed) only contains errorEvent, reserveTimeout and messageDeliveryTimeout notifications. We expected it to contain DataPlaneStateChanges as well, because it is a notification (it extends NotificationBaseType). I understand that the data plan state can be queried with a querySummary but the history of provision/release can not. I would suggest to let queryNotification also return the data plane state change notifications.
> 
> * In the pdf attached to issue 92 solution 2b says that the notificationId should be unique per NSA. Currently we implemented the connectionId to be unique per connection. I think this makes it easier to follow the notifications because there should be almost no gaps between the notification ids. If the query contains the data plane state change notifications no gaps at all.
> 
> Cheers,
> Alan van Dam
> Team member of SURFnet BandwidthOnDemand
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg



More information about the nsi-wg mailing list