search

netconf-wg / yang-push

Repository to keep track of yang-push draft.
4 stars 0 forks source link

Multiple receivers per Static Subscription #2

Closed ericvoit closed 7 years ago

ericvoit commented 8 years ago

Do we support many receivers for a single static subscription? Or should we have many subscriptions aggregated in a group tied to one filtered set of push updates

Note that this might intersect with the definition of what is a stream.

chiz99 commented 8 years ago

What attributes are looked to be shared across multiple receivers? The traditional design pattern for this would be to have a profile (filter-profile?) that gets named and stored and can be applied to multiple instances of something (subscriptions).

Sharon

From: ericvoit [mailto:notifications@github.com] Sent: Thursday, May 05, 2016 3:57 PM To: netconf-wg/yang-push Subject: [netconf-wg/yang-push] Multiple receivers per Static Subscription (#2)

Do we support many receivers for a single static subscription? Or should we have many subscriptions aggregated in a group tied to one filtered set of push updates

Note that this might intersect with the definition of what is a stream.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://github.com/netconf-wg/yang-push/issues/2

ericvoit commented 8 years ago

The current draft's YANG subscription model does have filter re-use. And I suspect that applying reused filters for event notification filters this might not be very expensive.for system generated events. But that is not the underlying cost which drove this issue.

For large YANG datastore extracts it can be expensive to recreate the same customized event notification stream towards multiple recipients. This is why a large MSDC customer wants many recipients for the same info.

Some have argued that this is an implementation detail, and that you could still have some aggregate subscription group generating a reused event stream. But that is kind-of complicated to implement as you must continually evaluate membership in the group (including if a management plane subscription modification is done on one of the members.)

This is why I think the jury is out on whether this complexity should be exposed or hidden. As well as how it might be hidden.

abierman commented 8 years ago

Hi,

I would like to know why this extreme server implementation complexity is warranted, given:

IMO a single receiver per session is much more operationally useful, simpler to understand, and simpler to implement.

Andy

On Fri, May 6, 2016 at 11:38 AM, Sharon notifications@github.com wrote:

What attributes are looked to be shared across multiple receivers? The traditional design pattern for this would be to have a profile (filter-profile?) that gets named and stored and can be applied to multiple instances of something (subscriptions).

Sharon

From: ericvoit [mailto:notifications@github.com] Sent: Thursday, May 05, 2016 3:57 PM To: netconf-wg/yang-push Subject: [netconf-wg/yang-push] Multiple receivers per Static Subscription (#2)

Do we support many receivers for a single static subscription? Or should we have many subscriptions aggregated in a group tied to one filtered set of push updates

Note that this might intersect with the definition of what is a stream.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub< https://github.com/netconf-wg/yang-push/issues/2>

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/netconf-wg/yang-push/issues/2#issuecomment-217524877

ericvoit commented 8 years ago

I think the cost is based on what I listed in my response to Sharon. We shouldn't have to regenerate custom datastore extracts for multiple recipients. Especially as some MSDCs want replicated streams for redundancy purposes.

This problem can be solved with lots of code which decouples custom stream generation from the subscription itself. (Maybe there is an under-the-covers subscription group which is invisibly managed to reduce on-box processing.) But there is complexity here which shouldn't be dismissed.

ericvoit commented 8 years ago

Hi Andy,

I posted a couple responses directly to the wiki. If you don’t automatically get them pushed to you, could you let me know? I am trying to figure out whether to reply to the emails, or just post to the web.

Thanks, Eric

From: Andy Bierman, May 06, 2016 6:25 PM

Hi,

I would like to know why this extreme server implementation complexity is warranted, given:

IMO a single receiver per session is much more operationally useful, simpler to understand, and simpler to implement.

Andy

On Fri, May 6, 2016 at 11:38 AM, Sharon notifications@github.com wrote:

What attributes are looked to be shared across multiple receivers? The traditional design pattern for this would be to have a profile (filter-profile?) that gets named and stored and can be applied to multiple instances of something (subscriptions).

Sharon

From: ericvoit [mailto:notifications@github.com] Sent: Thursday, May 05, 2016 3:57 PM To: netconf-wg/yang-push Subject: [netconf-wg/yang-push] Multiple receivers per Static Subscription (#2)

Do we support many receivers for a single static subscription? Or should we have many subscriptions aggregated in a group tied to one filtered set of push updates

Note that this might intersect with the definition of what is a stream.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub< https://github.com/netconf-wg/yang-push/issues/2>

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/netconf-wg/yang-push/issues/2#issuecomment-217524877

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHubhttps://github.com/netconf-wg/yang-push/issues/2#issuecomment-217578301

abierman commented 8 years ago

On Fri, May 6, 2016 at 3:39 PM, ericvoit notifications@github.com wrote:

I think the cost is based on what I listed in my response to Sharon. We shouldn't have to regenerate custom datastore extracts for multiple recipients. Especially as some MSDCs want replicated streams for redundancy purposes.

You are making lots of assumptions about implementation details.

Also, it is trivial to make 1 variant of the subscription request RPC to be "clone subscription-ID 42, but with this receiver address".

You didn't answer how the operator debugs delivery problems to multiple addresses, or how the server deals with undeliverable data. There is limited buffering so what does the server do? drop new events? drop old events?

This problem can be solved with lots of code which decouples custom stream

generation from the subscription itself. (Maybe there is an under-the-covers subscription group which is invisibly managed to reduce on-box processing.) But there is complexity here which shouldn't be dismissed.

The code can recognize what can be shared no matter how the inputs are presented.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/netconf-wg/yang-push/issues/2#issuecomment-217580525

Andy

ericvoit commented 7 years ago

We are doing this, as reflected in 5277bis