Minutes for ROLL at IETF-95
Routing Over Low power and Lossy networks
||Minutes for ROLL at IETF-95
* Thomas Watteyne
* Dominique Barthel
* Diego Dujovne
* [16.20] meeting starts
* Ines reminds note well
* Ines thanks Michael and Peter
* ines introduces agenda
* call for comments for draft-ietf-roll-routing-dispatch is on-going.
Provide feedback * expect to finish milestones by May 2016
* introduces new RFC
* sec reivew of AMI draft. Thanks Nancy
* related drafts, may be added to charter
* open tickets
* [16.25] when to use RFC 6553, 6554 IPinIP [Ines Robles]
* drafts introduces combinations of storing and non-storing modes
* total: 24 cases
* rules: we cannot modify IPv6 headers on the fly, we need to encapsulate
to "add" headers * cases in storing modes
* Ines presents table which lists whether a RPI, RH3, IP-in-IP are
needed (and the destination address in the IP-in-IP case)
* discusses when RPI and/or RH3 are added. In some cases, RH3 is optional.
* [Pascal] is we use 6loRH compression, RPI becomes useful for compressino,
you need to know which root of which DODAG is important. * [Ines] will
modify the draft accordinfly * gives enables in storing mode. proposes
Hop-by-hop encapsulation when * 6lo-routing-dispatch propses a compression
for RPL, RH3 and IP-in-IP * Ines calls for comments in the ML * [Peter]
invites for more comments in the review. Useful for complex document.
Invites 1-2 reviews of the document. Volunteers? * no volunteers, but Peter
will nominate some offline * [Michael R., though Jabber] we need a reviewer
from an implementor.
* [16.33] roll-routing-dispatch [Pascal thubert]
* 6lo suggested for roll to do the final review.
* improved documentation on how things work, step-wise operation
* ETSI plugtest, but the doc was too late, only one implementation
* draft will be validated in Berlin ETSI 6TiSCH plugtest
* found that with RFC6282, one cannot use outer header to compress inner
header. you cannot inherit that knowledge to compress the inner header *
problem for data coming from the root * 6lo-inner-compression is a very
small draft to fix that. Inherits from outer header. * Pacsal asks for
people to have a look at inner compression draft * 6LoWPAN has its own
contex (RFC6282), now RPL is a secondary source of context. The only
context is the prefix of the root. as provided by RPI header * 6loRH was
split in two. last call review is extended, because not enough comments.
Draf is a few pages. * issues addressed. RH3-6LoRH now called SRH-6LoRH *
draft contains examples. * wanted to make forwarding plane easy, with
context of fast path * things are ordered differenrlt in the compression
version * e.g. if you have a packet generated by the root (no IP-in-IP
needed), you place the RPI-LoRH before the IP header. allows:
* precession RPL without looked inside the packet
* no have to 6282 parser
* fragmentation is not changed
* example of IP in IP encapsulation. SRH in first header.
* with this new -inner-compression draft, inner header inherits root prefix
from RPI header. * Pascal thanks Michael for sheperding the draft * [Thomas
Watteyne] reminds of Plutest going to take place just before the Berlin
IETF meeting. * [Peter] would be nice that implementers read the draft
before implementing :-) and therefore comment them in the next two weeks! *
[Michael Richardson] can you speculate on ... RPI dropped by the time ...
compress the inner header (?) * [Pascal] non RPL-aware leaf <...>.
Context: doscussion at 6man about deather of HbH header. If 6man deprecates
it, will be a issue for us. One option is for the routers to drop it. If we
send the uncompressed, it will drop the packet. Renumbering to 43 instead
of 63 means that header is ignored instead of packet dropped. * [MR]: *
[Pascal] pb is you don't know what kind of device (RPL-aware or
non-RPL-aware) you have to deliver the packet to. * [MR] still concerned
about compression about IP in IP header. Bunch of stuff done so that we can
uncompress according to 6man rules. Could compress better if didn't have to
* [MR] with this proposal, we don't expect to support both modes. Either
one or the other in a given network.
* [16.53] No-Path DAO of RPL [Rahul Jadhav]
* NPDAO is a DAO with lifetime of zero. Used for route invalidation.
Routing entries use a lot of memory, especilally in big storing mode
networks. * goes through example. A node switches parent due to link
failure. Lists potential problems. E.g. route invalidation for node that
switches parent, not for dependant nodes. * [Pascal] all about storing
mode. In table, you expect to konw who is behind the child. If you loose
connectivity, you konw that if you loose all of the children, no need to
send No-DAO. in hte drawing, if the link btween B and D is broken, B can
send a NPDAO annoucing that D as well as E and F are lost. * [Rahul] cannot
send a DAO on behalf on other nodes. State consistency problem. * [Rahul]
problem with route downtime, becase of asyn mode of operation. * [Peter] we
need to conclude, can we continue on ML * [Rahul] presents requirements for
NPDAO improvements * [Peter] we need to continue discussion on ML and get
the problem statement clear
* [17.06] YANG MPL for RPL [Peter]
* we used YANG to describe the model, see if there is any inetreste to
coninue this work * 4 parts in model:
* how multicast addresses
* operational parameters
* operational statistics
* would welcome comments of ML. might say that is too complex for small
devices. * interest to continue this work? * several yes' from the ML
* [17.08] recharter [Ines]
* need to define tocpis for recharter
* Ines presents slides with different items, including
* maintenance of standards
* mixing modes?
* [Pascal] don't say that DAO project is maintenance, is new work. Should
not be in maintenance. * [Ines] thoughts? do we want to work on that? *
[Peter] who has read
* a couple of hands
* [Peter] agree it's interesting
* automatic selection of MPL forwarders to reduce mesg replication.
Interest? no answer from the room. * [Carsten] source-routed multicast
would benefit from it. * 5 people interested in Mcast * [Carsten] at 6lo
meeting IETF92 short presentation for using RPL for source-routed
multicast. bier for constrained environments. implemented and simulated.
seems to work. If we want to have some low-latency mcast, would be a way
for doing this. * [Peter] would be nice to compare with others * [Casrten]
not just performance, but also how much you ask to nodes * [Pascal] support
this work. use for bier for RPL can be interest for unicast, with bitmap,
DAO routes. Express each router zith a bit. High interest * [MR on Jabber]
cool for RI multicast. Can it be used for firmware updates? * [Thomas W]
using Bier ideas is good for replication and reliability. I support this
work. * [Carsten] lot of work on firmware updates. stay tuned.
* Peter: thanks for comments on rechartering. Will be discussed in Berlin.
[22:19] meeting closed