Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-09.txt

From: [email-masked]
Date: Thu, 17 Oct 2013 07:24:37 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Definitions of Managed Objects for Network Address Translators (NAT)
	Author(s)       : Simon Perreault
                          Tina Tsou
                          Senthil Sivakumar
	Filename        : draft-ietf-behave-nat-mib-09.txt
	Pages           : 87
	Date            : 2013-10-17

Abstract:
   This memo defines a portion of the Management Information Base (MIB)
   for devices implementing Network Address Translator (NAT) function.
   This MIB module may be used for monitoring of a device capable of NAT
   function.

   This document obsoletes RFC 4008.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-behave-nat-mib-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-nat-mib-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Simon Perreault <[email-masked]>
Date: Thu, 17 Oct 2013 16:30:59 +0200

This revision addresses comments by David Harrington, Dave Thaler, 
Juergen Schoenwaelder, Tom Taylor, and Jagadish Shivamurthy.

I'm really not sure the way I added NAT instances is correct syntax, so 
please if a MIB doctor could verify it would be appreciated.

At this point our to-do list for this MIB is now empty.

Thanks,
Simon

Le 2013-10-17 16:24, [email-masked] a écrit :
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

-- 
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: "ietfdbh" <[email-masked]>
Date: Thu, 17 Oct 2013 16:22:06 -0400

Hi,

I didn't do a full MIB Doctor review, but I took a quick look.

For a syntactic correctness check, did you run this through libsmi tools?

I'm not crazy about the description clause in the instance table.
The goal of IETF is to standardize how things are done.
Having the "contexts MAY be used instead" rather defeats that purpose.

In addition, MIB modules should be independent of the protocol used to carry
the data.
(e.g., can SNMPv3 contexts be used to access the MIB using Netconf?)
And MIB modules should be written to operate regardless of SNMP version
used.
(e.g., can SNMPv3 contexts be used to access the MIB using SNMPv1?)
So specifying that SNMPv3 contexts can be used is wrong.
You would also need to allow SNMPv1/v2c communities.
But then you hit the issue of forward-compatibility.
What happens if SNMPv4 eliminates contexts?
And given that the instance table is being added because SNMPv3 contexts are
not scalable here, why would we want to suggest that as an alternative?

I am not convinced this whole design has been well thought-out.
To explain why I am concerned, let me discuss SNMPv3 contexts a bit.
The same object, such as a counter, can exist in multiple contexts.
Contexts are this sort-of-virtual thingee that is not at all defined
semantically.
As a result, different implementations use contexts in different ways.

The ENTITY-MIB provides tables for physical-to-logical mappings, and
entity-to-container mappings, to help standardize this mess.

Can the same MIB objects exist in multiple instances?
Your description of an instance index says the semantics are
implementation-dependent.
But the semantics are important for interoperability, and for an operator's
understanding of what is being reported.
If an "instance" represents a specific board in a chassis, does that mean
the implementation will count natTranslations per board?
What if an instance in another implementation means something else, such as
a client in a multi-client environment?
Or maybe an instance represents an address range in a shared address system.
What will natTranslations count for each of these implementations?
How does an NMS compare counters from multiple vendors if what the counter
counts is implementation-dependent?

You COULD design a standardized instance definition, so engineers know how
to implement an "instance", interoperably.
But realize this would only work for the nat-mib; all the other objects in
"the MIB" would not recognize this idea of instance.
If the instance being designed here refers to a board, what about the other
objects instrumented on that board, that might be relevant to the NAT
implemented on that board? 
Will the "instance" now include things like the ipv4 and ipv6 and tcp
objects for that board?
Or will the instance simply use global counters for these values?

There are drafts for logging under development. Do each of these logging
approaches now need to include the concept of NAT instance?

I think this idea of instance needs a lot more discussion before being added
to the MIB module.

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Thursday, October 17, 2013 10:31 AM
> To: [email-masked]
> Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-09.txt
>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 22 Oct 2013 17:23:54 +0200

> I didn't do a full MIB Doctor review, but I took a quick look.

Thanks a lot!

> For a syntactic correctness check, did you run this through libsmi tools?

Yes.

> Can the same MIB objects exist in multiple instances?

Yes, that's my understanding of the purpose of instances.

> implementation-dependent.

What I should have said instead is that an SNMP agent may manage
multiple NATs, and that each NAT has its own set of objects identified
by an instance index.

We don't care whether "multiple NATs" refer to processes in memory, to
different physical boards, or whatever else.

> counts is implementation-dependent?

Does my formulation above help answer these questions?

> approaches now need to include the concept of NAT instance?

That' a good question.

Senthil? Tom?

> I think this idea of instance needs a lot more discussion before being added

Well, we do need *something*. Before -09, we had implicitly assumed that
SNMPv3 contexts would be used for that purpose. It seems like that
solution was flawed. Just reverting to -08 wouldn't solve the problem.
We need a true solution.

Simon

---

From: Tom Taylor <[email-masked]>
Date: Tue, 22 Oct 2013 12:06:16 -0400

>> I didn't do a full MIB Doctor review, but I took a quick look.
...
>> approaches now need to include the concept of NAT instance?
[PTT] I would assume that the SYSLOG HOSTNAME field identifies the 
instance explicitly, but it wouldn't hurt to add some text to that effect.

...

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 24 Oct 2013 10:56:40 -0400

> solution was flawed. Just reverting to -08 wouldn't solve the problem.

We've had one person state that a context solution isn't scalable.
The current proposal for designing some sort of "instance" representation
seems to be just reinventing contexts.
If the current proposal provided greater interoperability than contexts, I
might be on-board. I don't think it does.
If the current proposal has some serious explanation of how it solves a
"scalability problem" of contexts, I might be on board. I haven't see such
discussion.

SNMP has been in operation for 20 years..
NATs are not the first technology where multiple instances are managed by a
single agent. 
We might need to look around at how other problems of context scalability
have been addressed.

I'm an SNMP protocol expert and a MIB expert. But I'm not an operator.
Before we talk about solutions, I think we need much more discussion of the
operational *problems* we are trying to solve.
Then we can better decide whether contexts or instances and something else
might be a viable solution.

Why are contexts not scalable in practice?
Why would instances be scalable in practice?
What are the characteristics of an instance that must be interoperable?
What assumptions can an NMS make, or not make, about the data objects
contained in an instance?
How would such assumptions, or inability to make such assumptions, affect
how an NMS (or operator) can interpret data from an instance?
How can the values of objects not specified as being in an instance (e.g.,
existing MIB modules) be correlated with data within an instance?

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