Subject: requirement: agent initiated session support

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Mar 2006 07:01:21 -0800

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Hector Trevino \(htrevino\)" <[email-masked]>
Date: Fri, 31 Mar 2006 08:42:04 -0800

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> 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: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Andy Bierman
> >> Sent: Thursday, March 30, 2006 8:19 AM
> >> To: Netconf (E-mail)
> >> Subject: requirement: agent initiated session support
> >>
> >> Hi,
> >>
> initiated sessions 
> >> at all.  There are 2 use cases I think are important:
> >>
> >> 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 
> > to unsubscribe send a message to 
> [email-masked] with the 
> > word 'unsubscribe' in a single line as the message text body.