Subject: RE: Notification Message Processing Model

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 23 Mar 2006 09:39:21 -0500

hi

I think we have already said that when it makes operational sense to
perform your asynchronous commands on a separate connections, then
operators/managers will likely choose to do so. Some of these cases are
interesting for when the operator/manager does not anticipate the impact
of operations they are performing and puts things on the same connection
that perhaps shouldn't have been.

From my perspective, the operations that I expect to be on the same
connection are those related to notifications I receive. Learning about
the state of the system when I start managing it, perhaps asking
follow-up questions to the information received in the notification.

<Andy>
1) agent message priority (<rpc-reply> vs. <notification>).
   It is possible that messages of both type need to be queued
   for output in the agent.  Who wins if both are waiting?
   (Hint: operationally, both answers could be wrong.)
</Andy>

I'm not sure we need to specify. Is first in first out not sufficient?
As you have hinted, there are problems and benefits to all approaches. I
see the most interest in priority-based queuing based on the importance
of the individual notification, not generally by whether it is a
notification or something else.

<Andy>
2) The sword cuts both ways.
   We could have really big notifications, not just a
   really big <rpc-reply>.  This can seriously impair
   the use of the session for time-sensitive RPC operations
   (like fire-fighting a virus attack by making a configuration
   change to a firewall, router interface ACL entry, etc.).
</Andy>

I believe the event class will predict in a lot of cases how big the
notification will be.

<Andy>  
3) lack of an <abort> command.
   The manager cannot shut up the agent if it is spewing a reply
   or a notification, except by closing the connection.
   We took this command out of the protocol when we took out
   channels.  We took out channels because of unwarranted inherent
   complexity.
</Andy>

At least with the current design, you can send a <cancel-subscription>
command between notifications.

<Andy>
4) notification amplification
   Multiple notification subscriptions per session means that
   there are potentially N copies of every notification that
   get generated by the agent per session, where N is the number
   of subscriptions. This makes the impact of issues (2) and (3)
   even worse.
</Andy>

I'm not sure this is really an issue. I imagine perhaps a 30%
duplication rate among multiple subscriptions when they are used. I
can't imagine why someone would create N identical subscriptions as it
is more work for the operator/manager too. They will be used when they
provide value and I believe this is more the case when there is much
smaller amounts of overlap.

<Andy>
5) notification rate control
   The content-filtering is not a rate control mechanism,
   despite that appearance in the draft. (Just the opposite -- see (4))
   The document will need to define adequate rate control
   and notification queueing mechanisms (better than FIFO logjam).
</Andy>

Rate throttling is always a problem. I didn't think we included much
about it in the draft, so I'm not sure what you referring to. Filtering
would help somewhat since there are some notifications that will never
get sent so don't need to throttled, but obviously it remains an issue.
Rate throttling is not a minor topic, so we will have to decide how far
down that road we want to go. An understanding of the relationship
between sequence numbers and throttling is helpful and I can't remember
if we included that in the draft. It is easy enough to add that piece.

<Andy>
6) meltdown avoidance and repair
   It is very likely the NE device will be generating lots of
   event notifications when things go bad in a hurry, just as
   the operator is trying to reconfigure the device to make the
   root cause of the notification flood go away.  The document
   needs to define mechanisms to detect and prevent this type of
   scenario.
</Andy>

This is where throttling would help. Prioritized throttling is better
then just flow control, but again, we would have to decide how far down
this road we wish to explore.

Sharon

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Kent Watsen" <[email-masked]>
Date: Sat, 25 Mar 2006 12:50:22 -0800

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