RE: Notification Message Processing Model

["Hector Trevino \(htrevino\)" <htrevino@cisco.com>]

From an operational standpoint it makes much more sense to have
dedicated connections or channels for commands/control & notifications.
When using SSH it is an operational/resource constraint decision whether
or not a full dedicated SSH session is used for commands & notifications
or a single session with multiple channels is utilized.
A notifications session/channel needs to allow the transfer of commands
(i.e. rpcs and notifications mixed) because for example (just one, there
are others) a management application dedicated to
monitoring/troubleshooting may need to retrieve additional information
in response to a received fault-notification. I think that in this
situations it is ok to simply interleave messages. 

Now, given the above, someone may decide to use a single session for
both rpcs and notifications. This is a lose-lose situation as you point
out below. One thing that could be done if need be is to allow
configuration of priorities (prioritize rpcs over notifications or
viceversa but that's about it) & things run to completion. 

See additional comments in-line
Hector


       
 

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Wednesday, March 22, 2006 8:57 PM
> To: Netconf (E-mail)
> Subject: Notification Message Processing Model
> 
> 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.)

Sure, no right answer here. But as I said above the implementation could
allow prioritization of rpcs or notifications at the user's convinence. 

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

Yes. But IMO this is an operational matter. The protocol cannot solve
bad operational planning (at least not w/o much not needed complexity).
The operator(s) responsible for managing the network are likely aware of
this or could be made aware and should choose to have dedicated
sessions/channels. 

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

I think an abort command would've been useful regardless of whether or
not you have
mixed rpcs and notifications. 

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

Yes, sure but again this comes back to operations as I commented in 2.
The document could have some operational guidelines/recommendations on
this. 

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

OK

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