Subject: [BEHAVE] nat-mib-06 abbreviations

From: "ietfdbh" <[email-masked]>
Date: Sat, 22 Jun 2013 09:59:44 -0400

Hi,

My experience is that operators find abbreviations irritating.
"Let's see, was that spelled out as counter, or abbreviated as Cnt, or Cntr,
...?"

Counter names have often historically ended with an "s", which helps
identify it as a counter.

I'm not convinced you need the extra hierarchy of natCounters and natLimits
and natPoolObjects, but I can live with it.

Meaningful descriptors are preferred.
Some NMS applications display the object name without a corresponding
description, so  meaningful object names help operators.
Let's see, I wonder what natCntOOP means? The number of object-oriented
programming counters?
How about using natCntNoPorts instead?

Do you really need the "Cnt" in the names? Wouldn't natNoPorts suffice?
natCntTranslates => natTranslations?
natCntResource => natResourceErrors?

natCntStateMismatch => natStateMismatches?
I also have concerns that this definition is ambiguous. You give an example
rather than a clear description of what MUST and MUST NOT be counted in this
counter.
If the only thing that gets counted is incompatible flags, then name it
natIncompatibleFlags.
If other things are supposed to be counted, be explicit about WHAT gets
counted in this counter.
Ambiguity leads to differing interpretations, which hurts interoperability.
I think this description needs tightening (and possibly a reference to a
discussion of state mismatch)

natCntQuota => natQuotaErrors? natQuotaRejects? natQuotaRefusedPkts?
Does this only apply to incoming packets?

I'm a bit uncomfortable with "The number of packets to which NAT could not
be applied because ..."
Does this mean "The number of packets not translated because ..."

natCntMappings - it is generally considered bad practice to define objects
that are easily derived from existing objects.
These objects are instantiated on devices that should be focused on
forwarding packets, not running formula calculations.
Forwarding devices often have very limited resources, so having the nat
device use its CPU to do unnecessary calculations and store the results in
scarce memory is not a good idea.
Let the NM application get Creations and Removals and let it do the
calculations.
Complexity should be pushed to the SNMP manager, not the SNMP agent.

Here are the guidelines used in the BRIDGE-MIB:
" To be consistent with IAB directives and good engineering practices,
   an explicit attempt was made to keep this MIB module as simple as
   possible.  This was accomplished by applying the following criteria
   to objects proposed for inclusion:

   1. Start with a small set of essential objects and add only as
      further objects are needed.

   2. Require that objects be essential for either fault or
      configuration management.

   3. Consider evidence of current use and/or utility.

   4. Limit the total number of objects.

   5. Exclude objects that are simply derivable from others in this or
      other MIB modules.

   6. Avoid causing critical sections to be heavily instrumented.  The
      guideline that was followed is one counter per critical section
      per layer.
"

natCntMappings - Can Creations exceed Removals? That would seem reasonable
to me.
If so, then Mappings = removals - creations would generate negative numbers,
right?
Shouldn't this be creations - removals?

David Harrington
[email-masked]
+1-603-828-1401

---

From: Simon Perreault <[email-masked]>
Date: Mon, 24 Jun 2013 09:33:38 +0200

> natCntStateMismatch => natStateMismatches?

That makes sense, and I don't see a big problem with changing names now.

I remember that when naming some objects I hit the length limit and had 
to use abbreviations instead of full names. I'll see what I can do while 
staying under the limit.

> rather than a clear description of what MUST and MUST NOT be counted in this

Could this be due to the underspecified nature of NAT itself?

> If the only thing that gets counted is incompatible flags, then name it

It's not just flags. Various NAT implementations expect various things 
from packets so that they match state entries. One example of something 
that is not a flag would be TCP sequence number mismatches. Some NATs 
track TCP sequence numbers. When a packet is outside an acceptable 
window, this counter would get incremented.

> If other things are supposed to be counted, be explicit about WHAT gets

That's pretty much impossible given that NAT is underspecified and 
various NAT implementations do various things. What we can do is 
eliminate any ambiguity, while remaining generic.

> Does this only apply to incoming packets?

The whole MIB assumes that 1 packet in = 1 packet out. If an incoming 
packet gets dropped because an outbound quota is reached, then that 
still increments the counter. Is that what you meant?

