1. Yang Shi (Richard), Yong Zhang IETF 74 th 26 March 2009, San Francisco CAPWAP WG MIB Drafts Report

2.  Current Work Status  Open issues requiring discussion  Next Step Agenda

3. CAPWAP Base MIB Current version: 04 Total number Issues found by WG: 43 Issues closed: 39 Open issues: 4 CAPWAP Dot11 MIB Current version: 03 Total number Issues found by WG: 18 Issues closed: 12 Open issues: 6 Current Work Status At present, all issues are tracked by www.capwap.org

4.  Current Work Status  Open issues requiring discussion  Next Step Agenda

5. A mechanism that preserves the values of ifIndex Dot11 MIB should add a new Terminology “WLAN Profile” Editors suggest to let Base MIB support a WTP Profile configuration function Open Issues Require to Discuss Most open issues are clear, the following issues Requiring discussion in the WG.

6. The issue Description (found by Dan): A mechanism that preserves the values of ifIndex (1/6) 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 document that explains this mechanism.

7. A mechanism used by some vendors: A mechanism that preserves the values of ifIndex (2/6) It is common for most vendors: The device have configuration file to maintain configuration information: 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 into the interface file.

8. A mechanism that preserves the values of ifIndex (3/6) During system's initiation process, it would get initial value such as interface name for a specific interface from configuration file. Also, it would Query information kept in the interface file, and get ifIndex by interface name for a specific interface. By this way, ifIndex for a specific interface would keep same even after device reboot. Configuration FileInterface File Save interface name Save the mapping relationship Between interface name and ifIndex

9. A mechanism that preserves the values of ifIndex (4/6) What have we updated? For persistence of ifIndex of “WTP Virtual Radio Interface”, “WLAN Service Interface” and “WLAN BSS Interface”, we added the following text in the base MIB version 04 and Dot11 MIB version 03: “Also, the system (AC) MUST have a mechanism that preserves the values of ifIndex of ‘XXX Interface' ifType in the ifTable at AC reboot”

10. A mechanism that preserves the values of ifIndex (5/6) Review comments to the mechanism 1)David Harrington 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.

11. A mechanism that preserves the values of ifIndex (6/6) 2) Dan Romascanu 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.

12. Why is it required? The issues were found by Editors. In the Dot11 MIB 03, we changed the value scope of capwapDot11WlanId from (1..16) to (1..512) as AC side could Configure WLAN Service more than 16 (capwapDot11WlanTable). But for the operation of WLAN Id binding to Radio (capwapDot11WlanBindTable), it would conflict with RFC5416, as it specify the value scope of WLAN id is 1 to 16. Dot11 MIB should add a new Terminology “WLAN Profile” (1/3)

13. How to close it? In the section “Overview”’ of new version, we should bring forward a new terminology “WLAN Profile”, which is a configuration profile which includes several parameters such as MAC Mode. The value scope of profile’s Id is 1 to 512. Also, it should explain the relationship between WLAN Profile Id and WLAN ID. For MIB table, Current WLAN ID object in the table capwapDot11WlanTable should be replaced with WLAN Profile Id. and capwapDot11WlanBindTable should add a WLAN Profile Id Object. Dot11 MIB should add a new Terminology “WLAN Profile” (2/3)

14. System behavior would be: Suppose WLAN Profile Id configured is 32 (more than 16), when bind it with a radio (CapwapDot11WlanEntry), system internally should check what WLAN id should be allocated and assign an unused value to capwapDot11WlanBindWlanId. For example, for a specific radio, if it is already allocated WLAN id 8, when new configuration WLAN Profile Id 32 is set, WLAN id 9 should be assigned to this new configured WLAN on This WTP's radio. Dot11 MIB should add a new Terminology “WLAN Profile” (3/3)

15. Suggest Let Base MIB to Support a WTP Profile Function (1/8) The background of this new function In the current MIB MIB, operator could not prepare configuration for WTPs before they connect to AC. It only lets Operator to change configuration for WTP in run status. It does not explain how to create "Virtual radio interface “. In summary, We used to want to leave the following functions to vendors' private MIB implementation: 1)Allow operator to prepare configuration for WTPs before they connect to AC 2) To trigger system to create "Virtual radio interface “ during 1)

16. Suggest Let Base MIB to Support a WTP Profile Function (2/8) If we don’t have this function? Current MIB draft could work without it, while it would has the following issues: 1) Private MIB implementation for it would lead to Interpretability Issues. 2) MIB design would be Not fully consistent with CAPWAP protocol as latter has very strong configuration function.

17. Suggest Let Base MIB to Support a WTP Profile Function (3/8) What is a WTP Profile? It is a profile which includes several Configuration parameters such as static IP for a specific WTP, and operator Creates it before a specific WTP connects to AC. WTP WTP Profile It has the serial number of WTP, so system could match a WTP profile with a WTP AC CAPWAP MSG Serial Number Model Number AC

18. Suggest Let Base MIB to Support a WTP Profile Function (4/8) The design of MIB objects for WTP Profile The MIB objects for static IP configuration and so on would be moved to here from CapwapBaseWtpTable.

19. Suggest Let Base MIB to Support a WTP Profile Function (5/8) capwapBaseWtpProfileWtpModelNum: Operator would specify Model Number(RFC5415) of a WTP in the configuration of a Wtp profile. As a PHY radio number is pre-decided by WTP Model Number, when a row object is created, it will trigger system to create specific number of "Virtual Radio Interface" according to capwapBaseWtpProfileWtpModelNum. Current capwapBaseWirelessBindingTable will offer the mapping relationship between "Virtual Radio Interface" and PHY radio. (The above process is during the configuration phase, and before WTP connect to AC)

20. Suggest Let Base MIB to Support a WTP Profile Function (6/8) How WTP Profile is to be used? Operator uses CapwapWtpProfileTable to create WTP profile for WTPs to manage before WTP connect to AC, and it would trigger system to create “Virtual Radio Interface”. Operator Get ifIndex of “Virtual Radio Interface” from capwapBaseWirelessBindingTable, then operate IEEE 802.11 MIB Module to configure WLAN radio parameter All the process Will be done Before WTP Connect to AC

21. Suggest Let Base MIB to Support a WTP Profile Function (7/8) The impact to Current MIB objects: 1) Impact to capwapBaseWtpTable At present, capwapBaseWtpTable lets operator query Wtp property and do configuration for Wtp in run status. When we have capwapBaseWtpProfileEntry, the capwapBaseWtpTable should Only Let operator query Wtp property (such as capwapBaseWtpRetransmitCount) when Wtp in run status. The objects (such as capwapBaseWtpStaticIp) for configuration function should be moved to capwapBaseWtpProfileEntry.

22. Suggest Let Base MIB to Support a WTP Profile Function (8/8) 2) Impact to CapwapBaseWtpStateTable To help operator to query a Wtp 's current configuration, capwapBaseWtpTable should add a new object which keep current Wtp profile Id. 3) Impact to capwapBaseWirelessBindingEntry INDEX Would be { capwapBaseWtpProfileId (changed), capwapBaseWirelessBindingRadioId (No change)} The reason of change is: The creation of Virtual radio interface is triggered by operation on the CapwapBaseWtpProfileTable

23.  Current Work Status  Open issues requiring discussion  Next Step Agenda

24. Next Step We would close all open issues in next revision within Two weeks, includes updating reference part for RFCs (RFC5415 and RFC5416) A new round of WGLC is required.

25. Questions? Comments?