Subject: [OPSAWG] NAT-MIB bis

From: Simon Perreault <[email-masked]>
Date: Mon, 05 Sep 2011 16:36:28 -0400

Hello,

This was just posted:
http://tools.ietf.org/html/draft-perreault-opsawg-natmib-bis-00

There's been some work on MIBs in BEHAVE lately. There are a number of 
new things that require an update to RFC 4008:
- DS-Lite (shared internal address pools)
- CGNs (thresholds, alarms, statistics, etc.)
- NAT64
and RFC 4008 itself is in need of some polishing independent of those. 
That's why we started a NAT-MIB bis draft.

You can see in section 2 that most of the items are marked TO-DO. We 
will continue working on this draft. At this point we would like some 
early feedback on the worthiness of this effort. Will NAT vendors 
implement this? Do operators need this? Does this make technical sense? 
Text contribution is also very welcome.

As BEHAVE is shutting down, we would like to invite discussion on the 
OPSAWG mailing list. We would like this draft to be adopted by a working 
group eventually, and would appreciate guidance on this as well.

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, 9 Sep 2011 16:36:17 +0200

> http://tools.ietf.org/html/draft-perreault-opsawg-natmib-bis-00

A few quick comments:

Is it useful that NatAddrMapId and NatSharedAddrMapId use distinct
number spaces? This means the number always needs to be qualified.

  natInterfaceSharedAddrMapIndex OBJECT-TYPE
      SYNTAX      NatSharedAddrMapId
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
            "Link to a NatSharedAddrMapEntry.  If NULL,
             it is expected that there exist at least one
             NatAddrMapEntry pointing to this interface entry."
      ::= { natInterfaceEntry 8 }

What does NULL mean here??

  natSharedAddrMapIndex  OBJECT-TYPE
      SYNTAX      NatSharedAddrMapId
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
            "Along with ifIndex, this object uniquely
             identifies an entry in the natAddrMapTable.
             Address map entries are applied in the order
             specified by natAddrMapIndex."
      ::= { natSharedAddrMapEntry 1 }

I thought ifIndex is not indexing this...

  natSharedAddrMapName OBJECT-TYPE
      SYNTAX      SnmpAdminString (SIZE(1..32))
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
            "Name identifying all map entries in the table associated
             with the same interface.  All map entries with the same
             ifIndex MUST have the same map name."
      ::= { natSharedAddrMapEntry 2 }

Again, ifIndex?
 
  natSharedAddrMapInTranslates OBJECT-TYPE
      SYNTAX     Counter64
      MAX-ACCESS read-only
      STATUS     current
      DESCRIPTION
            "The number of inbound packets pertaining to this address
             map entry that were translated.

             Discontinuities in the value of this counter can occur at
             reinitialization of the management system and at other
             times, as indicated by the value of
             ifCounterDiscontinuityTime on the relevant interface."
      ::= { natSharedAddrMapEntry 16 }

Since this is not per interface, ifCounterDiscontinuityTime is not a
suitable discontinuity indicator anymore.

  natSharedAddrMapOutTranslates OBJECT-TYPE
      SYNTAX     Counter64
      MAX-ACCESS read-only
      STATUS     current
      DESCRIPTION
            "The number of outbound packets pertaining to this
             address map entry that were translated.

             Discontinuities in the value of this counter can occur at
             reinitialization of the management system and at other
             times, as indicated by the value of
             ifCounterDiscontinuityTime on the relevant interface."
      ::= { natSharedAddrMapEntry 17 }

See above...

  natSharedAddrMapDiscards OBJECT-TYPE
      SYNTAX     Counter64
      MAX-ACCESS read-only
      STATUS     current
      DESCRIPTION
            "The number of packets pertaining to this address map
             entry that were dropped due to lack of addresses in the
             address pool identified by this address map.  The value of
             this object must always be zero in case of static
             address map.

             Discontinuities in the value of this counter can occur at
             reinitialization of the management system and at other
             times, as indicated by the value of
             ifCounterDiscontinuityTime on the relevant interface."
      ::= { natSharedAddrMapEntry 18 }

See above...

/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: Simon Perreault <[email-masked]>
Date: Mon, 12 Sep 2011 15:10:27 -0400

(Removed [email-masked] from the CC: list.)

Juergen,

Thanks for your comments. They are super helpful. As you'll see, I
redirected many of your questions back to you. I have a lot to learn
about the dark corners of MIBs...

On 2011-09-09 10:36, Juergen Schoenwaelder wrote:
> number spaces?

Well, they are different object types, so I guess that naturally the
numbering space would be different.

> This means the number always needs to be qualified.

What do you mean by "qualified"? How is that a disadvantage?

We always know from context what object type we are looking for, so the
numbering space can overlap. Are you worried that this might not always
be the case?

> What does NULL mean here??

Let me redirect the question back to you. The intention is that for each
NatInterfaceEntry, either a) it points to a NatSharedAddrMapEntry, or b)
there exists a regular NatAddrMapEntry pointing to it. In case b) we
need natInterfaceSharedAddrMapIndex to be inexistent or to be marked
invalid somehow. How can we express that in MIB-speak?

> I thought ifIndex is not indexing this...

Copy-paste mistake. Will fix.

>       ::= { natSharedAddrMapEntry 2 }

Copy-paste mistake. However, I don't know how to fix it. I don't
understand the original purpose of this parameter. What kind of name is
that? Why was it needed in addition to ifIndex? Do we still need it in
the NatSharedAddrMapEntry? Does it need to be replaced with something else?

> suitable discontinuity indicator anymore.

Do we need to find another discontinuity indicator or can we just remove
that piece of text?

