[Roll] DRAFT minutes from IETF90 meeting

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 24 July 2014 14:46 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0F6B41A03BB for <roll@ietfa.amsl.com>; Thu, 24 Jul 2014 07:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.609
X-Spam-Level: ***
X-Spam-Status: No, score=3.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6, MANGLED_TOOL=2.3, MIME_NO_TEXT=2, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01, WEIRD_PORT=0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id pnlVxzkTaq2u for <roll@ietfa.amsl.com>; Thu, 24 Jul 2014 07:45:58 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7851A03B7 for <roll@ietf.org>; Thu, 24 Jul 2014 07:45:58 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F9EC20012 for <roll@ietf.org>; Thu, 24 Jul 2014 10:47:41 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id B192D63B0E; Thu, 24 Jul 2014 10:45:56 -0400 (EDT)
Received: from sandelman.ca (localhost []) by sandelman.ca (Postfix) with ESMTP id 9980163B0A for <roll@ietf.org>; Thu, 24 Jul 2014 10:45:56 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 24 Jul 2014 10:45:56 -0400
Message-ID: <13664.1406213156@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/w0Y_PNrh_5ihCcdolL-696bBC5Q
Subject: [Roll] DRAFT minutes from IETF90 meeting
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jul 2014 14:46:01 -0000

many thanks to Thomas.  Please /XXX for pieces that might need comment, here
they are:
    - Peter van der Stock indicated that you need control over <XXXX ????>.
      Changed SHOULD to MAY

    - [Pvds] can you send e-mail? XXXX
      (was re: Autonomic/ANIMA)

I'm not sure what "poipoi" means.

1300-1500 EDT Wednesday Afternoon Session I
Territories room

Agenda: https://datatracker.ietf.org/meeting/90/agenda/roll/
Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-roll
Meetecho (slides, audio, video): http://www.meetecho.com/ietf90/roll
Audio-only stream: http://ietf90streaming.dnsalias.net/ietf/ietf907.m3u

ROLL (Routing Over Low Power and Lossy Networks)


- State of all drafts (5min)
- Related Internet-Drafts
- State of all Issues (3min)
- Updates to Milestones, Schedule and Practice (5min)
- Feedback from Plugfest Event (5min)
- Updates on: draft-ietf-roll-security-threats (10min)
- Updates on: draft-ietf-roll-mpl-parameter-configuration (15min)
- Updates on: draft-ietf-roll-admin-local-policy (15min)
- Updates on: draft-ietf-roll-applicability-template. (5min)
- Updates on: draft-ietf-roll-applicability-ami (10min)
- Updates on: draft-thubert-6man-flow-label-for-rpl (15min)
- Open floor (15 minutes)


- _[1300]_ Meeting starts
    - **[Ines]** starts the meeting
    - reminds note well
    - meetecho available, minutes taken, Jabber as well
    - presents agenda

- _[1302]_ State of all drafts **(poipoi)**
    - Ines reminds status of drafts on sldies
    - Ines presents related I-D not adopted yet
    - Ines presents open tickets (see slides). Some work needed on the open
    - Ines presents milestones. Industrial applicability is behind.

    -Ines: need to decide whether nee to recharter or close.
           After work on MPL done,

- Related Internet-Drafts **(poipoi)**
    - poipoi
- _[1305]_ State of all Issues **(poipoi)**
    - poipoi
- _[1310]_ Updates to Milestones, Schedule and Practice **(poipoi)**
    - poipoi
- _[1315]_ Feedback from Plugfest Event **(poipoi)**
    - Thomas presents
      - Updates on: draft-ietf-roll-security-threats **(Michael Richardson)**
    - security applicability review.
      There was some lack of understanding amoung reviewers about the
      relationship between documents.  After some voice communications, we
      agreed that we needed to be more explicit about the relatinoship to
      other documents. Peter van der Stock proposed some text which is now in
      different documents
    - Michael presents threats document

    - secu area review about sec doc (september 2013). Very good reivew.
    Some tickets were opened. Lots got fixed. Robert Cragie found innaccuracies
    and things tha didn't make sense. Tickets got opened and fixed
    The -08 uploaded on Monday July 21. Use the diff tool to see the
    This document went through WGLC in Feb. Robert Cragie looked at it before
    sending to Adrian. Button pushed on Monday!!!!, should be discussed at
    IESG soon.  This has been a long (3 year) process.
    Will be nice to have done.

    - one of the things that came up is that we have a number of messages
      in ROLL which are important and multicast.
      From DICE, we know that secuirty multicast is tricky.
      With symmetric keying, members can impersonate.  Pieces in ROLL are not
      as strong as they could be as a result.
    -We clarified some of the text. Affects people that have a group-shared L2 key
    which is the same across the entire network. If you have a L2 master key
    from which link messags are derived, you can do something different.
    Ultimately, when multicast, you need to use key that all can read.
    This is something we clarified.
      - although DISare multicast, it's a "please answer me".
        The effect is that a timer goes faster. Not a huge deal if impersonated.
    - DIOs, if they are impersonated, that's an issue.
      One of the defenses is that is to unicast a DIS back, so mote sends a
      DIO again.   There is a workaround for the paranoid.

