Re: Management Requirements

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, August 07, 2012 1:55 PM
> To: Ronald Bonica
> Cc: [email protected]; [email protected]; [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.

Currently the Behave WG isn't looking at configuration, only monitoring
and eventing.   And my understanding is that presently it's not a 
requirement that WG's have a configuration solution, it's up to the WG.
 
> 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.

I've heard it said that IPFIX is for packet sampling not for metadata eventing,
but this isn't an area I know enough about myself to say.   I would like to say
that the Behave WG shouldn't do multiple solutions for the same thing.
I'd like the OPS area folks to help us decide which one is the most appropriate
one.   Currently we have a small number of individuals each advocating
a different protocol, and a large number of individuals (myself included)
that have no preference and want the OPS area experts to give guidance.
 
> 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.

The data instances can have a larger volume and may need to travel over
shaky links.   Also there's an existing MIB that is outdated and we want
to obsolete.   So the WG is currently using SNMP for retrieving 
operational state and debugging, by doing an update that is intended
to obsolete the existing MIB RFC.
 
> 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.

Answered above.   Looking to OPS for clear guidance on what eventing
protocol to use (or what criteria we should use to decide).   I don't want
multiple ones.

-Dave