[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: notification motivation and requirements



 

Here're some requirements/motivations/comments for having NETCONF
notifications

It may not be possible/feasible, at least now, to have a single
management interface that satisfies every need. However, IMO having a
management protoco/interface restricted to a single task (e.g.
configuration) is a significant limitation. So...
 

- Two areas with large voids (configuration and event notifications).
NETCONF could fill this void. Need a management interface which can be
used for configuration and monitoring of notifications resulting from
those configuration changes. 

- First priority for notifications: configuration change notifications 

- Need the following capabilities for event notifications: subscription,
filtering



Comments

- Adding notification support to NETCONF (i.e. just the protocol) is not
the end goal but it is the first and necessary step. Adding this support
provides a more useful management interface & adds features not found in
other protocols

- The next step is to define protocol independent event notification
messages (types & contents). Without this there is little value in
adding event notifications to NETCONF. But repeating the above, adding
protocol support is the first step 

- If the above work is done either as part of NETCONF WG or elsewhere,
on-going work in this area should be leveraged. 

- Some people consider adding notification support to NETCONF as
re-inventing things. The problem is that existing solutions are not
adequate (i.e. SNMP & syslog) 



Motivations

- SNMP is not used for configuration and it hardly provides an adequate
solution for event notifications. SNMP has been around for a long long
time and it's time to look at alternatives  
- Syslog messages are unstructured & protocol has limitations (e.g. size
limitations, filtering, subscription, etc.)
- The new syslog-protocol ID addresses the structured data but there are
no standarized SD fields (ok maybe 2 or 3).    
- Need to provide better ways for delivering event notifications. Many
industry segments moving to Web services (e.g. WS-management, WSDM,
converged standard). Network devices need to evolve as well. 
- Adding notification support to NETCONF & standarizing event
definitions allow vendors as well as users to choose how the want to
receive event notifications. If some prefer syslog protocol then use it.
The NETCONF notifications could be used as a migration from syslog to
NETCONF notifications for those who need a multi-purpose protocol.   

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