RE: Notification Message Processing Model

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

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