RE: requirement: agent initiated session support

["Kent Watsen" <kwatsen@juniper.net>]

Sharon wrote:
> 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


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