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

["ietfdbh" <[e-mail]>]

Hi,

 

Thanks for this explanation of the context scalability issue.

Comments inline.

 

David Harrington

 <mailto:[e-mail]> [e-mail]

[phone]

From: Jagadish Shivamurthy (jshivamu) [mailto:[e-mail]] 
Sent: Tuesday, October 29, 2013 7:59 AM
To: [e-mail]; [e-mail]; [e-mail]
Cc: Senthil Sivakumar (ssenthil); Hongchi Shih (hshih); Ganesan Rajam
(grajam); Swaroop George (swaroop)
Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-09.txt

 

Hi David, Simon,

Here are some inputs we have based on the past experience of handling
multiple instances in deployment scenarios to consider the instance based
mechanism. If you see any specific issues (inter-operability or other
issues), with instance based design of the MIB, please let us know.

 

Thanks

Jagadish

 

1. An SNMP V3 context (or SNMP v2c Community name) has to be configured for
each NAT instance. The SNMP context (or community name) has to be mapped to
specific NAT instance. Hence, this method involves 'additional'
configuration to make an NMS work with current deployments. If there are
high number of NAT instances in a router, this could be a tedious (and error
prone) task. You can refer 

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_examp
le09186a0080b1ff61.shtml as an example of configuring the SNMP
contexts/community names on Cisco IOS platforms. A similar configuration
exercise will be needed for other platforms.

 

OK.

 

L2VPN bridge instances on certain Cisco routers support Bridge MIB (RFC
1493). However, customers configure hundreds of L2VPN bridges and we had to
relay on the customer to configure an SNMP context for each instance. 

 

OK. 

Let me point out that the IETF still supports a standard for
"single-instance" Bridge MIB modules (RFC1493, 4188,4363, and 4318).

 

The IETF turned over further Bridge MIB work to the IEEE.

The IEEE developed Provider Backbone Bridges, which allows for multiple
instances.

See
http://www.ieee802.org/1/files/public/MIBs/IEEE8021-BRIDGE-MIB-201208100000Z
.txt (and
http://www.ieee802.org/1/files/public/MIBs/IEEE8021-TC-MIB-201202150000Z.txt
)

The addition of instance-indexing required that the OID assignments for
Bridge-MIB related objects be completely reassigned.

Existing NMS systems that knew how to query, say, the number of ports using
dot1dBaseNumPorts at { dot1dBase 2 }

Now needs to query ieee8021BridgeBaseNumPorts at {ieee8021BridgeBaseEntry 3}
- a totally different OID for the same info.

 

On the other hand, MPLS-L3VPN-STD-MIB.my defined in RFC 4382 supports
multiple instances directly without the use of contexts. In this, the
MPLS-L3VPN parameters are grouped in to tables/sequences which are indexed
by VRF(and other indexes where needed) so that, parameters pertaining to a
particular instance can be queried. 

 

Understood.

 

2. The Context approach grows in an MxN manner if there are M different
features (MIBs) and N number of average instances per feature (except rare
cases where many different features/MIBs can be identified by a common
attribute). MxN can easily grow to thousands and customers have to configure
those many contexts.

 

Understood. Thanks for clearly explaining the problem.

 

3. An instance table based approach provides for plug and play kind of
deployment. It will not require any additional configuration on the router

to make NMS pull data for multiple instances. The NMS walks through the
instance table and builds data for each instance.

 

This sounds great! But the devil is in the details.

Who assigns the instance identifier? I would assume the router.

This would be similar to ifIndex, which is assigned by a router to interface
instances.

 

ifIndex has quite a lot of discussion about interoperability, especially
persistence across reboot.

ifIndex has a corresponding ifAlias that is persistent across reboots.

This is REALLY important because NMSes frequently keep data queried about an
interface, even across reboots of the managed device.

While ifIndex can be changed across reboots, ifAlias must remain constant
across reboots.

This allows an NMS to recognize that interface#3 has now become interface#4,
and can align its old data for interface#3 with the current interface#4.

Without this feature of the IF-MIB, all data related to an interface prior
to a device reboot might as well be thrown away, since NMSes would be likely
to apply the old data to the wrong interface.

 

So what are the rules about the persistence of NAT instances across device
reboots?

Assuming a chassis-based arrangement with one NAT per board, what happens if
a board is removed/added/replaced?

How does an NMS align their existing data per NAT with potentially new
assignments of NAT instance identifiers?

A device might not have the information necessary to assign the same numbers
to each instance on reboot, so it needs to renumber (thus the long
discussion, and the addition of ifAlias in RFC2863)

If a particular board is replaced with another just like it, and the NAT
assignments remain the same, it might be inappropriate to align the
information related to the old board with the new board.

So an NMS should be able to detect when an instance has been simply
renumbered (the managed entity is the same, but its identifier has been
changed), and it should be able to detect when the thing an instance
identifier points to has actually changed (possibly rules about identifier
reuse).

 

I think identifier reassignments will be an especially sensitive
consideration for logging, when used to support law enforcement.

 

It could be important to align SNMP notifications and syslog entries and
ipfix data at the NMS side.

I recommend we standardize the information model of NAT instance identifier,
so it's usage is consistent across multiple protocols and across vendors.

 

4. With instance table mechanism, SNMP Contexts can be used for the purpose
of defining the contexts of the NMS system. For example, a router

being used in "multi tenant" mode, and each tenant having multiple instances
of NAT, Context can be used to define a specific Tenant. This

provides clear separation and one more hierarchy of scaling in a large scale
NAT.

 

OK. 

 The "overloading" of purpose has long been a problem with contexts.

Standardizing the information model for instance identifier would also allow
it to be used for more than one type of data model.

 

5. On the other hand, a small scale router that has single NAT instance, can
define just one instance with default attributes without any overhead.

 

OK.

 

 

Thanks,

Jagadish