Subject: [MIB-DOCTORS] Questions for the new NAT MIB

From: Simon Perreault <[email-masked]>
Date: Thu, 31 May 2012 15:45:55 -0400

Doctors,

Here are two questions related to draft-ietf-behave-nat-mib:

1. We are wondering how to support multiple NATs (possibly with 
overlapping address space) using a single SNMP agent. In our readings we 
stumbled upon SNMPv3 contexts. Dave Thaler also pointed us toward the 
Entity MIB. It's fairly complex stuff but we feel like the end result 
will be just a few lines of text in our draft. So far we were thinking 
of something along the lines of:

    SNMPv3 supports "Contexts" that can be used to implement MIB views on
    multiple NAT instances on the same system.  See [RFC3411] or its
    successors for details.

(Stolen from the OSPFv3 MIB [RFC5643].)

Is this sufficient? Do we need to say anything about the Entity MIB?

2. We want NAT operators to be able to graph the rate of mapping 
creations and removals. We already provide absolute counters of mapping 
creations and removals. We're envisaging to simply rely on the polling 
station to compute its own derivative. It looks like it is common 
practice. Is it the right thing to do? Will accuracy be compromised or 
will inaccuracies just average out over time?

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Jun 2012 18:38:34 +0200

On Thu, May 31, 2012 at 03:45:55PM -0400, Simon Perreault wrote:
> overlapping address space) using a single SNMP agent. In our
> readings we stumbled upon SNMPv3 contexts. Dave Thaler also pointed
> us toward the Entity MIB. It's fairly complex stuff but we feel like
> the end result will be just a few lines of text in our draft. So far
> we were thinking of something along the lines of:
> 

Not really sure what "multiple NATs" really means to you or me or
anybody else. Concerning usage of context and the ENTITY-MIB, it would
be good to specify what entLogicalType would contain for a
NAT. Perhaps also something would need to be said for
entAliasMappingIdentifier.
 
> creations and removals. We already provide absolute counters of
> mapping creations and removals. We're envisaging to simply rely on
> the polling station to compute its own derivative. It looks like it
> is common practice. Is it the right thing to do?

Yes.

> Will accuracy be compromised or will inaccuracies just average out
> over time?

I am not sure why there would be an accuracy problem.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 1 Jun 2012 10:25:10 -0700

Hi -

> From: "Simon Perreault" <[email-masked]>
> To: <[email-masked]>
> Cc: "Marc Blanchet" <[email-masked]>; "Senthil Sivakumar (ssenthil)" <[email-masked]>; "Tina Zouting"
<[email-masked]>
> Sent: Thursday, May 31, 2012 12:45 PM
> Subject: [MIB-DOCTORS] Questions for the new NAT MIB
...
> Is this sufficient? Do we need to say anything about the Entity MIB?

Consider whether you'd have any reason to support use cases in which
information belonging to two or more NAT instances would need to be carried
in a single request, or which would also need to carry information
belonging to any other component of the system (e.g. protocol status or
counters).  Contexts generally don't work well for those use cases, and
you'd probably be better of with an index structure in which one of
the indices (probably the first one) serves to distinguish the NAT instance.

Randy

---

From: Chris Elliott <[email-masked]>
Date: Fri, 1 Jun 2012 18:26:11 -0400

> I am not sure why there would be an accuracy problem.

Accuracy can be an issue for any number of reasons. The two most common
reasons I've run into are polling more frequently than the server updates
the counter (certain large switches from a certain large vendor updates
their line card ifTable counters every 10 seconds, roughly) and variable
delay in packet delivery. Not much to do on the first, but poll less
frequently. On the second, if you request sysUpTime.0 in the same packet as
the counter and use the time values returned to calculate the time delta
then you can usually improve the accuracy of the rate calculation.

Neither of these affects how the MIB should be written, however. Counters
are the way to go for this type of data.

Chris.

> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

-- 
Chris Elliott
[email-masked]