2019-06-18: Minutes
slides-interim-2021-ietfieee-08-sessa-2019-06-18-minutes-00
Meeting Slides | IETF-IEEE (ietfieee) IAB ASG | |
---|---|---|
Date and time | 2022-01-01 00:00 | |
Title | 2019-06-18: Minutes | |
State | Active | |
Other versions | plain text | |
Last updated | 2022-06-10 |
slides-interim-2021-ietfieee-08-sessa-2019-06-18-minutes-00
Minutes of the 2019-06-18 IETF-IEEE 802 Coordination Teleconference 1. Welcome, roll call, agenda bashing Present: - Randy Bush - Alissa Cooper - Janos Farkas - Ted Hardie - Russ Housley - Mirja Kühlewind - Scott Mansfield - Roger Marks - Cindy Morgan - Paul Nikolich - Alvaro Retana - Dorothy Stanley - Pascal Thubert - Magnus Westerlund - Peter Yee 2. Action item updates - In Progress: o Bob Heile to send a short description of 802's LPA project with pointers to Russ Housley for inclusion in the coordination list. <http://www.ieee802.org/15/pub/TG4w.html> (Added 2018-06-28) o Dorothy Stanley and Russ Housley to investigate the need for adding a coordination item on source address validation for 802.11. (Added 2019-02-20) - Done: o Alvaro Retana and Russ Housley to write up a description for a new coordination item on interactions between IETF LSVR and IEEE 802.1 regarding the IETF's LSoE protocol and a consideration for a new LLDPv2 protocol in 802.1. (Added 2019-02-20) - New: o Dorothy Stanley to ask Bob Heile for a status update on 802.15.12. (Added 2019-06-18) o Russ Housley to contact the IETF Security ADs and ask who will take over ownership of the pervasive monitoring coordination item from Eric Rescorla, who stepped down from the IESG in March 2019. (Added 2019-06-18) o Janos Farkas to send a liaison on 802E to the IETF Security ADs. (Added 2019-06-18) 3. IETF New Work summary - Applications and Real-Time ADD - Applications Using DoH - Discussions at the DoG WG and a side meeting at IETF104 suggest there appears to be significant interest in examining in the operational aspects of DoH deployment, particularly in operator and enterprise networks. This lead to the creation of the ADD mailing list where some of these issues have been discussed. The proposed BoF intends to establish if there are sufficient potential work items and enough interest at the IETF to justify the creation of a new Working Group which would focus on these topics. - General NETRQMTS - IETF Meeting Network Requirements - NOT WG Forming - The IETF meeting network has a long history of pushing beyond the bounds of normal event networks. This BoF will gather community input on the network requirements for IETF meetings, including prioritization and the resource implications associated with those requirements. - Internet NONE - Operations and Management MOPS - Media OPerationS - The purpose of this BoF is to highlight the many existing video activities that are leveraging IETF protocol work, identify gaps in IETF work and/or areas of incompatibility with video technology development efforts being carried out elsewhere, and identify a core group of IETF participants working on video activities across the IETF’s technology areas. - Routing NONE - Security CACAO - Collaborative Automated Course of Action Operations (CACAO) for Cyber Security - To defend against threat actors and their tactics, techniques, and procedures, organizations need to manually identify, create, and document prevention, mitigation, and remediation steps. These steps when grouped together into a course of action (COA) / playbook are used to protect systems, networks, data, and users. The problem is, once these steps have been created there is no standardized and structured way to document them, verify they were correctly executed, or easily share them across organizational boundaries and technology stacks. The intent is to charter a working group that will create a standard that implements the playbook model for cybersecurity operations. LAKE - Lightweight Authenticated Key Exchange - Constrained environments using OSCORE in network environments such as NB-IoT, 6TiSCH, and LoRaWAN need a 'lightweight' authenticated key exchange that enables forward security. 'Lightweight' refers to resource consumption, measured by bytes on the wire, wall-clock time to complete, or power consumption; and the amount of new code required on end systems which already have an OSCORE stack. - Transport LOOPS - Local Optimizations on Path Segments - Performance Enhancing Proxies (PEPs) have been used to improve performance over paths with links of varying quality, often peeking (and poking!) into the transport protocol. Encryption is putting an end to this practice. At the same time, more powerful network nodes are becoming available, making it more viable to trade processing power in network nodes against path quality. Transport protocols and their implementations are moving towards playing better with forwarding node functions such as ECN marking and AQM. 4. 802 New Work summary - 802.1ABdh -Amendment - Support for Multiframe Protocol Data Units Janos Farkas reported that this PAR amendment relates to the item on the coordination list about capability discovery. Alvaro Retana noted that the LSVR Working Group received a liaison statement from 802.1 on LSVR's work on LSoE. - 802.1Qdj - Amendment - Configuration Enhancements Janos Farkas reported that this PAR is about enhancing the Time- Sensitive Networking configuration' to specify enhancements to the User/Network Interface (UNI) to include new capabilities to support bridges and end stations in order to extend the configuration capability. - 802.1Qcj - Amendment - Automatic Attachment to Provider Backbone Bridging (PBB) services, PAR extension Janos Farkas noted that this is an extension of an existing PAR that will not finish its work items by the end of the year. - 802.3cv - Amendment - Maintenance #15: Power over Ethernet Dorothy Stanley reported that this is a PAR amendment to incorporate technical corrections and clarifications. - 802.11ay - Amendment - Enhanced Throughput for Operation in License-Exempt Bands Above 45 GHz, PAR Extension Dorothy Stanley noted that this is an extension of an existing PAR that will not finish its work items by the end of the year. - 802.11az - Amendment - Next Generation Positioning (NGP), PAR Extension Dorothy Stanley noted that this is an extension of an existing PAR that will not finish its work items by the end of the year. - 802.15.9ma- Standard, Transport of Key Management Protocol (KMP) Datagram Dorothy Stanley reported that this PAR is for a change in scope to move 802.15.9 from a recommended practice to a standard. 5. Review current coordination items - Item 3. IETF NVO3 and IEEE 802.1 DCB Janos Farkas reported that 802.1Qcy is currently with the IEEE editor. This item will be closed once 802.1Qcy is published. - Item 5. Enabling use of Local Addresses for virtualization and IoT Russ Housley reported that the DHC WG adopted draft-ietf-dhc-mac- assign in April 2019, and it will be coordinated with 802 once it is stable. Janos Farkas reported that 802.1CQ will be coordinated with the IETF once it is stable. - Item 11. IETF and IEEE 802.1 OmniRAN TG 802.1CF was published in May 2019. This coordination item will be closed. - Item 21. 6tisch Pascal Thubert reported that 6TISCH is mostly done with its work. draft-ietf-6tisch-architecture is currently in IETF Last Call. Pascal Thubert noted that he was not sure about the current status of 802.15.12, except that it should be coordinated with the IETF once it is stable. * Action item: Dorothy Stanley to ask Bob Heile for a status update on 802.15.12. - Item 24. Coordination between the IETF and IEEE 802 on Pervasive Monitoring * Action item: Russ Housley to contact the IETF Security ADs and ask who will take over ownership of this coordination item from Eric Rescorla, who stepped down from the IESG in March 2019. Janos Farkas reported that 802E is stable. Paul Nikolich suggested that he send a liaison to the IETF Security ADs with a pointer to the document and instructions on how to comment on the ballot. * Action item: Janos Farkas to send a liaison on 802E to the IETF Security ADs. - Item 25. Layer2/Layer 3 Interaction for Time-Sensitive Traffic Janos Farkas reported that draft-ietf-detnet-architecture is currently in the RFC Editor Queue. draft-ietf-detnet-use-cases (RFC 8578) and draft-ietf-detnet-problem- statement (RFC 8557) were both published in May 2019. - Item 27. Development of YANG models in the IEEE 802 Scott Mansfield reported that 802 has identified the missing metadata and plans to have it added to yangcatalog.org by the end of July 2019. Russ Housley reported that the operations of yangcatalog.org have moved to the IETF Secretariat, but that nothing about how the catalog is run has changed. - Item 30. Intelligent Transportation Systems (ITS) Russ Housley reported that draft-ietf-ipwave-ipv6-over-80211ocb iw currently in IETF Last Call. Dorothy Stanley reported that IEEE 802.11bd is making good progress. - Item 31. LPWAN Pascal Thubert reported that 802.15.4w is seeking feedback from the IETF Internet Area. - Item 32. Source Address Validation for Wireless LAN Dorothy Stanley reported that 802.11 received a request to review draft-bi-savi-wlan. Peter Yee added that he raised the issue with the architecture standing committee, but that they did not feel that they had the expertise needed to comment. Pascal Thubert reported that the 6LO Working Group published RFC 8505, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery." The group is now working on draft-ietf-6lo-ap-nd, which has been submitted to the IESG for publication and should go out for Last Call soon. 802.11 will be asked to review draft-ietf-6lo-ap-nd during Last Call. - Item 33. Capability Discovery Russ Housley noted that this item is related to the PAR amendment for 802.1ABdh. Alvaro Retana reported that LSVR and TSN have had good communication back and forth. He noted that the description of this item should be updated to note that the coordinated work item in LSVR relates to Layer 3 Discovery and Liveness (L3DL), rather than Link State over Ethernet (LSoE). - Potential New Items Mirja Kühlewind noted that the IPPM Working Group is taking on work for ethertype protocol identification in IOAM; there is currently an individual draft (draft-weis-ippm-ioam-eth) on this work. 6. Assess need for breakfast meeting during the 2019 July IETF meeting (Montreal 21-26 July) The group agreed that there was no need to meet during IETF 105 in Montreal. 7. Adjourn ------------------------------------------------------------------------ Post-meeting addendum from Pascal Thubert: From: "Pascal Thubert (pthubert)" <pthubert@cisco.com> Subject: Re: [ieee-ietf-coord] Draft Minutes from the 2019-06-19 IETF-IEEE 802 Coordination Meeting Date: June 24, 2019 at 7:56:43 AM PDT Dear all: As a follow up on the discussion of SAVI and IEEE 802.11. Please note that I published draft-thubert-6man-ipv6-over-wireless to explain better the issues with the SAVI draft and how RFC 8505 family solves them. Please note that as an implementor of SAVI in my company’s Wi-Fi gear, I have a first-hand view on these issues. In the introduction you’ll find the following: “ Discovering peer addresses by snooping the IPV6 ND protocol as proposed for SAVI [I-D.bi-savi-wlan] was found to be unreliable. An IPv6 address may not be discovered immediately due to a packet loss, or if a "silent" node is not currently using one of its addresses, e.g., a node that waits in wake-on-lan state. A change of state, e.g. due to a movement, may be missed or misordered, leading to unreliable connectivity and an incomplete knowledge of the set of peers. Wireless ND (WiND) introduces a new approach to IPv6 ND that is designed to apply to the WLANs and WPANs types of networks. On the one hand, WiND avoids the use of broadcast operation for Address Resolution and Duplicate Address Detection, and on the other hand, WiND supports use cases where Subnet and MAC-level domains are not congruent, which is common in those types of networks unless a specific MAC-Level emulation is provided. To achieve this, WiND applies routing inside the Subnets, which enables MultiLink Subnets. Hosts register their addresses to their serving routers with [RFC8505]. With the registration, routers have a complete knowledge of the hosts they serve and in return, hosts obtain routing services for their registered addresses. The registration is abstract to the routing protocol, and it can be protected to prevent impersonation attacks with [I-D.ietf-6lo-ap-nd]. The routing service can be a simple reflexion in a Hub-and-Spoke Subnet that emulates an IEEE Std 802.11 Infrastructure BSS at Layer 3. It can also be a full-fledge routing protocol, in particular RPL [RFC6550] that was designed to adapt to various LLNs such as WLAN and WPAN radio meshes with the concept of Objective Function. Finally, the routing service can also be ND proxy that emulates an IEEE Std 802.11 Infrastructure ESS at Layer 3. WiND specifies the IPv6 Backbone Router for that purpose in [I-D.ietf-6lo-backbone-router]. More details on WiND can be found in Section 4.1. “ I’m happy to discuss the draft on this list but would rather we copy 6MAN since I plan to present the draft there. All the best, Pascal