Re: Management Requirements

On Tue, Aug 7, 2012 at 5:01 PM, Romascanu, Dan (Dan) <[email protected]>wrote:

>
>
>
>
> > -----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
>
> [AD]  Adding another item to what Juergen listed on the task of monitoring:

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

For retrieving operational state and debugging on more than one or a few
devices,
SNMP can have the advantage.  SNMP works well when monitoring
numerous devices at once.

- Andy

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area