Subject: RE: netconf notification transport issues

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 26 Jan 2006 12:17:45 -0500

hi

There are cases when you want to have your synchronous commands on the
same connection as your asynchronous one.  This obviously does not imply
you always want to do this.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Thursday, January 26, 2006 12:08 PM
To: Balazs Lengyel
Cc: Netconf (E-mail)
Subject: Re: netconf notification transport issues

Balazs Lengyel wrote:

> Hello,
> Someone brought up the scenario that one netconf management system
> might supervise many (thousands) nodes. In this case requiring the 
> manager to have 2 instead of one sessions for each node might be a 
> problem.
>
> What is the problem actually with multi-use ? (The advantage of having
> fewer sessions is clear.) Even if we have multi-use sessions do we 
> really need multiple channels ? Why ?
>

It is a complexity tradeoff, not a problem.
I think the WG wants multi-use sessions, but I want to make sure.
The point of multiple channels or connections per session is too
keep notifications and rpcs separate.  If they share, they are
serialized.

So let's say your application is dumping the entire config on a huge
router
 -- a <get-config> that takes 28 minutes to complete.  Let's also say 
that a
one of the power supplies on that router  freaks out and fries 3 
daughter-cards
at once, 30 seconds after this <rpc-reply> starts.  That means you have 
a major
outage for at least 27.5 minutes before you know about it.  Not exactly
how
async notifications are meant to be used.

This is why you really don't want to do RPCs and receive notifications 
on the
message path, if you care about fault response time.

Andy

> Having a never ending RPC call that sound as a strange use of the RPC 
> concept for me also someone told me on this list that one RPC call can

> only get ONE reply. Is that so ?
>
> regards Balazs
>
> Andy Bierman wrote:
>
>> Hi,
>>
>> Phil brought up some transport issues again, that I think we should
>> find out some opinions, one way or the other.
>>
>> 1) Multi-use session
>>
>>   Is it important that a manager be able to issue <rpc> calls and
>>   receive <notification> messages within the same session?
>>
>>   The other option (Single-use session) implies that the manager
>>   will establish multiple single purpose sessions instead.
>>
>>   As Phil pointed out, if single-use is okay, then the manager can
>>   simply make a 'start-receiving-notifications' RPC call that
>>   never finishes (usually until the manager shuts down the session).
>>
>>
>> 2) Multiple channels and Multiple Connections
>>
>>   Should we try to bring back this concept?
>>   Wasn't this the main reason we picked BEEP in the first place?
>>   Is the BEEP mapping that relevant without it?
>>   This issue is only relevant if multi-use sessions are required.
>>
>>
>> 3) Application Acks and Reverse RPCs
>>
>>   As Phil and I pointed out in emails, a notification with an
>>   application-ack is really just another <rpc> method, but
>>   from the agent to the manager.  It might be simpler to define
>>   how to reverse the flow for notification purposes, rather
>>   than redefining the <rpc> and <rpc-reply> elements.
>>
>>   Should this feature be dropped, capability-based, or mandatory?
>>   If kept, how should it be done?
>>
>>
>> 4) Any More Transport Issues??
>>
>> 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/>
>
>

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

--
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: Thu, 26 Jan 2006 09:42:18 -0800

>you always want to do this.

Agreed.  That's why I specifically said 'fault'.
(I tried to remind people which problem-space really matters,
and why netconf is much more than an XML document problem.)

I like the subscribe-model that is in the current draft.
It allows for subscribing to notifications for eventClass='fault'
separately from everything else.  You could call this RPC
multiple times, but there needs to be a way to tell the agent
to use a separate message path somehow.

The transport details need to be resolved of course.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 26 Jan 2006 13:18:51 -0500

>you always want to do this.

Can you give details or use cases?

Thanks,
 Phil