Re: Management Requirements

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, August 07, 2012 11:55 PM
> To: Ronald Bonica
> Cc: [email protected]; [email protected]; ops-
> [email protected]
> Subject: Re: [OPS-AREA] Management Requirements
> 
> On Tue, Aug 07, 2012 at 03:29:52PM -0400, Ronald Bonica wrote:
> > Folks,
> >
> > The BEHAVE WG brings us a concrete example of a problem that we
> > discussed in Vancouver. According to their charter, the BEHAVE WG
> "creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function
in
> as deterministic a fashion as possible." Also, according to their
> charter, the BEHAVE WG "will update the NAT MIB (RFC 4008) to be
> consistent with the management aspects of its IPv6/IPv4 NAT solutions,
> and specify IPFIX information elements to meet logging requirements,
> reusing existing elements, if possible."
> >
> > Now BEHAVE is asking whether SNMP and IPFIX are the right tools.
Maybe
> NETCONF is the right tool for configuration? Maybe SNMP is right for
> fault monitoring? Maybe syslog is right for maintaining a record of
> address mappings? Who knows?
> >
> 
> For configuration, NETCONF/YANG is the right choice. There is nothing
> that really competes for configuration.
> 
> For event notifications, you have at least SYSLOG, SNMP notifications,
> IPFIX, NETCONF notifications. I think the last one is likely not a
main
> target. SNMP notifications means one SNMP message per event and the
same
> holds true for SYSLOG; IPFIX allows to send a collection of events in
> one IPFIX message and hence it might be more scalable, which might be
> important for some NAT deployments.
> 
> For retrieving operational state and debugging, both SNMP and NETCONF
> can work. If the data structures tend to be more complex and/or the
data
> instances are of larger volume, NETCONF has some advances (more
> efficient bulk transfer). If data needs to travel over shaky links
(e.g.
> high levels of packet loss), SNMP _can_ have an advantage.
> 
> Perhaps these thoughts help to make a suitable decision. One could of
> course also ask what the contributors prefer to implement, e.g. what
> they expect to ease integration into management systems relevant for
the
> protocol domain.
> 
> /js

[[DR]] I agree with all the analysis made by Juergen, maybe with one
reservation: 

> SNMP notifications means one SNMP message per event and the same
> holds true for SYSLOG; IPFIX allows to send a collection of events in
> one IPFIX message and hence it might be more scalable, which might be
> important for some NAT deployments.

You can actually send more than one SNMP message per event if you define
the notifications accordingly, so I say that this really depends upon
modeling. On the other hand if 'real-time'-liness is a requirement -
a.k.a as soon as certain events happen you _may_ have an advantage with
SNMP notifications. 

Regards,

Dan