Potential Areas for IETF/IEEE802 Coordination 0. Revision History 0.0 Initial Revision - 9/4/2012 0.1 revised for the period between 9/5 and 10/29 0.2 revised according to input received on 01, still reflects the 9/5-10/29 time interval 0.3 revised after the 10/29/12 meeting 0.4 revised for the period between 10/29 and 12/12 1. IETF TRILL Fine-grained labeling and IEEE 802.1 tags 1.1 Description In the 7/25 f2f meeting Paul Unbehagen presented a brief summary of the IETF TRILL WG work on Fine-Grained Labeling which raises concerns about the use of the existing 0x8100 Ethertype. IEEE 802 suggested that new protocols should require new Ethertypes. Further discussions - the TRILL contributors agreed to get different Ethertypes. This needs to be confirmed in the revised I-Ds. draft-ietf-trill-fine-labeling-02 was in WGLC between 11/6 and 11/19. 1.2 Relevant Documents https://datatracker.ietf.org/doc/draft-ietf-trill-fine-labeling/ 1.3 Owners - Ralph Droms 1.4 Action Items - IEEE 802.1 individual participants will read and comment the I-D - draft-ietf-trill-fine-labeling-02 was in WGLC between 11/6 and 11/19 ? need to verify if IEEE 802.1 participants reviewed it - Pat and Dan propose to CLOSE this item 2. IETF BFD and IEEE 802.1AX 2.1 Description In the 7/25 f2f meeting Norman Finn noted that drafts have been written (but not adopted in IETF WGs) for using BFD to detect Link Aggregation failures. Norman suggested that BFD is at the wrong layer for this, and suggested the following ways to avoid layer violations: - Invent and use a Layer 3 equivalent of LACP that fits routing and BFD - Use Ether OAM; work with 802.1 to invent a way to avoid needless configuration. - Encapsulate BFD below LinkAgg thus giving the world two ways to do exactly the same job The routing AD (Adrian Farrel) clarified by email that the IETF has no intention of working on modifications to or a replacement for LACP. The only work being undertaken in this area is the ability to run BFD on LAG members and report failures of individual members as a degradation of the link constructed from the LAG. Liaison statements were changed between the IEEE 802.1 and IETF BFD WGs. The BFD WG sent to the 802.1 WG a liaison on 9/25 https://datatracker.ietf.org/liaison/1192/ setting out the progress and continuing the communication. The authors of the BFD for LAGs work have posted several updates, the latest at http://datatracker.ietf.org/doc/draft-mmm-bfd-on-lags/ Note that this work is still currently not official BFD working group work. However, a re-charter of the BFD working group was considered by the IESG, reviewed by the IETF community, and advertised on the New Work mailing list on 10/16. This change in the charter was approved by the IESG on 10/25 and includes the following text: > 5. Provide one or more mechanisms to run BFD over Link Aggregation > Group Interfaces. ...and... > The working group will maintain a relationship with the KARP and MPLS > working groups, and will communicate with the IEEE with respect to BFD > over LAGs. ...so it is expected that the BFD working group will adopt a draft to work on soon, and that they will be in touch with 802.1 again in due course. 2.2 Relevant Documents https://datatracker.ietf.org/liaison/1192/ http://datatracker.ietf.org/doc/draft-mmm-bfd-on-lags/ 2.3 Owners - Adrian Farrel, Norm Finn 2.4 Action Items - follow-up the evolution of the doc, as it is adopted as a WG item 3. IETF NVO3 and IEEE 802.1 DCB 3.1. Description IEEE 802.1Qbg VDP might be used as the basis for the communication that NVO may need between an end system and an external box (e.g. bridge or router) doing the NVO encapsulation. Coordination will help determine if VDP is a suitable candidate and possibly to make any amendment needed in VDP for NVO usage. Status 10/26 - not much progress. The NVO3 working group continues to work on architecture and requirements. It remains unclear whether a "new" encapsulation will be required. Many people consider that there are enough encapsulations in the world already. In the 10/29 meeting - concerns from the IEEE that some of the NVO requirement drafts say things about 802.1 and its capabilities that don't take all the capabilities into account. There are some above layer 2 reasons to do NVO, and we think the requirements doc would portray that more accurately going forward. Concerns with the way 802.1Q capabilities are being portrayed. Also there's an 802.1 protocol called DCB that may be useful and we want it to get fair consideration if it's a fit. 3.2. Relevant Documents https://datatracker.ietf.org/liaison/1219/ 3.3. Owners - Adrian Farrel, Pat Thaler 3.4. Action Items - Adrian to ensure that architecture and requirements are liaised to the appropriate parties of IEEE. Done. Liaison sent by NVO3 - follow-up and send documents for review as they are adopted as WG items. 4. IETF awareness of IEEE 802.1Q-2011 4.1. Description Many IETF drafts reflect knowledge of IEEE 802.1Q-2005 and ignore the evolution to IEEE 802.1Q-2011. There are two aspects of this. First, it leads to statements in IETF drafts about the capabilities of IEEE 802.1 bridging that are incorrect, often as part of the justification for new work. Many NVO drafts are an example of this. E.g. frequent references to the 12-bit VLAN ID not scaling without mention that the I-tag carries a 24-bit I-SID (backbone Service Instance Identifier) for networks needing a bigger scale. Secondly, it can lead to incompatibility between bridging using more recent capabilities of IEEE 802.1Q-2011 and protocols written based on IEEE 802.1Q-2005. 4.2. Relevant Documents 4.3. Owners - Dan Romascanu, Pat Thaler 4.4. Action Items - Tutorial on IEEE 802.1Q architecture and recent standards will be held at IETF-86. Pat Thaler will coordinate the interaction of the IEEE 802.1 contributors with the EDU team. Outline will be provided until 12/15, the full presentation will be sent for review before the end of January 2013 5. Effect of virtualization on IEEE 802 architecture 5.1. Description At the 7/25 f2f meeting Glenn Parsons presented a brief overview of the IEEE Registration Authority Committee (RAC) mission, highlighting the current RAC policy on virtualization and asking what virtualization policy would reduce the consumption of EUI-48 addresses. Norman Finn suggested this could be an area of collaboration between the IETF and the IEEE 802. At the 9/5 virtual meeting Glenn Parsons reported that the action item from the last meeting on updating the IETF on virtualization at the Vancouver IETF Meeting (July/August, 2012) was completed. 5.2. Relevant Documents http://www.iab.org/2012/12/13/proposed-ieee-registration-authority-committee-oui-tier-restructuring/ 5.3. Owners - Glen Parsons 5.4. Action Items - Russ Housley and Ross Callon to arrange for presentation on MAC addresses and virtualization to be delivered by the IEEE at the IETF plenary in Orlando (March 2013). - Ross Callon and Glenn Parsons to arrange a conference call on OUI tier restructuring sometime in the next 3-4 weeks (end of November 2012) ? email interaction happened but no conference call - possibly no longer needed - Bernard (as IAB chair) sent on 12/12/12 a message to ietf-announce asking for feedback on the Proposed IEEE Registration Authority Committee OUI Tier Restructuring 6. IETF EMU and IEEE 802.1X, 802.11 and 802.16 security based on EAP 6.1. Description - CLOSED 7. IETF Ethernet MIB, ADSL MIB and IEEE 802.3 7.1. Description In the transition process between the IETF and the IEEE the following documents were taken over by IEEE 802.3: RFC 2108 - Ethernet Repeater Devices RFC 3621 - Power Ethernet MIB RFC 3635 - Ethernet-like Interface Types RFC 3637 - Ethernet WAN Interface Sublayer RFC 4836 - Ethernet Medium Attachment Units (MAUs) RFC 4837 - Ethernet Passive Optical Networks (EPON) RFC 4878 - Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces RFC 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB The IF-CAP-STACK-MIB in RFC 5066 is generic and the IETF proposed to continue to be maintained by the IETF in a separate new document The IEEE 802.3 proposed to create an RFC that documents the issues related to the transition of the Ethernet MIB work to IEEE 802.3 similar to RFC 4663 which documents the transition of the Bridge MIB work to IEEE 802.1 - The OPSAWG was rechartered in October 2012 to include the two relevant documents 7.2. Relevant Documents - IEEE 802.3.1 Draft - http://datatracker.ietf.org/wg/opsawg/charter/ - TBD OPSAWG I-Ds 7.3. Owners - Benoit Claise, Dan Romascanu, Ed Beili (IETF), Howard Frazier (IEEE 802.3) 7.4. Action Items - Dan Romascanu will enter the Sponsor Ballot pool and enter a comment suggesting that the IEEE 802.3 take out the IEEE8023-IF-CAP-STACK-MIB from their document and refer the IF-CAP-STACK-MIB instead ? in progress, Dan registered to the Sponsor Ballot Poll which will start soon (mid-December?) - Ed Beili will write an I-D targeting standards track that obsoletes RFC 5066 and extract IF-CAP-STACK-MIB from RFC5056, with wording emphasizing the generic nature of this module ? now on the OPSAWG charter, CRITICAL TIMING issue ? an Internet-Draft MUST be issued until the IEEE 802.3.1 Sponsor Ballot ends (mid-January) - Ed Beili will write an I-D targeting informational RFC, similar to RFC 4663, with: a) Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011 b) A table mapping the old IETF MIB names with the corresponding new IEEE ones c) Clarifications/rules on the IETF-IEEE interactions, mailing lists, reviews d) Clarifications on the intellectual property considerations The first version will be posted by Ed. Then Dan Romascanu and Howard Frazier will add IETF-IEEE interactions chapter. ? Now on OPSAWG charter - Howard Frazier to add a EDITOR'S NOTE in the current IEEE MIB document, to explain the situation 8. IETF 6LOWPAN and IEEE 802.15 8.1. Description - At the 9/5 virtual meeting Ralph Droms reported the new 802.15 Study Group should be aware of the work already taken place in the IETF 6LOWPAN Working Group. Ralph indicated he would take ownership of this item and ask Clint Powell to share the responsibility. He also indicated this would likely be an ongoing coordination effort. - 10/29 virtual meeting  Ralph reports that Tom Herbst was identified as SG liaison to the IETF. Monitoring mode. 8.2. Relevant Documents http://www.ieee802.org/15/pub/SCwng.html http://datatracker.ietf.org/wg/6lowpan/ 8.3. Owners: Ralph Droms, Clint Powell 8.4. Action Items - Ralph to contact and coordinate with Tom Herbst. 9. IETF PAWS WG and 802.11, 802.19, 802.22 9.1 Description - At the 9/5 virtual meeting Bruce Kraemer volunteered that one of the IETF PAWS WG Chairs (Gabor Bajko) is active in 802.11. Dan Romascanu took an action item to clarify with Gabor Bajko and Pete Resnick if there are any action items that need to be taken immediately regarding coordination. Gabors answer was that the coordination between IETF PAWS and IEEE 802.11af, 802.19 and 802.22 was so far handled by him; Gabor presented periodic updates of PAWS to these IEEE 802 groups, and took their input back to PAWS. So far this type of coordination did the job, although in the future some of this interaction may need to be handled via the official channels. - At the 10/29 meeting we confirmed the decision to take out IEEE 802.15 and IEEE 802.16 from the list. Coordination continues by now via participation of Gabor Bajko in both SDOs. Need confirmation this is OK with IEEE 802 9.2 Relevant Documents 9.3 Owners: Bruce Kraemer, Gabor Bajko 9.4 Action Items - clarify whether IEEE 802.11af, 802.19 and 802.22 are all the relevant groups within IEEE 802 that need coordination with PAWS, modify item title accordingly - Bruce to confirm the list and clarify at the IEEE plenary whether the current level of coordination is sufficient 10. IETF IPPM and LMAP, and IEEE 802.16 Metrology Study Group 10.1 Description - Coordinate future work in the IEEE 802.16 with existing work in the IETF - liaison message sent by IEEE 802.16 to IPPM and LMAP - after the November 802 Plenary, a follow-up statement on IEEE 802.16.3 was sent to the LMAP list . It wasn't send to IPPM because it wasn't directly about metrics. 10.2 Relevant Documents http://datatracker.ietf.org/wg/ippm/ http://www.ieee802.org/16/sg/met/ https://datatracker.ietf.org/liaison/1195/ 10.3 Owners - Roger Marks 10.4 Action Items - IEEE 802.16 to send a statement to IETF IPPM WG informing them of the status of the activities of 802.16, and possibly asking for input  Done (sent to IPPM with CC to LMAP list) - email response sent by IPPM chairs and AD to IEEE 802.16 chair on 11/28 11. IETF Mobile IP and IEEE 802.16 HetNet Study Group 11.1. Description At the 7/25 f2f meeting Roger Marks presented a proposal for a new IEEE 802 WG to specify access network abstraction layer above IEEE 802 access technologies, noting that the work is related to some IETF WGs (e.g. DMM, MIF, NETEXT), and made the following recommendations: - IEEE 802 OmniRAN can close the gap and tie 802 devices into a family of standards within a heterogeneous IP network supporting evolving IETF standards - IEEE 802 and IETF should: * leverage each other's expertise * plan communications * identify commonalities * link solutions * organize a team to coordinate milestones and progress At the 9/5 virtual meeting Roger Marks indicated he would be the owner of this item. An action item was identified: Roger Marks to form a team to discuss coordination with possible input from Brian Haberman and Charlie Perkins. Roger reported in the 10/29 meeting that discussions are expected to be hold at the plenary meeting and he expects to have information to report after the plenary Roger reported in a mail sent on 11/26 that the IEEE 802 Executive Committee (EC) initiated the EC OmniRAN Study Group. It is chartered through the March 802 Plenary, with an expectation of extension through July. Max Riegel is the chair. Max Riegel sent a mail to the IESG on 12/11 including information on the Study Group 11.2. Relevant Documents http://www.ieee802.org/OmniRANsg/ 11.3. Owners - Roger Marks 11.4. Action Items ? Discuss communication and coordination level in the 12/17 meeting 12. IETF HOKEY and IEEE 802.21 12.1. Description CLOSED 13. IETF MIF and IEEE 802.21 13.1. Description - IETF MIF should not re-do the work that 802.21 has already done * 802.21 defines a Media Independent Services SAP (API) that provides most of the functionalities that MIF is looking for * 802.21 also defines low level Media Specific SAPs for the underlying access technologies - IETF MIF should identify requirements and make references to 802.21 SAPs where appropriate * If non-existing functionalities are identified both MIF and 802.21 should work together At the 5/9 virtual meeting Dan Romascanu took the action item to ask Subir Das to clarify what is required. Subir answered that the relevant discussions will take place at the November IEEE 802 plenary At the 10/29 virtual meeting Subir reported about the discussion with MIF in Vancouver, and there presentations in .21. There's a joint draft from both groups that will be presented at Atlanta IETF. Hoping for more discussion. Ralph confirmed that the draft's been posted, did not review it yet. 13.2. Relevant Documents http://www.ieee802.org/21/ http://datatracker.ietf.org/wg/mif/ 13.3. Owners - Subir Das, Ralph Droms 13.4. Action Items - Subir Das to report back from discussions at the November IETF meeting and IEEE Plenary 14. IETF IPFIX Information Elements for Data Link monitoring The IPFIX WG specifies a couple of data link Information Elements, to be added to http://www.iana.org/assignments/ipfix/ipfix.xml. Feedback from the IEEE on the Information Element specifications would be appreciated. Information Elements for Data Link Layer Traffic Measurement draft-ietf-ipfix-data-link-layer-monitoring-00 Abstract This document describes Information Elements related to data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. 14.2. Relevant Documents - http://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer- monitoring/ 14.3. Owners - Benoit Claise and the IPFIX chairs (Juergen Quittek , Nevil Brownlee ) 14.4. Action Items - IETF needs to receive feedback from the IEEE (3 meetings a year, almost at the same time as the IETF) - Send a liaison letter send it the liaison letter to 802.1 and/or 802.11 as soon as the WG Last Call starts Note: the process works better if the liaison is informally discussed before it's sent (contact: Eric Gray) - Benoit and Dan to determine: 802.1 and/or 802.11. Done 802.1 - Benoit and IPFIX chairs to synchronize the WGLC with the IEEE schedules, the request for review was sent to the IEEE 802.1 asking feedback from participants. Was sent as liaison and distributed within IEEE 802.1. No feedback received. Discuss in the 12/17 meeting how to proceed. 15. IETF RADIUS attributes for IEEE 802 networks The RADEXT WG specifies RADIUS attributes related to IEEE 802 network. Feedback from the IEEE on the attributes specifications would be appreciated. RADIUS Attributes for IEEE 802 Networks draft-ietf-radext-ieee802ext-02.txt Abstract RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks, as well as clarifications on the usage of the EAP- Key-Name attribute, updating RFC 4072. The attributes defined in this document are usable both within RADIUS and Diameter. 15.2. Relevant Documents: http://datatracker.ietf.org/doc/draft-ietf-radext-ieee802ext/ 15.3. Owners Bernard Adoba, the RADEXT chairs (Jouni Korhonen and Mauricio Sanchez ), and Benoit Claise 15.4. Action Items - Bernard Adoba sent the document to IEEE 802.1 and 802.11, feedback was received from 802.11 - Discuss in the 12/17 meeting how to proceed. 16. IEEE802.1Q SRP (and Gen2 updates) and RSVP/SIP 16.1. Description IEEE 802.1Q currently includes a procedure for reserving bandwidth for particular streams and learning the worst case delays for those streams. Streams are identified using a stream ID that is the concatenation of the source MAC address and an arbitrary 16-bit number (for IP streams, it was expected to be the port #, but the only requirement is that it be unique for a particular source MAC address). The reservation is made using the 802.1Q MRP scheme, where the registration parameters are the StreamID, a destination MAC, a QoS class, a bandwidth requirement, and a stream ranking. Currently, the destination MAC address *must* be a group address, even if there is only asinglelistener since so many of the use cases need multicast, and handling both unicast and multicast was originally viewed as needless complication. The QoS class is called an "SR Class" and currently corresponds to expected delay requirements, where class A is for highly interactive applications such as live musical performance, while class B is for less stringent uses. Bandwidth is measured as worst-case bytes per second as measured over a class- specific interval (125us for class A, 250us for class B). Rank currently only has two values, "emergency" and "normal". The intention always was to allow RSVP and/or SIP to use SRP procedures to gain true L2 guarantees on bandwidth and latency, but not much has been done up to this point. There is an industry-specific effort underway by the AVnu Alliance (www.avnu.org) to specify a way to use SIP/SDP as a way for applications to access SRP services across multiple subnets. SRP is under revision right now, with various improvements in the queue: 1) Two-way and unicast reservations (for VOIP-type applications) 2) Multiple path establishment using IS-IS topology discovery. 3) Reduced "chattiness" due to the current MRP procedures. 4) Expanded QoS classes to support new scheduled (802.1Qbv) and preempting (802.1Qbu) traffic. 5) (others) 16.2. Relevant Documents IEEE Std 802.1Q-2011 "AVB Gen2 assumptions" RSVP - Resource Reservation Protocol (a gaggle of RFCs) SIP - "SIP: Session Initiation Protocol" SDP - "SDP: Session Description Protocol" 16.3. Owners - Michael Johas Teener 16.4. Action Items - need one or more IETF experts to work with the 802 community, particularly since the relevant parts of 802.1Q are open for revision. 17. IEEE 802.1AS/1588 and NTP 17.1 Description IEEE 1588 and it's primary L2-only profile, IEEE 802.1AS, define protocols and procedures for very precise and fast-responding synchronization. These procedures require some hardware-level time stamping services, and, in some cases, on-the-fly modification of packets as they are transmitted. 1588 is heavily used within the telecom and test/measurement community, and has been proposed for various smart grid applications as well. The L2-only 802.1AS is used in professional A/V networks, and is also in other environments where multiple L2 technologies are needed (the other 1588 profiles are Ethernet-only, even though they use IPv4 or IPv6 packet formats). The time format chosen by 1588 is a 64-bit seconds/nanoseconds composite instead of a seconds/fractions of a second composite as used by NTP. (Hey, don't blame me! I wanted the NTP format, myself.) Right now there are no specified procedures for NTP to use 1588/802.1AS when available, nor is there a router spec to define how 1588 can be used in the wider internet. There *are* a few papers that show that a "universal" time router/bridge could be built, and that if it were properly specified, the performance would be equivalent to any particularly 1588 profile. IEEE 1588 is about to be opened for revision, and the IEEE 802.1AS revision has already started as project 802.1ASbt. 17.2 Relevant Documents IEEE Std 1588-2008 - "Precision Clock Synchronization Protocol?for Networked Measurement and Control Systems",? IEEE Std 802.1AS-2011 - "Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", NTP -"Network Time Protocol Version 4: Protocol and Algorithms Specification",RFC 5905, June 2010 17.3 Owners - Michael Johas Teener 17.4 Action Items - need one or more IETF experts to work with the 1588 and 802 communities, particularly since the relevant parts of those standards are (or soon will be) open for revision. 18. 802.1AS/1588, 802.1Q time aware shaper(s) and RTP 18.1. Description RTP is viewed as the primary packet format for IP-based audio and video streams. The existing protocol uses various methods for labeling the time-significance of a particular chunk of data, and then uses yet another protocol (RTCP) to do the "cross timestamp" to associate the somewhat abstract timestamp used in the RTP packets to another time source that has more relevance to the application. IEEE 1722 is a non-routable simple streaming format similar to RTP and the IEC 61883 formats used by Firewire: IEEE 1394). Although 1722 was originally only being used in the pro A/V community, it's also being used in automotive and industrial control networks. Recent work in the IETF AVT-core group is building on new RTP extensions so that a precise timestamp based on 1588 or NTP can be directly used without the RTCP cross-timestamp. This simplification work opens up the? possibility?of using RTP as an IP carrier of IEEE 1722 streams in mixed IP/1722 environments. 18.2. Relevant Documents IEEE Std 1722-2011 - "Layer 2 Transport Protocol for Time Sensitive Applications in a Bridged Local Area Network", RTP - "Standard 64, RTP: A Transport Protocol for Real-Time Applications "RTP Clock Source Signalling", internet draft?draft-ietf-avtcore- clksrc-01 18.3. Owners - Michael Johas Teener 18.4. Action Items - This cooperative work should be continued and encouraged. Perhaps there should be more interaction?between?he AVT and 1722 communities. 19. Common OAM proposal 19.1. Description - proposal made by Tissa Senevirathne and a group of TRILL contributors at the IEEE 802.1 meetings in July and September to reuse the IEEE 802.1ag frame format for TRILL OAM. Needs coordination and architectural consistency with the IEEE 802.1 architecture and OAM practice. - discussion at the 10/29 meeting: The requirements doc is going through WGLC so will come to IESG fairly soon. The framework doc being considered as a WG doc, so it has some time before it will be published by the WG. 19.2. Relevant Documents https://datatracker.ietf.org/doc/draft-ietf-trill-oam-req http://www.ieee802.org/1/files/public/docs2012/liaison-tissa-oam-ieee-trill-0912-v02.pptx 19.3. Owners - Ralph Droms, Norm Finn, Ben Mack-Crane 19.4. Action Items Ralph will send the TRILL OAM requirements document to IEEE 802.1 expert review (Pat, Norm, possibly other). Done 20. Area Name - use of TRILL as an alternative path selection protocol for use in 802.11 mesh networks 20.1. Description a. IEEE Std 802.11(tm)-2012 defines mesh station operation, defines a single mesh path selection (routing) protocol, and is designed to be easily extensible, enabling additional path selection protocols and link cost metrics to be used. b. b. The rationale for and requirements for additional 802.11s mesh path selection protocols may be defined in the future. c. Discussion of new applications of IETF, 802 and 802.11 technologies is encouraged; typically use cases and requirements are defined. d. d. There is interest in the IETF TRILL WG in specifying an alternative path selection protocol for use in 802.11s mesh networks*. e. e. The 802.11ak PAR (802.11 Enhancements For Transit Links Within Bridged Networks) and 802.1Qbz PAR (Enhancements to Bridging of 802.11) have recently been approved. This work may address similar applications to those addressed by 802.11s. *For example, to enable peering of 802.11 mesh nodes with TRILL (RFC 6235) switches in a TRILL based network. (Note that the TRILL protocol would require some modification to be suitable as a Path Selection Protocol.) 20.2. Relevant Documents 20.3. Owners - Ralph Dorms, Tony Jeffree, Bruce Kraemer 20.4. Action Items No action required by IESG or 802 Executive Committee at this time; IETF TRILL, 802.11ak and 802.1Qbz to collaborate as needed, for example, to share use cases and requirements. 21. Area Name 21.1. Description 21.2. Relevant Documents 21.3. Owners 21.4. Action Items 22. Area Name 22.1. Description 22.2. Relevant Documents 22.3. Owners 22.4. Action Items 23. Area Name 23.1. Description 23.2. Relevant Documents 23.3. Owners 23.4. Action Items 24. Area Name 24.1. Description 24.2. Relevant Documents 24.3. Owners 24.4. Action Items