Re: [Roll] DRAFT minutes from IETF90 meeting
Thomas Watteyne <watteyne@eecs.berkeley.edu> Thu, 24 July 2014 15:02 UTC
Return-Path: <twatteyne@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72171A03D6 for <roll@ietfa.amsl.com>; Thu, 24 Jul 2014 08:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.224
X-Spam-Level: **
X-Spam-Status: No, score=2.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6, MANGLED_TOOL=2.3, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTrGA9sK7d4Y for <roll@ietfa.amsl.com>; Thu, 24 Jul 2014 08:02:39 -0700 (PDT)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04AB1A03F7 for <roll@ietf.org>; Thu, 24 Jul 2014 08:01:53 -0700 (PDT)
Received: by mail-pd0-f178.google.com with SMTP id w10so3786666pde.23 for <roll@ietf.org>; Thu, 24 Jul 2014 08:01:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=ZAsCg+53bNBF/ytDmMSdMhNA942O9jJXA4Uou2ZfKzc=; b=UxXuUqxEBOkNce3prsYAxTSMNCBYeo6F3KRl6tlQOEgQmeIZ7pGIjdg3YUGX9ipgm3 8LN4hkOPJMB8rmmPom4oFQqj47C0xHZCql3WfFvwtEJPOytF5hAm3k+gjLB6rIo1qxjZ 3R8OVk9bPrbhXT3f/g0cIKG9wxG2Dipv+1ot54C61yp33P48tznr/ubOAeDZ/YQWLiS+ OBh6y926Bcs6+e2petkMgyq6kTSF4l0MTPcnVucX6H5pI1AjMNWrZUuxb2an+pBPu4Tj +7A+ihma12e0A10J1cWu+D+AHQyqLxXA8Jx6WR+unRVQynddOcmAroHPPB1OGbd7A8kt eQaw==
X-Received: by 10.68.68.133 with SMTP id w5mr3277410pbt.166.1406214113175; Thu, 24 Jul 2014 08:01:53 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.144.1 with HTTP; Thu, 24 Jul 2014 08:01:32 -0700 (PDT)
In-Reply-To: <13664.1406213156@sandelman.ca>
References: <13664.1406213156@sandelman.ca>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Thu, 24 Jul 2014 11:01:32 -0400
X-Google-Sender-Auth: K_JJx_qSrEgdyaY_L9NN6IPavRg
Message-ID: <CADJ9OA9tNZYLjmHNneYQbM0qVo09wnRXAo58AkQT1sGZQpTPiw@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c3e352b1af9104fef1bc60"
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ernYsi0oB2V-zoA7sZb49GfCxAg
Subject: Re: [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 15:02:43 -0000
Michael, These are the raw notes at the end of the meeting. "poipoi" is just a placeholder. Thomas On Thu, Jul 24, 2014 at 10:45 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote: > > 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) > > Agenda > ------ > > - 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) > > 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 > tickets. > - 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 > changes. > 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 > networks > 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 > line, > - 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>, Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > >
- [Roll] DRAFT minutes from IETF90 meeting Michael Richardson
- Re: [Roll] DRAFT minutes from IETF90 meeting Thomas Watteyne
- Re: [Roll] DRAFT minutes from IETF90 meeting peter van der Stok
- Re: [Roll] DRAFT minutes from IETF90 meeting Ines Robles