Minutes IETF101: 6lo
minutes-101-6lo-00

IETF 101 6lo Working Group meeting, London, UK
Chairs: Gabriel Montenegro and Samita Chakrabarti
Date: March 22, 2018

Minute taker: Dominique Barthel

Agenda

*  Introduction and  draft status                         
Montenegro/Chakrabarti      10 min

  Agenda bashing; blue sheets; scribe; Jabber scribe

*  An Update on 6LoWPAN ND IESG review                         Pascal Thubert

    https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-14               
          15 min

  Discuss updates on RUID size and security length

    https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-06                        
          10 min

  WGLC Preparation and update:

    https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-06              
          05 min

*  6lo NFC draft WG LC status update

    https://tools.ietf.org/wg/6lo/draft-ietf-6lo-nfc-09       Younghwan Choi   
          10 min

*  Update on 6lowPAN Routing header lifetime                   Charlie Perkins

   https://tools.ietf.org/html/draft-ietf-6lo-deadline-time                    
         10 min

*  6lo Applicability and Use Cases Updates                     Yong-Geun Hong  
       10 min

    https://tools.ietf.org/html/draft-ietf-6lo-use-cases-04

*  Fragmentation Design team formation Update (DT Lead: Thomas Watteyne):

                  Goal, overview and Status of the progress    Thomas Watteyne 
                        10 min

                  draft-watteyne-6lo-minimal-fragment          Carsten Bormann 
                        10 min

                  draft-thubert-6lo-fragment-recovery          Pascal  Thubert 
                        10 min

                  Q&A                                                          
                        10 min

*  Information sharing to 6lo WG:

  draft-thubert-roll-unaware-leaves-03                         Pascal Thubert  
         05 min

 *  IETF Hackathon                                              Alain Rebault  
         05 min

Total: 115 min

[13:30]

    * status of the drafts

    * Fragmentation Design Team. lead by Thomas. Good progress

    * 6lo information page. looking for volunteers.

    * Carsten: came out in class, looking for something like cbor.io. Low
    effort to run. It's on GitHub,
               people contribute through Pull Requests.

    * Samita: volunteers, please contact the chairs

    * T2TRG side meeting, protocol interaction issues on the wire

    * 6lo plugtest on F-interop platform.

[13:44] Drafts revolving ND improvements (Pascal)

    * Factory sensor networks. Devices move beween DODAGs, without renumbering
    nor redoing association.

    * group of 3 documents: 6775 update, protection of address against theft,
    federation of 6lo meshes over
      a backbone that runs classical ND

    * draft-ietf-6lo-rfc6775-update-14: changes since IESG review:

         * length other than 2 because of cryptographic token (Registration
         Ownership Verifier).

         * R flag: tells this node is a host, not a router.

         * Transaction ID: counter that allows for roaming. When several
         messages are received from different DODAGs, which one is the new one.

         * Registration Lifetime

         * Registration Ownership Verifier: this is no longer a EUI-64 (privacy
         issue). The real need is just to associate a device to a claimed
         address.

    * message flow diagam shows bootstrap of network.

    * now "Extended ARO" option

    * IESG review feedback:

         * use of EUI64 discouraged, should it be deprecated?

         * what happens when registry is full? (could be an attack)

         * what is the minimum number of addresses?

         * Dave Thaler: Eviction not possbile for addresses entrered through
         ARO. Is it a 6lo or 6man problem

         * Erik: only occurs with 6lo.

         * Dave: Therefore needs to be addressed in this WG.

         * Dave: min number of addresses? 2 or higher.

         * Pascal: need link local address, global based on EUI64 (used for
         registratino),
                   global based on non-revealing IID. So at least 3.

         * Dave: about 10. If multiple subnets, a few 10s.

         * Pascal:  3 is good enough for constrained network.

         * Suresh: Support for MUST 3, Support for SHOULD 10

         * Suresh: Transaction ID: unconfortable with the text. It says
         compatible with RPL and copies
                   the RPL text. Pick one, either a reference or a copy.

         * Pascal: was initially a pointer to 6550, changed it to a copy.

         * Suresh: fine, keep the text but dont say it's from 6550.

         * Gabriel (from the floor): hoping we do this independant of RPL.
         Should be self-contained,
            ie. copy-paste without reference to RPL.

         * Erik: agree with self-contained, but suggest to say " at the time of
         this writing, this
                 algorithm was identical to RPL".

         * Erik: state the origin, and let know what happens if RPL changes.

         * Pascal concludes: will copy text and not say its identical to 6550.

    * draft-ietf-6lo-ap-nd-06: C flag to say it contains crypto-ID.

    * reused second NS but with other options (CIPO and NPSO, derived from
    existing options)

    * algorithm was higly compute-intendive on the device. Iterate SHA until
    reached predertimend value of a few bits.

    * Spec no longer mandates that. For more security, use longer  key.

    * Mohit: would make sense to make it longer, how much: 128 and leave it
    there? not a lot of deployment experience

    * Pascal length limited to 256 by length filed. Is it enough?

    * remember that DAR doesn' t have options, therefore no option length. Only
    way to infer size of key is length of DAR. Will not be able to add anything
    else.

    * <skips backbone router sldies>

    * Pascal: is there opposition to document xxx ?

    * Samita: premature to ask for feedback at this time. Bring it to the list.

    * Pascal: for AP-ND, we need more work.

    * Samita: agreed, needs more discussion.

    * Pascal moves on to unaware-leaf draft.

    * Carsten: use internet technology. Host.

    * Pascal: leaf  Defined in 6550.

    * Carsten: this is not ROLL meeting.

    * Pascal: look at the slide or come to the meeting tomorrow morning

 draft-ietf-6lo-backbone-router-06:
     There was no real changes on this draft since last IETF - so it was
     skipped due to time crunch.

