Subject: RE: requirement: agent initiated session support

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 3 Apr 2006 10:11:12 -0400

hi

I'm now responding to myself, but anyways ....

<Sharon>

<Andy>
>> 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.)
</Andy>

As a manager who actually supported Notification subscription in SNMP, I
hated the pre-configured approach for two reasons:

1) It was way too complicated. It was spread out over 100 tables with
far too many options. Even the case you used 99 times out of 100 was a
lot of work. You would get it to work for some devices, then find one
where it didn't work and realize that you forgot to create a row in yet
another table. I like the idea of command-line options since it acts as
a deterrent from over-engineering the subscription model

2) It was persistent. I had to always check if I was already set up to
get notifications from the box. This was more annoying then it sounds.
</Sharon

I think part of the problem here is who is the authoritative source of
'what the netconf client is interested in'. The netconf server is the
authoritative source of device configuration. The Netconf client is the
authoritative source of what synchronous commands it wants response
from, but suddenly with asynchronous messaging, we are proposing that
the netconf server is the authoritative source of what the netconf
client is interested in? This is annoying as a client. It's more work
and a loss of control.

<Sharon>
Plus, in a connection-oriented model, would we have the idea of
subscriptions that were there, but not active for when the underlying
session died?

</Sharon>

I

--
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: Andy Bierman <[email-masked]>
Date: Mon, 03 Apr 2006 07:32:13 -0700

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

Good luck with your model in an actual network after a power outage.
In the subscribe model, none of the agents can send any notifications
until a manager connects to them and asks for notifications.  The startup
notifications are critical to have, to check for any
config/image/HW mismatches that occurred during boot-up.

IMO, this approach is complicated -- not the traditional model.
There will probably be 2 or 3 tables, not 100.
I never said "over-engineer it to death" like SNMP did.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 03 Apr 2006 08:13:27 -0700

Phil Shafer wrote:
> Andy Bierman writes:
> 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>

I like this!  (Reminds me of RMON TimeFilter ;-)

I assume there are some config parameters
to setup logging somewhere else.  If <realtime/> is
missing then the <rpc> finishes when all saved notifications
have been delivered. If present, then the <rpc> never finishes,
and (in this example) new notifications may be interleaved
with saved notifications, so the manager needs to check the
timestamp as usual.

What about making it a generic RPC:

  <rpc>
    <get-log-records>
       <type>accounting</type>    <!-- or syslog or whatever -->
       <since>YYYY-MM-DD.HH:MM:SS</since>
       <realtime/>
    </get-log-records>
  </rpc>

> Thanks,
>  Phil

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 03 Apr 2006 10:52:35 -0400

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 03 Apr 2006 16:36:20 -0400

Andy Bierman writes:
>to setup logging somewhere else.

Yup, I was going off memory, but there should be a <profile> element
containing the name of a pre-configured profile.  The profile's configuration
details the content and frequency for what's to be recorded.

>If <realtime/> is

Exactly.

>       <since>YYYY-MM-DD.HH:MM:SS</since>

Even under type=syslog, you may need a syslog filename/collection name,
so the server can associate content with the name, as well as having 
somewhere to put aging data.

Thanks,
 Phil

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 04 Apr 2006 09:49:37 +0200

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.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 04 Apr 2006 08:31:14 -0700

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

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 05 Apr 2006 08:53:05 +0200

I see the replay capability as an independent topic from subscription based notifications.

Also for us one use case is managing a relatively small number < 50 of big nodes where we 
do not want to loose any notifications. In this case replay is really useful. We already 
have it in an SNMP based system.

Still when managing hundreds or thousands of nodes replay might not be as useful.
If you object to replay I can live without it.

Balazs

Andy Bierman wrote:
> 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