RE: manager subscription model for notifications: usage survey

["Sharon Chisholm" <schishol@nortel.com>]

hi

I'm not sure which bit is tripping you up. The manager starts to manage
a network element and then subscribes for the information that is of
interest to it. If its interests change, it modifies the subscription.
If it no longer wishes to manage that network element (moved to another
manager for example), it cancels the subscription. If it loses
connection, it re-establishes and re-subscribes knowing that everything
got nice and cleaned up when the session went away.

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.

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/>