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

["Hongchi Shih (hshih)" <[e-mail]>]

Hi,
Please look [*****] for my response.


From: ietfdbh <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 29, 2013 at 7:14 AM
To: "Jagadish Shivamurthy (jshivamu)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "Senthil Sivakumar (ssenthil)" <[e-mail]<mailto:[e-mail]>>, Hongchi Shih <[e-mail]<mailto:[e-mail]>>, "Ganesan Rajam (grajam)" <[e-mail]<mailto:[e-mail]>>, "Swaroop George (swaroop)" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-09.txt

Hi,

Thanks for this explanation of the context scalability issue.
Comments inline.



David Harrington
[e-mail]<mailto:[e-mail]>
[phone]
From: Jagadish Shivamurthy (jshivamu) [mailto:[e-mail]]
Sent: Tuesday, October 29, 2013 7:59 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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_example09186a0080b1ff61.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.

[*****]
Yes. We  keep both ifIndex and ifAlias 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?

[*****]
It is the same as ifTable.  If we take the same approach of ifTable for this NAT table , then  NAT index and NAT name/alias will be persistent across reboot.




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

[*****]
We will have  1..N  NAT per board instead of just one NAT per board. Our design always consider expendability/flexibility.
We have never designed  a board that has the restriction of  one per board.


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)

[*****]
We can follow that way. We also can add a notification "NAT Instance change notification"  for the NAT instance reassignment  of a managed system  which can't make  instance index/ name persistent across reboot and/or a real NAT instance change" due to board OIR.

This notification generation will inform NMS to re-learn NAT devices  from the managed system  reboot and or board OIR.
The NAT instance table  should  associate to the  entPhysicalIndex of Physical Entity Table  to indicate the location of the NAT instance.



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.

[*****]
NMS has a lot of experience on managing ifTable from IF-MIB and entPhysicalTable from ENTITY-MIB.  This NAT Table is similar to ifTable and entPhysicalTable from those two MIBs.  For the logging consideration of this MIB, it is no difference from  other two IETF MIBs.




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