Minutes IETF100: roll
Routing Over Low power and Lossy networks
||Minutes IETF100: roll
Agenda of the ROLL WG meeting
Date: Wednesday, November 15, 2017
Time: 13:30-15:00 Wednesday Afternoon session I : 90 minutes
Presenter ROLL Status meeting - (5 min.)
-----> Peter/Ines RPL-info (10 min.) -
draft-ietf-roll-useofrplinfo -----> Ines No-Path DAO (10
min.) - draft-ietf-roll-efficient-npdao -----> Rahul
DAO-projection (5 min.) - draft-ietf-roll-dao-projection ------>
Pascal Discussion on new work and relations (15 min)
------> chairs + WG Load Balancing - (15 min.) -
draft-qasem-roll-rpl-load-balancing ------> Mamoun RPL DAG Metric (10
min) draft-pkm-roll-nsa-extension ------> Georgios Fast
reroute (15 min) - draft TBD ------>
Pascal Q&A (5 min.)
[13:31] Meeting starts
[13:31] ROLL Working Group status (Peter/Ines)
[13:32] Use of RPL info (Ines)
rationale of the proposed changes is presented.
new RPI option in network. Advertise its use in DIO option.
Question: should this WG work on avoiding a flag day?
Pascal: only operational deployement known are W-HART, WiSUN, ... Consortia
decide which RFCs are observed. Certification process defines packages. Don't
mind of Flag Day. Rahul: might be nodes left in the network with the older
document is in WGLC. Please read and comment. Volunteers for review (of flag
day part)? Rahul, Georgios, Pascal. Peter: please do read and comment on the
ML. WGLC ends today. Also 6man to be involved
[13:39] No-Path DAO (rahul)
reminds of the problem and solution (already presented at previous IETF
meetings) decided to create new RPL message (plenty of codes available)
no longer a flag for DAO to go down.
Also ACK to go with it.
Also secure version of them both.
Who read the draft? 5 hands. Who will review? Charlie, Pascal, Mamoun.
Working code? Yes. Deployement? a pilot.
No open-source code yet available with this feature.
[13:45] DAO projection
added Non-storing mode.
Most of the work in next presentation.
Rahul: Fast Reroute should be a separate document
Pascal: are you willing to contribute?
[14:48] Discussion on new work and relations (chairs + WG)
Goal of this is to review work on our plate and discuss way forward.
Classified with [A][B][C][D][E]
- YANG models: Peter feels alone on this. RTG area thinks it's important.
Rahul: can concepts proposed in DAO-projection draft also be described a
YANG module? Peter: yes.
- independent topics:
DIS-optimisation will move forward after next few months, earlier if
contributors join in.
- DAG manipulation:
Pascal: no contradiction between the WG-adopted drafts on this topic. Can't
say about the other ones. Pascal: We expect the amendments to interact with
RPL without issues. Ultimately, RPL and all its amendments go into an
Internet Standard. Rahul: would the WG be interested in a problem statement
before work on the new amendment? Peter: yes. Want a coherent view on where
we want to go. Rahul: based on discussion on ML, will write a
problem statement document. Who wants to contribute? Pascal: facing some
problems: choice of DODAG to join, ... But don't have an all-encompassing
view of all problems that RPL needs fixing. Rahul: DTSN needs reflashing,
such kinds of issues. Peter: proposes (new) items to be listed in wiki
- CCAST and bloom filters
Pascal: today packaged as two documents. what does the group propose?
Peter: this looks interesting to reduce headers and tables.
Rahul: seen problem statement, interesting. Are you proposing to look at
problems these drafts solve, and then combining them? Pascal: BIER is for
multicast, using bitmaps. Three-dimensional: storing vs non-storing ,
encoding (bits or BLOOM filter), unicast vs multicast. Pascal: how do we
want to structure the work. One doc per cell in the matrix? Regroup along
dimensions? Peter: we had the CCAST and BLOOM presentations at last IETF.
Plan for bringing the topic again at IETF101. Pascal: will organize a
presentation (20 mins?) and contact Carsten
Ines: AODV draft is in WGLC. Please review and comment. Who read? 5 hands.
[14:09] Load Balancing (Mamoun)
combined two earlier drafts.
skips the "pb to solve" slide, already presented in Dallas.
definition of Child Node Count metric in DMC. Optionally contains the parent
IPv6 address. In storing mode, number of children can be counted from the
DAO, no need to use parent address in DIO. In non-storing mode, parent
address in DIO allows parent to learn it's being used by child node as a
parent. Dominique: RFC6550 says to ignore DIO coming from node with lower
rank. Make sure you update 6550 so that parent looks into this DIO. Pascal:
RANK goes up with the CNC. Needs to detach and re-attach somewhere else in
DAG. Pascal: some info from 6TiSCH: joining node needs to pick among two
DODAG. 6TiSCH says express willingness to be joined. No related to RANK which
is used for routing. Pascal: this is a Join Willingness. May express the load
at the Root. Want to load the least loaded. Pascal: metrics can still be
propoagated through DMC, that's fine. When 6TiSCH knows what is needed, will
come back to ROLL. Pascal: the number of children is not most useful, but
still usable in non storing mode. Look at what is being done at 6TiSCH.
Georgios: Pascal: 6TiSCH node will see a beacon (in EB). Join priority draft.
Jianqhang: 6TiSCH problem is narrow scenario. Why not solve it in this WG?
Peter: the stack produced in 6TiSCH is usable in other environments as well.
Pascal: 6TiSCH is the WG where the Join process is being studied. Nothing to
do with the Channel Hopping nor 15.4. Doing it for the IoT at large.
Regarding Energy metric: congestion at overloaded node. It will be close to
dying before network. Jianqhang: in WiSUN ....10 years lifetime. Remaining
energy metric will only kick in a few years. We want to achieve balance
faster. Pascal: load may be different per source node. Tree balancing on CNC
does not necessarily achieve load balancing Peter: who read the draft? 7
people Ines: please continue discussion on the ML. Provide comparison with
[14:33] RPL DAG Metric (Georgios)
Goal is to replicate packets and eliminate. Send to RPL parent and alternate
parent. Promiscuous overhearing. Extend the DIO to provide info about parent
node set. TLV in NSA (Node State and Attribute) metric. Describes operation
of a simple topology. Implemented in Contiki. Rahul: clarification question
on example. High density network, limit in operations you can do. Pascal:
much better in centralized fashion. Pascal: PRE at each hop. Georgios: see my
draft at 6TiSCH. Pascal: there is IPR behind this. Hesham: how do you
eliminate replicas? Hesham: network coding would work, too. Pascal: sure.
Building a ladder. Basic flooding along the ladder. Could do NC instead of
flooding, comes on top of topology. Georgios: relevant to this WG? Peter: who
interested to review? 3 (Peter, .., ...).
[14:47] Fast Re-route (Pascal)
Node needs to re-parent to node lower than itself. This is a pain in any DV
routing. With RPL, takes some time. Need to poison downward. Looking at doing
fast reroute. Go around the problem, to another node that is good enough.
Note: Simon claims that sometimes packets are caught in a loop and kept long
enough to exit through new parent on repair. Idea: sending packets to the
nodes lower to try and find a route, rather than waiting for a new parent.
Use bit in RPI to say we are intentionally sending an upward packet downward.
If the packet comes back, the node below was a child. Try another lower node.
If packet does not come back, we were lucky and found an exit route. Mamoun:
how do you pick the lower node? randomly? for how long? Pascal: yes. Until
DAG is repaired. Could also send a probe packet to the root (instead of
forwarding packet from elsewhere). See where Charlie: seems to have a design
by which you eliminate neighbors one by one? Pascal: ping the root through
the various neighbors. This works in both NS and Storing mode. Peter: short
on time. Continue discussion on ML. Could also apply centralized computation
and ARCs. Maybe will talk about this at next IETF meeting. Peter: pascal is
invited to do so
[15:01] Questions and Answers
skipped for lack of time
Peter: will organise a discussion session on the side of the IETF WG meeting
next time if appropriate concerning fast reroute and bits and bloom filters.
[15:02] Meeting ends