+--------------------------------------------------------------------------------+
          |                              Agenda ROLL IETF 105
          |
          |
          |
          |                Wednesday Morning session I, July 24, 2019 (EDT)
          |
          |
          |
          +--------------------------------------------------------------------------------+
          |          Time          |               Topic               |
          Presenter     |
          +------------------------+-----------------------------------+-------------------+
          |  10:00 - 10:05 (5 min) |             WG Status             |
          Ines/Peter    |
          +------------------------+-----------------------------------+-------------------+
          | 10:05 - 10:15 (10 min) |   draft-ietf-roll-dao-projection  |
          Pascal       |
          +------------------------+-----------------------------------+-------------------+
          | 10:15 - 10:25 (10 min) |   draft-ietf-roll-unaware-leaves  |
          Pascal      |
          +------------------------+-----------------------------------+-------------------+
          | 10:25 - 10:35 (10 min) |   draft-ietf-roll-nsa-extension   |
          Georgios     |
          +------------------------+-----------------------------------+-------------------+
          | 10:35 - 10:50 (15 min) |      draft-rahul-roll-mop-ext     |  Rahul
          (remotely) |
          +------------------------+-----------------------------------+-------------------+
          | 11:50 - 11:00 (10 min) | draft-thubert-roll-turnon-rfc8138 |
          Pascal      |
          +------------------------+-----------------------------------+-------------------+
          | 11:00 - 11:55 (55 min) |      Discussion on ROLL-BIER      |
          Pascal/Carsten  |
          +------------------------+-----------------------------------+-------------------+
          |  11:55 - 12:00 (5 min) |              Open Mic             |
          Everyone     |
          +------------------------+-----------------------------------+-------------------+
          
          Meeting notes
          [10:01] Intro (chairs)
            Blue sheets
            Scribes: Michael Richardson on Jabber, Dominique Barthel on etherpad.
            Note well are presented
            Agenda bashing: Lee i sgoing to present -turnon.
          
            WG status
              3 drafts in IESG review.
              YANG model for MPL looking for comments, then will go forward.
              DIS-modification will be resumed
              Looking for volunteers to review -traffic-aware
          
          [10:11] draft-ietf-roll-dao-projection (Pascal)
            close to LC, but maybe more things to add before that.
            in non-storing mode projected route, who do you report to in case
            of error?
            added flag in RIP to indicate projected route.
            in RPI, some other flags dont make sense for projected routes
            (e.g. up/down bit).
            MCR: found inefficiency in compression. Is this just for projected
            routes?
            Pascal: yes.
            Type 5 is RPI in both elective and critical.
            Rahul (remote): you said packet does not go up/down. Only true for
            non-storing projected routes, not storing-mode.
            Pascal: once in a projected route, can't go out of it, otherwise could
            create a loop.
            Rahul: there is a possibility that projected route in storing mode
            creates a loop.
            Pascal: yes, but the RPI flags don't help.
            RFC8138 is another encoding of IPv6. All destinations are in the front.
            A few discussions still need to be had:
              * how does the root about the topology? Currently, root can project
              route, but how does it know the topology?
                Target Options and Transit Options provides tree information. We
                need for info on siblings.
                Create a new option in this draft?
                Inès: any objection? none heard
                Pascal will propose new option on the ML, put it in the draft.
              * how does the root of the node capabilities?
                capability option in MOP extension.
                need to advance that draft so that this draft not blocked by
                Downref.
              * what happens if paths are stitched with loose source-route segments
              and storing mode segments. This can create loops.
                text is in place to restrict this. Please review that text and
                comment. Needs tp be well thought.
                If there's one piece in the code to be looked at, this is the one.
              * compression of control plane
                Georgios:
                Pascal: we need a draft for RPL control plane compression
                why not compresion the Via Info option in the 8138
                format? implementation easier.
                Peter VdS (chair hat off): want this draft fixed. Additions can
                be done later, offloaded to other document. Otherwise,
                  not at IESG before Nov.
                MCR: DAO projection not functional without theses fixes. Think
                there needs to be one place where implementers find it all.
                MCR: doesn't matter if multiple documents, may even make it heavier
                for IESG.
                MCR: our documents are interesting, which makes them attractive
                to the IESG.
            Pascal reiterates that we need to make sure the path stitching is done
            right. These paths can be far away from the root,
            routers cant call up the root to fix things.
            Difference between routing and forwarding.
            ROLL is the place to do the slow-evolving part (routing).
            RAW (previously PAW) for the forwarding. Side meeting on Thursday.
            Li Zhao: can we define DAO query from the root?
            Pascal: reformulating. Who gets to tell the root to establish the
            path? maybe an application, maybe a node inside the mesh.
            No signalling for the latter. Could be something like the DIS.
            Inès: please check the open tickets.
            Peter: make these changes, publish, then ask for review.
            Pascal: needed for Detnet.
          
          [10:40] draft-ietf-roll-unaware-leaves (Pascal)
            A series of drafts at 6lo. RFC8505 registration mechanism. Host tells
            the RPL router to do things on its behalf.
            Reduces traffic. DAO redirects the DAR/DAC towards the root.
            Address protection draft protects address against theft, using
            6LoWPAN-ND.
            In the future, would want to extend it to use RPL mechanism.
            Unaware-leave have no RPL understanding at all.
            Draft allows to split 6LBR and root.
            No ROVR in RPL, can't regenerate it at the root. Improvment could be
            to place it in the DAO.
            Inès: thought we said we would merge.
            Pascal: cases where they are different. E.g. when DAR/DAC is translated
            to DHCP. This case is used at Cisco.
            Would suggest to add ROVR in the DAO, and secure it next.
            E bit in DAO tells the root that packet should be send as IP in IP
            addressed to the router.
           Inès: who read the draft? about 5.
           Inès: send this discussion to the ML.
           Inès: who is willing to review? Michael.
           Inès: will ask on the ML as well.
           Pascal: get question as to MPL support? Pascal is not in favor.
           Michael: feel that MPL is so much less understood that wouldn't want
           to put it in the same document.
            Not as much a pb as the unicast, because ...
           Pascal:
           MCR: would suggest we need to wait for somebody to come up with real
           case where this does happen.
           Pascal: let's publish this one without including MPL
           Li: requirement for deep-sleep nodes, cannot use unicast to send
           multicast packets. Deep-sleep nodes synchronize to multicast schedule.
           MCR: that's a great use case. But these nodes are not relay nodes. We
           can send different headers to these mlticast nodes, because are not
           going to be relayed.
           Pascal: unaware leaves are really leaves, they dont relay.
           Peter: don't think you should do MPL in this dicument. Different
           mechanism.
           Peter: what about Trickle? If you have a MPL problem, we should also
           look at the Trickle problem.
           Pascal: agreed, too complex to include in this document.
           Inès: we need reviews.
           Inès: volunteers to review this draft? MCR, Li
          
          [11:00] draft-ietf-roll-nsa-extension (Georgios)
            Currently -04, here is the update since -00
            Main change is that CA algorithms now described as Objective
            Functions. Hence the change in the title.
            No more reference to 6loRH-like compression, to avoid confusion.
            Review requested for the new test on OFs.
            Peter: still work to be done in this draft, or confident it's complete?
            No known issue to address.
            Aris: one issue (editorial): as an extension to MRHOF. Is this the
            right way of doing it? Feedback needed.
            Inès: Reviewers? Dominique, Rahul.
            Pascal: Updates the way it is done, you are extending and not updating,
            expressing what they are
            Dominique: I looked at the diff, at most one page, not difficult to
            read, but one has to go back to MRHOF to understand it,
            requires a bit of time.
            about the understanding of what is really done
            Inès: who has read this document? 4
            Inès: implementations?
            Georgious: we have implemented.
            MCR: you mentionned teaching. Is this work counted in your tenure
            record?
            Georgios: no.
            Pascal: indeed, we need to work with academia to make this recognized.
          
          [11:09] draft-rahul-roll-mop-ext (Rahul, remote)
            MOP extension proposal is straightforward.
            Exchange is a bit less simple.
            Not sure the 24 bits currently allocated to MOP extension are actually
            needed. Considering to shorten it a bit. Opinions?
            Pascal: could have type and subtype. Including collections of bits to
            allow combinations, not mutually exclusive modes.
            Rahul: this behavior would be provided with the proposed capabilities.
            Pascal: I think you need both. Would want the MOP to say non-storing
            *and* projected in storing and non-storing.
              It's more than capabilities.
            Rahul: currently, it's a choice between non-storing and non-storing
            with projected. Any combination should be a new MOP.
            Pascal: if a node cant do the MOP, doesn't join the network (or as
            a leaf)
            Rahul resumes presentation.
              MOP are mandated, capabilites can be negociated.
            Pascal: capability is not necessarily a bit. Can be up to 100 bits.
            Pascal: this draft needed for -unaware
            Use DIO/DAO/DAO-Ack as a 3-way handshake to negociate capabilities.
            What if 6LR nodes in bewtween, would it be ok for 6LR to mask off
            some capabilities?
            Not in the draft at this time, but technically feasible.
            Pascal: Configuration Option is not negociable, has to come from root,
            but this one can be modified on the intermediate 6LRs.
            Rahul reiterates that MOPs and Capabilities are independant things,
            although defined in the same draft.
              Open to feedback from the group on how to reduce protocol overhead
              of MOP-ext.
            Suggestion to use MOP-ext instead of adding a bit in 6550 for 8183
            turnon.
            MCR: "mutually exclusive" means you can't put them together. I think
            you mean "orthogonal".
            Rahul: you can have MOP-ext and CAP options in the same packet.
            MCR: scanned through the draft. Good idea. Think we should immediately
            adopt it. Don't think we should split in two documents,
              too many documents.
            MCR: think bad idea to have MOP equal to 7 + MOP-ext. Easier and less
            confusing to define "if MOP is 7, then MOP-ext contains
              the value".
            Pascal: completely agrees. Also allows to put MOP-ext option in the
            next packet. MOP 7 would mean just wait for the next MOP-ext option.
            MCR: dont know if too many bits. Would recommend to express it as an
            integer, which can be compressed.
            Pascal: should structure it in 2+5 bits.
            MCR: think needs further discussion.
              Not sure DAO-projection can be a capability.
            Pascal: CAP is "I can do that", MOP is "this is how it works".
            MCR: like that this CAPability is introduced, very valuable draft to
            get passed. Better delay DAO-projection until this is done.
            Pascal: I concurr, this is infrastructure work, need this done before
            DAO-projection.
            Pascal: regarding 6LoRH turnon, this would be a misuse of
            CAPability. Root should send it as part of the Configuration Option.
            Rahul: agreed, document needs to clearly separate out Configuration,
            MOP and CAPabilities.
            Inès: please humm for yes? many humms heard. Against? none heard. Will
            confirm on the mailing list.
          
          [11:37] draft-thubert-roll-turnon-rfc8138 (Li Zhao)
            Reminds of 8138 goal: to compress RPL artifacts.
            But 8138 does not cover coexistence and migration.
            One bit in DIO CO proposed by UseOfRPLInfo to indicate 8138 compression
            in effect.
            This draft proposes to avoid Flag Day. New bit in DODAG CO.
            Goes through proposed behavior.
            Allows to keep network alive while festure is gradually turned on.
            Goes through proposed transition scenarios.
            Nodes that dont suport 8138 must stay as leaves. Need for packets to
            be decapsulated and sent to parent, which will decapsulate.
            MCR: don't think a MOP will help, will double the number of MOP. If
            CAPabilities work, this would be a valuable use for them.
            MCR: not sure the encapsulation is necessary. These nodes still have
            to be leaves, but the important thing is that the parent
              knows that the nodes doesn't do 8138.
            Li: ...
            Pascal: agreed, this would work. Tend to disagree that this would be
            a capability.
            Pascal: if this node joins as a leaf, why should it be RPL-aware? Now
            that we have -unaware, have this node join as unaware,
            and this solve the encapsulation question, because we have this
            already defined
            Inès: reviews? MCR,
            Pascal: this doc is very simple. Just forgot to do it in 8138. We can't
            deploy 8138 because of this shortcoming. We need this quickly. One
            bit. An easy one.
            Peter (chair hat off): ...
            Pascal: this is replicating what we did in UseOfRPLInfo.
            Rahul (remote): you say just one bit. But do you require nodes to
            report to the root that they do 6LoRH?
            Pascal: this is just for better automation. Don't need every node to
            turn it on, will work on mixed population.
              Would love to have CAPabilities, both for UseOfRPLInfo and for
              this. Need for the Rahul's draft.
            Peter (chair): suggest we discuss this adoption on the mailing. Seek
            more comments, discussion, alternate proposals to do this.
          
          [11:55] Discussion on ROLL-BIER (Peter)
            not much recent activity. Abandon concept of design team for a while,
            suggests that Pascal progresses the draft in the
            scope of his grand scheme.
          
          [11:57] Charter discussion
            Peter: work is advancing. Some more documents to be rolled out. Would
            like to keep moving without rechartering.
            Alvaro: like the way you have managed the WG. Not sure about the exact
            charter language right now.
              Good to keep focus, charter is meant to set milestones.
            Peter: ...
            Alvaro: maybe, will have to look at the specifics.
          
          [12:00] Meeting adjourned