Hi,

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

From: ietfdbh <ietfdbh@comcast.net>
Date: Tuesday, October 29, 2013 at = 7:14 AM
To: "Jagadish Shivamurthy (jsh= ivamu)" <jshivamu@cisco.com>, "simon.perreaul= t@viagenie.ca" <= simon.perreault@viagenie.ca>, "behave@ietf.org" <behave@ietf.org>
Cc: "Senthil Sivakumar (ssenth= il)" <ssenthil@cisco.com&= gt;, Hongchi Shih <hshih@cisco.com>, "Ganesan Rajam (grajam)" <grajam@cisco.com>, "Swaroop George (swaroop)" <swaroop@cisco.com>
Subject: RE: [BEHAVE] I-D Action: d= raft-ietf-behave-nat-mib-09.txt

Thanks for this explanation of the= context scalability issue.

Comments inline.

David Harrington

ietfdbh= @comcast.net

+1-603-828-1401

From: Jagadish Shivamurthy (jshivamu) [mailto:jshivamu@cisco.com]
Sent: Tuesday, October 29, 2013 7:59 AM
To: ietfdbh@comcast.net; = simon.perreault@viagenie.ca; behave@= ietf.org
Cc: Senthil Sivakumar (ssenthil); Hongchi Shih (hshih); Ganesan Raja= m (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 deploym= ent scenarios to consider the instance based mechanism. If you see any spec= ific issues (inter-operability or other issues), with instance based design of the MIB, please let us know.

Thanks

Jagadish

<= /o:p>

1. An SNMP V3 context (or SNM= P v2c Community name) has to be configured for each NAT instance. The = SNMP context (or community name) has to be mapped to specific NAT inst= ance. 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_configura= tion_example09186a0080b1ff61.shtml as an example of configuring the SNMP contexts/community names on Cisco IOS p= latforms. A similar configuration exercise will be needed for other pl= atforms.

OK.

<= /o:p>

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

OK.

Let me poin= t out that the IETF still supports a standard for =93single-instance=94 Bri= dge MIB modules (RFC1493, 4188,4363, and 4318).

The IETF tu= rned over further Bridge MIB work to the IEEE.

The IEEE de= veloped Provider Backbone Bridges, which allows for multiple instances.

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

The additio= n of instance-indexing required that the OID assignments for Bridge-MIB rel= ated objects be completely reassigned.

Exist= ing NMS systems that knew how to query, say, the number of ports using dot1dB= aseNumPorts at { dot1= dBase 2 }

Now needs t= o query ieee8021BridgeBaseNumPorts at {ieee8021BridgeBaseEntry 3} =96 a tota= lly different OID for the same info.

<= /o:p>

On the other hand, MPLS-L3VPN= -STD-MIB.my defined in RFC 4382 supports multiple instances directly w= ithout 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.=

<= /o:p>

2. The Context approach grows= in an MxN manner if there are M different features (MIBs) and N number of&= nbsp;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 co= nfigure those many contexts.

Understood.= Thanks for clearly explaining the problem.

<= /o:p>

3. An instance table based ap= proach provides for plug and play kind of deployment. It will not requ= ire any additional configuration on the router

to make NMS pull data for mul= tiple instances. The NMS walks through the instance table and builds d= ata 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 a= cross reboot.

ifIndex has= a corresponding ifAlias that is persistent across reboots.

[*****]

Yes. We keep both ifIndex and ifAlias persistent across reboots.

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

While ifInd= ex can be changed across reboots, ifAlias must remain constant across reboo= ts.

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

Without thi= s 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.<= o:p>

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 ifTab= le for this NAT table , then NAT index and NAT name/alias will be per= sistent across reboot.

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

[*****]

We will have 1..N NAT per board instead of just one NAT pe= r 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 mi= ght not have the information necessary to assign the same numbers to each i= nstance on reboot, so it needs to renumber (thus the long discussion, and the addition of ifAlias in RFC2863)<= /p>

[*****]

We can follow that way. We also can add a notification "NAT Insta= nce change notification" for the NAT instance reassignment = ;of a managed system which can't make instance index/ name pers= istent across reboot and/or a real NAT instance change" due to board OIR.

This notification generation will inform NMS to re-learn NAT devices &= nbsp;from the managed system reboot and or board OIR.

The NAT instance table should associate to the entPh= ysicalIndex of Physical Entity Table to indicate the location of the = NAT instance.

If a partic= ular board is replaced with another just like it, and the NAT assignments r= emain the same, it might be inappropriate to align the information related to the old board with the new board.=

So an NMS s= hould be able to detect when an instance has been simply renumbered (the ma= naged entity is the same, but its identifier has been changed), and it should be able to detect when the thing an insta= nce identifier points to has actually changed (possibly rules about identif= ier reuse).

I think ide= ntifier reassignments will be an especially sensitive consideration for log= ging, when used to support law enforcement.

[*****]

NMS has a lot of experience on managing ifTable from IF-MIB and e= ntPhysicalTable from ENTITY-MIB. This NAT Table is similar to ifTable= and entPhysicalTable from those two MIBs. For the logging considerat= ion 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=92s= usage is consistent across multiple protocols and across vendors.

4. With instance table mechan= ism, SNMP Contexts can be used for the purpose of defining the context= s of the NMS system. For example, a router

being used in "multi ten= ant" mode, and each tenant having multiple instances of NAT, Cont= ext 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 = =93overloading=94 of purpose has long been a problem with contexts.

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

<= /o:p>

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

OK.

Thanks,

Jagadish

--_000_CB1B483277FEC94E9B58357040EE5D0236489810xmbrcdx15ciscoc_-- From ssenthil@cisco.com Tue Oct 29 17:49:36 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6290511E82B9 for ; Tue, 29 Oct 2013 17:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ984MhO5cJq for ; Tue, 29 Oct 2013 17:49:31 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 27B9311E82B5 for ; Tue, 29 Oct 2013 17:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2768; q=dns/txt; s=iport; t=1383094171; x=1384303771; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=FEU6dtPkkQQUIqgB5N6mZae4OxLzIknPF3LpGLmCzOw=; b=U9GGDos88PVNDx27xnnSJz4s/ldy9lacWF958s9fkN2iTrSvLsAWsWOH yVnJOcUzl4dCS5Urglwq/5H/A+5XdOAQOriiisHr4OUMRohFvHlPrxJCw mk4uOumfHDTelNiLBJUVaxB9JezqpMAF3p5uwVBT/NEK6tDYKTKDvOeY9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFAFZXcFKtJV2c/2dsb2JhbABPCoMHOFS/PYEqFm0HgiUBAQEEJ1ISAQgiVhsBBgMCBA4FCBOHbLpnjX6BEjEHgx+BDQOZOZBZgyaCKg X-IronPort-AV: E=Sophos;i="4.93,597,1378857600"; d="scan'208";a="278325359" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 30 Oct 2013 00:49:07 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9U0n7j9010288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 30 Oct 2013 00:49:07 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.246]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 19:49:07 -0500 From: "Senthil Sivakumar (ssenthil)" To: "behave@ietf.org" Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-09.txt Thread-Index: AQHO1J5GVOEDQ9ROsUi+4b3GQWo7sZoMDRKAgAAL3QCAAE/ggIAAEmEA Date: Wed, 30 Oct 2013 00:49:06 +0000 Message-ID: In-Reply-To: <87D25FCF512C8443BB97BC6EB7CCFDF80F9831E6@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.117.198.131] Content-Type: text/plain; charset="windows-1254" Content-ID: <7570ED6F5EEF39408839E7BF93829179@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Hongchi Shih $hshih$" Subject: [BEHAVE] FW: I-D Action: draft-ietf-behave-nat-mib-09.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 00:49:36 -0000 Forwarding to the list.. On 10/29/13 3:43 PM, "Hongchi Shih (hshih)" wrote: > > >On 10/29/13, 7:57 AM, "Simon Perreault" >wrote: > >>Le 2013-10-29 10:14, ietfdbh a =E9crit : >>> 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. >> >>All very good points. >> >>> I recommend we standardize the information model of NAT instance >>> identifier, so it=B9s 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? >[*****] >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=20 > > >> >>Thanks, >>Simon >>--=20 >>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 hshih@cisco.com Tue Oct 29 12:37:25 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6EF11E828A for ; Tue, 29 Oct 2013 12:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.398 X-Spam-Level: X-Spam-Status: No, score=-9.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qckPEk8WoQd3 for ; Tue, 29 Oct 2013 12:36:21 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 71F6121E80B0 for ; Tue, 29 Oct 2013 12:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39017; q=dns/txt; s=iport; t=1383075342; x=1384284942; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=IXoDAbD/1uAAhpms/JsEB2/fF25qagSZEtyA3a90GFM=; b=T9bui/Y0u+DjqjJAKjszcM+pg/7EvVZ12r04PAvifMtPyl9vpwVc1Qnq ELG8bwn610NiX5q4Vfkc9MjSmWsH7oPGQC1/G/hDNPz80lyOFW7lLRqE8 qEJ+xi38GKdappMlcrkiG60dxwDG3FMfeCTmD1qL/QCaZBB/rKoF5Z0Vo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAE4NcFKrRDoH/2dsb2JhbABWA4JDRDhUvzSBLBZ0giUBAQEELUwSAQgRAwEBAQsWAQY5FAkIAgQBDQUIDIdhAw4BDbA0CIlwjxYgARAGAQkIgw6BDQOBU4QApD+DJoIq X-IronPort-AV: E=Sophos;i="4.93,595,1378857600"; d="scan'208,217";a="92672438" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 29 Oct 2013 19:35:28 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9TJZOxx018345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 19:35:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.110]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 14:35:24 -0500 From: "Hongchi Shih (hshih)" To: ietfdbh , "Jagadish Shivamurthy (jshivamu)" , "simon.perreault@viagenie.ca" , "behave@ietf.org" Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-09.txt Thread-Index: AQHO1N4CKzv1IqwjKEidfBdXNUTL/A== Date: Tue, 29 Oct 2013 19:35:23 +0000 Message-ID: <87D25FCF512C8443BB97BC6EB7CCFDF80F9831D0@xmb-rcd-x10.cisco.com> In-Reply-To: <03ee01ced4b1$3f5e5610$be1b0230$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.155.34.47] Content-Type: multipart/alternative; boundary="_000_87D25FCF512C8443BB97BC6EB7CCFDF80F9831D0xmbrcdx10ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 30 Oct 2013 08:20:44 -0700 Cc: "Ganesan Rajam $grajam$" , "Swaroop George $swaroop$" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-09.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:37:29 -0000 --_000_87D25FCF512C8443BB97BC6EB7CCFDF80F9831D0xmbrcdx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Please look [*****] for my response. From: ietfdbh > Date: Tuesday, October 29, 2013 at 7:14 AM To: "Jagadish Shivamurthy (jshivamu)" >, "simon.perreault@viagenie.ca" >, "beha= ve@ietf.org" > Cc: "Senthil Sivakumar (ssenthil)" >, Hongchi Shih >, "Ganesan R= ajam (grajam)" >, "Swaroop George= (swaroop)" > 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 ietfdbh@comcast.net +1-603-828-1401 From: Jagadish Shivamurthy (jshivamu) [mailto:jshivamu@cisco.com] Sent: Tuesday, October 29, 2013 7:59 AM To: ietfdbh@comcast.net; simon.perreault@viagen= ie.ca; behave@ietf.org Cc: Senthil Sivakumar (ssenthil); Hongchi Shih (hshih); Ganesan Rajam (graj= am); 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 multi= ple instances in deployment scenarios to consider the instance based mechan= ism. If you see any specific issues (inter-operability or other issues), wi= th 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 t= o specific NAT instance. Hence, this method involves 'additional' configura= tion 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) ta= sk. You can refer http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_exam= ple09186a0080b1ff61.shtml as an example of configuring the SNMP contexts/co= mmunity 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 149= 3). However, customers configure hundreds of L2VPN bridges and we had to re= lay on the customer to configure an SNMP context for each instance. OK. Let me point out that the IETF still supports a standard for =93single-inst= ance=94 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 ins= tances. See http://www.ieee802.org/1/files/public/MIBs/IEEE8021-BRIDGE-MIB-20120810= 0000Z.txt (and http://www.ieee802.org/1/files/public/MIBs/IEEE8021-TC-MIB-2= 01202150000Z.txt) The addition of instance-indexing required that the OID assignments for Bri= dge-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= } =96 a totally different OID for the same info. On the other hand, MPLS-L3VPN-STD-MIB.my defined in RFC 4382 supports multi= ple 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 fea= tures (MIBs) and N number of average instances per feature (except rare cas= es where many different features/MIBs can be identified by a common attribu= te). 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 depl= oyment. It will not require any additional configuration on the router to make NMS pull data for multiple instances. The NMS walks through the ins= tance 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 interfac= e instances. ifIndex has quite a lot of discussion about interoperability, especially pe= rsistence 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 a= n interface, even across reboots of the managed device. While ifIndex can be changed across reboots, ifAlias must remain constant a= cross 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 likel= y 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 thi= s 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 i= f a board is removed/added/replaced? [*****] We will have 1..N NAT per board instead of just one NAT per board. Our de= sign 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 assi= gnments of NAT instance identifiers? A device might not have the information necessary to assign the same number= s to each instance on reboot, so it needs to renumber (thus the long discus= sion, 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 whi= ch 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 Physi= cal Entity Table to indicate the location of the NAT instance. If a particular board is replaced with another just like it, and the NAT as= signments remain the same, it might be inappropriate to align the informati= on related to the old board with the new board. So an NMS should be able to detect when an instance has been simply renumbe= red (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 point= s to has actually changed (possibly rules about identifier reuse). I think identifier reassignments will be an especially sensitive considerat= ion for logging, when used to support law enforcement. [*****] NMS has a lot of experience on managing ifTable from IF-MIB and entPhysical= Table from ENTITY-MIB. This NAT Table is similar to ifTable and entPhysica= lTable 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 ip= fix data at the NMS side. I recommend we standardize the information model of NAT instance identifier= , so it=92s usage is consistent across multiple protocols and across vendor= s. 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 instance= s of NAT, Context can be used to define a specific Tenant. This provides clear separation and one more hierarchy of scaling in a large scal= e NAT. OK. The =93overloading=94 of purpose has long been a problem with contexts. Standardizing the information model for instance identifier would also allo= w 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, ca= n define just one instance with default attributes without any overhead. OK. Thanks, Jagadish --_000_87D25FCF512C8443BB97BC6EB7CCFDF80F9831D0xmbrcdx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <243E3C997AA65A40BDE91B6A65F06548@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi,

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

Hi,

Thanks for this explanation of the = context scalability issue.

Comments inline.

David Harrington

ietfdbh@= comcast.net

+1-603-828-1401

Hi David, Simon,

Thanks

Jagadish

<= /o:p>

OK.

<= /o:p>

OK.

Let me point= out that the IETF still supports a standard for =93single-instance=94 Brid= ge MIB modules (RFC1493, 4188,4363, and 4318).

<= /o:p>

The IETF tur= ned over further Bridge MIB work to the IEEE.

The IEEE dev= eloped Provider Backbone Bridges, which allows for multiple instances.=

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

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

Existi= ng NMS systems that knew how to query, say, the number of ports using dot1dBa= seNumPorts at { dot1d= Base 2 }

Now needs to= query ieee8021BridgeBaseNumPorts at {ieee8021BridgeBaseEntry 3} =96 a tota= lly different OID for the same info.

<= /o:p>

Understood.<= o:p>

<= /o:p>

Understood. = Thanks for clearly explaining the problem.

<= /o:p>

3. An instance table based ap= proach provides for plug and play kind of deployment. It will not requ= ire any additional configuration on the router

to make NMS pull data for mul= tiple instances. The NMS walks through the instance table and builds d= ata for each instance.

<= /o:p>

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

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

This would b= e similar to ifIndex, which is assigned by a router to interface instances.=

<= /o:p>

ifIndex has = quite a lot of discussion about interoperability, especially persistence ac= ross reboot.

ifIndex has = a corresponding ifAlias that is persistent across reboots.

[*****]

Yes. We keep both ifIndex and ifAlias persistent across reboots.

<= /span>

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

While ifInde= x can be changed across reboots, ifAlias must remain constant across reboot= s.

This allows = an NMS to recognize that interface#3 has now become interface#4, and can al= ign 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.<= o:p>

<= /o:p>

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 ifTab= le for this NAT table , then NAT index and NAT name/alias will be per= sistent across reboot.

<= /span>

Assuming a c= hassis-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 pe= r board. Our design always consider expendability/flexibility.

We have never designed a board that has the restriction of = ;one per board.

<= /span>

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

A device mig= ht not have the information necessary to assign the same numbers to each in= stance on reboot, so it needs to renumber (thus the long discussion, and the addition of ifAlias in RFC2863)<= /p>

[*****]

This notification generation will inform NMS to re-learn NAT devices &= nbsp;from the managed system reboot and or board OIR.

The NAT instance table should associate to the entPh= ysicalIndex of Physical Entity Table to indicate the location of the = NAT instance.

<= /span>

If a particu= lar board is replaced with another just like it, and the NAT assignments re= main the same, it might be inappropriate to align the information related to the old board with the new board.=

