Notification Message Processing Model

[Andy Bierman <ietf@andybierman.com>]

Hi,

I am trying to understand how the protocol will have
to be modified to support notifications and RPCs on
the same channel-less connection.

The document will have to define all possible interactions
between RPC and notifications in the architecture, regardless
of whether 1 or 2 connections are used.  However, if a shared
connection is used, then all possible message processing
interactions within the same session also needs to be defined.

Some example issues to consider:

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.)

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.).
 
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.

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.

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).

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



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