Subject: [BEHAVE] NAT MIB: compliance levels

From: Tom Taylor <[email-masked]>
Date: Fri, 21 Nov 2014 11:04:47 -0500

One of the issues David Harrington raised regarding the NAT MIB -11 
version was what he thought might be an excessive number of compliance 
levels.

(Issue 36, http://trac.tools.ietf.org/wg/behave/trac/wiki/MibIss036)

These are the ones currently defined:

(1) Basic NAT, all mappings are administered.

(2) Dynamic port mappings are supported

(3) Address maps and address pooling are supported

(4) "Receive fragments out of order" is supported

(5) Subscribers are supported

I think we can combine the first with the second one. We can get rid of 
the fragment-related one by redefining the dropped fragment counter to 
count all dropped fragments and providing an object to indicate the 
fragmentation behaviour to help interpret the counter.

This gives us three application scenarios:

-- basic NAT: support of port mappings only. Objects in the 
natv2InstanceTable, natv2NextProtocolTable, and natv2PortMapTable
are relevant.

-- large-scale NAT: additional support of address pools and address 
maps, hence natv2PoolTable, natv2PoolRangeTable, and 
natv2AddressMapTable come into the picture.

-- subscriber-aware NAT: additional support of subscribers, hence 
natv2Subscribers and natv2SubscriberIngressInterfaceIdentifierTable
are added.

Comments?

Tom Taylor

---

From: Simon Perreault <[email-masked]>
Date: Fri, 21 Nov 2014 14:05:29 -1000

On Fri, Nov 21, 2014 at 6:04 AM, Tom Taylor <[email-masked]>
wrote:

> -- large-scale NAT: additional support of address pools and address maps,
> hence natv2PoolTable, natv2PoolRangeTable, and natv2AddressMapTable come
> into the picture.
>

Makes sense.

FYI, the IETF term for "subscriber-aware NAT" is, perhaps surprisingly,
"carrier-grade NAT" [RFC6888].

Simon