Minutes IETF100: roll
minutes-100-roll-00

Meeting Minutes Routing Over Low power and Lossy networks (roll) WG
Title Minutes IETF100: roll
State Active
Other versions plain text
Last updated 2017-11-15

Meeting Minutes
minutes-100-roll

   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