Re: Notification Message Processing Model

[Andy Bierman <ietf@andybierman.com>]

Hector Trevino (htrevino) wrote:
> It was in my response to your original e-mail. Pasted below
>
> "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. "
>   

Okay.
This is really just part of the previously mentioned advantage that the
management station saves a netconf session per agent,
which saves memory, a TCP connection, and a tiny amount of bandwidth.

The code and documentation complexity are higher when notifications
and RPCs are mixed on the same channel.  That much is established consensus.
Whether or not the additional complexity warrants the manager resource 
savings
is not clear.


> Hector
>   

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