Re: [OPS-AREA] [OPS-DIR] SNMP notification configuration

["David Harrington" <ietfdbh at comcast.net>]

Hi, 

comments inline, and a request for additional feedback from operators.

> -----Original Message-----
> From: Phil Shafer [mailto:phil at juniper.net] 
> Sent: Tuesday, June 03, 2008 10:34 AM
> To: David Harrington
> Cc: ops-dir at ietf.org; 'OPS Area'; isms at ietf.org
> Subject: Re: [OPS-DIR] SNMP notification configuration 
> 
> "David Harrington" writes:
> >SNMP notifications have traditionally been close-to-real-time and
> >scalable. I think netconf notifications are great for interactive
> >configuration work. I don't think the netconf subscribe approach is
> >scalable to managing large networks. 
> 
> The difference is much smaller, I think.  SNMP sends async 
> notifications
> based on content descriptions set in (typically) configuration.
> NETCONF sends async notifications based on content descriptions
> given in client subscriptions.  Once set, both styles send 
> notifications
> when event happen.  The action of the snmp agent and the netconf
> agent are completly similar.
> 
> The major difference is that NETCONF requires the manager establish
> a connection beforehand, where SNMP sends notifications without
> regard to the manager.  

SNMP can send notifications when an event happens, without having to
wait for a manager to initiate a connection first. This distinction
can be important, especially during startup. As SNMP moves from a UDP
transport to an SSH transport, an entity-to-entity connection will
need to be initiated before the notification can be sent, so the fact
that a connection must be instantiated first might become less
important. The distinction of WHO must initiates the connection first
might become more important because of NATs.

> The real cost is that a manager needs to
> have connections up and running to each managed device.  The cost
> for the agent is a connection (one per manager) which is negligible.

These costs probably are similar between netconf/SSH and SNMP/SSH.

So, in ISMS terms, would operators find it acceptable if SNMP adopted
a "manager must subscribe to get notifications (with replay
capability)" similar to the netconf notification protocol approach,
when using SNMP over a secure transport layer like SSH or TLS? 

Using a manager-must-subscribe mechanism would eliminate the need for
having the agent establish the SSH connection.

The ISMS WG could consider using the same notification protocol design
as netconf. This could be done by 
1) using a MIB extension to the TARGET-MIB, EVENT-MIB, et. al.,
requiring a manager to use SNMP SETs to create subscriptions similar
to that of the netconf notification protocol. Notifications would be
buffered, possibly using the NOTIFICATION-LOG-MIB, just as with
netconf notifications. or 
2) not sending SNMP notifications over secure transports, but rather
requiring support for the netconf notification protocol in all SNMP
agents and managers that support SNMP/secure-transport, so managers
would need to use netconf to get the notifications. SNMP would
presumably continue to support its existing notification model,
requiring no subscription (but still requring pre-configuration), when
used over UDP. or
3) we could define a new SNMP operation to create a subscription
comparable to the netconf notification protocol.

The second and third approaches seem to be totally out of scope of the
ISMS WG charter, but if they would be better solutions, we could
presumably re-charter. 

(Once we get some operator feedback, we can take this discussion off
the OPS lists and return to detailed engineering discussions in the
ISMS WG. ;-)

David Harrington
dbharrington at comcast.net
ietfdbh at comcast.net
dharrington at huawei.com


_______________________________________________
OPS-AREA mailing list
OPS-AREA at ietf.org
https://www.ietf.org/mailman/listinfo/ops-area