Re: requirement: agent initiated session support

[Andy Bierman <ietf@andybierman.com>]

Juergen Schoenwaelder wrote:
> On Thu, Mar 30, 2006 at 07:18:59AM -0800, Andy Bierman wrote:
>
> [...]
>
> I just added
>
> * solution should support preconfigured notification destinations [AB]

What about the session and transport aspects, and losing
all the startup notifications if you use the subscription approach?
We have users and sessions in netconf, not host endpoints like snmp.


> to the wiki page.
>
> > 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.
>
> The subcription model helps to simplify management applications that
> are not constantly running, such as a configuration tools that you
> kick off once in a while (or periodically) to check and configure
> things if the checks do not deliver the expected outcome.

It doesn't work if the agent initiates the session.


> The preconfigured approach requires that such an app 
>
> (a) first finds a suitable notification receiver,
> (b) authenticates with this notification receiver,
> (c) subscribes to this notification receiver 


How is this any different if the client initiates it?
It's the same amount of code either way.

I favor a combined approach:

1) profile table
   Each profile contains the configuration data for that
   named profile

2) get rid of all the parameters in the start-notifications
   or modify-subscription except the profileName (index)

This way agents and managers can both share the profiles
and the manager won't reenter the same data in the most
complex manner possible every time.  I can configure
the agent to connect to notification receiver X using
profile Y.  The manager can just subscribe using profile Y.

(An agent may not allow a profile in use to be modified.)


> before it can actually start to do its job. In other words, such apps
> will always have a subscription and the question is whether you force
> such apps to go through an intermediary or provide the means to talk
> directly to the box in question.
>
> Perhaps you don't like such apps or you do not care much about the app
> side of things. This is the old story of finding the right balance
> between the "complexity" on the agent and the "complexity" on the
> manager. My SNMP experience is that the lack of a common way to
> subscribe to SNMP notifications has been a pain.
>
> Sure, with SNMPv3 you can in principle subscribe by configuring the
> target tables but this (a) requires appropriate authorization rules
> and (b) there is no standardized way to cleanup dynamic targets so
> crashing apps leave garbage around which is painful to try to clean as
> well.

What about the problem of losing all the startup notifications?
If apps care about that they better configure a notification
receiver in NVRAM.  What about discovery?  Does it really scale
for 100000 agents to come up, and 1 or a few managers find all
of them and check if they support notifications, and then
start subscriptions on all the appropriate boxes?  It sure
seems easier to just configure the subset of agents which are
notification generators to connect to a receiver upon reboot.

> /js

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