Subject: requirement: agent initiated session support

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Mar 2006 07:18:59 -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: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 31 Mar 2006 12:38:59 +0200

On Thu, Mar 30, 2006 at 07:18:59AM -0800, Andy Bierman wrote:

[...]

I just added

* solution should support preconfigured notification destinations [AB]

to the wiki page.

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

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 

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.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Andy Bierman <[email-masked]>
Date: Fri, 31 Mar 2006 06:10:10 -0800

> * 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.

> things if the checks do not deliver the expected outcome.

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

> (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.)

> crashing apps leave garbage around which is painful to try to clean as

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.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 31 Mar 2006 16:27:57 +0200

> We have users and sessions in netconf, not host endpoints like snmp.

I fail to see how your comment applies to the quoted text. I do not
understand why you wrote the last sentence at all.

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

He? Please help me understand what you mean. I fail to match you
comment to the quoted text.
 
> (An agent may not allow a profile in use to be modified.)

Show me the detailed profile information you have in mind and how this
can be tweaked by an app that comes and goes and I will then tell you
whether I consider a plain subscription "the most complex manner
possible".

> >* solution should support preconfigured notification destinations [AB]

I do not understand your message.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 31 Mar 2006 06:36:21 -0800

> understand why you wrote the last sentence at all.

A destination is not enough in netconf, but I guess you meant
this is a generic sense

> comment to the quoted text.

I don't think it's a good idea to use a design
which excludes important use cases.

> whether I consider a plain subscription "the most complex manner

I'm not writing the data model now.
If you think the parameters in the current draft
are sufficient, then imagine those parameters
in a real data model instead of RPC parameters.

> I do not understand your message.

You should add a requirement about scaling so it won't
get ignored.  The subscription model has some scaling
problems that don't exist in the traditional notification
generator application model.

Andy