Minutes IETF111: 6lo
minutes-111-6lo-00

  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