From: Andrew Smith To: "P802. 1 (E-mail)" Subject: DRAFT Minutes of IEEE 802.1 Montreal meeting Date: Mon, 19 Jul 1999 13:48:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-p8021@hepnrc.hep.net Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by hepnrc.hep.net id PAB11623 Please send corrections/additions. Andrew Smith -------------------------------------------------------------- DRAFT Minutes of IEEE 802.1 Montreal meeting 7/5/99 - 7/8/99 minutes recorded by Andrew Smith IEEE 802.1 Plenary Meeting called to order at 2:15pm. Voters and voting - Rosemary Slager 36 voters current, 14 lost voting rights in November 1998, 17 in March 1999. 802.5 voting rights - contact Rosemary Slager 802.3ad voting rights - list of names collected at March 1999 meeting was forwarded to 802.3 Chairman Thompson. Bill Lidinsky followed up: they will make sure that those 802.1 members who want to vote are well read (it was noted that this same restriction was not being applied to 802.3 voters). Status of standards - Bill Lidinsky 802.1Q-1998: distribution of gongs to Mick Seaman and Tony Jeffrey on publication. 802 Overview &Architecture - sponsor ballot in progress. 802.1r - GPRP - completed 802.1 ballot: may need a motion to go to sponsor ballot. 802.1s - Multiple Spanning Trees: draft available. 802.1t - Maintenance for 802.1D: draft available. 802.1u - Maintenance for 802.1Q: PAR approved March 1999; draft available. 802.1v - VLAN Classification by protocol and port: PAR approved June 1999. 802.1w - Rapid Reconfiguration: PAR approved June 1999; draft available. 802.1x - Port-based Network Access Control: will possibly submit to exec this week. Report from the 802 Executive Committee meeting, Monday am - Bill Lidinsky 1. Need to be a member of the IEEE standards' association in order to be on a sponsor ballot. 2. Liaison requests from TIA: TR41 want to use 10/100 interface but with supplied power: they want 802 to do such a standard: if not they will do it: 802.3 will consider this. TR42 (premises cabling) want 802 to consider Cat.6 in their new standards. 3. 802.15 wireless personal-area networks - new working group. Wants "strong liaison" from 802.1. 4. 802.16 broadband wireless - new working group. 5. ISO SC6 - 8802-1 Overview document. 6. IEEE 802/SC6 interrelationship: document from Robin Tasker. Summary: IEEE802 should not bother getting ISO approval for its LAN documents. Wednesday session with Jim Carlo to discuss this. SC6 has approved IEEE as a class C liaison organisation - still needs to be passed by JTC1. This allows ISO to comment on IEEE ballots. See closing plenary below. 7. IEEE Industry Standards Technology Organisation (ISTO) - launched January 1999. The IEEE Standards Association is also inventing a category of "entity ballots". These actions are both a result of a need to shift revenue streams from the sale of standards to value added services related to standards. Please send comments to s.tantier@ieee.org Other - Bill Lidinsky, Mick Seaman RESOLUTION on 802.1x PAR: "802.1 requests 802.0 to forward the PAR for 802.1x Port-based Network Access Control, previously circulated to 802.0 for information and advance notification, to IEEE NESCOM for approval". Proposed: Seaman, seconded Jeffree; motion passed 12 in favour, 0 against, 2 abstaining. Motion to adjourn at 4:20pm (Proposed: Jeffree, Seconded: Slager) passed by acclamation.. GPRP - 802.1r Passed first WG ballot - still open issue as to whether this work should be standardised or not. Protocol-sensitive VLANs - 802.1v No discussion at this meeting - Andrew Smith (ed.) Editor to produce a first draft within 1 month. Will discuss this at interim meeting for possible ballot before November plenary. 802.1D Maintenance - 802.1t - Tony Jeffree Tuesday am - Jeffree (ed.) New draft P802.1t/D1 from editor is on the reflector. 2 new editorial fixes; need to fix up notes in section 6.5.1 of 802.1D-1998 to include description of MAC service for frames with EtherType. Editor looking for input on this. Changes since /D0: - 8.10.2 added some text to say that we stick to existing path-cost table: runs out of steam at 2x10Gbps and does not handle link aggregation - you might want path-cost to track effective link speed but, there again, you might not (the primary use for path-cost is for management to establish a logical topology). Will add an example of an aggregated link used for reliability reasons, as opposed to increased bandwidth. Recommend that a default behaviour not track dynamic effective bandwidth too closely. Extending the range of port numbers can be considered as a maintenance item but right now these changes have been included in 802.1w. Should these be moved to 802.1t? - need to specify whether to round down or return error if management specifies invalid values. - will need some changes to SNMP MIB anyway to modify allowed range of port priority values. Decide to move this from 802.1w to 802.1t. No consensus at this time as to when would be the right time to ballot 802.1t - it may well be that 802.1t and 802.1w get published together. 802.1Q Maintenance - 802.1u - Tony Jeffree Tuesday am - Jeffree (ed.) New P802.1u/D1 draft from editor is on the reflector. Note: at some point there will be changes for 802.1w that need to be incorporated into 802.1Q. Depending on timing, these may get described in 802.1u at some point. Changes/issues: - Added diagram to show position of VLAN tagging/untagging function in an end-station. - Will add note to say that frames used for the internal operation of the MAC layer are not subject to the tagging/untagging function. - Added new per-port parameter to control whether GVRP is allowed to create new VLANs that are not in the static FDB. Some unease about adding this functionality so soon after publishing 802.1Q (and IETF new bridge MIB). Should probably add this capability to GMRP in 802.1t as well. - Potential clarification to user priority/regenerated user priority Feeling is that it is not yet necessary to ballot this document - should maybe loosely couple this to 802.1v schedule. Port-based Network Access Control - 802.1x - Paul Congdon Tuesday pm Presents an overview of EAP (Extensible Authentication Protocol) over Ethernet (EAP in RFC2284). Full detail of protocol was circulated in a May 3rd draft by Jain/Congdon/Vollbrecht/Smith/Yavatkar/Rosen/Roese. Needs to invent some new terminology for "authentication blocked". Need to be clear that this runs on top of link aggregation. Note that EAP over RADIUS is the preferred IETF mechanism for dialup authentication. Authentication process is typically driven by switch challenging the end station when it detects a "port up" indication. But need to be able to kick it off from end station too. Switch state machine - one per switch port (for now). Is a per-VLAN state machine interesting (same forwarding hardware as 802.1Q)? Some concerns that we should not go beyond yes/no answers: maybe this should just be a kickoff mechanism for other more general config mechanisms. Client state machine - almost the same as EAP-over-PPP state machine: but we add an EAP start message from switch and some differences on "hang-up" too (LAN environment is a bit different to dialup). Questions - is it appropriate to limit this solution to a single authenticated user per switch port? Multiple users would be more complicated and probably require switch hardware changes. - why not EAP-over-PPP-over-Ethernet? - there are opportunities for switch to add additional information e.g. port number on the way up to EAP server. In fact we probably need this in order to avoid a 256-port limit - slight concern about the size of authentication packets - are there any cases where the response from EAP server is significantly bigger than the request? There is an implicit assumption that all EAPOE exchanges fit in a single 1500-byte packet. - is this applicable to repeaters too? Should we generalise the terminology and avoid "switch" terminology? Need to be able to draw a diagram of the forwarding function that is not specific to switches. But the PAR does cover only switches. Participants will surely make sure that we do not include anything that precludes its use in a broader set of devices. - how much of EAP needs to be understood by the switch? Fairly small set of indications/requests at this service interface. - is there a need for asynchronous "authentication fail" from backend server? Apparently EAP does not support this. - should it run before or after DHCP? Maybe need to allow both? Note: EAP does its own negotiation of auth mechanisms - all we need to establish is EAP connectivity. Required changes to 802.1D to support port-based network access control - Tony Jeffree/Mick Seaman This document was previously circulated on mailer. Service interfaces: needs an up/down indication from MAC (or from link aggregation). Discussion on where in the architectural diagram (figure 7-10 in 802.1D-1998) the authentication on/off switch should live. In particular, how does this get generalised if you want to extend the authentication to per-VLAN? i.e. what does figure 7-10 look like in a 802.1s environment? Rough consensus that this should be modeled as a second switch in series and defined in a different document. Some believe it should be left for potential future standardisation. Rough consensus that spanning-tree BPDUs, GVRP and GMRP (and SNMP of course) should be stopped at an unauthenticated port i.e. the on/off authentication switch is on the vertical line of figure 7-10 (this is somewhat different to what Seaman document says). Jeffree to generate a base 802.1x document (assumes approval of PAR). IEEE 802.15 Wireless Personal Area Networks - Tom Siep See document 802.15-99/042x0. WPAN has no infrastructure; 10m range; much simpler than 802.11. Work came out of MIT. HomeRF and Bluetooth are industry consortia. Bluetooth defines all 7 layers - 802.15 has been given L2CAP and below to standardise. There seems to be some correspondence between L2CAP/Link Manager and LLC - IP can run on top of either. Seem to be both connection-oriented and connectionless services (e.g. CO for voice channel). Bluetooth does specify PPP over L2CAP. Master-slave relationship: there is no slave-slave communication. Master represents the slave devices to the outside world. Bluetooth consortium seems to want IEEE802 to maintain their lower layer specifications and concentrate on upper layer stuff. 8 classes of service include: Audio, Synchronous, Still Images, Bridging, Comm Port Application, Network, Wireless Access Protocol , Human Interface Device (Network and WAP run over TCP/IP). Question as to the economic value of casting the Bluetooth architecture in IEEE language: this is only interesting if people e.g. want to bridge from other MAC technologies. If all they want to do is IP route then there is no value here. IEEE 802.16 Broadband Wireless Access - Jim Mollenauer, Ray Sanders Mollenauer: LMDS band 28-31GHz band, 10s of Mbps data rates maybe. Fixed wireless access - primary application is as a low-cost fibre replacement. 0.5% of all buildings have fibre running to them. Shows a stack involving IP over LLC over Packet convergence over 802.16 MAC/PHY. Also supports Frame relay over packet convergence over 802.16, ATM over 802.16 and STM over 802.16. Questions as to where wireless ATM standard fits into this. If you want to run IP you could plug it in in multiple places: there seems to be most interest in IP over LLC over 802.16 directly without putting frame relay or ATM in the way. Requirement to be able to carry IP DiffServ capabilities: how do these get signaled to/from the convergence layer? Some of the characteristics of the MAC layer scheduling need to be exported to the packet convergence layer. Sanders: Bandwidth efficiency is critical in this space. Convergence of voice/video/data is too. Therefore bandwidth management is key. Unit of allocation should be a "minislot" (short compared to an ATM cell). Assertion that it is quite tractable to offer priority-based services on top of a lower-layer that has bandwidth allocation. It is quite intractable to offer bandwidth-based services on top of a priority-based lower layer. So bandwidth allocation needs to be a part of the MAC-layer. It was pointed out that the most interesting deployment scenario for this technology is with an Ethernet connector at each end. Questions about whether bandwidth is the only interesting parameter - what about jitter, bursts etc. ? Multiple Spanning Trees - 802.1s - Alan Chambers Wednesday pm - Chambers (ed.) New draft P802.1s/D2.9 is available, July 1999. This is a supplement to 802.1Q-1998. Editor presented an amended set of proposed conformance requirements. Some discussion as to whether the "802.1Q version number" needs to be incremented - depends on whether the management changes are backward compatible, in particular on whether sensible/useful values are to be returned for "old" operations on a "new" MST bridge. Editor proceeded page by page through the 2.9 draft with brief pauses for clarification. 8.16: default value for the VID that the common spanning tree (CST) should use - should this be manageable i.e. should you be allowed to use VID != 1 for the CST? Some argue that this should not be allowed. Current text says CST == 1 is just the default. Need to think some more - will leave as is for now. 11.2.3: GVRP contexts: need to clarify this description as rules for SST bridges (hopefully these rules are same as 802.1Q-1998!) and rules for MST bridges. There does not appear to be a requirement to discard received GVRP frames from a secondary VID: as long as 2 bridges have "consistent" mappings it is OK to accept these. Consistent means that the sets of VIDs in each ST context are the same even if the designated primary VIDs are not the same at each switch. This allows one set of potential misconfigurations to still function. BPDU format: we do need the VID of the primary VLAN of a STP group encoded in the body of the new BPDU frame. Some discussion of whether this still works for protocol-sensitive VLANs. We think it does but there may be some interesting misconfiguration scenarios. 13.8.4: compulsory registration of primary VLANs: decided that this is not needed. MST configuration protocol - still within the scope of 802.1s but contribution-driven. Current proposal is derived from Cisco VTP. Discussion of what is the minimum connectivity needed in order to run the protocols: is a single simple spanning-tree OK? Should it run independently of the spanning-tree, just relying on links? Is the 802.1E "reliable multicast" protocol the appropriate one here? Consensus that editor should turn this all into 802.1s/D3 and put it out for ballot. Rapid reconfiguration - 802.1w - Tony Jeffree/Mick Seaman Thursday am - Jeffree (ed.) New draft P802.1w/D1 from editor is on the reflector. Updated state machine provided as separate handout. Particular issues: - Version flag in BPDUs: note that 802.1G remote bridging already defines version "1". Need to ensure that further changes for version "2" do not break this. We need to add the STP context identifier for 802.1s. Possible that we need to deal with non-conformant implementations (or at least ones that took the original 802.1D liberally). Note that a V0 implementation (802.1D-1993) ignores the version field; a V1 implementation can treat V0 and V1 BPDUs differently. Note that section 5.2.4 of 802.1D-1993 says explicitly that no new flag values will ever be defined (why?) so we do need to use a new version number for these new changes. Implementers need to go check what might break in their old implementations. - Introduction of a "disabled" port role: this lets you not run STP on a port and have it forward all the time. Useful for edge ports. Left as an exercise for the implementer to decide how to determine whether a port is an edge port. We have also talked previously about just starting off STP in "forwarding" state for edge ports - this needs to be noted. Note that a port in disabled role must silently drop BPDUs. (802.1D-1998 did not acknowledge that you might ever completely turn off STP). - Probably no need for the "forgetting" state that is described in /D1 (haven't proven this but have not come up with a disproof yet). - What if the hardware supporting a port is actually lagging behind the protocol operation? Concept of a "configuration update" procedure to be executed whenever a role assignment event happens i.e. "become rootport/designated/alternate/backup". This ensures sufficient coordination between different ports: 1. Select the root 2. If different to current root then must retire prior root port, if any. But this "retire all" event must not occur until transition of this new port to root has been completed. - Is it really necessary for a port to go back learning->listening again if root did not change? Should not be necessary - Mick will check this. - Forwards/forwarder/forwarding states: these are used to store memory of whether a port was "recently" a root port. - Link up/down events cause the configuration update procedure to run (that is how they are input to the state machine) - in theory it is a local optimisation to try to make sure that the whole bridge needs to recompute everything - but we will describe this explicitly in next draft. IEEE 802.1 Plenary 802 Overview and Architecture - Bill Lidinsky/Alan Chambers Ballot will go out next week (should have been done already). ISO/IEC/SC6 relationship - Tony Jeffree Tasker proposal (SC6 N 11235) seems to be acceptable to SC6. Broadly in line with IEEE802 discussions. A few modifications needed. IEEE802 will be made a "Class C" liaison organisation - can then submit documents directly to ISO, rather than having to go via ANSI. May need to then distinguish between "task force ballots" and true "working group ballots" since the latter will go to SC6 as well as WG members. It would be a good thing to have SC6 involved at the WG ballot stage. In accordance with current 802 policy, we will make efforts to resolve any such "observer status" comments. IEEE actions at publication stage: only publish under IEEE label, not ISO or ANSI. Will acknowledge that SC6 was involved in the process. Will notify SC6 of any re-affirmation or retirement of an IEEE standard. WG can decide if it wants an ISO label - 802 SEC can then request ISO fast-track submission via a friendly national body. 802 SEC must give explicit approval (and copyright release) if a national body requests ISO submission. Misc Alan Chambers and Norm Finn volunteer to take care of LCD projector during meetings; Next interim 802.1 meeting In York, UK. Tuesday/Wednesday end of September. November plenary - Kauai Monday schedule: 802 plenary 11am-noon, 802.1 plenary 1pm-3pm. Possible 802.1 pre-meeting 8am - 10:30am. RESOLUTION: "WG 802.1 resolves to hold a pre-meeting from 8:30am to 10:30am on Monday 8th November 1999 in Kauai, Hawaii. WG 802.1 resolves to hold an interim meeting on September 28th and 29th, 1999 in York, UK. The topics to be progressed at the pre-meeting will be defined at the 802.1 interim meeting in York, UK." Motion passed 12 in favour, 0 against, 2 abstaining. Voters and Voting - Rosemary Slager 802.1 voting membership, as of Thursday, July 08, 1999: Les Bell Harish Belur Martin Brewer Alan Chambers Paul Congdon J.J. Ekstrom Hesham ElBakoury Norman W. Finn Sharam Hakimi Richard Hausman Tony Jeffree Toyoyuki Kato Hal Keen Daniel Kelly Atsushi Kimoto Keith Klamm Bill Lidinsky Yaron Nachman Satoshi Obara Toshio Ooka Luc Pariseau Anil Rijsinghani Mick Seaman Michel Sorensen Rosemary V. Slager Andrew Smith Dono van-Mierop Robert Williams Michael D. Wright John (Jiun-Sheuan) Yang Members who can claim membership at the next meeting: Hadriel Kaplan, & Ted Schroeder. Approval of minutes - Bill Lidinsky Move to approve minutes of the March 1999 802.1 WG plenary meeting: P: Jeffree/S: Chambers - approved unanimously. June 1999 Interim meeting was not quorate so no minutes to approve. 802.1 Interworking Task Force - status - Mick Seaman - 802.3ad voter list has been sent to Thompson; awaiting approval - 802.1r: needs further thoughts about implications. If no more input will drop this PAR at next plenary meeting. - 802.1s: RESOLUTION: "P802.1 instructs Alan Chambers, the editor for P802.1s (VLANs - Multiple spanning trees), to prepare a revised version of P802.1s/D2 and P802.1s/D29 in accordance with the discussions and agreements at the July 1999 Montreal meeting of P802.1, and to submit the resulting text for 30-day P802.1 Task Group ballot as P802.1s/D3. The ballot closing date is to be no later than 6th September 1999." Proposed: Chambers, Seconded: Jeffree, motion approved with 14 in favour, 0 opposed, 0 abstaining. - 802.1t/u/v/w status - see above. - 802.1x needs to be proposed by Lidinsky at Exec meeting tonight. Numbering of IEEE 802 standards - Bill Lidinsky Discussion on a new proposed document numbering scheme. Contribution from Mick Seaman: A. There have been many changes in the proposed numbering of standards in the past, b. In our experience, none of these have materially assisted the readership of our standards or the promotion of our standards by industry supporters, 3. Further changes will only serve to confuse the readership and our supporters further, (iv) No proposed labelling scheme is likely to fully capture all future requirements and opinions as to what the relationships between groups, documents, supplements, overviews, revisions and advisory documents should be shown, e. At this time the community of users seems to have adjusted to the existing 802.1 standard designations as well as at any time in the past. http://802.ieee.org/8021/meetings/July99/closing-plenary/resolutions/5/F Enough is enough already. RESOLUTION: "WG 802.1 resolves that the new numbering system proposed: i.e. 802.n.xa where n = Arabic numeral designating the working group designator, x = Arabic numeral designating a base standard and a = letter to represent revisions, is not workable for WG 802.1 (it is stupid i.e.. sucks big time). WG 802.1 plans to continue to use its current identification system." Proposed: Slager, Seconded: Jeffree, motion passed 14 in favour, 0 against, 0 abstaining. IEEE-SA/ISTO - Bill Lidinsky RESOLUTION: "In order to further the goal of making P802 standards free and electronically available to the public worldwide, IEEE P802 resolves that all P802 funds now used to support ISO secretariats be immediately diverted to supporting the IEEE-SA in achieving the above goal." Proposed: Slager, Seconded: Jeffree, motion passed 14, in favour, 0 against, 0 abstaining. 802.1 Website - Neil Jarvis volunteers to help maintain the web page. Mercifully, a motion to adjourn was proposed: Jeffree, seconded Sørensen, passed unanimously at 3:41pm.