IETF/IEEE 802 Liaison Report
Bernard Aboba
November 2006
Status Updates
Dorothy Stanley’s IEEE 802.11 Liaison report for November is available here:
ftp://ftp.802wirelessworld.com/11/06/11-06-1782-00-0000-november-2006-ieee-80211-to-ietf-liaison-report.ppt
Bert Wijnen’s IETF/IEEE 802.1 Liaison slides are available here:
http://www.drizzle.com/~aboba/IEEE/ietf-to-8021-Nov2006.pdf
Emergency Services Workshop
An Emergency Services Workshop was hosted at Columbia University on October 5-6, 2006. The workshop involved IETF as well as IEEE 802 participants. A summary of the workshop was presented at the IETF 67 ECRIT WG meeting, as well as to IEEE 802.11u at the IEEE 802 plenary in November:
http://www.ietf.org/proceedings/06nov/slides/ecrit-2.ppt
Information on the workshop (including slide presentations) is available here:
http://www.ietf-ecrit.org/EmergencyWorkshop2006/
TSV Area Meeting
At the IETF 67 Transport Area meeting there were presentations on IEEE 802.1Qau Congestion Notification (by Pat Thaler) as well as IEEE 802.1 AV Bridging (by Michael Johas Teener):
http://www3.ietf.org/proceedings/06nov/slides/tsvarea-2.pdf
http://www3.ietf.org/proceedings/06nov/slides/tsvarea-1.pdf
Liaison Letters
A liaison letter has been received from IEEE 802.1 relating to use of IEEE 802.1Q VLAN tags:
https://datatracker.ietf.org/documents/LIAISON/file358.pdf
The IETF CCAMP/GELS WG sent the following response, which included a question:
https://datatracker.ietf.org/documents/LIAISON/file370.txt
The response from IEEE 802.1 is available here:
http://www.ieee802.org/1/files/public/docs2006/liaison-ieee-802-1-ietf-ccamp-1106.txt
A liaison letter has been received from IEEE 802.11, responding to a query from the BMWG WG as to whether the IETF BMWG WLAN Switch Benchmarking Proposal, available at http://www3.ietf.org/proceedings/06/jul/slides/bmwg-7sld1.htm is in scope for IEEE 802.11. This document contains the liaison response to that request:
https://datatracker.ietf.org/documents/LIAISON/file369.doc
Requests for Review
IETF Requests
IAB
The IAB has requested review of the multiple encapsulations document (draft-iab-link-encaps-05) by IEEE 802.16. Comments from individual IEEE 802.16 participants have been received.
RADEXT WG
The RADEXT WG has requested review of a potential WG work item (draft-aboba-radext-wlan-03.txt) by IEEE 802.11. Comments are likely to be provided after the IEEE 802.11 interim meeting in January 2007.
TRILL WG
The TRILL WG has requested review of the architecture document (draft-ietf-trill-rbridge-arch-01) by IEEE 802.1. Eric Gray, author of the document, presented at the IEEE 802.1 meeting in Dallas. Due to scheduling issues, it appears that IEEE 802.1 will not be able to provide a formal response until March, but will forward individual comments sooner (see message from Mick Seaman below).
IEEE 802 Requests
IEEE 802.11r has requested that the IEEE 802.11 WG chair make available the latest TGr draft to external security experts for review. The initial list of experts (see below) includes many IETF participants. The document is available here:
http://grouper.ieee.org/groups/802/11/private/Draft_Standards/11r/
Documents
The Internet-Draft ‘Simple Network Management Protocol (SNMP) over IEEE 802 Networks’ – ftp://ftp.rfc-editor.org/in-notes/authors/rfc4789.txt which was written by Juergen Schoenwaelder at the request of IEEE 802.1 was approved by the IESG as a Proposed Standard and is now in AUTH48 state at the RFC Editor. This document will obsolete RFC 1089. The Internet-Draft ‘Guidance for AAA Key Management’ has completed IETF Last call. The current version of the document is available here:
http://www.ietf.org/internet-drafts/draft-housley-aaa-key-mgmt-06.txt
Date: Tue, 21 Nov 2006 15:39:50 -0800 From: Clint Chaplin <clint.chaplin@GMAIL.COM> To: <STDS-802-11-TGR@LISTSERV.IEEE.ORG> Subject: [802-11TGR] External Security Review
All,
One of the actions TGr took last week was to request that the IEEE 802.11 WG chair make available the latest TGr draft to selected external security experts for review of the TGr security. This request has been formally made to the WG chair, and I believe that he is ameniable to the request.
The next question we need to think about is: which external security experts? The followling list was developed by several TGr participants to be used as a starting point: Bernard Aboba (Microsoft) Bill Arbaugh (Univ. of Maryland) Bill Burr (NIST) Charlie Clancey (Univ. Maryland) Niels Fergusson (Microsoft) Scott Fluhrer (Cisco) Scott Kelly (Aruba) Dave McGrew (Cisco) John Mitchell (Stanford) Dave Nelson (Enterasys) Dave Wagner (Berkeley) Doug Whiting (Hifn) Glen Zorn (Cisco)
Some on this list will be unable to participate.
Have we missed any potential candidates? Comments on the list?
Clint -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization(US)
From: "Mick Seaman" <mick_seaman@ieee.org> To: "Bernard Aboba" <bernard_aboba@hotmail.com>,<Eric.Gray@marconi.com>,<tony@jeffree.co.uk>
I’m certainly planning to put together a response, but whether there is an official voted 802.1 response will depend on timing. It may be that you get a set of unofficial responses or contributions earlier, and official ones later.
I say this because (a) 802.1 doesn’t meet again until January 22nd-26th (b) that is only an interim meeting, and we don’t vote on items at interims so the first voted response could not be until March, though I am sure that Tony acting as WG chair could forward what he believed to be the interim meeting consensus (c) I think you would want to do something with feedback in January.
I think Eric’s summary touches the main points, though I will try to inject further clarity when I am able, and I would note that MSTP could easily be made capable of plug-and-play operation with a well known VLAN config, and that the proposed SPT (Shortest Path Tree) extensions already autoallocate VLANs for shortest path bridging so are plug-and-play.
To give a hint on the direction my thoughts are taking… I would observe that RBridges were first proposed as layered under bridges (the RBridge region looked like a LAN to bridges) and are now layered over bridges (the RBridges look like routers, in fact they don’t look like much else other than L2 VPN over routers), and that both these approaches suffer the ‘wiring closet’ problem. The solution to this problem is already known and deployed with MSTP, and it is highly non-trivial to come up with another working solution. Basically the bridges/bridge regions peer rather than layer.Further, MSTP technology auto establishes regions of bridges with certain attributes (in that case the ability to run MSTP) and ensures that these are seen as indivisible bridges by other bridges and the same (already deployed) technology is also proposed as part of SPB (Shortest Path Bridging), and could equally be used by RBridges to establish RBridge regions without intervening legacy bridges, and that such a design seems closer to meeting real RBridge deployment scenarios than the worst case spaghetti presented.
I would also observe that the RBridges (if understood Eric’s presentation correctly) add not just one but two layers of addresses, the outer to make them routers rather than bridges of any kind, and the inner essentially to provide the same functionality as P802.1ah (Provider Backbone Bridges). If the ‘wiring closet problem’ is solved with the peering ‘bridge regions’ solution we already have and the P802.1ah TAG (known as the I-TAG) is used over an encapsulating backbone that is based on SPB technology we have essentially assembled all the components necessary for solution that provides RBridge functionality while addressing its deficiencies – using the encapsulating I-TAG with SPB deals with any scale limitations of the latter. A solution of this form can use all the supporting technology and VLAN classification and coexistence methods/MIBs/etc. It is also (I discovered) fully capable of equal cost multipath, and of assigning traffic to equal cost paths using the top level (customer or C-)VLAN, can support MAC Security (P802.1AE), and (I believe) will work well with Raj Jain’s newly proposed FECN (forward explicit congestion notification).
This of course will need spelling out in fine detail for those who are unfamiliar with VLANs and with the 802.1 architecture in general, and that is going to take quite some effort on my part. Of course any prepared comment will clearly distinguish between (a) what is right and what is deficient with the RBridge proposal; and (b) how 802.1 might use its current toolkit to assemble a solution to any particular definite market requirement.
Mick
From: "Gray, Eric" <Eric.Gray@marconi.com> To: Tony Jeffree <tony@jeffree.co.uk>, Mick Seaman <mick_seaman@ieee.org> Subject: Feedback from IEEE 802 on RBridge/TRILL Architecture, etc. Date: Mon, 27 Nov 2006 16:47:43 -0500
Tony/Mick,
I want to run this by you to make sure I did not forget something important, or get something wrong, in reporting the feedback I received from the presentation.
I am about equally certain that I’ve captured everything and that I am missing something important. 🙂
The IETF/IEEE liaisons and the IETF TRILL working group chair should feel free to jump in as well.
=================================================================== SUMMARY of IEEE Feedback on TRILL and TRILL Architecture ========================================================
o One point was to address all of the documents: the statement that spanning tree protocol converges slowly, is inefficient or otherwise defective requires more clarification. o 802.1s (MSTP) has been around since 2000 - and is now part of 802.1D (2004). o RSTP has a convergence time much quicker than appears to have been considered in the problem statement draft. o The TRILL document set should be specific as to which aspects of spanning tree "deficiencies" it will address and how it will address them. o Current bridging deployments take advantage of the STP root election process to optimize the use of certain links in the bridging topology. o The specific scenario described is the "wiring closet" problem outlined in the Architecture draft. o The 802.1 group would like to point out that they feel the TRILL solution will be dead on arrival if it does not address this issue. o The group does not consider replacing all wiring closet equipment with RBridges as a valid approach to address this issue. o Currently developing 802.1 protocols and enhancements must be considered in working through the process of TRILL protocol definition. o For example, there are issues with supporting BCN in the use of tunneling technologies (specifically, how will an egress RBridge ensure that a congestion notification is delivered to the actual source). o There was some discussion of BCN details (see below), but it will be important to have continuing dialogue (or some other form of interaction) going forward. o There are several other issues with 802.1 enhancements and/or extensions and issues with address transparency that should be considered as well. o The group considers the intention of developing an SPF-based approach (using a link-state routing protocol) - particularly with intended plug-and-play capabilities - commendable, but would prefer: o the IETF consider sending routing experts to help the IEEE with shortest path bridging using a link-state routing protocol (replacing the current DVRP), or o focus strictly on defining control plane mechanisms to establish forwarding information for already existing - and yet to be defined 802 encapsulation and data-plane technologies.
In the brief discussion on the topic of BCN, one thing that came out was that there is a need – and considerations in progress – to include some part of an original data-frame as part of congestion notification messages. This could potentially address issues with “tunneled” MAC frames – provided that the portion included is of sufficient length to include at least the MAC DA/SA of the triggering frame.
There are no guarantees that this will happen, and it would be a very good idea to track the development of BCN in IEEE 802.1 – assuming we might want to support data-center applications using RBridges.
As a further amplification on the issue with “STP deficiencies” it is certainly the case that I was not clear in stating that MSTP cannot be applied in the plug-and-play case – since MSTP replies on existence of VLANs and (AFAIK), VLANs require configuration.
======================================================================= -- Eric