RE: Notification architecture

["Sharon Chisholm" <schishol@nortel.com>]

hi

Tighter integration is a major driving factor. Plus, as much as we love
syslog, there are a few problems that I can't figure out how to solve
with it. 

As far as sessions go, the network element would not have to maintain
that many, perhaps only one, to the management application, so I am
guessing you are asking about the management application. Management
applications today that use things like TL1 and some proprietary
protocols are used to connection-oriented management and see to cope OK.
There is likely overhead, but they also save on not having to run keep
polling the SNMP agent to ensure it can still talk to the device. I
might look around to see if I can find any hard numbers (and if I can
share them).

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Martin Bjorklund
Sent: Tuesday, January 24, 2006 4:35 PM
To: ietf@andybierman.com
Cc: Chisholm, Sharon [CAR:ZZ00:EXCH]; netconf@ops.ietf.org
Subject: Re: Notification architecture


Hi,

This has probably been discussed before, and the answer might be
obvious, but I can't find anything in the archives.  I'd like to know
why a new notification framework is needed?  Is it simply that we need
to be able to send larger messages than what syslog can do?  Or is it
because the content of the notifications will be tightly coupled to the
ordinary netconf content, and therefore it's easier to use a new scheme
than trying to map the netconf model to syslog?  Or something else?

I think the most important question then is the session model - if the
manager should set up the session and keep it open or if the agent
should establish the session when needed.  If the manager is supposed to
keep it open, how well does that scale?  1000 sessions?  10000?



/martin


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