6lo WG Agenda - IETF 111, Virtual 21:30-22:30 (UTC) @ Room 4 Wednesday, July 28, 2021 Chairs: Shwetha Bhandari, Carles Gomez Responsible AD: Erik Kline Minute takers: Dominique Barthel, Georgios Papadopoulos Times in UTC [21:30] Introduction and draft status Bhandari/Gomez 10 min Agenda bashing; blue sheets; scribe; Jabber scribe https://datatracker.ietf.org/meeting/111/materials/slides-111-6lo-chairs-introduction-00.pdf Note Well shown Agenda shown. No comments. WG drafts status is presented. Since last meeting, one new RFC (9034) IPv6 mesh over BLE draft was evaluated by the IESG, and few comments are required to be addressed. IP6 over PLC : expect IESG comments in a few weeks use-cases : new version of draft is submitted, and today this updated version will be presented. [21:36] Update of Applicability and Use Cases draft Yong-Geun Hong 10 min https://datatracker.ietf.org/doc/html/draft-ietf-6lo-use-cases-11 https://datatracker.ietf.org/meeting/111/materials/slides-111-6lo-6lo-applicability-and-use-cases-00.pdf Yong-Geun Hong presents the updated version of the draft. Comments from Tero Kivinen and from Derek were addressed : minor comments on the common (recommend) practices and the expression (title) of the IEEE standard (i.e., IEEE Std 802.15.9). Typo-related comments from Dered were also addressed. Tero Kivinen: the IEEE Std 802.15.9-2021 will be published quite soon, it has already passed the sponsor ballot and is now in the IEEE editors phase. I would expect it to be published in one or two months. IEEE Std 802.15.9-2021 is revision of the 802.15.9 that will add support for algorithm agility from the 802.15.4y. Shwetha asks for shepherd volunteer. If you volunteer, send mail to the ML. Otherwise, Shwetha will shepherd. [21:45] Transmission of SCHC-compressed Packets over IEEE 802.15.4 Carles Gomez 15 min https://datatracker.ietf.org/doc/html/draft-gomez-6lo-schc-15dot4-00 https://datatracker.ietf.org/meeting/111/materials/slides-111-6lo-transmission-of-schc-compressed-packets-over-ieee-802154-networks-00.pdf Carles Gomez presents a new draft on SCHC over 6LoWPAN. He first introduces the RFC 6282, RFC 8724, and SCHC header compression mechanism. SCHC can also compress aplication level protocol such as CoAP, which RFC6282 doesn’t do. SCHC header compression mechanism over 6loWPAN network allows (theoretical) up to 40% battery lifetime improvement. This version extends the previous schc dispatch draft. Then, he presents the alternative protocol stack bsed on SCHC HC instead of 6LoWPAN HC. SCHC fragmentation not used. 6lo “fragment recovery” recently published. 6lo payload size does not require SCHC fragmentation. Dispatch byte: use the paging mechanism, and use one full page for less overhead. Guangpeng Li: why whole page 2 instead of one value from page 0? Carles: currently only 2 pages assigned, this one would be the 3rd. Looks ok to allocate this full page. Pascal: (in overall, Pascal agrees with Li: we should explore using one value in page 0) we use one value of page 0 to signal page 2. If full page 2 is used for this, no benefit. We might be able to squeeze this in page 0. Carles : yes, we should have a look on it. Work to do: explain in this draft how the IID is derived from Layer 2. Also, SCHC model is star, may require adaptation for 6lo which can be peer-to-peer Guangpeng: SCHC is very good compression, good idea to use it here. Georgios will review and comment on the ML. [22:01] Native Short Address for Internet Expansion Guangpeng Li 15 min https://datatracker.ietf.org/doc/html/draft-li-native-short-address-00 https://datatracker.ietf.org/meeting/111/materials/slides-111-6lo-native-short-address-for-internet-expansion-00.pdf Guangpeng Li is presenting the draft. allocating addresses with current IP mechanisms has shortcomings (protocol overhead, complexity) The draft proposes the NSA, Native Short Addresses, a distributed assigned network layer identifier technique that will optimize the networking of IoT devices. It does not depend on DHCPv6 server neither link-layer addresses. RFC6282 header is 7 bytes for routable addresses, best case; this proposal would save 43%. In NSA, addresses are allocated based on position and role in tree. Routing is table-free. translation between IPv6 and NSA is done by prepending/removing a Prefix at border router. NSA extended to 64 bit lower IPv6 address requires new dispatch type from IANA for this new packet format Interest, comments? WG interest / adoption. Pascal: this has been tried in the past IEEE 802.15.5, and failed. If topology changes, you need to renumber. This work sounds rather IEEE oriented work (Layer 2) and less IETF focus. Dominique: tree-based address allocation was also tried with the first version of Zigbee, then quickly changed back to another scheme. Main reason is: when the topology changes, then renumbering needs to happen. Carles: regarding the 6lo charter, unclear whether nodes in the NSA domain actually support IPv6 in the usual sense, since those nodes are unaware of their IPv6 addresses. [22:20] Fragment forwarding and FEC Amaury Bruniaux 10 min https://datatracker.ietf.org/meeting/111/materials/slides-111-6lo-fragment-forwarding-and-fec-00.pdf Amaury presents the draft. He presents first RFC 4944 (the forwarding mechanism), and presents its disadvantages. Then the VRB mechanism is presented which addresses some of the RFC 4944 issues. Introduces the notion of FEC. 3 proposals: XorFEC, RFEC, XorFEC: one extra fragment is sent, XORing all sent fragments. Recovery capability is 1 lost fragment. XorFEC uses as well the VRB mechanism for the forwarding part. RFEC: each fragment is repeated once (two transmissions). High reliability but high overhead. NCFEC: based on network coding. If N original fragments, any N encoded fragments received among M are enough to recover the original fragments. SA/DA repeated in each encoded fragment, so that they can be routed independently. Even if the first fragment is lost, there is no issue contrary to the previous RFCs (e.g., 4944 and the VRB-based one). Carles: time is out. Discussion will happen on the ML. Please write and publish I-D so that it can be discussed! [22:34] Meeting adjourned Meeting Chat: Carles Gomez Hi Erik! Just one point. We were wondering: are there any recent details/news on the next steps for the IPv6 over NFC draft?03:09:02 Erik Kline based on some informal discussions, it’s likely that some on the IESG will continue to ask to see the NFC spec03:10:17 Tero Kivinen Btw, the IEEE Std 802.15.9-2021 will be published quite soon, it has already passed the sponsor ballot and is now in the IEEE editors phase. I would expect it to be published in one or two months. IEEE Std 802.15.9-2021 is revision of the 802.15.9 that will add support for algorithm agility from the 802.15.4y.03:10:39 Erik Kline I saw that the NFC spec is listed as being similar to 802.2, but I don’t know to what extent an 802.2 spec is substitutable for the NFC 1.3/1.4 spec03:11:11 any help from the group/authors on how to get ahold of a version of the NFC spec for the IESG to use would be very helpful03:11:43 Younghwan Choi I am Younghwan Choi, one of the authors for IPv6-over-NFC.03:15:14 Peter Yee And IEEE 802.15.9-2021 is a standard not a recommended practice as the previous edition was. The 2021 version is an improvement over the previous edition.03:15:46 Younghwan Choi Of course I will hwlp you for that.03:15:53 Please let me know how to help…03:16:48 Yong-Geun Hong Thanks to Tero Kivinen and Peter Yee…03:17:43 Younghwan Choi I need to have a look on more details about 802.2 and NFC1.403:20:03 Erik Kline Younghwan: is there a version of the 1.3 spec that can be shared with the IESG in order to complete its review?03:20:08 Younghwan Choi yes i have that03:20:33 I will give you the spec. NFC 1.3/1.403:20:46 Erik Kline (separately, I saw something claiming 1.3 was deprecated and 1.4 is the new thing. Does this impact anything, do we need to adjust/update?)03:20:53 thank you!03:21:30 Younghwan Choi As I know there is no more thing impact03:21:58 of NFC1.403:22:10 Erik Kline meaning that the differences between 1.3 and 1.4 don’t affect the 6lo document?03:22:45 👍03:23:16 Younghwan Choi yes it is… i think so03:23:17 Erik Kline thanks