Minutes IETF105: roll

Meeting Minutes Routing Over Low power and Lossy networks (roll) WG
Title Minutes IETF105: roll
State Active
Other versions plain text
Last updated 2019-07-30

Meeting Minutes

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

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