Subject: Re: Informal Issue summary for Netconf Notification

From: Balazs Lengyel <[email-masked]>
Date: Mon, 20 Mar 2006 11:54:49 +0100

Hello Sharon,
I think some guidelines about this question should be included in the notifications draft 
so people understand the situation the possibilities and the consequences. We can argue 
whether they should be in the main part or an Annex.

Balazs

Sharon Chisholm wrote:
> hi
> 
> Well, I would say it isn't a gating problem, because people can choose
> to use separate sessions if they think the command will take a long
> time. It's a reasonable workaround since I don't think configuration
> connections would be as long lived.
> 
> The problem could be solved via some sort of fragmentation mechanism for
> large commands, but I don't think we need it yet. Retrieving active
> alarm list is an interesting case where you would want them to be on the
> session, but we have an event-replay mechanism where this isn't a
> problem.
> 
> If resources are tight and they really only want one connection, then
> multiple channel support seems to be the better solution.
> 
> Sharon
> 
> -----Original Message-----
> From: Balazs Lengyel [mailto:[email-masked]] 
> Sent: Friday, March 17, 2006 10:54 AM
> To: Chisholm, Sharon [CAR:ZZ00:EXCH]
> Subject: Re: Informal Issue summary for Netconf Notification
> 
> 
> Sharon,
> Someone voiced the concern that if we have only a single channel and use
> the same Netconf 
> connection for both configuration and notifications then a big response
> to a <get> 
> operation might block notifications for considerable time.
> What is the solution?
> - You don't think this is a problem
> - it is recommended to use separate Netconf connections
> - multi-channel
> - the problem is not a real problem because ???
> - else
> 
> regards Balazs
> 
> Sharon Chisholm wrote:
>> 3)	Multiple-channel support: seem to have consensus to defer
>>
>   > Sharon Chisholm
>> Nortel
>> Ottawa, Ontario
>> Canada
>>
>> --
>> 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/>
> 

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

--
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: Phil Shafer <[email-masked]>
Date: Mon, 20 Mar 2006 08:57:16 -0500

Balazs Lengyel writes:
>so people understand the situation the possibilities and the consequences.

I just keep thinking about the times I need notifications while I'm
doing a non-instantaneous RPC, such as <commit-config>.  Having to
wait til the operation is done to see that my new igp config melted
my network might be a bad thing.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Mar 2006 06:16:01 -0800

> my network might be a bad thing.

One big concern I have with the Notification draft is whether the 
inherent complexity
is warranted for the specific task at hand.   The first thing I notice 
is that there
aren't any deployed solutions which send notifications and operations on the
same connection. 

I find very little established operational validity in the idea that 
this is even
a "nice to have" feature, let alone mandatory functionality.
The cost of an additional connection for notifications is trivial.
The notion that this "shared session" mechanism somehow obviates the 
need to do
event correlation is also flawed.   A well-designed manager needs
to account for notifications that its own direct actions did not cause
(e.g., the notion that of all the notifications that get generated after 
a <commit> are
related to that <commit> may be  incorrect).

Andy