Subject: Notification Message Processing Model

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Mar 2006 19:57:09 -0800

Hi,

I am trying to understand how the protocol will have
to be modified to support notifications and RPCs on
the same channel-less connection.

The document will have to define all possible interactions
between RPC and notifications in the architecture, regardless
of whether 1 or 2 connections are used.  However, if a shared
connection is used, then all possible message processing
interactions within the same session also needs to be defined.

Some example issues to consider:

1) agent message priority (<rpc-reply> vs. <notification>).
   It is possible that messages of both type need to be queued
   for output in the agent.  Who wins if both are waiting?
   (Hint: operationally, both answers could be wrong.)

2) The sword cuts both ways.
   We could have really big notifications, not just a
   really big <rpc-reply>.  This can seriously impair
   the use of the session for time-sensitive RPC operations
   (like fire-fighting a virus attack by making a configuration
   change to a firewall, router interface ACL entry, etc.).
  
3) lack of an <abort> command.
   The manager cannot shut up the agent if it is spewing a reply
   or a notification, except by closing the connection.
   We took this command out of the protocol when we took out
   channels.  We took out channels because of unwarranted inherent
   complexity.

4) notification amplification
   Multiple notification subscriptions per session means that
   there are potentially N copies of every notification that
   get generated by the agent per session, where N is the number
   of subscriptions. This makes the impact of issues (2) and (3)
   even worse.

5) notification rate control
   The content-filtering is not a rate control mechanism,
   despite that appearance in the draft. (Just the opposite -- see (4))
   The document will need to define adequate rate control
   and notification queueing mechanisms (better than FIFO logjam).

6) meltdown avoidance and repair
   It is very likely the NE device will be generating lots of
   event notifications when things go bad in a hurry, just as
   the operator is trying to reconfigure the device to make the
   root cause of the notification flood go away.  The document
   needs to define mechanisms to detect and prevent this type of
   scenario.

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: Phil Shafer <[email-masked]>
Date: Wed, 22 Mar 2006 23:08:14 -0500

>   channels.  We took out channels because of unwarranted inherent

Any chance of getting <abort/> back in?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Mar 2006 20:20:56 -0800

> Any chance of getting <abort/> back in?

Not if any of the 4 completed documents have to be
modified in any way to support it.

That is, assuming the WG even wants it, which doesn't
seem to be the case.

Andy

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Mar 2006 22:39:19 -0600

If it's needed, this would be the sort of thing a capability might express.

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Mar 2006 05:38:17 -0800

> If it's needed, this would be the sort of thing a capability might express.

IMO, we have enough optional functionality already.
The permutations the manager needs to deal with should be considered here.

Also, you cannot use a capability to contradict normative text.
You can only use it to add normative text.

Andy

---

From: Shane Kerr <[email-masked]>
Date: Thu, 23 Mar 2006 16:53:04 +0100

> the same channel-less connection.

Rather than go into specific details, I would rather say that:

- - Putting notifications and RPCs on the same channel adds complexity to
the server.

- - It also adds complexity to the client (but really only to clients that
want it).

- - It would be nice to live without the complexity if we can.

I *think* this is pretty much what Andy Bierman has been saying.

As I see it, a client can usually multiplex two channels into one very
easily. Can someone explain a case where this is not true? (One case
presented in the working group where this may not be true is for clients
that are managing tens of thousands of devices. However, I think both
SSH and BEEP allow multiple channels on a single TCP connection, so we
should probably consider the "massive management" case a non-problem.)

Also, can someone give a specific example where putting notification and
RPCs on the same channel would be simpler than creating a new channel?

Apologies if this has already been given and I missed it!

- --
Shane

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Mar 2006 08:53:00 -0800

Shane Kerr wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andy Bierman wrote:
>   

Exactly.
I've been taught the whole art of Engineering is
having just enough complexity, but no more.
(A concept totally foreign to the IETF.)

> Apologies if this has already been given and I missed it!

No -- you missed nothing.
I have thought about it as much as I can.
I can't come up with any use cases in which a robust
event management system would be simpler because
operations and notifications were mixed on the same channel.

I have only found bad things that can happen to your OPS
if you did this.  No real benefits at all.  I'd love to hear
why management stations need this feature.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 24 Mar 2006 16:17:46 +0100

Hello,
It would be very useful if notifications could somehow reference a netconf RPC. I forsee a 
long running RPC that feeds back multiple results to the netconf manager (could be 
progress indication or something more serious). We could implement this using a set of 
notifications that contain a reference to the RPC.

I see that this can be solved without a combined rpc/notification connection but it might 
be easier putting both on the same channel.

I believe that while normal usage would be to have a separate connection for notifications 
and normal operations, but I feel we could still allow notifications on the normal 
operations channel.

Balazs