December 2004 IEEE 802/IETF Liaison Report

Bernard Aboba
December 2005

Since IEEE 802 did not meet in December (but will have an interim meeting in Monterrey in January), so this month’s report is an update of the issues discussed in the November report.

IEEE 802/IETF Review Work

Review of EAP Network Discovery

Paul Congdon made a presentation to 802.1, requesting feedback on the EAP Network Discovery draft which is on the 3GPP “critical” dependency list. No comments were received.

802.11 WIEN met in San Antonio, and has provided feedback on the Network Selection Problem Statement document, a work item of the EAP WG.

Based on the comments from IEEE 802 and resolution of “pseudo-WG last call” comments on the EAP network selection document, EAP WG review of this document for publication as an Informational RFC (individual submission) is now complete.

Change to the 802.11 EAP Method Requirements Document

802.11 voted to request two changes to the EAP Method Requirements document that is now in the RFC Editor Queue. A letter has arrived from Stuart Kerry, Chair of 802.11, detailing the requested changes. I think the assumption is that these will be handled in AUTH48. There has been some question about whether AD approval or EAP WG review is required before the changes are made.

802.11r feedback on the EAP Key Management Framework

Jesse Walker submitted a requirements document to 802.11r that relates to the EAP Key management framework document under discussion in EAP WG. Since this document was not voted on by 802.11, it will be submitted as a comment to the EAP WG.

New Work Issues

WNM PAR Revocation Vote

As noted in November’s report, there were some issues with the IEEE 802.11 WNM PAR proposal, which although it passed, garnered a significant number of “No” votes. The text of the PAR included mistatements relating to SNMP, as well as some confusion about the purpose of the group (e.g. is it to handle specific issues, or to develop a new management framework specific to 802.11). At the IEEE 802.11 plenary on Friday, November 19 a motion was made to revoke the PAR approval, based on the criticisms made in the “No” votes and the vagueness of the PAR.

The motion did not meet the required 75% approval hurdle, so the WNM PAR stands. At the January 802.11 interim, the newly approved TGV will meet and will work on better understanding the required work items.

Division of Work Discussions

802.11 Benchmarking

At IETF 61, the BMWG WG considered a submission relating to benchmarking of 802.11 Access Points and Stations. Since 802.11 TGT also is considering some of the same issues, the question arises as to where the work should be done. The answer is not entirely obvious since BMWG has previously done benchmarking work on switches (RFC 2889). While the document under discussion deals with similar issues such as determination of maximum forwarding speed, radio propagation issues inevitably arise, and 802.11 has a long history of dealing with that.

In the BMWG WG meeting, we discussed that the determination of where the work would be done would be based on several factors:

a. The demonstrated expertise of the IETF and IEEE 802 in the area in question. As described above, in this case there is evidence of expertise in both groups.

b. The desire of the authors/community of interest. Tom Alexander, as primary author, is most familiar with IEEE 802 and attends meetings regularly. Similarly, folks with expertise in 802.11 benchmarking tend to congregate in 802.11 rather than IETF. However, Tom had asked for review by BMWG, given its past history with switch benchmarking, to make sure that he was applying the concepts correctly.

c. The desire of the WGs/TGs involved. In this particular case, the BMWG chair expressed a willingness to work on all or part of the problem. During the IEEE 802.11 TGT meeting, it was determined that all of the draft presented by Tom Alexander was within scope of TGT.

Given the above, my recommendation is that the work be done in 802.11 TGT, but that review be conducted by the BMWG WG. This was subsequently discussed and agreed to by the BMWG WG chairs. Next step is to find a BMWG WG participants to carry out the liaison with 802.11 TGT. A suitable volunteer has not yet been found.

IPVLX WG

A charter is being considered for the IPVLX WG which grew out of the IETF 60 RBRIDGE BOF, and similar questions have arisen. Where should the work be done? What level of review and/or advice is required from IEEE 802? Here are some thoughts:

