1300-1500 EDT Wednesday Afternoon Session I Territories room Slides: http://www.ietf.org/proceedings/90/slides/slides-90-roll-5.pdf 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://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF90_ROLL&chapter=chapter_0 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-applicability-template. (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-ami (10min) - Updates on: draft-thubert-6man-flow-label-for-rpl (15min) - Open floor (15 minutes) Minute taker: Thomas Watteyne ( Million Thanks Thomas!) Minutes -- To be Updated with Audio ------- - _[1300]_ Meeting starts -Slide 1-4 **[Ines]** starts the meeting - reminds note well - meetecho available, minutes taken, Jabber as well - presents agenda - _[1302]_ State of all drafts **(Ines)** - Slide 5 Ines reminds status of drafts on slides - 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, - Slide 6 Related Internet-Drafts **(Ines)** - _[1305]_ Slide 7-8 State of all Issues **(Ines)** - _[1310]_ Slide 9-10 Updates to Milestones, Schedule and Practice **(Ines)** - _[1315]_ Feedback from Plugfest Event **(Thomas Watteyne)** -Slide 11-19 Thomas presents goal, participants, description of the PlugFest IETF 90 - _[1320]- Updates on: draft-ietf-roll-applicability-template. (Michael Richardson)** (5min) review. Slide 21 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 _[1325]--Updates on: draft-ietf-roll-security-threats **(Michael Richardson)**(10min) review. -Slide 22 Michael presents threats document -Slide 23 -Ssecu area review about sec doc (september 2013). Very good review. Some tickets were opened. Lots got fixed. Robert Cragie (Doc. Shepherd) found innaccuracies and things that 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. - Slide 24- 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 security 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) - [13.35] Updates on: draft-ietf-roll-mpl-parameter-configuration **(Yusuke Doi)** (15min) review. - Slide 25 - draft tp propose 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 modificable. - Slide 26 - 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 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. - Slide 27 - 28 --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 unit16 - [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. - - Ines asks to read the drafts and comment on ML Skip the additional slides. - _- _[13.50]_ Updates on: draft-ietf-roll-admin-local-policy **(Peter van der Stok)** (15min) review - Slide 38: 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. - wich is that it would be automatically discovered - Slide 39 -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 - Slide 40 -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 - Slide 41- introduce boolean flag call MPL blocked. - we use protocol to determine whether should be true or false - Slide 42 - 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 - Slide 43: -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. look into it. - [Pvds] Thank you very much - [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 [14.10]- Updates on: draft-ietf-roll-applicability-ami **(Daniel Popa)** 5 min review - Slide 45: Daniel indicates what changed . Sections 9-1, 9-2, 10, 7.2.2 - [Michael] which issues are open? - [Daniel] open tickets: Slide 7 - #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 They are almost fixing the issues. - [Michael] excellent - _[1425]_ Updates on: draft-thubert-6man-flow-label-for-rpl **(Pascal Thubert)** 15 min review - Slide 48: 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 - Slide 49: 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 - Slide 50-51: 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 - Slide 52-53: 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 - Slide 54: 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 publishing? - [Adrian] yes you can, the WG can support a draft with a name that doesn't start with WG name. - [Michael] will write line in charter? Will talk to 6man chairs to make sure, today. - [PK] chair fo ISA100.11a. Fought over every bytes. As vice chair of 802.15, there is a reason why we don't have 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 **(15min review)** - Slide 57: 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 leaf of a RPL network. There is a need for a classical IP host and moile host. Invite you to 6lo. - [Ines] please send email to ML. - as we work on 6TiSCH, there is a case where a node moves. We would have work on how to clean upstate route. As we chartered? - [MR] cleaning up stale motes is in charter, but depends on milestones. Let's back to ML to have a better understanding on what this means. The question is what the impact is on node which don't 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 meeting? =- [MR] opinion is that not in Honolulu. We have the home automation, secutity-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] look at drafts, plan is to fire a number of drafts, - [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 for maintenance. - [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, threads about open topics. We need to work on the open issues before rechartering/closing.