RE: Notification Message Processing Model

["Kent Watsen" <kwatsen@juniper.net>]

Andy Bierman wrote:
> I hate Requirements Documents but this document has hardly
> been read or reviewed by anybody in the WG.  I think we
> should try to agree on what we want to do with NETCONF
> notifications before going any further.  Real use cases,
> based on real products, used in real networks -- not
> "nice-to-have", "maybe need this someday" features.

NSM is Juniper's Enterprise-class NMS/EMS having a rather
diverse set of users:  small-to-medium enterprise, large
enterprise, retail outlet chains, service providers, telcos, 
federal, etc.

At the EMS-level, users want NSM to present management
as a suite of service-oriented applications - configuration
manager, software manager, status monitor, log analyzer, 
troubleshooter, etc.

Architecturally, NSM is composed of service-oriented 
components on a message bus - each having its own
logical connection to the device.  For instance, both the
configuration manager and the status monitor would
have their own NetConf session with the device to serve
their own needs.

However, both of these components desire the ability to
receive asynchronous notifications relevant to them - to
avoid polling for deltas periodically, which doesn't scale.
For instance, the configuration manager would like to be
notified when interesting parts of the config change due
to an out-of-band modification (i.e. via CLI, webUI, or
another management application).  Likewise, the status
monitor would like to be notified whenever interesting
parts of the device's state have changed beyond some
threshold.  Ideally, both of these notifications should
contain that which has changed (i.e. an XML sub-tree) to
avoid the need to poll for it with an <rpc>.

Please note that the log analyzer component, which has
its own logical connection to the device, may or may not
be interested in these same events - pending how it
has been configured.  But it definitely does not want the
events to be heirarchally-structured as it ultimately must
operate on a normalized list of fields - as customers want
the log viewer to present logs as if they are rows in a table
with a fixed number of columns... While the log analyzer
component could receive flattened xml logs, the value 
of this over structured syslog is not clear and surely the
processing of xml would be more expensive, which would
have a negative impact on our logging rate.

The net of all this is that we would like netconf to have a
publish-subscribe interface for notifications on the same
schema that netconf itself operates on.  Each subscription
should allow for any number of schema-based interest-
expressions and notifications should be the matching xml
sub-tree that may be pruned down by another filter.  Also,
I'd like to add that we view subscriptions to be somewhat
dynamic - for instance, as the user is clicking around the
interface, the status monitor might be subscribing and 
unsubscribing to different parts of the schema for the 
purpose of providing real-time updates to whatever the
user is looking at.

Hope that helps - and congrats on the IESG approval!

Kent


--
Kent Watsen
NSM Architect
Juniper Networks


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