Minutes IETF103: roll
minutes-103-roll-00

+--------------------------------------------------------------------------------------------------------+
|                                          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           
                                                        |
+--------------------------------------------------------------------------------------------------------+

http://etherpad.tools.ietf.org:9000/p/notes-ietf-103-roll

Agenda
09:00 - 09:05   WG Introduction                                    (Ines/Peter)
09:05 - 09:35   ROLL-BIER Design Team Status                       (Toerless)
09:35 - 09:45   draft-ietf-roll-efficient-npdao-09                 (Rahul)
09:45 - 10:00 † draft-ietf-roll-rpl-observations-00                (Rahul)
10:00 - 10:10   draft-ietf-roll-aodv-rpl-05 †                      (Charlie)
10:10 - 10:25  †draft-ji-roll-traffic-aware-objective-function-02  (Georgios)
10:25 - 10:40   draft-koutsiamanis-roll-nsa-extension-02           (Georgios)
10:40 - 10:55   draft-ietf-roll-dao-projection-04                  (Pascal)
                draft-thubert-roll-unaware-leaves-05
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 nodes") * 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 documents. * 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 manageable. * 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 draft.
    * 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