RE: requirement: agent initiated session support

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

> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Friday, March 31, 2006 7:42 AM
> To: Hector Trevino (htrevino)
> Cc: Netconf (E-mail)
> Subject: 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?

HT: There are two cases that were covered for netconf server session
initiation a) call home and b) notification forwarding. Case "b"
required subscription information to be configured. Hence the need to
have persistency. Otherwise, I'd agree that the manger wouldn't know to
issue 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.

HT: Yes, I agree it would be. But what you say above is essentially what
the appendix attempted to describe (i.e. the notification destinations
have to be configured). This could be done by the netconf client or
pre-configured by hand (e.g. a profile as you indicate). The netconf
server (agent) establishes the session when there are notifications to
be sent out.  

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