>       ::= { natSharedAddrMapEntry 17 }

Same.

>       ::= { natSharedAddrMapEntry 18 }

Same.

Simon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Sep 2011 21:40:47 +0200

> numbering space would be different.

Since NatSharedAddrMapId is a new TC, the question is why we need it.
The definition of NatAddrMapId is:

NatAddrMapId ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS current
       DESCRIPTION
               "A unique id that is assigned to each address map
                by a NAT enabled device."
       SYNTAX   Unsigned32 (1..4294967295)

One could argue that this id applies to all maps, whether they are
associated with a particular interface or shared does not matter.

> What do you mean by "qualified"? How is that a disadvantage?

Well, I can't tell you map 42 is wrong. I always have to say either
shared map 42 is wrong or interface map 42 is wrong. If I want to
define a notification that a map is running out of addresses, I have
to complicate things since I can't simply ship a map number that works
regardless whether the map is shared or interface specific. It seems
simpler to me if all address maps on a device have a simple unique id.

> numbering space can overlap. Are you worried that this might not always

As explained above, things will be simpler if the ids are unique.

> invalid somehow. How can we express that in MIB-speak?

You have the choice to not instantiate the object (which some
tools/people do not like so much) or you have to reserve a special
value that represents the id is not used. The best way to do this is
to introduce a NatAddrMapIdOrZero:

NatAddrMapIdOrZero ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS current
       DESCRIPTION
               "A unique id that is assigned to each address map by a
                NAT enabled device. The semantics of the value zero
                are object-specific and must, therefore, be defined as
                part of the description of any object that uses this
                syntax. Examples of the usage of this extension are
                situations where none or address maps need to be
                referenced."
       SYNTAX   Unsigned32 (0..4294967295)

Then you use NatAddrMapIdOrZero as the SYNTAX and you explain the
meaning of the special value zero.

> the NatSharedAddrMapEntry? Does it need to be replaced with something else?

Looks indeed like an interesting construction. It seems that the goal
was to give all entries in the natAddrMapTable that belong to the same
interface a common name, perhaps to allow other interfaces (e.g. a
command line) to refer to a map by name instead of ids. This leads to
the question whether we need to support multiple shared maps. I guess
the answer is yes and in that case we might retain the concept and
have a natSharedAddrMapName so we can refer to a collection of entries
in the natSharedAddrMapTable via their name.

> Do we need to find another discontinuity indicator or can we just remove

The default discontinuity indicator is sysUpTime. Since interfaces are
often hot swapable, they have their own discontinuity indicator. A
shared map counter likely does not experience discontinuities if an
interface gets swapeped - hense relying on the default sysUpTime might
be sufficient.

/js

---

From: Simon Perreault <[email-masked]>
Date: Mon, 12 Sep 2011 16:22:11 -0400

> As explained above, things will be simpler if the ids are unique.

Makes sense. The next revision will remove NatSharedAddrMapId and reuse
NatAddrMapId instead.

> meaning of the special value zero.

Thanks. Here's the new natInterfaceSharedAddrMapIndex definition:

natInterfaceSharedAddrMapIndex OBJECT-TYPE
    SYNTAX      NatAddrMapIdOrZero
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
            "Link to a NatSharedAddrMapEntry. If zero, no
             NatSharedAddrMapEntry exists for this interface entry,
             and it is expected that there exist at least one
             NatAddrMapEntry pointing to this interface entry."
    ::= { natInterfaceEntry 8 }

> command line) to refer to a map by name instead of ids.

Then why put this information in each map entry instead of just once in
the interface definition? You would obtain the ifIndex first, then query
the addr map table using that.

> This leads to
> the question whether we need to support multiple shared maps.

...per interface?

> I guess

You mean that we would replace natInterfaceSharedAddrMapIndex with that
name instead?

If we want to support multiple shared maps per interface, why not create
a new number (instead of a string) to represent a collection of shared
addr map entries?

I just find it hard to see what the string would map to on real NAT
implementations, whereas a number is easy to come up with.

> interface gets swapeped - hense relying on the default sysUpTime might

Makes sense. I'll update the text.

Thanks,
Simon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Sep 2011 09:56:28 +0200

> the addr map table using that.

I don't know. I guess they were trying to save a table definition.
 
> You mean that we would replace natInterfaceSharedAddrMapIndex with that

My understanding of the current MIB is that you have interfaces (say
ifIndex 2 and ifIndex 3) and the associated address map may consists
of several address maps, that is multiple entries in the
natAddrMapTable for one interface. So you can have:

ifIndex natAddrMapIndex natAddrMapName
   2           8           eth2-map
   2           9           eth2-map
   2          10           eth2-map
   3          11           eth3-map
   3          12           eth3-map

In other words, the name eth2-map (or eth3-map) refers to all address
maps of the interface 2 (interface 3). For shared maps, we could do
this:

natSharedAddrMapIndex natSharedAddrMapName
         15                 shared-map1
         16                 shared-map1
         17                 shared-map1
         18                 shared-map2
         19                 shared-map2

Of course, natInterfaceSharedAddrMapIndex would then not be of type
NatAddrMapIdOrZero but instead we would have to refer to an address
map name. I guess we agree so far but I just wanted to make sure.

> implementations, whereas a number is easy to come up with.

Whether it is a number of a string can be debated. If internally you
have a number and your implementation is read-only, you can easily
convert the number into a string. Once you talk about configuration,
being able to refer to things by name is usually what is operationally
a better choice because a name can carry additional meaning for human
operators. Since the existing MIB tables already use a name to refer
to collections of address maps, I tend to favour consistency unless
there is a strong technical argument to give up consistency.

/js