* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Roll Status Pages

Routing Over Low power and Lossy networks (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2008-Feb-15 —  

IETF-103 roll minutes

Session 2018-11-05 0900-1100: Boromphimarn 1/2 - Audio stream - roll chatroom


minutes-103-roll-00 minutes

          |                                          AGENDA ROLL IETF
          103                                          |
          | Date: Monday, Nov 5, 2018 (UTC+07)
          | Time: 9:00 - 11:00 - 120 minutes - Morning session
          I                                                   |
          | Place: Boromphimarn 1/2 - 3rd Floor
          09:00 - 09:05   WG Introduction
          09:05 - 09:35   ROLL-BIER Design Team Status
          09:35 - 09:45   draft-ietf-roll-efficient-npdao-09                 (Rahul)
          09:45 - 10:00 † draft-ietf-roll-rpl-observations-00
          10:00 - 10:10   draft-ietf-roll-aodv-rpl-05 †
          10:10 - 10:25  †draft-ji-roll-traffic-aware-objective-function-02
          10:25 - 10:40   draft-koutsiamanis-roll-nsa-extension-02
          10:40 - 10:55   draft-ietf-roll-dao-projection-04
          10:55 - 11:00   Open Floor (everyone)
          Meeeting notes
          [9:00] Meeting starts
              * Blue sheets, notetakers, Jabber scribe, Note Well
              * Agenda : no comments
          [9:01] WG Status - Introduction (Ines)
              * shows milestones, drafts in progress, open tickets (3 new after
              last meeting, #187, 188, 189)
          [9:03] ROLL-BIER Design Team Status                       (Toerless)
              * goes through introduction slides, goal of BIER in ROLL
              * example of lighting control application
              * Carsten: "client-server", you mean small thing and big box, not
              client-server communication?
              ACTION: Toerless please fix the slides to use some other terminology.
              * Toerless: indeed
              * not done in BIER WG so far, bring individual bits to the app
              * Simon S: server has state, client has none
              * Greg Shepherd: if there is a gap for ..., please bring this up
              in BIER
              * Carsten: could also use sender and receiver terms.
              * framework includes nodes that are not routing node ("Lightweight
              * Greg: ...
              * in ROLL, one differentiation from BIER WG is lossy compressed
              bitmap with bloom filters
              * in forwarding plane, no distinction between BIER and BIER-TE models
              * Pascal Thubert: think was clear no need to reset the bits. BIER
              does reset to avoid loop (because flooded), but RPL uses DODAGs.
              * Pascal: another draft about managing state in the TE world. Come
              to PAW bar-BOF (Tuesday 11am), advertised on Detnet list.
              * Pascal: in RPL, additinoal header says if packet travelling up or
              down the structure. Packet will never loop.
              * Toerless: so would explicitely ignore bits that have the packet
              go up again.
              * Pascal: set of bits per child instead of per leaf.
              * Pascal: one bit per adjacency. In storing mode, routing table has
              state per child in the DODAG. In non-storing mode, ...
              * Toerless: let's capture this properly
              * Carsten: this a graph, not a tree. If you never reset bits, nodes
              lower in graph never sure that ....
              * Toerless: runnign out of time. Goes through list of related
              * decision made to use IP multicast (knowing that it is compressed
              with 6LoRH).
              * Pascal:
              * Toerless: if unicast, one bit only. False positive are possible,
              but will be recognised (discarded) at destination.
              * Carsten: we need a day to discuss this.
              * Pascal: BIER allows saving a lot of state, critical for RPL in
              storing mode.
              * Pascal: one bitmap bit per child.
              * Toerless: lets make sure to capture this properly.
              * MCR:
              * Pascal: still need to have some info per leaf. But bitmap has one
              bit per child. Elasticity canbe obtained with bloom filters
              * Greg:
              * Pascal: talking non-TE at this time
              * Carsten: by limiting to 256, we make storing mode much more
              * Carsten: sparse groups can be addressed with pretty small
              filters. Dense groups need larger filters.
              * Toerless: need to focuss scope of what we need to work on.
              * muticast, do we need MLDv2 or can we do with SSM only.
              * Carsten: comment on choosing SSM. Everything goes through RPL root,
              solves SSM ... problem. The whole thing assumesthat the whole group
              is within one RPL domain.
              * Greg: going back to SSM, dont forget that BIER domain is kind of
              a RP.
              * Pascal: also remember RPL has instances, could be used for ...
              * Peter, Toerless: need to plan for a full day to discuss this at
              a future meeting. In person or at virtual interim meeting.
              * Greg: in-person is a huge difference.e
              ACTION: investigate having an interim meeting, virtual interims,
              IETF104+ day-long interaction
          [9:45] draft-ietf-roll-efficient-npdao-09                 (Rahul)
              * goes through recent updates to the draft
              * Peter: this document is finished and we will send it for publication
          [9:47] draft-ietf-roll-rpl-observations-00                (Rahul)
              * document may not end up being published, but will be kept around
              for reference
              * discussing various ambiguous parts of RPL.
              * First observation: is DTSN a lollipop counter? how is DTSN used?
              * Pascal: at the time RPL was specified, could not decide i pull or
              push model for DAOs. Left it open on purpose. Not enough experience
              at the time
              * MCR: could be clearly articulated in 6550 that push model and pull
              models are possible. Would like to have a specific draft for this.
              ACTION: Rahul to create new draft on DTSN counter.
              * Second observation: DAO-ACK behavior
              * is DAO-ACK to be sent downstream right away or after DAO-ACK
              received from upstream (the latter interpretation means maintaining
              long lasting state).
              * Pascal: Contiki implemented this hack ofr a particular use
              case. Design on the left ot hte slide is the official behavior in RPL.
              * Pascal: parent takes responsability and pushes it through,
              or detach+poison.
              * Pascal: no extra state, just a bit in routing table that ACK was
              received from parent.
              * Pascal: we could specify a mechanism to get an ACK from the root
              all the way down the DODAG. Could be a new draft.
                 ACTION: new draft on ACK from the root?
              * Rahul: RPL not good at handling aggregating targets, how to ACK
              if one fails.
              * upcoming observations: e.g. use of multiple links
          [10:07] draft-ietf-roll-aodv-rpl-05 †                      (Charlie)
              * will go through comments received during Last Call.
              * SequenceNumbers: maybe could reuse DODAGVersionNumber and DTSN
              fields, but this is new Mode of Operation anyway.
              * Peter: will review it personnally,
          [10:16] draft-ji-roll-traffic-aware-objective-function-02  (Aris)
              * goes through changes since -01
              * recap: several Objective Functions for RPL (two RFCs and one
              draft). This one addresses the load balancing requirement.
              * explains Remaining Throughput computation, shows examples.
              * Pascal: throughput is dangerous metric. Leads to
              oscillations. Arpanet experience. Use it together with another metric
              to slowly rebalance part of your traffic, not switch parent abruptly.
              * convert Remaining Troughput to Join prirority (PAN priority in EB
              at layer 2).
              * asking for next steps:
                  - two volunteers to review (Rahul and Dominique)
              * address comments by Pascal and call for adoption
          [10:32] draft-koutsiamanis-roll-nsa-extension-02           (Georgios)
              * goes over principles of this draft: Packet Replication, Elimination
              and Overhearing.
              * find alternate parent(s) that has (have) Common Ancestor.
              * three different versions implemented. Each one corresponds to a
              different criterion to select alternative parent.
                - strict. May lead to no replication.
                - medium
                - relaxed. Increased cost (energy, bandwidth)
              * goes through simulation results
              * Peter: do these simulations include link failures?
              * Georgios: yes, 70-100% PDR.
              * "strict to medium" optimisation. If not replication possible at
              some stage in strict mode, allow medium mode.
              * Rahul: how to apply PRE only to a subset of traffic?
              * so far for the whole traffic
              * Pascal: this inherits from work done at Detnet, which identifies
              flows. This can be done here too, see PAW discussion.
              * Georgios: journal paper uses Cooja simulations.
              * Rahul: beware of Cooja. Very different results with NS3
              * Ines: who is willing to reveiw this draft? Rahul
              ACTION: Rahul volunteered to review.
              * Humm for adoption? several hums. Against? one hum. -(Correction on
              16-11-2018: no hums against, the person understood wrong the humm
              adoption, the person clarified to the chairs the situation after
              the meeting ends)
              * Pascal: with Route projection, Controller could project the two
              route with better reliability than discovering alternative parents
              * Charlie: selection algorithm bsed on grand parents looks nice in
              the grid drawing. Does it apply to real life networks?
              * Pascal: using overhearing opportunity. Think of a wave, restricted
              to a wave guide.
              * Charlie: please show other network topologies. Also, there are
              other ways to find alternate routes.
              * Pascal
              * Aris: related to Route Porjection. This is distributed, useful
              when you don't have a central controller.
          [10:56] draft-ietf-roll-dao-projection-04                  (Pascal)
              * Taking RPL into the SDN world.
          [10:56] draft-thubert-roll-unaware-leaves-05 (Pascal)
              * tell what the WG does want and what it does not want into this
              * router registers an address on behalf on RPL-unaware node.
              * discussion needed: is LBR the RPL root or not necessarily? if yes,
              some flows described here can go away.
              * also Address Protection - ND draft. Crypto mechanism to avoid
              foreign node to register address already in use. However, protection
              at the edge. A rogue router could still register such an address.
              * Ines: put these questions on the mailing list.
          [11:03] meeting adjourns

Generated from PyHt script /wg/roll/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -