Subject: [Capwap] The update of question: Base MIB issue T4: About a mechanism that preserves the values of ifIndex

From: young <[email-masked]>
Date: Tue, 10 Mar 2009 09:53:09 +0800

Hi,

I updated the discussion record of issue: Base MIB issue T4: About a
mechanism that preserves the values of ifIndex.

Please check it in the http://www.capwap.org/cgi-bin/roundup.cgi/MIB/

Here is all discussion we have till now.

The issue was found by Dan:
   In order for ifIndex to be used as a common handler for the
   CAPWAP MIB and for the interface specific MIB modules like a dot11
   MIB from IEEE one needs to ensure that the same numbering scheme and
   mapping is used by all MIB modules, and that it behaves identically
   for events like interface card swapping, reset or power loss.  I do
   not see how this can happen, I am not sure that this is possible at
   all, and in any case there is no text in the CAPWAP MIB that explains
   this mechanism.
 
----------------------------------------------------------------------------
----------------
   We (editors) did change in the version 04:
   In the Capwap Digest, Vol 39, Issue 4
<http://www.capwap.org/cgi-bin/roundup.cgi/MIB/issue4> , we gave the text to
explain a
   mechanism that preserves the values of ifIndex, Request mailing list
   to confirm it.
 
1)  Yes, there are mechanisms that preserves the values of ifIndex in the 
ifTable at AC reboot. 
2) I do confirm some vendors support to preserves the values of ifIndex. The

mechanisms would depend on vendor's proprietary method.
3) Here I give one method they usually use.
It is common for most vendors: The device have configuration file to keep 
configuration, and interface name, device name and so on are in it. The
value 
of ifIndex for an interface is not in the configuration file. 
The proprietary method is:
Besides configuration file, system would have another file (suppose we call
it 
as interface file) to keep ifIndex value for a specific interface which is 
identified by interface name. When user execute save configuration file 
command, system would also save mapping relationship between interface name 
and ifIndex.
 
During system's initiation process, it would get initial value from 
configuration file. System could get interface name for a specific
interface, 
also it would 
Query information kept in the interface file, and get ifIndex for a specific

interface. 
By this way, ifIndex for a specific interface would keep same even after 
device reboot. 
 
   In the section of "Relationship to the IF-MIB", add text "Also, as
   ifIndex[RFC2863] will be used as common handler for corresponding
   interfaces in the CAPWAP-BASE-MIB and specific wireless technologies
   MIB modules, the system (AC) MUST have a mechanism that preserves
   the values of ifIndex in the ifTable at AC reboot."
 
----------------------------------------------------------------------------
-----------
   David gave comments to this change in the Capwap Digest, Vol 40, Issue 2
<http://www.capwap.org/cgi-bin/roundup.cgi/MIB/issue2> :
 
Hi,
 
I believe the interfaces-mib explicitly allows the ifIndex to not be
preserved 
across reboot. That was a conscious decision of the WG that did the update
to 
the interfaces-mib (despite the advice of those, like keith McLoughrie who 
explained that was a really really bad decision). But the WG did this
because 
it is very difficult for devices to be sure that the interfaces were not 
physically reordered (e.g., removal or insertion or moving of a board in a 
chassis) while the device was powered off during the reboot.
 
The ifName (if I remember correctly) was added to allow remote systems (such

as an NMS) to correlate new ifIndex assignments to pre-boot assignments.
 
I think it would be inappropriate to require non-changing ifIndexes.
 
dbh
----------------------------------------------------------------------------
-----------
 For David's comment, editors asked:
Can we use "should" /"may" instead of "must" for ifIndex persistence?
 
Dan gave reply:
 
This is not that easy. The problem cannot be solved by changing the MUST in 
SHOULD or MAY, because all the model is based on consistent indexing between

the CAPWAP agents and the 802.11 MIB agents. If persistency is not ensured
how 
can you ensure consistency? 
 
My opinion is that the solution that you have chosen is acceptable. Indeed,
as 
David mentions, this puts a requirement on CAPWAP agents that is not common
to 
other ifTable implementations, but I believe that this is acceptable here. 
This is not however what a standard ifTable implementation would do. Another

alternative would be to index the tables with ifAlias which is the
persistent 
object in ifTable that stores a name of the interface in a persistent
manner, 
which would allow using standard implementations without the need for
further 
constrains but will impose on managers to configure each interface with a
non-
default and unique ifAlias value.  
 
Dan

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap