ROLL Working Group Meeting Minutes - IETF-73 - Minneapolis Many Thanks to M.B. anand and Laurent Montini for the notes. Agenda ###### 1) Agenda/admin (Chairs - 5mn) [5] 2) Charter Review and Milestones (Chairs - 5 mn) [10] 3) Update of the Interim WG ROLL Meeting in San Jose (Chairs - 5mn) [15] 4) Update on the routing requirement solutions (in LC) (Several - 15 mn) [35] draft-ietf-roll-home-routing-reqs-00 (Anders - 5mn) draft-ietf-roll-indus-routing-reqs (Kris - 5mn) draft-ietf-roll-urban-routing-reqs (Dominique - 5mn) 5) Building Automation Routing Requirements (Jerry - 10mn) [45] draft-ietf-roll-building-routing-reqs 6) Update on the Routing Metrics document (JP - 5mn) [50] draft-mjkim-roll-routing-metrics 7) Discussion on Routing Metrics (All - 10mn) [60] 8) Discussion: "Do we need to start protocol work ?" (All - 10mn) [70] 9) Discussion on Re-chartering (All - 10mn) [80] Minutes ####### 1) Agenda/admin (Chairs - 5mn) [5] 2) Charter Review and Milestones (Chairs - 5 mn) [10] 1. Called to order 2. Comments invited on Agenda - no comments 3. Document progress report from JP - urban requirements publication has been requested - two new WG documents since last mtg.: terminology & building routing requirements - Excellent progress made by the Working Group and thanks to all the authors of the requirements documents who brough deep knowledge in the field on the requirements. - Still there is a sense of urgency: we need to quickly come up with a routing solution for these networks. 4. Milestone report on work items presented by JP (see the slides) 3) Update of the Interim WG ROLL Meeting in San Jose (Chairs - 5mn) [15] JP> Update on ROLL interim meeting held Oct. 2008. The meeting was devoted to discussing protocol survey document and consensus reached subsequently on mailing list that no existing protocol would meet ROLL requirements JP (to the room)> You can still comment if you disagree. Anybody disagreeing ? No comment from the room. Arlesan> Short update on protocol survey document presented - small change on control cost criteria causing some changes to treatment of RIP. But end result stayed the same. Changes are reflected in the current version of the protocol survey draft. 4) Update on the routing requirement solutions (in LC) (Several - 15 mn) [35] draft-ietf-roll-home-routing-reqs-00 (Anders - 5mn) draft-ietf-roll-indus-routing-reqs (Kris - 5mn) draft-ietf-roll-urban-routing-reqs (Dominique - 5mn) A. HOME - terminology updates, security section trimming to routing only, groupcast removed - Publication request shortly B. INDUSTRIAL - Some changes to the MUSTs in the routing requirements - The document is currently in Working Group Last Call - Important change: we must have a mechanism to link L4 to L3 to L2 capabilities C. URBAN - Publication Requested - Changes to conform to terminology draft, taxonomy - Small changes to security section - Some text moved around Dave Ward (AD)> Make sure things needed from the routing systems for debugging etc. are documented somewhere. JP> Management issues are covered in the requirement documents but the discussion about debugging tools will be included in the routing architecture document. 6) Update on the Routing Metrics document (JP - 5mn) [50] draft-mjkim-roll-routing-metrics and 7) Discussion on Routing Metrics (All - 10mn) [60] 9. Update on metrics document JP> - We have to be very cautious about metrics. The idea was to get all candidate in first release knowing lot of them will be removed long discussion about load energy (power or battery energy): flags, ... node workload: expecting one bit is sufficient latency: agreed should be removed; less useful than path latency - Discussion on link bi-directionality - agreement that allowing asymmetric links could make for huge complication - JP still pointed out that unidirectional routing is a strong properties of currnt protocols and bi-directional constraints can lead to sub-optimal path or no path at all. - Discussion on residual energy metric, still some more discussion to do: do we need scalars, a few thresholds, .. more on the mailing list. - Agreed to remove node degree - Discussion on aggregation, still some more discussion to do. JP> Note that we are defining the metrics that MUST be supported by the protocol, which of course does not mean that every instantiation of the protocol will have to use all metrics. Some metrics may not be suitable to specific environments. - Would like to work on metrics in parallell with protocols 5) Building Automation Routing Requirements (Jerry - 10mn) [45] draft-ietf-roll-building-routing-reqs - initial document had a lot of valuable information about the application space but extraneous to routing - scoped and focused document on routing 8) Discussion: "Do we need to start protocol work ?" (All - 10mn) [70] 9) Discussion on Re-chartering (All - 10mn) [80] JP (to Dave Ward and the room) Here are the proposed next steps - Make quick progress on building routing requirements in order to Last Call fairly soon - The industrial routing requirements should be done soon (in Last Call). Plan is to request publication very soon - At that time, all routing requirements will be done - Start a WG Last Call on the protocol survey right after Minneapolis - Chairs will document the WG consensus on the fact that no existing routing protocols exist - First WG document on routing metrics and security framework to be submitted before end of Dec. - Start re-chartering process to do protocol work JP> Does that make sense Dave ? Dave Ward> Sure. 12. Question on multivariable calculations - answer that computation is not really a problem, but memory and communication exchange will be the problem Dave Ward> What is the expense of overhead calculation? David Culler> Some sensors have lot of computing power - memory and keep table current is challenging Most of protocols exchange very little info; lots of non-IP protocol that works done outside IETF things have been proven to work but agreed resolve very limited set of problems Dave Ward> When going to recharter need to get a simplified, reduced instead of fantasy WG JP> There are already many different proprietary algorithms or open source that work. And YES ! we are very agreeing that things need to get a simple as possible, we have made a thourough analysis of the requirements, we have the right skills in the WG. Note that looking at the set of proprietary protocols out there, that gives an idea of the urgency and the ability to based work on existing routing experiences JP> Meeting ajourned.