Proposal: Subscribing of events in NSI
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
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@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi On Thu, 18 Apr 2013, John MacAuley wrote:
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…
It is always easy to add stuff :-).
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?
I'd say no. An RA can just resubscribe instead of trying to probe the state. This is a pattern which I see a bit too often IMHO: Trying to figure out the current state and the reacting on it. Just do the damn thing. Detecting duplicate strings and saying OK is not complicated.
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.
The number of notifications is going to be relatively small, so I'd say the client can do the filtering.
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);
I don't really think we need the latter two and the filter.
Some things to thin about:
- Are subscriptions persistent?
I'd say yes, otherwise they are not really useful.
- Are subscriptions removed automatically when the schedule is terminated (or after a guard time to make sure dataPlaneStateChange events have purculated up the tree).
I'd just remove them along with all the connection data, when it is reaped some time after termination. It is an array of strings, nothing complicated to keep in a database.
- 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.
That is ok. The PA should just detect the duplicate and return an OK. Idempotent operations are a good thing.
- 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?
A subscription is a static thing (at least as a starting point :-)). A notification message can timeout if it cannot be delivered. Retries and such are OK, but at some point the notification must be dropped. Most who have worked with subscriptions outside a lab setup have realized that some notifications will be lost. The solution is typically to fallback to polling (query) for certain situations. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi John and all I concur that there are quite a few possible issues to consider and discuss. May I suggest that we follow our new process of someone making a proposal, schedule a weekly call to present it. And then we consider? Also, I strongly advise against adding this feature now. I suggest we focus on the v2 doc to get it completed before we add more new fearures. IMO we make a pub/sub notification process part of or a requirement in "v3'. BR Jerry Sent from my iPhone On Apr 18, 2013, at 11:02 AM, John MacAuley <john.macauley@surfnet.nl> wrote:
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@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (3)
-
Henrik Thostrup Jensen -
Jerry Sobieski -
John MacAuley