> Does this mean "The number of packets not translated because ..."

Agreed. Fixed in my local copy.

> Complexity should be pushed to the SNMP manager, not the SNMP agent.

Makes sense. Fixed in my local copy.

> Shouldn't this be creations - removals?

You're absolutely right! Fixed in my local copy.

Thanks a lot!

Simon

---

From: "ietfdbh" <[email-masked]>
Date: Mon, 24 Jun 2013 10:40:01 -0400

> I also have concerns that this definition is ambiguous. You give an 
> example rather than a clear description of what MUST and MUST NOT be 
> counted in this counter.

> If the only thing that gets counted is incompatible flags, then name 
> it natIncompatibleFlags.

It's not just flags. Various NAT implementations expect various things from
packets so that they match state entries. One example of something that is
not a flag would be TCP sequence number mismatches. Some NATs track TCP
sequence numbers. When a packet is outside an acceptable window, this
counter would get incremented.

> If other things are supposed to be counted, be explicit about WHAT 
> gets counted in this counter.

That's pretty much impossible given that NAT is underspecified and various
NAT implementations do various things. What we can do is eliminate any
ambiguity, while remaining generic.
[dbh>] But you're NOT eliminating the ambiguity.
I have a background in NMS development, and know that it is frustrating to
have the same counter name used to count different things on different
implementations. The counter simply  becomes useless. Having a "standard" is
pretty useless if I have to code my application to know that the xyzCounter
counts one thing on Cisco NATs, but Juniper NATs count something else, and
Acme NATs some other implementation-dependent stuff, while Foobar NATs
include their implementation-dependent things. And if the standard is
ambiguous, then different models from the same vendors can choose to count
different things as well, making it REALLY useless.

The problem is that an NMS cannot compare the value of this counter across
different implementations because the meaning of the counter differs across
implementations. I recommend standardizing what can be agreed upon, and let
those things that are implementation-specific (i.e., not agreed upon) be
documented in implementation-specific MIB modules; maybe at some time in the
future, agreement can be reached to extend the standard.

if the counter goes into an IETF standard MIB, then it should standardize
what gets counted in that counter.

> I think this description needs tightening (and possibly a reference to 
> a discussion of state mismatch)
>

The whole MIB assumes that 1 packet in = 1 packet out. If an incoming packet
gets dropped because an outbound quota is reached, then that still
increments the counter. Is that what you meant?
[dbh>] well, yes, that is what I meant, at least to a degree.  
Remember that under SMI rules, you cannot go back and change the semantics
of this description later.
As long as there is a 1:1 mapping, it probably doesn't matter whether you
count this as an incoming packets of an outgoing packet issue. However,
given the variety of NAT implementations, as you've mentioned, and I'm not
sure that variability will go away anytime soon, somebody might choose to
implement different quotas for incoming and outgoing. Hence, it could be
better to specify that this counts "the number of incoming packets that did
not get translated ..."; that way if ever implementations allow for a
not-1:1 mapping, they still know which packets to count in this counter. And
if the 1:1 assumption always holds true, it makes no difference.

I think the naming should change to reflect that this is a drop counter - I
suggest natQuotaDrops. 

In general, counters count behaviors/actions such as drops, rather than
things like quotas, so the behavior/action being counted should be part of
the name. If I am an operator looking at a counter named natCntResource, is
this counting the resources? Or is it counting the drops caused by
inadequate resources? Ideally an operator should not need to go read the MIB
description clause to figure this out, while trying to debug why the
company's shopping cart network connection suddenly isn't working. It helps
a lot to use meaningful object names.

Dbh

---

From: Simon Perreault <[email-masked]>
Date: Wed, 26 Jun 2013 09:51:46 +0200

> [dbh>] But you're NOT eliminating the ambiguity.

Right. I did not propose a way to eliminate the ambiguity. I was only 
suggesting that that is what we should do (as opposed to eliminating 
generality).

> what gets counted in that counter.

That's a fair point.

Unless the WG disagrees, the state mismatches counters will be removed 
from the next revision.

> if the 1:1 assumption always holds true, it makes no difference.

Will do.

> I think the naming should change to reflect that this is a drop counter - I

Ok.

> a lot to use meaningful object names.

Makes total sense. Thanks for the help!

Simon