* 6lo NFC draft WG LC status update (Younghwan Choi , ETRI)

    * got 3 reviews. Now in WGLC.

    * Gabriel: please provide comment, including simply positive acks. This is
    useful.

*  Update on 6lowPAN Routing header lifetime                   Charlie Perkins

    * Header informs about deadline time for delivery. If not reached, can drop
    the packet. Maybe also rush
       delivery if approaching deadline

    * doc has been around for a year. Improved to include ASN, header
    compression

    * Implementation is OpenWSN.

    * Drop flag changed from SHOULD to MUST.

    * Think doc is ready, would appreciate more review. Approaching WGLC

[14:45]

*  6lo Applicability and Use Cases Updates                     Yong-Geun Hong

    * reiterates goal of document: help newcomer understand, help adaptation
    for L2 technnologies.

    * added G3-PLC scenario, updated MSTP.

    * now 7 technologies + 1 potential new one (LTE-M, will be removed from
    next revision since no IPv6 adaptation layer is needed).

    * goes through technologies and use cases.

    * believes draft is stable. Add more use cases?

    * Gabriel (from the floor): like the idea of removing stuff that does not
    belong at 6lo, such as LTE-M.
      What about Netricity?

    * Yong-Geun: this is PLC.

    * Bob: Netricity is now part of WiSUN.

[14:54]

* 6lo fragmentation design team (Thomas Watteyne)

    * Created at last IETF meeting - Team members are:
       Thomas Watteney, Carsten Bormann, Rahul Jadav, Pascal Thubert,
       Gorry Fairhurst, Gabriel Montenegro

    Problem statement

    * Original RFC 4944 proposed per-hop reassembly has problems (latency,
    reliability).

    * There are a few proposals to do fragment forwarding (Carsten, Pascal)

    * The goal of DT is to produce 2 documents:

          * informatinoal document to summarize state of the art, dicuss the
          limitations

          * proposed solution, normative

    draft-watteyne-6lo-minimal-fragment Carsten

    * Virtual Reassembly Buffer: not store data longer than you absolutely have
    to. Forward early.

    * still need buffer space for a few fragment, for Medium Access.

    * may have to wait for first few fragments if routing header is big

    * header increasing over route: put slack in first header, to accomdate for
    expansion.

    * Yasuyuki shows simulation results, comparing 4944 and minimal-fragment

    * contact him for more details

    * Samita (chair hat off): Which situation justifies one algorithm over the
    other?

    * Thomas: With infinite memory, doesn't make a difference. But with memory
    limitation, 4944 quickly looses packets.

    * Plan is to have 2 fragmentation 6lo documents and 1 lwig document for the
    implementation part.

[15:12]    draft-thubert-6lo-fragment-recovery          Pascal  Thubert

    * Main update is change in title : over the 10 years, things have evolved.
    Forwarding no longer in.
      Now only about Fragment Recovery

    * Forming forward and return pathes. Needs two of the VRBs described in
    Carsten's draft.

    * Bitmap in ACK, each bit acknowledges an individual fragment.

    * End to end signalling allows to sned abort condition and clean state
    along the path.

[15:18]

    * Gabriel: Thanks to the Design Team, providing good answers.

    * Gabriel: Does the DT want to address other issues?

    * Carsten: the regular WG work now starts based on these 3 drafts, they are
    not final.

    * Thomas: Some work to be done on the first 6lo doc. Let's not close the DT
    now.

    * Thomas: should we call for WG adoption or is this too early?

    * Suresh: regular process. Deliver the 3 docs, then ask for WG adoption

[15:22] 6lo interop F-interop project Benjamin T/Alain Rebault

    * KEREVAL lab 6lo interop plugtest is involved with European project
    F-interop which aims to develop and
      interoperability testing platform with WPAN

    * Benjamin and Alain participated in IETF hackathon with interop tests for
    RFC4944, RFC6282 and RFC6775

    * F-interop provide secure channel between two remote devices, and provides
    conformance analysis tool.

    * Aims at reducing cost of interop

    * Thomas: Phy layers?

    * Ben: 15.4 24. GHz

    * Rasbian, card plugged on Raspberry.

    * Samita: next time, please announce early so that peaple can make plans to
    attend the event

AOB ? none

[15:25] meeting ends