Minutes IETF99: roll
Routing Over Low power and Lossy networks
||Minutes IETF99: roll
Agenda of the ROLL WG
Date:Thursday, July 20, 2017 (CEST)
Time: 13:30-15:30 Thursday Afternoon session I : 120 minutes
Topic to Present
Presenter ROLL Status meeting - (10 min.)
-----> Peter/Ines RPL-info (20 min.) -
Multicast-Bier (20 min.) - draft-ietf-roll-ccast
No-Path DAO (15 min.) - draft-ietf-roll-efficient-npdao
AODV-RPL - (15 min.) - draft-ietf-roll-aodv-rpl
Load Balancing - (15 min.) - draft-hou-roll-rpl-parent-selection
DAO-projection - (20 min.) - draft-ietf-roll-dao-projection
Q&A (5 min.)
[13:32] meeting starts
Ines Note well, agenda
shows list of milestones
be aware 2 drafts have IPR
shows list of tickets
[13:33] Michael Richardson presenting Use of RPL info draft
The draft has been completely rewritten. Not as simple as met the eye at first
writing. Thanks to Mike Heard for his constructive comments, including radical
changes. Also text clarification.
Why update 6553? we changed the bits on the wire because of trouble adding /
substracting headers for devices that do not speak RPL. To accommodate the pure
need we'd have to have a transport hop by hop, with decap, encap. So we decided
that the control bits in the option type should clarify that if the option ion
HbH is not understood (or if the device is not configure to care for the
option) the option may be ignored. RPI is now option 0x23. Then came changes to
2460bis. Introduced the behaviour we wanted. Now update 6553: processing of HyH
Option is now optional.
Pascal: compress the outer IP header makes it very cheap.
Michael : adding 6LoRH created a flag day. We are surfing that flag day. so the
introduction of 0x23 can be synchronized. Use a DIO option for telling nodes to
uses the new code. Pascal: Configuration Option could be used for that. MCR:
good point. Will do. Should we bother? Pascal: what if device reboots? will use
0x63 again until sees the option again. MCR: if reboots, need to hear a parent
anyway. New nodes will accept 0x232 and 0x63. Only question is which one to
transmit. Pascal: option may not be present in all DIOs. Rahul: persistent
storage expected anyway for other reasons. Pascal: all right. Persistent
storage is expected. MCR: Flag day option useful? very little response, no
opposition MCR: Should we change from 0x63 to 0x23? 6 hands. No opposed.
Juliusz: can you please explain the rationale to use 0x63 initially? MCR: if
nodes in DODAG also connected through other links and packets going through the
wrong interface, drop packet. But in reality, we can't remove packet without
Pascal: MCR forgot to say: nodes on non-RPL network would forward the packet
and potentially inject them back into the RPL network. That would be a problem.
MCR: inital experimenter ... This draft explicitly created to document what to
do with these headers, so many cases. Pascal: we are clarifying that ... is
not an option. Was a problem with the initial Contiki implementation. MCR:
summary: .. we'll add text clarifying reboot assumption. Peter: we'll have a
new version and do WGLC on that. Inès: please read the new version when it's
[13:57] Carsten Source-Routed Multicast for RPL
Multicast doesn't work in our networks.
Still want to make it work. Several solutions: MPL for storing mode, untested.
In non-storing mode. Nodes need to know they are members down the tree. But
don't want to store the state. Embedding an outgoing interface list does not
work. Bier: Pascal: see BIER-TE (Traffic Engineering) similar to this concept.
Bloom filters: seemingly natural solution. Has been around for long time. Uses
hash functions. Nodes check their outgoing interface against bloom filter to
decide to send. False positives introduces some inefficiency. Showed damage is
not too large. Uses a Multicast listener option similar to a DAO. Pascal:
Carsten makes two points: selection of next hop and compression of route
description. Orthogonal to each other. Carsten: root has knowledge of network,
is in a good position to make good decision. Use a 6LoRH option to carry this
field (see draft by Pascal), not RPL option in IP-in-IP packet. Implemented in
2013 on Contiki to play with it. Industrial implementation coming up soon.
[14:11] Pascal BIER/RPL
remember two angles : storing mode and representation with individual bits.
Could be translated to Bloom filters with usual pros and cons. (e.g. distribute
the hash functions). RPL builds preferred tree, install multicast through it.
BIER has a bitmap, bit set for each node to receive the multicast. Several
options on the allocation of bits (static, local automatic allocation,
6LBR-assigned). MCR: does 6LBR know stuff that makes allocation significantly
better? Pascal: will show in next slide. With BIER, need state for each
immediate child, which is the size of neighbor cache. DAO aggregation going up
is OR operation on bitmap. Destination can be one bit (unicast) or multiple
bits (multicast). Bloom makes this more elastic. Carsten: assuming 256 bis in
bit map, this would limit network to 256 nodes. Pascal: not quite. There's a
notion of groups in BIER. Carsten: Bloom filters change two things. Describe
forwarders, not destinations. And ... Juliusz: why do you index forwarders in
one case, and destinations in the other case? Pascal: vertices or edges.
Juliusz: what would be the advantage of index the vertices? Pascal: in my spare
slides. In storing mode, less vertices than edges to leaf nodes MCR: taken
multicast and used it to simplify unicast. You have optimized storing mode.
Peter: how are we going forward with these documents ???: Pascal: need some
free bits to not allocate old bits to new node until sure old node is gone.
Peter: running late Ines: please bring this to the mailing list
Pascal: now reliable multicast. ACKs aggregate exactly like the DAO, through an
OR operation. Retransmission map simply built out of previous map, "minus"
(==XOR) the ACK map. Ines: please write this draft just for me :-)
[14:33] Rahul Jadhav, Efficient No-Path DAO for RPL storing MOP
Issue presented at Chicago. Recap here. NPDAO needs to go down.
Contiki implementation done.
MCR: we have enough type code for you to ask for a new type code. No drought of
numbers. Cleaner. keep same structure, just other semantics. Pascal: would feel
more confident with new code, just to make sure not mis-interpreted by old
nodes. Psacal: we should not be repairing routes that are not used. RPI is
meant for that, discover and fix situations on the spot. Pascal: put the right
words of caution, how to use your mechanism wisely. Rahul: actually situation
improved. Pascal: if no traffic, not improved. Rahul: neighbor churn and other
cases described in the draft. Zhao : concurs to add explanation to the draft on
when to use it. Ines: please send comments to Rahul's draft on the mailing list.
[14:43] Charlie Perkins AODV-RPL implementation
No significant change to the draft.
Should AODV-RPL specify non-storing mode?
Messages much smaller in storing mode.
Should put non-storing mode in same of different draft? But should do
non-storing mode at all? Peter: does the audience think non-storing mode should
be done? no hands. Peter: opposite question. No hands. Charlie: principle of
inertia. Will not do it and not suggest it any more unless significant
interest. Currently assumes links are symmetric. Pascal: would like to keep the
asymmetric capability. Should routes have a lifetime? issue was brought up on
the mailing list. Peter: let's wait. Draft ready for last call (since not much
left to do) Implementation on github.com/lavanyahm Ines: who is willing to read
and comment on the document? 3 hands Ines: please add to the draft more
information on AODV security.
[14:53] Jianqiang Hou Parent selection
Two problems motivated this work.
Randomly Unbalanced Networks (has been described in IETF98).
Goal to balance number of children. Indirect way of balancing traffic, in case
nodes send same amount of traffic. Pascal: (regarding side 4) traffic comes
form leaves, not children. If you want to balance traffic, use something that
is related to traffic, not children. Proposed solution computes number of
children from Neighbor Table, combine this metric with other
metrics/constraints (like ETX, ...) proposes new metric in DMC, called CNC for
Child Node Count. Comparison with draft-qasem-roll-rpl-load-balancing, which
puts node address in DIO option. Pascal: we have discussed for a long time at
6TiSCH a willingness to join the DODAG. Select a Join Proxy. Willingness to be
chosen as Join Proxy, very abstract. Metric expressing this willingness should
come from the top (the DAGROOT), propagating down can already reduce
willingness. Nothing to do with the Rank. You MUST NOT mix the two because the
semantic is very different. There has to be a Join Function, similar to the
Objective Function. Jianqiang: good suggestion. But if Root controls
everything, will take time for the network to converge. Diego: other problem
with this proposal. If child count limit, a node may be left alone. Jianqiang:
in storing mode, use DAO. In non-storing mode, use NS+ARO. Ines: please read
draft and send comments to mailing list.
[15:08] Pascal Thubert DAO Projection
This draft brings SDN into RPL.
creates a tunnel into the network.
Rewrote the draft following Rahul's proposal.
Initially would send DAO with a via option to the exit point of the tunnel.
Now multiple via options.
Questions to the audience:
Rahul asked about loop avoidance with all this, in particular loose and not
end-to-end route. Answer is to use the O bit (dataplane validation). Pascal
shows example of tunnel installation across network. Data packets will use SRH.
Case from leaf node to leaf node could be done as well. Peter: could this use
bitmap as shown at the beginning of the meeting? Pascal: yes it can. Ines: who
is willing to review this doc? 3 hands (Diego, Rahul, ...)
Peter: we'll keep working on these drafts and move them forward.
Ines: no more question?
[15:20] meeting ends