(Ines reminds about blue sheets)

- Updates on: draft-ietf-roll-mpl-parameter-configuration **(Yusuke Doi)**
    - draft tp [ropose DHLC option to configureMPL
    - idea: control MPL. Used in smart meter network. Intended for slow
      update of MPL forwarded. Because MPL trickle algo has control between
      network usage and MPLlatency,this is a tradeoff.

     -parameter should be modifiable.

    - updated the draft to -01 weeks before the IETF meeting.
      Asking ROLL and DHC WG for feedback. DHC gave feedback.
      -02 on Monday.
    - operational considerations were added. What happens when
       MPL parameters were changes when MPL network is running
    - Peter van der Stock indicated that you need control over <XXXX ????>.
      Changed SHOULD to MAY

    - Asks WG for feedback. Please give review on these sentences

    -last week, lots of feedback from DHC. Most concern idea to make timer
      in floating point. Didn't like that. Changed the format, simplified.
    - Yusuke presents the format of the packets. the unit of the time is
       added to the packet. e.g.of tunit is 100,timer is 100ms. timers in uint16
      - [MR] like floating point, but easily absorbed?
      - [YD] encoding is simple
      - [MR] for unknown options on DHCP server,people will have to calculate
      the hex anyway...
      - [YD] believe almost all implementers don't need to worry about
        this. Wrote Python code to generate this
    - mostly clients have to worry about this
    - very simple and straight forwards. Needs experience and feedback on
       range fo timers
    - current specification is only able to go up to 4.6 hours.
      Not sure if enough for all of usages, including expiration timers.
      If we need larger duration, need to think again on these timers
    - message: please give meyour feedback.
    - <no feedback from the room>
    - Ines asks to read the drafts and comment on ML

- _[1325]_ Updates on: draft-ietf-roll-admin-local-policy
           **(Peter van der Stok)**
    - draft is about having admin local be automatically determined
    - multiple: realm-local scope, link-local and admin-local
    - different topologies possible
    - linklocal scope: automatically determined, single hop
    -real: local: automatically, determined by L2
    - admin-local: multiple hop, include different L2 networks.
    - wish is that it would be automatically discovered
    - idea is that we have 2 router: one standard, and one router has MPL
         router with MPL forwarded. They all subscribe to ALL_MPL_FORWARDER scope 3
         and 4
    - about MPL routers, assuming R1 and R2, assuming they have 2 mesh
      What we want to do is have an MPL scope which includes mesh
        networks but excludes <the enterprise/home/etc.>
    - introduce boolean flag call MPL blocked.
    - we use protocol to determine whether should be true or false
    - start with MPLlock false. at least every hour, send an MPL message to
      MPL_FORWARDEDS_SCOPE. If no get message back, no interested nodes on that
    - query for nodes are interested, if none, close and don't use
    - result is that some interfaces are enabled (to the mesh),
      disabled (to the Northbound)
    - allows to automatically determine MPL zone
    -if you have an egde router, you should false interface to block
    - [Pascal]flow reminds in autonomic, see BoF.Encourages to ANIMA.
          Probably you could propose this there.
    - [Pvds] can you send e-mail? XXXX
    - [Michael] could you derive the 1h period, i.e. 3 Imax. If it
             can't maybe you have a new parameters forthat other doc.
    - [Pvds] good suggested
    - need also security section

- _[1400]_ Updates on: draft-ietf-roll-applicability-template.
 - see beginning

- Updates on: draft-ietf-roll-applicability-ami **(Daniel Popa)**
    - daniel indicates what changed . Sections 9-1, 9-2, 10, 7.2.2
    - [Micheal] which issues are open?
    - [Daniel] open tickets:
        - #135, missed pointer to security section of RFC6550
           - #136 add a section on security consideration when RPL security
                  mechanisms are not used
           - #137 incorporate a model for initial and incremental
                  deployments. Added section 9.1. and 9.2. For #136
                  and #137 will ask the WG to what we can change in the
                  draft on what we can change
    - [Michael] excellent

- _[1415]_ Updates on: draft-thubert-6man-flow-label-for-rpl **(poipoi)**
    - when started RPL, idea what to transport Hop by hop in flow label.
      6man was redefining how it wouldoperate. At roll, we created hop by hop
      header in RFC6583. Header cannot be compressed
    - if a frame is coming from outside the RPL domain, you need to
      encapsulate the packet in IP-in-IP to be able to send back ICMP error and be
      able to strip it
    - these are many bit that we don't want to 802.15.4-2006 MAC
    - when worked in ISA100.11a, worked hard to eliminate in single bit. Real
      war to remove UDP checksum. Just for 2 bytes. This was key to the adoption
      of 6LoWPAN.
    - here, we are talking about 5+ octets: not acceptable
    - what important in 6282 compressed in the 2 bits which indicates how
      6LoWPAN compresses the flow label and traffic class. we can have flow label
      with or without DSCP

    - proposed encoding fits in the 20 bits of the flow label. We are
      to replace 5 bytes by 20 bits. Rank expressed as 8 bites. You need to have a
      deployment with a min hop of 256.
    -[Michael]you are using upper 8 bits of rank?
    - [PT] yes. You can compress the rank in single octet. Described in
           OF0, operates wih minhop rank of 256
    - RPL was prepared for this. Text says that 6583 is only one was. WE went
      to ROLL and 6man with this. Brian Carpenter has good response. Idea is to
      have a WGLC in this group, then a confirmation WGLC from 6man to make sure
      they agree.
    - if a packet has to come from the outside, it's responsibility of the
      root to add flow label that makes sense
    - Adrian was help out
    - draft has been out there for year.
    - [MR] feeling is that this is something we should adopt and seems that we
           can close to WGLC even with this document. Pascal, agree?
    - [PT] yes, different revisions from different WGs
    - [MR] is there a technical reason to adopt before publshing?
    - [Adrian] yes you can, the WG can support a draft with a name that
               doesn't start with WG name. People who think you should not be working
    - [Michael] will write line in charter?  Will talk to 6man chairs
                to make sure
    - [PK] chair fo ISA100.11a. Fought over every bytes. As vice chair of
           802.15, there is a reason why we don't haev longer packets. Shorter packets
           means less energy and better probability. Both hats say that this is what
           we need
    - [Pascal] we have running code for thos, Xavi demonstration de draft on
           OpenWSN implementation. Screenshot indicate wireshark,. You don't have a
           H2H header, was implemented very rapidly in OpenWSN

- _[1448]_ Open floor **(poipoi)**
    - Ines asks AOB
    - Pascal: we are working at 6TiSCH how a pure 6LoWPAN client can be a
    leaf in a RPLnetwork. Today, all devices have to have code specific to RPL.
    A better idea is that you have what is necessary in 6LoWPAN, so that6LoPWAN
    device can be a lieaf of a RPL network. THere is a need for a classical IP
    host and moile hist. Invite you to 6lo.
    - as we work on 6TiSCH, there is a case where a node moves.
    We would have work on how to clean upstate route. Aswechartered?
    - [MR] cleaning up stale motes is in charter, but depends on milestones.
         Let's take to ML to have a better understanding on what this means. The
         question is what the impact is on node which don' have the code.
    - [Pascal] additional functionality
    =[MR] then this might fit in maintenance.
    - [MR]any other elements in open mic?
    - [Peter] will there be any other ROLL meetrings?
    =- [MR] opinion is that not in Honolulu. We have the home automation,
        threads, and AMI document which seems close to done. Unless we do somethng
        that expands the charter, don't see a reason to meet again before closing
        the WG. Of course, AD could put WG in maintenant mode.  Maybe will becomes
        controversial and we need F2F meeting.
    - [PT]what would help you make that decision? 6TiSCH might come up with
          elements, and we would need ROLL to be there.
    - [MR]good idea, send question. We could go in hibernation and resume
          when needed.
    - [PT] plan is to fire a number of drafts, and when
    - [MR] better now than in december
    - [Ultich] personally, don't feel 6lo is right WG because not
            always RPL.
    - [MR] we could go to the routing Area WG
    - [Adrain] good point. It's ok for WG to say that shut down. It's nicer
           to close the WG and create a new WG when needed. Not a good idea to have WG
           sitting around. AD can sponsor documents. Do we need a forum for discussion
           and driving the work? If yes, we'll create a spacefor it.
    - [Ines] there were e-mails about open topics. We need to work on
             issues before rechartering/closing.

Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/