IETF100
Agenda of the ROLL WG meeting
Date: Wednesday, November 15, 2017 
Time: 13:30-15:00 Wednesday Afternoon session I : 90 minutes
Room: VIP-A

Agenda                                                                       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.)                                                       ------>   Everyone

Meeting notes
[13:31] Meeting starts

[13:31] ROLL Working Group status (Peter/Ines)

[13:32] Use of RPL info (Ines)
  draft-ietf-roll-useofrplinfo
  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 setting.

  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)
  draft-ietf-roll-efficient-npdao
  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.
  Comments?
  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
  draft-ietf-roll-dao-projection
  minor changes
  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?
  Rahul: yes

[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)
  draft-qasem-roll-rpl-load-balancing
  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 what exists.

[14:33] RPL DAG Metric (Georgios)
  draft-pkm-roll-nsa-extension
  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