Minutes for ROLL at IETF-95
minutes-95-roll-1

taking notes
* Thomas Watteyne
* Dominique Barthel

Jabber:
* Diego Dujovne

* [16.20] meeting starts
    * Ines reminds note well
    * Ines thanks Michael and Peter
    * ines introduces agenda
    * milestones:
        * 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.
    * changes:
        * 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.
* AoB?
* Peter: thanks for comments on rechartering. Will be discussed in Berlin.
[22:19] meeting closed