[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: requirement: agent initiated session support

Hector Trevino (htrevino) wrote:

The main body of the netconf-notif doc does not describe this but
Appendix B.4 discusses potential protocol enhancements to support
NETCONF server session initiation. One of the use cases mentioned there
is "call home". 
The same appendix also mentions the subscription info persistency issue
that you talk about below. It is suggested as a potential enhnacement
but if you want "simple" then this is not a needed feature. The document
does not discuss a notification logging feature because it is not a
protocol feature (it is a system/model capability)- although it could be
added. So, I agree w/your comment about this being a problem but if
we're limited to protocol discussion then can't be addressed in the doc.



There's a lot of unspecified details in that appendix.
How does the manager know that some agent that initiates
the session wants it to invoke a <create-subscription> RPC?

The whole approach seems extra complicated for no apparent reason,
if I just want the agent to connect to a notification receiver
application using a pre-configured profile.



Hector



Andy








-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman 
Sent: Thursday, March 30, 2006 8:19 AM
To: Netconf (E-mail)
Subject: requirement: agent initiated session support

Hi,
The current subscribe model does not support agent initiated sessions at all. There are 2 use cases I think are important: 

1) notification generator application
   Traditional model as in SNMP.
   Agent SW dedicated to notification generation
   (maybe an aggregator for multiple sub-agents)
   Agent connects to the notification receiver application
   and sends notifications as they are generated.

2) bootstrap (thin agent)
   Agent is initially configured with a
  (username, password, cofig-server-IP-addr) tuple.
  Agent boots and immediately connects to the config-server
  (manager role in netconf), and issues a <configure-me>
  notification (perhaps with some parameters). The config
  server then issues <rpc> edit-config or copy-config
  commands to finish bootstrapping the agent.


Boot-up Problem with Subscribe model:
Using the client-subscribe model, all of the initial notifications generated upon system reboot will be lost because the agent isn't connected to a manager yet, and we have no NOTIFICATION-LOG-MIB. Requiring the agent to save all notifications because a manager might connect someday and request them is a huge memory burden and not likely to be supported.
In general, I don't really see the subscription model as an improvement over the traditional configuration data model approach. Even when used in the client-initiated mode, it isn't as efficient because the manager has to re-enter the config-data every time (in the form of a start-notifications RPC). If the profile wasn't opaque that could be used instead. 

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





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