Minutes IETF103: roll
minutes-103-roll-00
| Meeting Minutes | Routing Over Low power and Lossy networks (roll) WG | |
|---|---|---|
| Title | Minutes IETF103: roll | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2018-11-15 |
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