a. Demonstrated expertise. The IPVLX Charter envisages adaptation of existing routing protocols such as IS-IS. The expertise in this area lies with the IETF. However, the expertise regarding LAN topology management protocols resides within 802.1, as does expertise relating to IEEE 802 service requirements.

b. Desire of the authors/community. Radia Pearlman is the primary author and would prefer the work to be done in the IETF. Other interested parties tend to come from the routing community, and have a similar preference.

c. Desire of the WGs/TGs. There is no existing group working on this subject. Over the last several years there have been a few similar proposals discussed in IEEE 802.1, but no official work item has been proposed.

The above evaluation would tend to indicate that the work would most conveniently be done in the IETF, but that review by IEEE 802 or appointment of a technical expert with IEEE 802 expertise would be appropriate.

Interestingly, there appears to be considerable support within IEEE 802.1 for the IPVLX work, although there are also some sceptics. So a suitable advisor can probably be found.

The proposed IPVLX Charter will be circulated for comment to IEEE 802 via the New Work list.

Reprint of the November 802.1 liaison report from David Harrington <dbharrington@comcast.net>

BRIDGE WG

A presentation was given to the Bridge WG and to the 802.1 WG regarding the transition of MIB module work to the 802.1 WG. That presentation is available in the IETF61 proceedings and the 802.1 WG public documents web page.

The Bridge WG is in WG last call for three MIB modules: An SMIv2 version of the BRIDGE-MIB, an update to the P-BRIDGE-MIB and Q-BRIDGE-MIB modules, and an RSTP-MIB. These are expected to be the final documents produced by the Bridge WG. New MIB module work is expected to be done by the 802.1 WG.

802.1aa (.1X maintenance) includes MIB module changes. It has not received MIB Doctor review.

Draft 12 of 802.1AB has recently been posted and should get a MIB Doctor incremental review.

MIB module work for 802.1AC, ad, af and ag has not yet been started.

• AC = Media Access Control Services

 

• ad = Provider Bridges

 

• af = Authenticated Key Agreement for MAC Security

 

ag = Connectivity Fault Management

A presentation regarding the MIB module design for 802.1AE (MAC Security) was discussed in San Antonio and posted to the public web site. The Bridge WG provided links to the presentation (and the request that it be discussed only on the 802.1 list).

The 802.1 PARs for ah, aj, and ak were announced on the Bridge WG list, to solicit comments (to be made on the 802.1 list). All three are expected to include SMIv2 MIB modules for management.

• ah = Provider Backbone Bridges

 

• aj = Two-port Media Access Control Relay

 

ak = Multiple Registration Protocol to improve the speed of Provider Bridges topology convergence

There are three proposals for MIB modules for an MSTP MIB (802.1s). The 802.1 WG is developing a PAR and 5Cs for this work. The 802.1 WG has posted the proposals on their public documents web page, and the Bridge WG list has been provided links to the documents.

The 802.1 WG discussed the proposed PAR and the MIB module proposals at the San Antonio meeting.

Dan Romascanu:

“There was some discussion about the PAR for the MSTP MIB in the opening session on Monday, but eventually no motion was voted about submitting the PAR for approval. The main problem that needs to be solved is identifying a committed editor, who can attend the IEEE 802.1 WG meetings. Paul Congdon took an Action Item to work on this.

No technical discussion about the three submitted documents took place in the meeting, because only one of the documents authors attended. However, a fair level of discussions took place on the IEEE 802.1WG reflector.

I missed the closing Plenary session, but I can see in the final presentation a slide titled ‘What are we going to do about…’, which includes the following bullet.

– Bridge MIB activity – do we need to raise a PAR (or PARs)? If so, we should be spending time on this in Sacto, and some input text for the PAR(s) would help.”

The Bridge WG chairs have asked that all discussion of this work be done on the 802.1 mailing list, not the Bridge mailing list. The Bridge WG chairs will cross-post messages of particular note, but not detailed discussions of the technology development.