Re: Management Requirements

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Dave Thaler
> Sent: Wednesday, August 08, 2012 2:23 AM
> To: Juergen Schoenwaelder
> Cc: [email protected]; [email protected]; tsv-
> [email protected]
> Subject: Re: [OPS-AREA] Management Requirements
> 
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> > university.de]
> > Sent: Tuesday, August 07, 2012 3:43 PM
> > To: Dave Thaler
> > Cc: Ronald Bonica; [email protected];
> > [email protected]; ops- [email protected]
> > Subject: Re: [OPS-AREA] Management Requirements
> >
> > On Tue, Aug 07, 2012 at 09:51:44PM +0000, Dave Thaler wrote:
> > >
> > > 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.
> >
> > Out of curiosity, is there meanwhile a clear description you can
point
> > to explaining why the old NAT-MIB is broken?
> 
> The current text by the authors of the update is at
> http://tools.ietf.org/html/draft-ietf-behave-nat-mib-02#section-2.1
> 
> > > > 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.
> >
> > What are the events considered? How frequent will they occur? How
> > stringent are the requirements to deliver them (almost) all or is
the
> > even source designed to throttle notifications? How much data is
> > needed to describe the events?
> 
> One example would be creation/deletion of a mapping table entry.
> Depending on the exact techniques used by the instrumented
> implementation it may range from extremely frequent and large volume,
to
> infrequent and
> small volume.   There is no discussion of throttling, only of
techniques
> that one could use to reduce the volume (independent of the protocol
> used to report events).   How much data?   Probably tens of bytes per
> event.
> 
> > If all that is rather "standard" (in terms of notification volume
and
> > individual notification size), then SNMP might just do fine.
> 
> Looking not for what "might do fine" per se, as that might be a large
> number of protocols, but rather for what single protocol is
recommended
> or alternatively, a set of guidance on how a WG should choose among
> various protocols.
> 
> -Dave
> 

[[DR]] It looks like there are two levels in this discussion. One
relates specifically to the domain currently managed by using the
existing NAT MIB, with the analysis of the gaps (and brokenness) and
solutions for the specific problems. The other is about ' a set of
guidance on how a WG (any WG, not only BEHAVE) should choose among
various protocols'. If my guess that BEHAVE would rather have the first
specific level addressed without waiting for a generic solution to the
later level, I suggest that we focus on the NAT management problem space
first. We (in the OPS area) may learn some lessons about how to deal
with the more general level as well. 

Dan