[Nsi-wg] Proposal: Subscribing of events in NSI

[John MacAuley]

Henrik,

Having notification subscriptions in a product I am currently working on makes me oversensitive to the issues that can crop up.  Here is some food for thought…

Should we support the ability to query subscriptions?  Would it be useful for an RA to query the PA for all valid subscriptions so it can audit after error and restart scenarios?

Would providing a filter on registration be useful?  For example, I only want to be notified of dataPlaneStateChange events on a connectionId.  I am trying to think of an application that might find this useful, but i think they would also want to know about errors, so maybe the filter provides no value here.

I assume a goal here is to not introduce the concept of a subscriptionId, so we will need to specify endpoint and connectionId in unsubscribe operations:

subscribe(connectionId[], endpoint, *filter*);
unsubscribe(connectionId[], endpoint);
listByConnectionId(connectionId[]);
listByEndpoint(endpoint);

Some things to thin about:

- Are subscriptions persistent?
- Are subscriptions removed automatically when the schedule is terminated (or after a guard time to make sure dataPlaneStateChange events have purculated up the tree).
- Define the behaviour around re-registering a subscription that already exists.  I may restart and want to make sure I am registered by sending down the same registration again.
- Do subscriptions time out?  For example, if I have not been able to deliver notifications to an endpoint for an hour can I automatically delete the subscription?

John

On 2013-04-18, at 4:13 AM, Henrik Thostrup Jensen <htj at nordu.net> wrote:

> Hi
> 
> At the meeeting yesterday John brought up the point of where notifications
> should be send to, as this is currently not properly defined. This is for
> messages such as dataPlaneStateChange and errorEvent (which includes forcedEnd
> and other).
> 
> One solution is to use the replyTo that was specified during the initial reserve. This has a number of limitations though, as it is not possible to change the where notification events go, and it is not possible to notify multiple parties.
> 
> Instead we came up with the suggestion of explicit subscriptions. This means including to new messaging primitives for subscribing and subscribe to notifications. Furthermore we would add a way to indicate subsription in the header for future events. This allows subscribing in a reserve without having to send a seperate subscribe message. This can either be a flag indicating to use the replyTo field or a seperate field (are there any uses for different replyTo and subscription events).
> 
> 
> Implications of adding this:
> 
> * Two new message primitives: subscribe and unsubscribe.
> - A subscribe message will have a single endpoint, and can specify a
>   number of connection ids.
> - The return message should specify which connection ids the subscription
>   succeeded
> * A flag or a field in the header for subscribing.
> 
> 
>    Best regards, Henrik
> 
> Henrik Thostrup Jensen <htj at nordu.net>
> Software Developer, NORDUnet
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg