Minutes IETF104: 6lo
minutes-104-6lo-01
| Meeting Minutes | IPv6 over Networks of Resource-constrained Nodes (6lo) WG | |
|---|---|---|
| Title | Minutes IETF104: 6lo | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2019-04-03 |
minutes-104-6lo-01
6lo WG Agenda - IETF 104, Prague
13:50-15:50 @Karlin 1/2
Monday, March 25, 2019
Chairs: Shwetha Bhandari, Carles Gomez
Responsible AD: Suresh Krishnan
Minute takers: Dominique Barthel, Antoine BERNARD
Jabber scribe: Rahul Jadhav
Meetecho for remote participants: https://www.meetecho.com/ietf104/6lo
Etherpad for notes:
https://etherpad.tools.ietf.org/p/notes-ietf-104-6lo?useMonospaceFont=true
----------------------------------------------------------------
AGENDA (see live meeting notes below the agenda)
Introduction and draft status Bhandari/Gomez
10 min Agenda bashing; blue sheets; scribe; Jabber scribe
Status of WGLC - Address Protected ND
10 min
https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-11
Status and Publication Request of Backbone Router Pascal Thubert
5 min
https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-11
ND Unicast Lookup - WG adoption
10 min
https://tools.ietf.org/html/draft-thubert-6lo-unicast-lookup-00
6LoWPAN packet delivery deadline time: Last changes Charlie Perkins
15 min
https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-04
Update after WGLC and discussion on next steps Yong-Geun Hong
10 min
https://tools.ietf.org/html/draft-ietf-6lo-use-cases-06
Update after WGLC of IPv6 Mesh over BLE networks Carles Gomez
10 min
https://tools.ietf.org/html/draft-ietf-6lo-blemesh-05
Preparation for WGLC for LLN Minimal Fragment Forwarding Thomas Watteyne
10 min
https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-01
Status of Fragment Recovery Pascal Thubert
10 min
https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-02
Status of Transmission of IPv6 Packets over PLC Networks Remy Liubing
5 min
https://tools.ietf.org/html/draft-ietf-6lo-plc-00
Total: 95 min
----------------------------------------------------------------
MEETING NOTES
[13:51] meeting starts
[13:51] intro (chairs)
https://datatracker.ietf.org/meeting/104/materials/slides-104-6lo-chairs-introduction-6loietf104-00
* New chairs thank Gabriel and Samita, out-going chairs, for their work
* Blue sheets, Note Well.
* Agenda is shown. No comments on the agenda. Chairs propose to add one item,
6lo Wiki. No objection. * Suresh: NFC doc went through IESG evaluation, lot
of stuff to address there, do authors want to add details? * Y. Choi: had
telechat with IESG. Would like to thank all reviewers at IESG. Will address
comments and produce updated draft. * Suresh: comment that some parts looked
like "marketing text", can provide help to tone it down. * Suresh (on
Jabber): one of the issues was that the technology related text was very
marketing-oriented. * Y. Choi: will address that
New RFC (RFC 8505) since the last meeting, congratulations to the authors
9 drafts updated since the last IETF
Packet Delivery Deadline Time draft submitted, some reviews from various
directorates, the comments were taken into account and a new draft was
submitted WGLC ended on a few documents. Will be discussed today. Minimal
fragment forwarding document believed to be ready for WGLC by the authors.
Fragment Recovery and IPv6 over PLC in progress.
[14:00] Status of WGLC - Address Protected Neighbor Discovery (Pascal Thubert)
https://datatracker.ietf.org/meeting/104/materials/slides-104-6lo-wireless-nd-00
* Bunch called "Wireless ND" by Pascal.
* Consist of series of 4 drafts that focus on ND.
* A series of expections between IETF and IEEE that were never met :
* Multicast is not reliable because it is not acknowledged, and also
often slower, uses bandwidth. * IEEE expected from the IETF that proxy ND
would be done at the access point.
* Proposal is to register node address at Border Router.
* Slide IPv6 and 802.11 : Text of the current specification for Proxy
Neighbor Discovery as proposed by the IEEE. * Proposing new text for 802.11
main spec, including quote to RFC8505. * The text now explains the reasons
why neighbor discovery and backbone router specification are necessary *
Summary on RFC8505: message sequence diagram shown. Multicast kept to a
minimum (first RS from node) * The registration is done sending an NS (with
EARO option) message, changes to the address registration process. * First
address registration includes a TID (similar to a public key) that will prove
ownership for later registration attempts. It used to be the MAC address, a
new process was proposed for security reasons. * Address Protection ND based
on a first time first serve based ownership . * Address Protected ND has 3
crypto modes. * 6LR will challenge the joining 6LN to prove its authenticity
when joining for the first time. * This required ROVR (Registration Ownership
Verifier) option field, variable length. * René added some text in the
security section. * Shwetha : The draft has already passed last call and
received no reviews. What is the opinion of the people in the room
considering the WG Last Call ended on March 16 ? * Pascal: got early SecDir
review. * Shwetha: no disagreement in the room to proceed. Will do shephard
write-up.
[14:16] Status and Publication Request of Backbone Router (Pascal Thubert)
* Layer 3 access point, proxy neighbor discovery made by the backbone router.
* Started since the start of the work on RFC6775 and split out of it during
the work on it. * Resurected 2/3 years ago. * Pascal: Didn't go to 6man or
INT on it, but would be happy to get reviews. * 6BBR transforms proactive
unicast registration from 6LN/6BR to DAD over the backbone. * Looking for
destination results in NS lookup in broadcast. * Bridge and proxy router mode
available (depending on the link between 6BBR and 6LBR)
[14:20] ND Unicast Lookup - WG adoption (Pascal Thubert)
* Matches a lot of proprietary implementations behavior.
* Makes it standard.
* We want to install 6LBR on the backbone that knows which address was
registered by whom. * Created a new address mapping message, re-using the
existing EDAR message type of ICMP, but defining a new code value inside the
type. * lookup is now unicast as well. * Pascal goes through new message
sequence diagram. Can now do unicast EDAR/ADAC to the registar on the
backbone. * The big benefit of having a BBR on the backbone, you can use
multicast only (but you can also fall back on the legacy system if you need
it). * Pascal would like to get reviews. * Shwetha: volunteers? Rahul,
Charlie. You can even cross post it in 6man, this might have a more generic
applicability. * Yes, it is designed for Wi-Fi but can be useful for other
networks. * Charlie Perkins: would be unusual to adopt a draft if very few
people have read it * Pascal: Not calling for adoption. Asking for reviews. *
Carles: Thanks to Rahul and Charlie. Please post your reviews on the mailing
list. I will try to do the same. * Pascal: And yes, once I have reviews and
once they are addressed, I will probably ask for rapid adoption because this
draft is behind the others. * Suresh: Remind Pascal of the efficient-nd draft
at 6man a few years back (with Eric and Samita), faced opposition. Why would
this one be different? * Pascal : I have been thinking about it. Pascal
proposes to talk about it with Suresh the next time they meet.
[14:30] 6LoWPAN packet delivery deadline time: Last changes (Charlie Perkins)
https://datatracker.ietf.org/meeting/104/materials/slides-104-6lo-packet-delivery-deadline-time-01
* Gone through WGLC, went to IESG, got many comments from directorates
reviews. * -04 addressed these. * Assumes that devices are time synchronized.
* Draft history and thanks to reviewers. * Discussion about multiple ways of
representing the same time. Also, how do you know what is T0. Pretty ok for
the time unit, though. * New draft addresses the T0 issue. * Suggestion by
reviewer to use NTP time representation. NTP actually has 2 representations.
New draft uses these, with added scaling factor to save bits. * One of the
reviewers pointed out that instead of sending a complete time it would be
better to send a delta encoding of the Origination Time (related to the
Deadline Time), in order to save bits. * Binary point representation instead
of Exponent, given the variety of representations now allowed. * Quite a lot
of new additions due to addition of Synchronization to the draft. * New
Format presentation.
* Charlie: Will solicit new feedback for the latest version.
* Pascal: forwarding based on this option should be drop or no drop. Anything
else, more subtle. * Charlie: you're taking about the D bit. * Pascal: what
about Quality of Service decision? * Charlie: If you want to expand, we would
thank any review. * Shwetha: this draft is about deadline time. Pascal, other
uses could go in separate draft. * Pascal: works. * Suresh: This hex digit is
misleading, use nibbles instead. * Charlie: I was told that hex digit was
better, but no problem to use nibbles.
[14:45] Update after WGLC and discussion on next steps (Yong-Geun Hong)
https://datatracker.ietf.org/meeting/104/materials/slides-104-6lo-draft-ietf-6lo-use-cases-06-00
* Co-authors are each experts in different 6lo technologies.
* This document is 2 1/2 years old. Purpose is to help newcomers understand
how to use 6lo over various technologies. * May not be interesting to 6lo
experts but has some real potential for future adopters. * WGLC was done in
late 2018, but no comment was received. Maybe because it is very good! *
Updated anyway to include PLC, and reflect advances in various documents
referenced by this one. * 4 6lo scenarios. * HomePlug Alliance has stopped
operating, rumored to transfer its standardization activity to Wi-SUN, but no
official announcement. * Shwetha: living document. Should be published as an
Informational document, or keep it in the 6lo Wiki? * Yong-Geun: what is the
6lo Wiki? * Carles: Place where different resources about the working group
can be found: https://trac.ietf.org/trac/6lo * YGH: could be. Would still
like to uprade doc with expert comments. * Pascal: What do we expect from 6lo
in the future, would be cool to keep the document open. * Carles (as a
co-author): would like to know how to interpret the silence during WGLC. *
Shwetha: what does Suresh think? * Suresh: Not sure about the archival value
of the draft, and also about the scope of the draft. If we decide to go for
publication we will probably need to chop down a bit of it. * YGH: point
taken. Will discuss with co-authors. Will considering narrowing down the
scope.
[14:52] Update after WGLC of IPv6 Mesh over BLE networks (Carles Gomez)
https://datatracker.ietf.org/meeting/104/materials/slides-104-6lo-ipv6-mesh-over-ble-00
* WGLC on -04, comments received, -05 released addressing those comments.
* Therefore authors believe doc is ready for next step.
* Going through list of updates:
- Terminology consistency
- Not sure if doc is sufficient by itself to build a mesh over BTLE. Now
made clear that it is not enough, e.g. does not define routing. -
Fragmentation was not explicitly addressed, it is now with BTLE4.2 uses
L2CAP fragmentation - Now refers to RFC8505 regarding ND. Discusses use of
crypto addresses, protected ND... - Updated the security consideration part
in the draft or by referencing other drafts (such as 6lo-ap-nd)
* Questions?
* Shwetha: does it address all reviewersÂ’ comments? Nodding in the room.
[14:59] Preparation for WGLC for LLN Minimal Fragment Forwarding (Thomas
Watteyne)
https://datatracker.ietf.org/meeting/104/materials/slides-104-6lo-minimal-fragment-forwarding-00
* Thomas reviews RFC4944 fragmentation, explains why per-hop F/R is
problematic:
- Latency
- Memory constraint
* Proposition to use fragment forwarding, will send the data without
reassembling until the destination. * To describe that solution, 2 drafts at
6lo WG (minimal FF, frag recovery), 1 at lwig WG (virtual reassembly). *
Minimal FF draft posted recently as an Informational draft to present the
problem and the solution that is to be adopted. * Shows simulation results
(simulation by Yatch on 6TiSCH simulator), which highlight the problem and
the effectiveness of the solution.
- the solution proposed reduces the memory usage and prevents packet loss
* Believe draft is stable, asking about WGLC?
* Carles: comments on this document? None heard.
* Carles: will open WGLC, volunteers? George, Dominique
[15:07] Status of Fragment Recovery (Pascal Thubert)
https://datatracker.ietf.org/meeting/104/materials/slides-104-6lo-fragment-recovery-00
* Thanks to Thomas for the introduction, will present the complementary work
of the previous presentation. * Minimal FF does not address classical case of
one lost fragment. Reassembly buffer blocked. * This draft about recovering
the missing fragment(s). Similar to SCHC fragmentation. * You send the
fragment, you receive an Ack bitmap that indicates which fragments were lost.
* Cannot use RFC4944 format, defined new one. * With Flow Control, ECN, etc.
* Implementations provided comments. Format did not allow for very large
frames. * Format modification to reduce the size of the datagram tags, bits
saved for datagram size field, therefore allows for large datagrams. (15.4g
has 2 KiB frames.) * 6LoWPAN compression might change size of packet, had to
include slack to allow for change in size on retransmission depending on the
capacities of the devices that handle the packet. * Need to change the way a
packet is handled without changing it depending on if you are the sender, the
receiver or an intermediary. * Pascal: implementers are happy. Ready for
WGLC? * Laurent: why not use SCHC meachanism instead? * Pascal: because this
existed before SCHC. * Pascal: Would love to have reviews from the SCHC
authors. One difference is that SCHC does not handle multiple hop
retransmission. * Carles and Laurent to review before asking for WGLC.
[15:15] Status of Transmission of IPv6 Packets over PLC Networks (Remy Liubing)
https://datatracker.ietf.org/meeting/104/materials/slides-104-6lo-status-of-transmission-of-ipv6-packets-over-plc-networks-00
* Reviews history of this draft. Originally written by Huawei.
* PLC used for more applications than metering. To control traffic lights,
etc. * New uses now need Layer3. * G.9903, P1901.1 and P1902 are in scope of
ths draft. * Was adopted and re-submitted as WG draft. * Not received a lot
of comments, only 1 by Carsten, relating to confusing PLC landscape
description. Description includes wide range of PLC technologies. * Added
some clarification following this comment, that this draft focuses on
constrained PLC. * Future work will add more references to header compression
RFCs. * Feedback is requested. * Carles: are you aware of any
implementations? * Remy: Some implementation exist. * Carles: It would be
good to use these implementations as a work base to improve the specification.
[15:21] 6lo Wiki (Carles as chair)
* Requests that useful information is provided to populate the wiki.
* Useful information includes open source implementations, interop events,
etc.
[15:22] Any other business?
[15:22] Meeting adjourns