Balazs Lengyel wrote:
I think having local copies is a good idea. We could think about the use case when the node is already running and the manager is switched on. This could follow a manager restart or a power outage where the agent comes up faster. The same could be useful if there is a trouble with the connection between the node and the manager.In this case some notifications are lost anyway. It would be nice to be able to get these once the manager is up and running. This would naturally complicate the agent somewhat, so one has to decide if it is worth the effort.
Worth the effort... hmmm... First, there will be different size ring buffers on each agent. The manager will not have as long as it wants to get all the startup notifications. It won't know how long it has to finish hunting down all the agents and retrieving their notifications (this sounds a lot more like dumb polling that notification-driven NM.) IMO, this is clearly a way to add more complexity to deal with an already inappropriately complex design. Just keep piling on complexity until you get it to work. I don't think the "manager-subscribe" model is appropriate for general notification management at all. It is somewhat convenient (in some contrived cases) for a manager to receive the supposedly related notifications immediately following an RPC operation on the same session. This is only true if the NMS has no need to centrally process notifications at all. I would like to know if there are any products used by operators that manage notifications with a client-subscribe, client-provides all parameters architecture. I doubt it. Even the publish/subscribe models use SW and NV-config on the agent so it knows what events to publish. Are there Cisco or Nortel products that work as described in the Notifications draft? If so, how do operators use it and in what kind of relative numbers (compared to more traditional notification approaches).
Balazs
Andy
Phil Shafer wrote:Andy Bierman writes:In the subscribe model, none of the agents can send any notificationsuntil a manager connects to them and asks for notifications. The startupnotifications are critical to have, to check for any config/image/HW mismatches that occurred during boot-up.We do this with our accounting-profiles RPC (which I'm planning on mimicing for syslog data) with a combination of the <realtime/> flag and the <since>timestamp</since argument. The system makes local copies of accounting records and can serve them up with a starting window, in realtime, or as a combination, where the records since the given timestamp are passed along and then the RPC switches to realtime. <rpc> <!-- from memory; check docs for accurate details --> <get-accounting-records> <since>YYYY-MM-DD.HH:MM:SS</since> <realtime/> </get-accounting-records> </rpc> Thanks, Phil -- 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/>