| Re: The changs log of CAPWAP Dot11 MIB version 03 | <– Date –> <– Thread –> |
From: David Harrington (ietfdbh comcast.net)
|
|
| Date: Tue, 3 Mar 2009 15:05:03 -0800 (PST) | |
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 > -----Original Message----- > From: shiyang 00338 [mailto:young [at] h3c.com] > Sent: Tuesday, March 03, 2009 8:59 AM > To: capwap [at] frascone.com > Cc: chelliot [at] cisco.com; yozhang [at] gmail.com > Subject: [Capwap] The changs log of CAPWAP Dot11 MIB version 03 > > > Hi, > > The CAPWAP Dot11 MIB version 03 was published, and most > changes are to > close issues found by Dan. We also modified some issue > found ourself. > > > > T1. T4. 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 > > > > > > > Shi, et al. Expires September 4, 2009 > [Page 23] > > > > Internet-Draft CAPWAP Protocol Binding MIB > March 2009 > > > > > all, and in any case there is no text in the document that > explains > this mechanism. > > > > > -------------------------------------------------------------- > > > > In the Capwap Digest, Vol 39, Issue 4, we gave the text to > explain a > mechanism that preserves the values of ifIndex, Request > mailing list > to confirm it. > > > > In the section of "Relationship to the IF-MIB", add text: > > > > Also, the system (AC) MUST have a mechanism that preserves > the values > of ifIndex of 'WLAN Service Interface' ifType in the > ifTable at AC > reboot. > > > > Also, the system (AC) MUST have a mechanism that preserves > the values > of ifIndex of 'WLAN BSS Interface' ifType in the ifTable > at AC > reboot. > > > > T2. Is the WLAN Service interface described in Section > 7.2 modeled > by capwapDot11WlanConfigTable? If so please say it and > make this > clear by using a more explicit naming convention. The > model here is > not clear to me. On one hand you say 'the interface > SHOULD be > modeled as an ifEntry ...' Why only a SHOULD and not a > MUST? What > is the procedure for the manager? Is he looking for all > 802.11 > interfaces on the AC and then creates manually a WLAN > Service entry > in the table for each? What if the ifNumber does not > correspond to a > 802.11 interface? What if the 802.11 interface > disappears? > > > > -------------------------------------------------------------- > --- > > > 1) The "WLAN Service interface" is modeled by > > capwapDot11WlanConfigTable, and capwapDot11WlanConfigTable > is rename > as capwapDot11WlanTable. > > > > 2) Yes, the the interface MUST be modeled as an ifEntry, > not SHOULD > be > > > > 3) What is the procedure for the manager? Is he looking > for all > 802.11 interfaces on the AC and then creates manually a > WLAN Service > entry in the table for each? > > > > Please refer to the section of Example of CAPWAP-DOT11-MIB > Module > Usage (the section is updated in the new version). > > > > The creation operation of a row object on > capwapDot11WlanTable would > trigger system to create "WLAN service Interface", and it > does not > require operator to manually create a "WLAN service > Interface". > > > > > > > Shi, et al. Expires September 4, 2009 > [Page 24] > > > > Internet-Draft CAPWAP Protocol Binding MIB > March 2009 > > > > > In the section of "Relationship to the IF-MIB", add text: > > > > Also, the system (AC) MUST have a mechanism that preserves > the values > of ifIndex of 'WLAN Service Interface' ifType in the > ifTable at AC > reboot. > > > > T3. What 'could be always enabled' means for > ifAdminStatus and > ifOperStatus in the WLAN Service Interface table? Either > change this > to MUST or explain in what cases these should be other > than enabled. > > > > -------------------------------------------------------------- > > > > The section for interpration of specific MIB objects in > the iftable > was removed in the new version. Reader could refer to > RFC2863 > > > T4. What does the statement that 'the other objects such > as > ifInOctets ... are unused' relative to the VLAN Service > interface > mean? Counters are always zero? > > > > > -------------------------------------------------------------- > > > > The section for interpration of specific MIB objects in > the iftable > was removed in the new version. Reader could refer to > RFC2863 > > > T5. In 7.4 - does the text mean that the manager can > reuse objects > from the IEEE 802.11 MIB modules, or that values of these > objects are > being duplicates in this MIB module? (why? Which ones?) > In any case > the IEEE 802.11 standard that defines these objects must > be a > Normative Reference for this document. > > > > > -------------------------------------------------------------- > --- > > > Yes > > > > 1)the text mean that the manager can reuse objects from > the IEEE > 802.11 MIB modules, and the section of "Mechanism of > Reusing Wireless > Binding MIB Module" give explain to it. > > > > 2) also, add one text of "The CAPWAP-DOT11-MIB module does > not > duplicate those objects in the MIB module of IEEE 802.11 > standard." > in the section of "7.4. Relationship to MIB Module in > IEEE 802.11 > Standard" > > > > 3) yes, IEEE 802.11 standard was added as a Normative > Reference. > > > T6. The RFCs that define all MIB modules required for > IMPORTSs must > be Normative References to this document. > > > > > > > > > > Shi, et al. Expires September 4, 2009 > [Page 25] > > > > Internet-Draft CAPWAP Protocol Binding MIB > March 2009 > > > > > > -------------------------------------------------------------- > --- > > > add reference to RFC3411 in the section of "MIB modules > required for > IMPORTS", add "SNMP-FRAMEWORK-MIB [RFC3411]," > > > > T7. The value of the object capwapBaseWTPId in the > example is the > string '12345678' not the integer 12345678 > > > > > -------------------------------------------------------------- > --- > > > Yes, it is change into '12345678' > > > > T8. The names of the objects in the > capwapDot11WlanConfigTable are > not consistent (similar prefix) to > capwapDot11WlanConfigEntry. > > > --------------------------------------------------------- > > > > Yes, they are changed with: > > > > CapwapDot11WlanEntry ::= > > SEQUENCE { > > capwapDot11WlanId > CapwapDot11WlanIdTC, > capwapDot11WlanServiceIfIndex InterfaceIndex, > > capwapDot11WlanMacType > CapwapBaseMacTypeTC, > capwapDot11WlanTunnelMode > CapwapBaseTunnelModeTC, > capwapDot11WlanRowStatus RowStatus > > } > > > > T9. The names of the objects in the > capwapDot11WlanBindTable are not > consistent (similar prefix) to capwapDot11WlanBindEntry. > > > > --------------------------------------------------------- > > > > Yes, they are changed with: > > > > CapwapDot11WlanBindEntry ::= > > SEQUENCE { > > capwapDot11WlanBindBssIfIndex InterfaceIndex, > > capwapDot11WlanBindBssRowStatus RowStatus > > } > > > > T10. What does 'Bits are exclusive for each other for a > specific > WLAN Id' mean for capwapDot11WlanTunnelMode? That only > one tunnel > mode can be configured (one bit set)? I assume this does > not include > the bit unused(0). What happens if the manager sets more > than one > bit, ore no bit, or unused(0) - how does the agent behave > in this > case? > > > > > > > > > > Shi, et al. Expires September 4, 2009 > [Page 26] > > > > Internet-Draft CAPWAP Protocol Binding MIB > March 2009 > > > > > > -------------------------------------------------------------- > --- > > > 1) Yes, unused(0) is removed. > > > > 2) The description is updated with: > > > > Bits are exclusive with each other for a specific WLAN Id, > and only > one tunnel mode could be configured. If operator set more > than one > bit, the value of the Response-PDU's error-status field is > set to > `wrongValue', and the value of its error-index field is > set to the > index of the failed variable binding." > > > > T11. What is the persistency of the > capwapDot11WlanTunnelMode at > agent reboot? Is the whole table persistent at agent > reboot? > > > > -------------------------------------------------------------- > --- > > > Yes, it should be whole table persistent instead of > previous > statement "Values of all read-create objects in this table > are > persistent at restart/reboot." > > > > T12. I do not understand how does row creation in the > > capwapDot11WlanBindTable work. It is indexed by ifIndex > and > capwapDot11WlanId. The only visible object in this table > except > RowStatus is capwapDot11WlanBssIfIndex which is read-only > and the > description says that 'it is the same interface as > identified by the > same value of ifIndex. But the manager cannot read its > value until > the row exists. How does the manager know its value in > order to > create the row in the table? > > > > > -------------------------------------------------------------- > -- > > > The old description would lead to misunderstanding when it > says "The > interface identified by a particular value of this index > is the same > interface as identified by the same value of ifIndex". In > fact, the > ifIndex here is not a ifIndex in the INDEX { ifIndex (it > is a > "Wireless virtual radio interface), capwapDot11WlanId }, > while it is > a "WLAN "WLAN BSS Interface". > > > > To clarify it, the following text is added to the > description of > capwapDot11WlanBindBssIfIndex: > > > > The ifIndex here is for an interface of 'WLAN BSS > Interface'. For a > WLAN configuration on a radio, an interface of 'WLAN BSS > Interface' > will correspond to it. The creation operation of a row > object on the > capwapDot11WlanBindTable would trigger AC system to > automatically > create a 'WLAN BSS Interface' and it is identified by > ifIndex. It > does not require operator to manually create a 'WLAN BSS > Interface'. > > > > > > > Shi, et al. Expires September 4, 2009 > [Page 27] > > > > Internet-Draft CAPWAP Protocol Binding MIB > March 2009 > > > > > For the table of capwapDot11WlanBindTable, the description > is updated > with the following text: > > > > A table of objects that configure which WLAN (identified > by > capwapDot11WlanId) will be provided on which 'WTP Virtual > Radio > Interface' (identified by ifIndex) Also, display and > control the > mapping relationship between interface of 'WTP Virtual > Radio > Interface' interface and interface of 'WLAN BSS > Interface'. The PHY > address for interface of 'WTP Virtual Radio Interface' > ifType will be > base BSSID address for PHY radio. > > > > Values of all bjects in this table are persistent at > restart/reboot. > > > For the table of capwapDot11WlanBindEntry, the description > is updated > with the following text: > > > > A set of objects that display the mapping relationship > between > interface of 'WTP Virtual Radio Interface' and interface > of 'WLAN BSS > Interface'. The Index object ifIndex is a ifIndex of a > 'WTP Virtual > Radio Interface'. > > > > T13. Is the capwapDot11WlanBindTable persistent at agent > reboot? > > > > -------------------------------------------------------------- > --- > > > Yes, The whole table is persistent at restart/reboot. > > > > E1. Not all acronyms are expanded at first occurrence - > e.g. WTP > > > > -------------------------------------------------------------- > --- > > > The Terminology section is updated with more Terminology > such as > CAPWAP,WTP,AC, Wireless Binding,Split and Local MAC and so > on. > > > E2. Please avoid using the construct 'the MIBs' (e.g. in > Section 5). > s/the MIBs/the MIB modules/ > > > > > -------------------------------------------------------------- > --- > > > use either "MIB module" or "MIB modules" in the document > > > > E3. There is no need to include sections 6.1 and 6.2, > they provide > no new or specific information for this MIB module. > > > > > -------------------------------------------------------------- > -- > > > Yes, they were removed > > > > > > > > > > Shi, et al. Expires September 4, 2009 > [Page 28] > > > > Internet-Draft CAPWAP Protocol Binding MIB > March 2009 > > > > > E4. I suggest for this document to be verified by a > native English > speaker for English spelling and grammar. > > > > E5. ifIndex, ifDescr, ifName, ifAlias in the WLAN Service > Interface > and WLAN BSS Interface table contain no specific > information, I > suggest to just mention that they are used as per RFC 2863 > > > > > -------------------------------------------------------------- > > > > The section for interpration of specific MIB objects in > the iftable > was removed in the new version. Reader could refer to > RFC2863 > > > Other changes made by authors: > > 1) reorganized the section of overview, and divided it into > the > following sub sections: > > 5. Overview . . . . . . . . . . . . . . . . . . . . . . . > . . . . 5 > 5.1. Requirements and Constraints . . . . . . . . . . . > . . . . 5 > 5.2. Mechanism of Reusing Wireless Binding MIB Module . > . . . . 5 > > > 2) Update some words in the section of" Example of > CAPWAP-DOT11-MIB > Module Usage, especially explain how interfaces of > > "WLAN service Interface" and "WLAN BSS Interface" are > created. > > > 3) Modify the value scope of CapwapDot11WlanIdTC from (1, 16) > to > (1, 512), and description of it. > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap >
-
The changs log of CAPWAP Dot11 MIB version 03 shiyang 00338, March 3 2009
- Re: The changs log of CAPWAP Dot11 MIB version 03 David Harrington, March 3 2009
Results generated by Tiger Technologies using MHonArc.