[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: manager subscription model for notifications: usage survey



<Andy> 
> By the way, the update, which was sent to the Internet Draft folks but

> hasn't shown up yet, does include an optional capability with 
> different behaviour meant to handle the call-home cases. I don't 
> expect this to be the method generally used since the normal 
> subscription is much more predictable and reliable, but as people have

> indicated there are cases when you need to reverse roles.


There is a simple established way to do this,
without adding massive amounts of complexity.
Just define a notification target data model and use the existing RPC
operations like edit-config to fill it in.

</Andy>

That's the easy part. The complexity is around managing your
subscriptions (determining if they already exist, pushing them out to
all the devices you are managing and trying to determining if things are
running as expected), but as people have said, in some use cases the
tradeoffs for the call-home approach make sense. They don't want the
simplicity of long-lived connections that self-clean in these cases.

Sharon


> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] 
> On Behalf Of Andy Bierman
> Sent: Friday, April 28, 2006 10:21 AM
> To: Netconf (E-mail)
> Subject: manager subscription model for notifications: usage survey
> 
> 
> Hi,
> 
> I am having a hard time understanding how the
> peer-to-peer manager subscribe model defined
> in the notifications draft fits with syslog and
> SNMP notifications already in use.
> 
> Who is using this model today?
> What products work this way today?
> 
> IMO, this is much different than the Tibco model.
> That is a publish/subscribe model with a virtual bus.
> The netconf proposal uses multiple point-to-point manager-initiated 
> subscriptions instead.
> 
> I think it would be wise to understand how the entire
> managed system is going to work when netconf notifications
> are added to the mix.   How will a network of 100 - 10000 devics
> behave in various common failure scenarios?
> 
> If this subscribe-only model is not being used in a meaningful way in 
> the real world, then I don't understand why we need to standardize it 
> at all.
> 
> 
> Andy
> 
> 
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with the

> word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with the

> word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>