So an NMS sh= ould be able to detect when an instance has been simply renumbered (the man= aged entity is the same, but its identifier has been changed), and it should be able to detect when the thing an insta= nce identifier points to has actually changed (possibly rules about identif= ier reuse).

<= /o:p>

I think iden= tifier reassignments will be an especially sensitive consideration for logg= ing, when used to support law enforcement.

[*****]

<= /span>

<= /o:p>

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=92s = usage is consistent across multiple protocols and across vendors.

<= /o:p>

4. With instance table mechan= ism, SNMP Contexts can be used for the purpose of defining the context= s of the NMS system. For example, a router

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

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

<= /o:p>

OK.

The = =93overloading=94 of purpose has long been a problem with contexts.

Standardizin= g the information model for instance identifier would also allow it to be u= sed for more than one type of data model.

<= /o:p>

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

<= /o:p>

OK.

Thanks,

Jagadish

--_000_87D25FCF512C8443BB97BC6EB7CCFDF80F9831D0xmbrcdx10ciscoc_-- From hshih@cisco.com Tue Oct 29 12:44:26 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463F621F9DB0 for ; Tue, 29 Oct 2013 12:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 549FmdVpb8AD for ; Tue, 29 Oct 2013 12:44:21 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE1E11E8292 for ; Tue, 29 Oct 2013 12:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2588; q=dns/txt; s=iport; t=1383075815; x=1384285415; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+QTEIqbJ/CgIEB/2gAW8uPaZHMLelQ/GPF43uaj9S8Y=; b=ab+K/o9ps0e2xdPtXuDLLOutWGd/DABDxYYIhGB8aL7HyOP0KodKfyCB s1EVtTJoBQtufZ89EgnDQFcte85BWcDJwWdGcoyfdcYprqkvpuZDpxVLG NIvLMet8s37doGZvppPJHoZoe9nQ2h/1INgJEcGNxn+DXIot/iMGmFYnY 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FACkPcFKtJXG8/2dsb2JhbABPCoMHOFS/NIEsFnSCJwEEJ1ISAQgiViUCBAENBQgTh2y6QI4EgRIxB4MfgQ0DiQeQMpBZgyaCKg X-IronPort-AV: E=Sophos;i="4.93,595,1378857600"; d="scan'208";a="278130823" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 29 Oct 2013 19:43:18 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9TJhIFK018986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 19:43:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.110]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 14:43:18 -0500 From: "Hongchi Shih (hshih)" To: Simon Perreault , ietfdbh Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-09.txt Thread-Index: AQHO1N8dKzv1IqwjKEidfBdXNUTL/A== Date: Tue, 29 Oct 2013 19:43:17 +0000 Message-ID: <87D25FCF512C8443BB97BC6EB7CCFDF80F9831E6@xmb-rcd-x10.cisco.com> In-Reply-To: <526FCCD4.5040703@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.155.34.47] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 30 Oct 2013 08:20:44 -0700 Cc: "Ganesan Rajam $grajam$" , "Jagadish Shivamurthy $jshivamu$" , "behave@ietf.org" , "Swaroop George $swaroop$" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-09.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:44:27 -0000 On 10/29/13, 7:57 AM, "Simon Perreault" wrote: >Le 2013-10-29 10:14, ietfdbh a =E9crit : >> 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. > >All very good points. > >> I recommend we standardize the information model of NAT instance >> identifier, so it=B9s 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? [*****] 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=20 > >Thanks, >Simon >--=20 >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