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

From: "Jagadish Shivamurthy (jshivamu)" <[email-masked]>
Date: Tue, 29 Oct 2013 11:59:09 +0000

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.

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.

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.

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.

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.

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.

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.

Thanks,
Jagadish

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 29 Oct 2013 10:14:57 -0400

Hi,

Thanks for this explanation of the context scalability issue.

Comments inline.

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: Jagadish Shivamurthy (jshivamu) [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 7:59 AM
To: [email-masked]; [email-masked]; [email-masked]
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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 29 Oct 2013 10:57:24 -0400

Le 2013-10-29 10:14, ietfdbh a écrit :
> 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?
>
> 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)
>
> identifier points to has actually changed (possibly rules about
> identifier reuse).
>

All very good points.

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

At this moment, one solution I can imagine would be to define an 
ifAlias-like object for NAT instances. That's kinda sucky, and far from 
what I would call a standardization of the information model of NAT 
instance identifiers.

Any other idea?

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: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 30 Oct 2013 00:48:29 +0000

Forwarding Hongchi's response to the list..

From: "Hongchi Shih (hshih)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 29, 2013 3:35 PM
To: ietfdbh <[email-masked]<mailto:[email-masked]>>, "Jagadish Shivamurthy (jshivamu)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Senthil Sivakumar <[email-masked]<mailto:[email-masked]>>, "Ganesan Rajam (grajam)" <[email-masked]<mailto:[email-masked]>>, "Swaroop George (swaroop)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-09.txt

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

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

Hi,

David Harrington
[email-masked]<mailto:[email-masked]>
+1-603-828-1401
From: Jagadish Shivamurthy (jshivamu) [mailto:[email-masked]]
Sent: Tuesday, October 29, 2013 7:59 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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,

Thanks

Jagadish

OK.

OK.

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

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.

Understood.

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.

[*****]
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.

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.

OK.

Thanks,
Jagadish

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 30 Oct 2013 00:49:06 +0000

Forwarding to the list..

On 10/29/13 3:43 PM, "Hongchi Shih (hshih)" <[email-masked]> wrote:

>
>
>On 10/29/13, 7:57 AM, "Simon Perreault" <[email-masked]>
>wrote:
>
>>> identifier, so it¹s usage is consistent across multiple protocols and
>>> across vendors.
>>
>That is not sucky.  In fact, we always have an unique index and name to
>identify a device instance.
>Normally, the name index is used by XML and/or command line to identify a
>device.
>We use a integer value index in MIB table access is because of access
>performance and efficiency consideration.
>
>If we use XML to manage this NAT device, then it will use a "Name string"
>to identify this NAT instance.
>
>Thanks.
>-Hongchi 
>
>
>>
>>Thanks,
>>Simon
>>--

---

From: "Hongchi Shih (hshih)" <[email-masked]>
Date: Tue, 29 Oct 2013 19:35:23 +0000

Hi,

Hi,

David Harrington

Hi David, Simon,

Thanks

Jagadish

OK.

OK.

Understood.

[*****]

[*****]

[*****]

[*****]

[*****]

OK.

OK.

Thanks,
Jagadish

---

From: "Hongchi Shih (hshih)" <[email-masked]>
Date: Tue, 29 Oct 2013 19:43:17 +0000

[*****]

Thanks.
-Hongchi