Minutes IETF98: 6lo
minutes-98-6lo-00

                       6lo WG,IETF 98 Meeting Minutes

Chairs: Samita Chakrabarti, Gabriel Montenegro
Secretary: James Woodyatt
Responsible AD: Suresh Krishnan
Technical Advisor: Ralph Droms
Minute takers: Dominique Barthel
Jabber scribe: Ines Robles
March 29, 2017
Chicago, USA

 6lo Chairs like to thank Dominique Barthel for note taking and Ines Robles for
 being jabber scribe.

  -------------------------------  meeting notes 
  -------------------------------------------
1. Introduction and  draft status are provided by the chairs. Gabriel
Montenegro went through
   the drafts one by one: 4 new RFCs since the last IETF.They are,
   RFC 7973 (draft-ietf-6lo-ethertype-request)
   RFC 8025 (draft-ietf-6lo-paging-dispatch)
   RFC 8065 (draft-ietf-6lo-privacy-considerations)
   RFC 8066 (draft-ietf-6lo-dispatch-iana-registry)

   The documents that are in IESG processing are:
    draft-ietf-6lo-dect-ule (AUTH 48)
    draft-ietf-6lo-6lobac-06 (RFC Editor's Queue)
    draft-kivinen-802-15-ie  (RFC editor's queue)

    Suresh (AD) mentions IE(information element) has been allocated by IEEE.
    There will be a minor update of the draft before publishing.

   Newly adopted drafts are:
    draft-ietf-6lo-rfc6775-update
    draft-ietf-6lo-use-cases

    * draft-ietf-6lo-mesh-link-establishment: No more interest from originating
    group, ZigBee NAN/Jupiter
      Mesh. The chairs are going to drop the document from the 6lo WG after
      confirming it on the mailing list and verifying with the co-authors.

2 IPv6 over NFC                                    Younghwan Choi
  https://tools.ietf.org/wg/6lo/draft-ietf-6lo-nfc-06 was presented by
  Younghawn Choi on updates and discussed comments from WG and NFC forum. The
  draft was reviewed by NFC forum, no more comments from NFC forum. The author
  likes to move to WGLC.

  Dave Thaler:IID generation changed as a result of previous meeting

  Pascal: Replacing 6 bit address with hashing function with fixed parameters.
  Scanning is still easy. How is it different? YC: offset. Dave: offset should
  be random to add entropy, not predictable. Gabriel: offset may not be a right
  name. Nonce would be better. Samita: need reviewers before WGLC. Pascal,
  Dave, would you volunteer? Pascal will do the reivew and Dave agreeed to
  review the final update.

3 IPv6 over Bluetooth Low Energy Mesh Networks        Carles Gomez
  https://tools.ietf.org/html/draft-ietf-6lo-blemesh-02
  Main updates: 6LN replaced by host. Clarification in header compression
  section. Implementation started. Compared to RFC7668 (IPv6 over BTLE), ND and
  HC need to be extended. Suresh: follow-up from BT SIG? Gabriel: yes. "mesh"
  name overload. Confirmed we don't need anything else from them to support
  this. Samita: clarify "host" and "6LN" distinction in the slide deck

  Hannes: draft refers to 4.1. But BT also works on a mesh.
  Gabriel: Absolutely, another mesh.
  Hannes: better to run IPv6 over their mesh?
  Gbriel: This is route-over. They're doing mesh-under.
  Kerry: Need supporting work from BT SIG?
  Gabriel: Nothingn new needed, this was confirmed by BT SIG.

4 6lo Applicability and Use Cases                     Yong-Geun Hong
  https://tools.ietf.org/html/draft-ietf-6lo-use-cases

  Update since IETF97: added one technology, 3 use cases, 2 authors.
  Now 8 link layer technologies. Possible LTE-MTC will be added.
  Gabriel: nobody working on LTE-MTC in this Group. We should limit ourselves,
  otherwise this dcument
           can grow indefinitely.
  YGH: Will be discussed tomorrow morning with LPWAN chairs.
  Alex Pelov: Explain the LTE-MTC for LoRa.
  YGH: backhaul for LoRa (nano?) gateway.
  The Yong-Geun continues with his questions, comments on the documents.
  Reviews comments were received from Samita. It restates goals for this
  document. next steps: work on comments. Discussion on whether LPWAN
  technologies belong to this draft. Security considerations, for each case or
  global?

  Suresh: repeat on question at previous meeting. IESG statement against this
  document. What is the archival
      value at this? Will be outdated quickly. This could go to the IESG and
      not get published. Could go to a Wiki, etc.
  Gabriel: Share that concern. One way to move forward would be to write
  security consideration to
           reduce the scope. Point at existing security considerations in other
           RFCs.
  Samita: Also had similar feeling that it would not pass IESG in its current
  form.
          Though it is good to have guidelines to pass on to non-IETF people.
          We also requested WiSun and Jupiter mesh to provide material.
          Document should be concise and to the point. She can help Yong-Geun
          to edit the document to reduce the content and define the scope.

5 An Update to 6LoWPAN ND                             Pascal Thubert

        https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-01
        https://tools.ietf.org/html/draft-ietf-6lo-ap-nd/
        https://tools.ietf.org/html/draft-ietf-6lo-backbone-router/

   Summary update:
   A set of 3 documents that work together on improving 6LoWPAN ND.
   6lo-ap-nd registers address on first-come first-served basis, avoiding
   identity stealing. Splits two functionalities into two documents (extended
   ARO and proxy registration) Behcet: ??? Authors think the work is stable,
   implemented, tested at ETSI interop. Suggest in-depth review and WGLC. [
   Pascal might be referring to rfc-6775-update and backbone-router drafts]
   Suresh: Not much in the way of comparison with other mechanisms. "better
   that SeND". Suggest to write a generic update document. Roadmap in this
   space is already very confusing. Difficult for people to figure out what to
   do.

   Suresh: want ot have the WG to have a discussion
   Erik N: Down the road, 6775-bis would be greater. In the meantime, better to
   have independant documents
           on each tweek for people to consider and express interest in. If put
           together too early, wil be more difficult to gauge what people agree
           on.
   Suresh: fine. But at some point, want to have clarity.
   Pascal: ok. But split documents makes it easier for other groups (securiy,
   ..) to review what they
           are interested in.
   Samita (asking Suresh): should the 3 docs be folded in one? Seems backbone
   should stay separate. Suresh: This is going to update 6775. Meaning of
   update is unclear (see also, replaces, ...). Need
           some clarity.
   Lorenzo: Applicability of 6lowpan-nd: specific to some link types, not
   general about 6lowpan. RFC7934
           says ... "Some link types may have requirements that override
           general recommendations". Unless explicitly stated, this document
           may violate RFC 7934 recommendations.
   Pascal: Will reference the RFC and general recommendations, and leave
   decision open to particular link
           technology. Device registers and then moves. ARO is not a request.
   Suresh:  PIO + Administrative stuff, Can we agree?
   Erik: Registration and DAD parts. We should figure out some clarifying text
   and make the intent clear
    * Lorenzo:
    * Pascal: If remove text about administrative stuff, will that solve the
    problem? * Lorenzo: defining way for network to say no, could cause a
    denial attack. * Pascal: if node moves, requests DAD from new place. We
    need to be able to remove state from first LBR. * Lorenzo: Problem is lots
    of codes (for negative answers). * Suresh: Loreenzo, don't take things too
    litterally. It is not like a request to get an address * Lorenzo: This
    would cover 802.11, if you read it. * Erik: should figure out some text to
    make clear that this should net be used to admistratively deny
            nodes to form an address.
    * Christian Huitema: privacy issue with addresses. Randomness in the
    address should not be prevented
      by AR mechanism. Compression for private addresses ?
    * Pascal: It can register anything.
    * Christian: Anything that reduces the space of allowed IIDs creates
    privacy issues. * Lorenzo: Doing ARO requests the network to provide
    service for you. If DAD fails because of,
      e.g. neighbor cache full, is the address still valid? Draws the line
      about what is a request and what is not.
    * Suresh: If node has 6lowpan ND and classic ND, node can still carry on
    with classic ND if ARO fails.
      Otherwise, cannot continue.
    * Lorezo: Do we know that 6lowpan ND and classic ND work together?
    * Suresh: No. Today, this is considered separate. IPv6 discussed
    efficient-nd some time ago,
      in order to address the interoperability between 6lowpan-nd style network
      and Classic ND.
    * Dave: support Erik's  comment.It (ARO) is treated similar to DAD. Add a
    text to say that should not be used to deny service. * Erik: This solution
    should help host to go to sleep, not prevent privacy. * Suresh: regarding
    mixed stuff, will discuss it at 6man. Not in scope for 6lo. * Gabriel
    (chair): we already had this discussion in Seoul. Make concerted effort to
    have text in
      place by Prague. Maybe a small design team.
    * Samita: we need reviewers for the 3 drafts, but after the authors and
    Lorenzo, Suresh, ... haved
      worked on the new text.

6 Packet Expiration Time in 6lo Routing Header        Charlie Perkins
  https://www.ietf.org/id/draft-lijo-6lo-expiration-time-01.txt
  The goal is to be able to remove fragments from buffer if there are no longer
  useful. It is a delay-aware operation. Decided to have elective header with
  origination time and expiration time. Potentially in different time units.
  The discussion goes through frame format. Gabriel: user-defined field value.
  How do you ensure interop? Charlie: don't have an answer.Systems may have
  different time systems. It needs a few editorial changes. Compressed time,
  should be care for ASN to better work with 6TiSCH? Kerry: time units. Hours?
  Charlie: The way it is, able to express pretty large values. Pascal: intent
  to use this mechanism to e.g. influence routing? This is a routing header.
  Charlie: could be, e.g. for voice traffic. Chairs: Who's read the draft?
  about 6. Samita: Please, read and provide comments.

7 Transmission of IPv6 Packets over PLC Networks      Jiangquiang Huo
  https://tools.ietf.org/html/draft-huo-6lo-plc-00
  First presentation of this draft.
  The presenter goes through brief intro to PLC. Several standards, some with
  MTU>1280, some with MTU<1280 The draft distinguishes cases, provides
  specification for fragmentation, header compression, L2 mesh header Future
  work: include more PLC standards?  Received comments from Samita and will
  update based on comments. Daniel Popa pointed at his expired draft on G3.
  Samita: Mesh connectivity diagram. Does PLC also support extended mesh? JH:
  this is an example. More topologies are possible. Like interconnected
  diamonds. Gabriel: two SDOs specifiying the link technology: one is ITU, one
  is IEEE. Do you work with tehm? Are they aware of this work? JH: indirect
  relations. Gabriel: we can help you establishing official relationship.
  Samita: We will help in connecting

8 Fragmentation in 6lo networks
  Samita: There are several contributions related to fragmentation in 6lo WG.
  Within the next 20-30 min,
          will have two presentations in order to discuss 6lo fragmentation
          issues and we seek WG opinions on whether the WG needs to work on the
          fragmentation issues and solutions.

 Updates to the FRAG draft                           Pascal Thubert
    Long history. Experiment in 6LoWPAN.
    6TiSCH has fragments. Need for this work.
    Juergen developped MIB to investigate slow 6LoWPAN network and discovered
    related to fragmentation/ressaembly. Julius xxx: have you considered ... ?
    Pascal: In mesh, fragments can follow different routes. An intermediate
    node may not receive all
     fragments even if everything is right. He goes through various issues with
     fragment forwarding.
      * proposes to remember some state from first fragment so that following
      fragments follow the same route. * explains forwarding strategies,
      optmisation. Label switching. * needs to clean-up state at intermediate
      nodes. Timeout or protocol.
    Julius: why do you need state? why not just blindly forward them?
    Pascal: First fragment has IP address. Need state so that next fragment
    follows the same route.
            L2 switching doesn't have this issue. we need a protocol, this
            cannot be solve by smart implementation
    Gabriel: Spell out which problems occur in route-over vs. mesh-under, with
    large packets vs. small,
               with fragments vs. packets.
    Pascal: This is a solution document for fragments in route-over mesh
    network. Not a requirement
            document. Not attempting to say why.That would be another document.
    Thomas W (remote): Without fragmentation, 6lowpan is almost unusable.
    Problems appear as
              soon as ou start fragmenting, even with small packets.
              Most implementation just drops fragments as their buffers fill
              up. Small memory. Buffer for one packet is over a
              Kbyte.Implementation will drop fragments of one packet as soon it
              receives a fragment belonging to another packet.
    Gabriel: I was asking about scoping the problem, not against the solution.
    Michael R: This work changes behaviour in all nodes of networks. What if
    some devices are slightly
               more capable than others?
    Thomas: confirm that netwrok can run with nodes that do and nodes that
    don't implement this? Pascal: yes. Confirmed. Ralph Droms: Transport area
    review is needed in order to make sure there is no transport layer issues
                 due to many fragments of the same packet
    Pascal: this presentation not about my draft.
    Ralph: have you done fragment retransmission work?
    Pascal: yes
    Samita: we're going to ask Suresh for recommendation for Transport area
    experts' review Carsten: Been discussing this for 8 years. Allocate time to
    do this. However, already solutions out
             there. Thomas says they are bad implementations out there. Can we
             fix the problems in the code or in the protocol?
    * Pascal: Protocol
    * Carsten: different views on the subject.
    * Suresh: if WG interested in this work, will get somebody from Transport
    to do a review.
       But more, define a cluster of problem, at next meeting will meet in a
       room to work on the problem.
    * chairs: How many people willing to work on fragmentation issues and
    solutions?
              count: 18 people

9 Optimized 6LoWPAN Fragmentation Header              Carles Gomez
   https://www.ietf.org/id/draft-gomez-6lo-optimized-fragmentation-header-00
   Reminds 4944 state of the art, L2 technology constraints.
   Describes proposal: fragment format. Requires allocating 16 dispatch values.
   This addresses compression of Fragmentation header
    Interest in WG?
   Suresh: how does the recipient know how much buffer it needs on receiving
   the first fragment? Carles: Not thought through yet. Suresh: Not just
   heuristic. Need to fail gracefully. Gabriel: Discussed this before. Carles:
   Maybe these points not so much an issue in some scenarios. Need feedback.
   Gabriel: who has read the draft? 5-6. Gabriel: not sure this belongs in this
   WG. Will open it to the mailing list.

10 IEEE 802.15.4 and related standards update          Pat Kinney
   A repeat of presentation done at 6TiSCH meeting yesterday.
   How IEEE works: amendments, revisions, corrigenda.
   15.4q: not interopoerable with other modulation modes.
   Most standards are coming out of 15.4 now have 2047 bytes MTUs, not just 127.
   Corrigendum on 64-bit MAC address transmission order: was changed in
   15.4-2015 to match Ethernet etc but broke 15.4. Changing it back. Next
   revision (incorporating corrigenda and amendments), approval anticipated May
   2019 . If you see corrections needed, send them now. 15.9 Key Management
   Protocol. Includes general purpose multiplex mechanism. Adds another
   fragmentation mechanism. 15.10:  Layer 2 routing. See link to tutorial in
   the slides. 15.12: upper layer interface for 15.4. 28 parameters to request
   a dataframe be sent with 15.4 (ethernet 4, 802.11 6). Simplfying this to
   maybe 6.
     also adds object management.
   Configuration: will define profiles. Makes it easier to switch
   configurations for different applications. Yand data models and Netconf.
   Netwrok management: Netconf. Pat calls for participation and reviews.
   Conference call, phycical meetings and conference.

11 6lo Plugfest interest and discussion
   Due to time constraints this discussion was skipped. Samita requested WG to
   contact 6lo-chairs, Carsten and Kerry for Prague 6lo Plugtest participation.

 end of meeting