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