Minutes IETF104: 6lo
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