Potential Areas for IETF/IEEE802 Coordination 0. Revision History 0.1 Initial Revision - 9/4/2012 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. 1.2 Relevant Documents 1.3 Owners 1.4 Action Items 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 2.2 Relevant Documents 2.3 Owners 2.4 Action Items 3. IETF NVO 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. 3.2. Relevant Documents 3.3. Owners 3.4. Action Items 4. IETF awareness of IEEE 802.1Q-2011 4.1. Description Many IETF drafts reflect a 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 4.4. Action Items 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. 5.2. Relevant Documents 5.3. Owners 5.4. Action Items 6. IETF EMU and IEEE 802.1X, 802.11 and 802.16 security based on EAP 6.1. Description 6.2. Relevant Documents 6.3. Owners 6.4. Action Items 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 7.2. Relevant Documents - IEEE 802.3.1 Draft 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. - 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 - 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 - - 8. IETF 6LOWPAN and IEEE 802.15 8.1. Description 8.2. Relevant Documents 8.3. Owners 8.4. Action Items 9. IETF PAWS WG and IEEE 802.1, 802.11, 802.15, 802.16, 802.22 9.1 Description 9.2 Relevant Documents 9.3 Owners 9.4 Action Items 10. IETF IPPM and IEEE 802.16 Metrology Study Group 10.1 Description 10.2 Relevant Documents 10.3 Owners 10.4 Action Items 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 11.2. Relevant Documents 11.3. Owners 11.4. Action Items 12. IETF HOKEY and IEEE 802.21 12.1. Description The HOKEY charter includes: Assistance to the 802.21a group in specifying the integration of EAP pre-authentication with IEEE 802.21a. The HOKEY Working Group shall perform tasks that are complementary to and do not duplicate work being done in IEEE 802.21a. Note: since July the HOKEY WG concluded. If there are any pending tasks they should be transferred to some other place in the IETF. 12.2. Relevant Documents 12.3. Owners 12.4. Action Items 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 13.2. Relevant Documents 13.3. Owners 13.4. Action Items 14. IETF IPFIX Information Elements for Data Link monitoring 14.1. Description 14.2. Relevant Documents 14.3. Owners 14.4. Action Items 15. IETF RADIUS attributes for IEEE 802 networks 15.1. Description 15.2. Relevant Documents 15.3. Owners 15.4. Action Items 16. IEEE802.1Q SRP (and Gen2 updates) and RSVP/SIP 16.1. Description 16.2. Relevant Documents 16.3. Owners 16.4. Action Items 17. IEEE 802.1AS/1588 and NTP 17.1 Description 17.2 Relevant Documents 17.3 Owners 17.4 Action Items 18. 802.1AS/1588, 802.1Q time aware shaper(s) and RTP 18.1. Description 18.2. Relevant Documents 18.3. Owners 18.4. Action Items 19. Area Name 19.1. Description 19.2. Relevant Documents 19.3. Owners 19.4. Action Items 20. Area Name 20.1. Description 20.2. Relevant Documents 20.3. Owners 20.4. Action Items 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