Subject: RE: requirement: agent initiated session support

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 3 Apr 2006 08:50:21 -0400

hi

<Andy and Hector discussing call-home deleted>

Doesn't the call-home stuff in the Beep draft just specify that the
agent initiates the connection, but then that normal roles resume?
Wouldn't that be what we would be looking for here? Is the discussion
about NAT traversal or are we trying to address another use case here?
Before we go down the road of making things more complicated, I just
want to understand the use cases.

Sharon

--
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: "Sharon Chisholm" <[email-masked]>
Date: Mon, 3 Apr 2006 10:38:22 -0400

<Andy>

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

If a tree falls in the forest ... what's the point of someone sending
out notifications if no one is listening to them? How exactly would that
work in the absence of a Netconf session anyways? (Note that on-device
logging and replay works fine with non-persistent subscriptions)

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

How is not requiring persistency more complicated?

Yes, there are always ways to keep things simple in theory. My favourite
is that if we do decide to allow persistency, that we also keep the
command line options. 

Sharon
=

---

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

hi

You don't need the end-less RPC thing for replay. You can use the same
message delivery mechanism for the replayed notifications as the
real-time ones. There are advantages to this continuity. You just need a
mechanism to let the client know the replay is completed. We opted for a
notification.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, April 03, 2006 12:22 PM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: requirement: agent initiated session support

Sharon Chisholm wrote:
> hi
> 
> There is no mechanism for replay in the current draft.

I meant the whole thing.
Phil is suggesting an endless-RPC if the <realtime/>
parameter is included.  IMO this is a nice simple approach.
The manager connects and gets new and 'old-since-time-X'
in the same RPC.  It can fill the data gap and keep going
in 1 easy step.

> Sharon

Andy

> 
> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]]
> Sent: Monday, April 03, 2006 11:37 AM
> To: Chisholm, Sharon [CAR:ZZ00:EXCH]
> Cc: Netconf (E-mail)
> Subject: Re: requirement: agent initiated session support
> 
> 
> Sharon Chisholm wrote:
>> hi
>>
>> This is similar to the event replay work we have done. Our method
>> works fine without persistent subscriptions. The user creates a new 
>> subscription with a timestamp that indicates the start of the replay 
>> window and the other parameters it sends when it creates a normal 
>> subscription.
>>
>> We didn't include it in the draft since we felt it could be done 
>> later
> 
>> as an optional capability.
>>
>> Is there interest in including replay in release one?
> 
> I'm interested in implementing what Phil is suggesting,
> not the mechanisms in the current draft.
> 
>> Sharon
> 
> Andy
> 
> 
> --
> to unsubscribe send a message to [email-masked] with the

> word 'unsubscribe' in a single line as the message text body.

---

From: "Kent Watsen" <[email-masked]>
Date: Mon, 3 Apr 2006 12:20:29 -0700

> Is there interest in including replay in release one?

I would like to see "replay" included as part of release one.

More importantly, though, since there continues to be confusion 
regarding requirements and real-world use cases - let me try again:

1. Agent-initiated connections (must-have)

   NSM supports both outbound connections to the device as well as 
   listening for inbound connections from the devices - all connections 
   use a multi-channeling transport.  Regardless of which peer initiates
   the underlying connection, NSM always assumes the role of "client"
   and the device always assumes the role of "server" - this is for 
   every protocol the connection multiplexes including crypto-setup, 
   auth, channel opening/closing, and a bunch of proprietary
configuration
   and notification protocols we implemented because the current
standards
   don't meet our needs [but NetConf has the potential to fix]

2. Subscription-based filters (must-have, for high-volume logging only)

   NSM's current logging protocol supports subscription-based filters 
   as some of Juniper's devices would otherwise have an unmanageable
   logging rate.  Depending on the application, only a subset of all
   notifications are interesting - for instance, a fault-analyzer only
   cares for fault-related logs and a security-analyzer only cares about
   traffic-related events.  The obvious purpose for device-side
filtering
   is to improve the signal-to-noise ratio, which in turn enables the
   application to scale better.

   All that said, I do NOT think that NetConf Notifications should ever 
   be used for high-volume throughput logging - XML is way too expensive

   for that.  If Netconf Notifications are limited to just
configuration-
   changes, then the need for device-side filtering may not be there...

3. Replay subscriptions (nice-to-have - for high-volume logging only)

   NSM's current logging protocol allows for the device to send logs
that
   may have been missed due to not being connected at the time the event
   occurred.  This is done by NSM telling the device, in its
subscription
   request, the timestamp of the last log it received and the device
doing
   its best effort to send that which was missed - this solution is only
   limited by the device's buffering capacity.

   All that said, NSM's configuration manager does NOT use this
mechanism
   to resynch its state as relying on the device's buffering capacity is
   fundamentally unreliable.  Thus, NSM's configuration manager always
   performs a diff to discover what has changed since its last
connection
   with the device.

4. Dynamic Subscriptions (must-have - for high-volume logging only)

   NSM's real-time monitor needs to modify its data subscription as 
   users navigate around the UI to monitor different aspects of the 
   device.  Please note that NSM may have multiple NSM client's looking
   at different aspects of the same device at the same time - regardless
   of the number of connected NSM clients, NSM always maintains just one
   connection to the device.  Without the ability to reliably replay
   notifications (see #3 above), re-connecting to the notification 
   channel whenever modifying the subscription would potentially result
   in lost notifications and stale information being presented to the 
   NSM client.

5. Notifications on same channel (nice-to-have)

   While I don't think this is architecturally critical, NSM's current
   proprietary configuration protocol does support notifications in the
   same channel as the RPCs - as I explained in my previous email, this
   was done because our configuration-manager component has its own 
   logical connection to the device and it needs to both send RPCs and
   receive config-oriented notifications.  However, without too much
   effort, we could have architected each of our components to always
   have two channels (one for RPCs and the other for notifications) or
   have an adapter to multiplex the two device-channels into one channel
   inside our system.

BTW, its worth noting that NSM doesn't have any issues multiplexing 
RPCs and notifications on the same channel since our protocol enables 
messages to be fragmented and interleaved over-the-wire (each side 
round-robins around their channel's send-queues).  This is where 
NetConf fails - the issue has never been if notifications will get
blocked by large RPCs - it is that NetConf allows large RPCs and 
they block everything!  NetConf's current "pipelined" nature inhibits
the ability for a management system to walk and chew gum on the same
channel.  While it may be more than this WG is ready to sign-up for,
I believe that we could fix this oversight via an "Asynchronous 
Capability" that each side would need to advertise in its <hello> 
enabling message-chunking - if there is sufficient interest, I could
draft a proposal for this...

Kent

--
Kent Watsen
NSM Architect
Juniper Networks

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 3 Apr 2006 13:21:04 -0400

<Juergen>
Sure, with SNMPv3 you can in principle subscribe by configuring the
target tables but this (a) requires appropriate authorization rules and
(b) there is no standardized way to cleanup dynamic targets so crashing
apps leave garbage around which is painful to try to clean as well.

</Juergen>

I'm catching up on the mailing list in reverse order, but Juergen raises
some good points here. I forgot about the garbage collection issue. 

Plus, I'm not sure I like the idea of other users being able to modify
my subscription.

Sharon