Minutes IETF106: roll
minutes-106-roll-01

IETF 106 - ROLL Meeting-Tuesday-19Nov

MATERIAL: https://datatracker.ietf.org/meeting/106/session/roll
Meetecho: https://www.meetecho.com/ietf106/roll/

Meeting Notes:
    Michael Richardson's colour.
    Dominique's colour
    Alexander's color

    The Tuesday meeting notes  are at the bottom of the Etherpad.

-------------------------------------------------------------------------------------------

Monday

Agenda

 Monday Nov 18, 2019 15:50-17:50 Singapore time (UTC+8)
+--------------------------------------------+-------------+------------------------------+
| Topic                                      | Time 120 mn | Presenter - On
site/Remote   |
+--------------------------------------------+-------------+------------------------------+
| Introduction - WG Status                   | 16 min      | Dominique/Ines    
          |
+--------------------------------------------+-------------+------------------------------+
| draft-ietf-roll-rpl-observations-02        | 40 min      | Rahul             
          |
+--------------------------------------------+-------------+------------------------------+
| draft-ietf-roll-dao-projection             | 25 mn       | Pascal            
          |
+--------------------------------------------+-------------+------------------------------+
| draft-ietf-roll-mopex-cap-01               | 35 mn       | Rahul             
          |
+--------------------------------------------+-------------+------------------------------+
| Wrap up                                    | 4 min       | Ines              
          |
+--------------------------------------------+-------------+------------------------------+

Meeting Notes:
[15:51] meeting starts

Introduction:
  * Note Well
  * Thanks to Peter, out-going co-chair, for his excellent work over the last
  years * Jabber scribe Georgios * minutes takers : Alex Pelov, Laurent Toutain

[15:53] Introduction - WG Status (Ines and Dominique)

Ines shows the updated milestones. Comments welcome.
Pascal Thubert: DAO projection still a bit optimistic. Rather next year,
hopefully by IETF107. Ines: See active use of Github for ticket tracking. We
are going to watch it as well as the IETF tracker. Ines: shows relationships
between currently active drafts. Question: DAO projection: should be a new MOP?
Question to be answered today or on the mailing list. Question for tomorrow:
should turnon-8138 be implemented as a capability?

[15:58, expected 16:05]
draft-ietf-roll-rpl-observations-02        | 40 min      | Rahul               
        | This draft contains RFC 6550 observations and clarifications with
input from implementations Every section has a question: should we do it this
way or that way? Draft may not be published as RFC but kept as a work document
and update it

Parent switching
In non-storing mode, DTSN value is directly controled by the root.
In storing mode, it is more difficult, can lead to a lot of DAOs or big DOA
requiring frag. Pascal: the specification is not clear. In storing mode, the
amount of state to be transferred is the same, less bytes over the air if D
rebuilds an aggregated DAO to send to C. Pascal: would argue we want to pack
many targets in to the DAO to make it reasonably big, also to compress it as
much as we can. Radul: talking about compression, each target has different
path sequence number and lifetime. Not possible to aggregate them in the same
transit info option. A lot of control overhead. having said that, incrementing
DTSN and resetting Trickle timer will create an enormous amount of overhead,
too. But so easy to implement! Michael Richardson: three questions: 1-
procedural next step: when we know hat we want, should we put the fix in 6550
errata or leave in this draft? Question 2: is there an interoperability issue
between the two possibilities you mention? Rahal: RFC does not mandate/specify
handling of aggregated DAOs. Contiki doesn't work at multiple hops today.
Michael: I understand your second option does not work today because the
handling of aggregated DAOs not cleary articulated in 6550. We have an erratum
here, should say MUST handle multiple DAOs. MCR: The Sender knows it implements
aggregated DAO, but does not know if the receiver is able to handle it. We have
an interop issue. MCR: not knowing what the receiver accepts, only option for
sender is to incremente DTSN and send individual DAOs. Pascal: seems we're
mixing 2 problems. Clarifying: PT: Problem 1: does D answer on behalf of its
children PT: Problem 2- whether D sends them as individual messages with one
target in them or packs them as one big message with lots of targets in them.
MCR: sending DTSN down also results in individual DAOs coming back up, and you
don't have to package them. PT: D sending single DAO (aggregated) vs multiple
DAOs is orthogonal to the question of sending DTSN down. MR: Multiple DAOs - we
have problem with interoperability, it sounds like everyone would like to use
solution B, it's just that we don't know if we are able to implement it MCR:
how many in the room use storing MOP? Anima is using storing. MCR: We should
not spend too much time over this issue (we could use capabilities to fix this,
discovering if all nodes support DAO aggregation) MCR:  Alternatively, we could
use non-storing mode and projected DAO as a replacement, regardless. MCR: Write
errata - "you should support multiple DAOS, if you don't you have a bug. You
should resend them from your storage rather than incrementing DTSN." MCR: We
shoud write these two statements, not worry about back compatibility issue.
Pascal [at 16:15]: it is in the RPL spec that you can package multiple targets
in one DAO.

DAO-ACK Handling: in non-storing mode, Ack is sent by the root, to say to the
node that application traffic can begin. in storing MOP, DAO is sent hop by
hop, relying on the parent to forward it to the root. If parent answers
immediatly with a DAO-ACK, it is not a information that the traffic can start.
Indeed, something might happen upper in the DAG. Negative status can be
transmitted by the upper node, but no way to propagate it down because
intermediate node already sent positive ACK down.

Pascal: (the new) DCO can be used for the second point

MCR: storing mode - DAO-ACK from B is failed, D thinks it can send trafic, but
it will not recieve any answer. It's OK to have DAO-Ack mean - "Start trafic" -
as there may be other nodes to which the node could communicate. Rahul: yes,
but nodes below starting their application traffic just aggravates the problem.

Alvaro Retana (as a WG contributor): like the DCO. What other protocols do is
wait for ACKs cascading down from the root.

Rahul: cascading the DAO-ACK down has implication on amount of state to be held
at intermidiary nodes. Pascal: the design was that by ACKing the DAO, a node
takes responsibility for propagating the DAO, and also for killing the
relationship to the child if node fails to propagate the DAO, because can't
serve it as a parent. Before having the DCO, the node had to completely stop
being a router. The subtree will find another way. The problem, the time to
wait is not known. Michael : notice the last point in slide : does not
interoperate. Pascal: there is no other scheme. Contiki has a behavior that is
not in the spec. Pascal: the cascading version will have long timeouts.

Rahul:  Contiki's implementation is another interpretation of RFC6550, not
really violated a mandate. Pascal: probably correct, but that behavior was not
the intent. Status=0 used as an indication that path is established.

Next point: Signaling resource constraints
Node D going through node B, B with limited resources, B cannot take any
further nodes. There is no metric to send this informaiton downlink. We need to
put this information somehow in the metrics.

Georgios Papadopoulos: we have a draft on this. Remaining resource, in DIO.
MCR: dont undestand why this is not usable at multiple hops.
Rahul: The point is when H (connected to F and D) is going to be added do B,
but B doesn't have the resources -> D can switch the route to pass through C
instead, but C may not have the ressources either for the full sub-DODAG.
Rahul: this happens with networks with lots of nodes.

Pascal: was discuss during original RPL design to have a message to say, I
cannot take more resource. Only thing is to push back. It has been proposed but
would have made RPL more complex. The chosen solution was to say that every
node needs to have enough resources to store the necessary state for the whole
network. Otherwise, the mechanisms to handle when some nodes may not have
sufficient resources make the solution too complex. Rahul: this design
assumption never came into 6550. Should be mentioned somewhere. Implementers
realize it at a late stage. PT: Depends on the assumptions on your hardware. It
is mostly a deployment question, not that much developer one. Rahul: use case
document says we can use storing mode for networks of thousands of nodes. Maybe
shoudl capture the assumption. PT: yes, it should be written somewhere Rahul:
we need nodes to have enough resources, all the nodes, if we want storing MOP
to be used.

Transit Information Option: contains a target-specific flag; the Option cannot
have mutliple targets. Pascal: agree, not factorisable

Rahul: in this case, no different Path Sequence, but still Path Lifetime.
Pascal: factorising Target only works for devices physically tethered together.

Eliding Option: 6550 says Configuration Options can be elided, but there is
scenario where it is not passible to elided, there is a specific draft for this
issue. See next.

Rahul: Node needs persistent storage for lollipop counters, otherwise it can be
in non-deterministic stage for long time. Node may reboot multiple times.
Pascal: there is a linear part to accomodate for several lost messages. Its
length has to be tuned to the frequency your are sending. Pascal: size of
linear part to be adjusted according to frequency of message, we should revisit
each lollipop in RPL and adjust its linear part length. 16 was thought for
DIOs. Rahul: problem for DTSN. We don't say which length should the linear part
be. Pascal: agree, for DTSN the linear part should be 0. => ACTION POINT: go
through RFC6550 and look at each lollipop counter to define its length.

Path Control Bit:
    - not used now. Provide multiple downward routes, allows to do load
    balancing. Might be used by 6TiSCH.
Pascal: this is a basic thing, there are new proposals that are more powerful,
this can be deprecated. Pascal: could decide to deprecate this when we revisit
6550, and look at the newer approach. Rahul : nsa-extension has different set
of design assumptions, including security. Overhearing requires to have same
shared key. Pascal: but nsa has intricated paths instead of bottleneck, still
benefits.

Sending DAO-ACK when K bit is set is SHOULD in 6550, should be MUST.
Pascal agrees.

TIO is optional, should be mandatory

Rahul suggests to have a mininal-RPL without all the complex features (Path
Control, ...)

Back to DAO-ACK issue.
Pascal: DCO was meant to kill something, now could transport some info. E.g.
new status (below 128), such as "route is open". Rahul: maybe we should have
used a different name (not "cleanup") - as it does more things (e.g. root
reachibility indication) Pascal: DCO is a powerful tool, has RPL status in it,
can do more than kill route. Pascal: may find new acronym.

More points uncovered: Multi-Sink/BR practices, Multicast operations
dependency on ND. Prefix info is part of RPL but other stuff like DNS config
still relies on ND. Michael: would rather put some context info in DIO and be
ok without ND. However, we need ND for RPL unaware leaves. Both options have
value. Michael: we need to have a conversation about configuration information.
Pascal: now, we have capabilities to elide config info. Pascal: when designing
RPL, separated RA from DIO because of different pace expected for each of them.

Rahul: we need numbers, cost of these mechanisms.
Ines: feel free to contribute / participate in implementation. Or contribute to
a draft on lollipop counters. Newcomers welcome.

[16:58, expected 16:45]
draft-ietf-roll-dao-projection             | 25 mn       | Pascal              
        |

Pascal presenting
Made a lot of additions since last IETF.
compressing Via option of P-DAO with RFC8138
P-DAO is a segment per 8138, addresses compressed to the same number of bytes.
Otherwise, split in several segments.

managing created path needs a Path id
A PAth is called a track in 6TiSCH, it's a DODAG to a destination, use the
local RPL instance ID + the destination IP to build a Track ID.

Georgios: how to define the track, how is it updated?
Pascal: the root will send a new P-DAO message with a new Path sequence number

A Track is not a just a serial path. Different segments constitute the Track.
A segment ID was also missing, added in the latest rev of this draft (this
morning!)

Added Sibling ID to signal non parents to the root (does not take into account
sibling selection) Rahul: path control bits can do that. Multiple Transit Info
to the root. Pascal: but only for parents. We want do send info to the rot
regarding non parents.

Sibling selection may be needed, but not addressed in this draft. May need
something similar to an OF to select a few siblings among all of them.

Introduced a P-DAO request - unicast packet for a node to request from a second
node a path to a third node. And associated P-DAO Request ACK.

In the future, add something like a metric container, but with the quality
metric of the path that want to be built. Maybe not quite the metrics we have
right now. Do we need it?

Rahul: SegmentID is purely for management purposes, TrackID may be used in the
data plane as well. Pascal: indeed. Signaling the Track in Packet -
(Global/Local, Sourc/Dest, Inst)->IPv6.destination - the track is always going
to somewhere, never coming back. Therefore the S/D bit is always Destination.

Pending issues: Tickets #179, #180, security of P-DAO, config parameters into
P-DAO Requests

There are a lot of changes in the document. Some of it was discussed on ML,
some got feedback, others didn't. Feedback is necessary to see if the progress
is in the right direction. Eventually, some optimization can be done after
ongoing discussions are cleared. WGLC next IETF.

Who's willing to review the draft?
5: Georgios, Michael, Rahul, Remy, xxxx

[17:20, expected 17:10]
draft-ietf-roll-mopex-cap-01               | 35 mn       | Rahul               
        |

Rahul presenting

What are capabilities (CAP)?
Difference between Mode of Operation (MOP) and DIO Configuration options?

Design goals: any node can generate it, any option could be sent in any
message, upward or downward, could be explicitly queried, ... Earlier version
of this draft had only combination of bits, now most capabilities having their
TLV.

Handling CAP unaware nodes? CAP would be used only for the new MOPs. Need WG
opinion. We need to be able to query the CAP. New message altogether? Need WG
opinion.

MOP numbering: decided to use value carried in extended-MOP as is, not added
with MOP field. This way, can still use existing MOP values with CAPs turned on.

Pascal: coming back to capabilities: the configuration is when the root imposes
something, capabilities inform of what the nodes can do. Management can also be
used for the latter. Michael: are you saying you dont want CAPs for 8138 turn
on? Pascal: express the capability with this draft, trigger turn on/ok with
turnon8138 Pascal: we have devices in the field that need 8138. We need a way
to turn compression on, quickly. Let's ship turnon8138.

Rahul: Now that we have CAPs, less reliance on number of MOPs. Reduce current
24 bits downto 16? Seeking opinion. Rahul: suggest to split CAP and MOPEX into
two different drafts, they are independant things. Pascal: question to Alvaro?
Makes more sense to us engineers to split, but IESG might not like it. MOPex
very simple, we could flash it through. Alvaro: doesn't really matter. Would
prefer one document because easier to handle for IESG. But other
considerations. Either way is fine. Michael: I prefer 2 documents. Michael:
MOPex is RPL option, TLV format, so dont need to worry about it size now. Maybe
have a max to a reasonnable value. Like 4 bytes max. Pascal: agreed. Pascal: we
are essentially making a version 2 of rpl which is MOP 7 and MOPEX, packing all
the options. Rahul: will do a major revamp of the document based on this
discussion.

Ines: should P-DAO be a new MOP?
Pascal: no. There was great discussion on mailing list (by Rabi?). Use CAP to
project routes. No new MOP needeed. Rahul agrees.

Willing to review? (after split) Michael, Pascal, Remy
Michael: can we split quickly and adopt MOPEX quickly?
Ines: if split today, can adopt tomorrow

[17:40, expected 17:45]
Wrap-up

[17:40]
Session adjourns

===========================================================================================
Tuesday

Tuesday Nov 19, 2019 10:00-12:00 Singapore time (UTC+8)
+--------------------------------------------+-------------+------------------------------+
| Topic                                      | Time 120 mn | Presenter - On
site/Remotely |
+--------------------------------------------+-------------+------------------------------+
| Introduction                               | 5 mn        | Dominique/Ines    
          |
+--------------------------------------------+-------------+------------------------------+
| draft-ietf-roll-unaware-leaves             | 30 mn       | Pascal/Michael    
          |
+--------------------------------------------+-------------+------------------------------+
| draft-ietf-roll-useofrplinfo               | 10 mn       |
Ines/Pascal/Michael          |
+--------------------------------------------+-------------+------------------------------+
| draft-thubert-roll-eliding-dio-information | 20 mn       | Pascal/Dominique  
          |
+--------------------------------------------+-------------+------------------------------+
| draft-ietf-roll-efficient-npdao-17         | 10 mn       | Rahul/Pascal      
          |
+--------------------------------------------+-------------+------------------------------+
| draft-thubert-roll-turnon-rfc8138          | 15 mn       | Pascal            
          |
+--------------------------------------------+-------------+------------------------------+
| Open Floor                                 | 30 mn       | Everyone          
          |
+--------------------------------------------+-------------+------------------------------+

[10:03] session starts
Introduction                               | 5 mn        | Dominique/Ines      
        | Introduction (Ines, Dominique)
  - Note Well
  - Jabber scribe: Michael, minutes takers: Alex
  - agenda presented: no comments

[10:05, expected 10:05] draft-ietf-roll-unaware-leaves  (Pascal)
| draft-ietf-roll-unaware-leaves             | 30 mn       | Pascal/Michael    
          | Pascal presenting The draft is an application of RFC8505, PT: This
document is how a leaf would use 8505 to register to RPL services. Changes
since last time DCO is the only message that goes down to the leafs. This way
the router can say to a leaf that there is a problem. This document replaces an
empty message with explicit status. "RPL is like an extention of ND for
multihop".. this way at the end-node it is like pure ND There is a need to have
a mapping between the way ND expresses things and RPL does.

Explanation of how the status works - RPL -> 6LR -> unaware leaf. --

in ND you have ROVR - capability of the host to express that  own the address,
currently we are not using to protect RPL, maybe in future. For the moment, 
The ROVR is to signal to 6LBR in case that is not integrated to the root.
Currently is piggibacked in RPL

The RUL document has a normative reference to useofrplinfo, and not the other
way around. Defines the notion of leaf, which was used before but not clearly
defined. IPv6 host attached to a RPL network. The RUL document is one way to
indicate the route to a RPL unaware, not the only one possible. RUL is leaf
that is not aware of RPL.

As editor Pascal believes that the draft is ready.
1-2 reviews, than WGLC.

Who is willing to review? Rahul,,
Rahul: question regarding RPL status. Overlapping a lot of ND stuff onto RPL.
Pascal: new format has 64 values for RPL status and 64 values for ND status .
Doesn't seem we need more.

If the bit on the left is 1 then this indicates an err.-rejection
The ND is indicated if the second bit is ON.

Using status codes in RPL should be done via IANA.

Rahul: now that we have 6LR doing the signaling on behalf of unaware leaf,
PT: would not express it that way. In theory you could decompress on every hop.
Compressed form is equivallent to uncompressed; Rahul: so 6LR makes the
decision on behalf of the RUL, including data plane. PT: yes. If does not know
better, will decompress to forward outside of RPL domain, which is the case of
link to RUL.

[10:22, expected 10:35]
| draft-ietf-roll-useofrplinfo               | 10 mn       |
Ines/Pascal/Michael          |

Ines presenting

Terminology is modified. Added definition of RUL and the sections in SM that
have destination the RUL. We can have router as a leaf.

Pascal: link local encapsulation at every hop is gone. This is important change
to 6550, to be noted. Ines: The trafic destination is the 6LR

Pascal: question to Alvaro. Since this doc was taken out of RFC Editor queue,
what are the next steps? Alvaro (as AD): will look at ML, implement changes,
don't think will need to go back to IESG evaluation.

[10:27, expected 10:45]
| draft-thubert-roll-eliding-dio-information | 20 mn       | Pascal/Dominique  
          |

Pascal presenting
ANIMA likes RPL, cause  the configuration of router is learnt as part of the
protocol itself. The whole network is self-configuring itself RPL sorts itself
out, even with big number of nodes. When everyone understands the
configuration, there is no point in repeating it -> you can elide it.

However, if there is a modification in the configuration, it must be sent to
everyone.. repeat it until everyone got it, but then stop. Prefix informaiton
can be such information. 6550 does not say how/when elided info is sent again,
how nodes know things have changed. This draft introduces a number in DIO to
reflect changes in any option. If node has earlier version number, queries
router for updated options. Could have a version number of each option
individually, more selective but more costly. Would not scale well with
upcoming new options. Pascal suggests one single number for the set of all
options. Need review.

Pascal goes through the slides describing this.

Rahul: node sending DAO does not know which nodes are traversed. If something
has changed in the middle of the network, a sender node may not be aware of
that change. Pascal: intermediate node has to send full DAO info to parent that
is outdated, abbreviated info to parent that is fresh. Rahul: are we expecting
to keep every capability in every node? Pascal: capabilities are not part of
the DAO message, so they are not concerned with that Rahul: ok, we need to
clarify that capabilities are not concerned with this mechanism Pascal: it's a
simple draft, but it enables a live network to work much better. It makes the
network much more manageable

PIO is one of the protected option. Will be able to change prefix during life
of network. These changes (nicknamed RPL v2) will help keeping a netwrok alive
as opposed to stopping it and restarting it as with current RPL.

Child sending last RCSS to which this node is synced. The parent can then send
updated information to the child.

DIS changed to add flags to query each of the 5 protected options.
Is this needed? Is there a case when a child could want to ignore one fo the
options? We could send all 5 options in all cases and save the flag bits.

Part of discussion - can you detect a reboot of parent?
Yes - the straight part is very short, so it can be detected rapidly.

Resync would work even when parent is restarted, because the value will
increase beyond the last value.

Rahul: we need to talk about the lollipop counter.
Pascal: doesn't expect that the lollipop mechanisms is an efficient way of
detecting reboot. Trying to make the counter be such mechanisms. Rahul: the
question is about the length of the straight part. As short as possible, but
how long?

Alex: does this mean the nodes need to remember the full history of option
values as they change? Pascal: only remember version number of last change of
each option.

Rahul: dis modification draft is going to be included in the dratf, both are
going to be combined? Pascal: there was a draft on providing how the answer is
sent - multicast / broadcast, whether Trickle timer is reset or not. Pascal:
could we package and include it in this draft Dominique (as a contributor):
it's on the github (not published yet), can be merged. The two bits in DIS
modifications (leftmost in Pascal's draft) - unicast vs multicast DIOs. It's
all relevant to Pascal's options. Pascal: if we agree we can put this in this
draft. RPL gives a complex behavior, which depends on the request
(unicast/multicast) - the logic was hardwired. The bits should not signal if
you use trickle or multicast. The point is - do as RPL says, or inverse the
behavior. Dominique: I hear what you're saying, but the current RPL behavior is
too complex to just say 'reverse'. We need to work on this Pascal: yes, let's
discuss on the ML Pascal: the point is to see how DIS / DIO messages work
together Dominique: DIO must be send in multicast, you are going a step
further, so that the other nodes are also listenting to mutlicast DIS Pascal:
how do you derive a multicast address from a prefix. Here, everyone has the
same prefix, so we don't care about it. But we want to be able to form this for
the parent.. So the point is to have a multicast address that is just for the
partent and its children.

Rahul: comment on the whole utility about having a way of telling the other
nodes to hear the DIS and not sent it . The scenario when a node sends a DIS is
a one-off scenario. when all the nodes restart. Let's say that all send DIS the
problem is that trickle timer wont be reseted Pascal: there are two things. The
first is, that there may be misunderstanding of what it means to reset a
trickle timer. If your trickle timer is reset, you need to set i=0. If you
reset it again, there is no point in restarting the timer - that would be a
mistake and needs to be specified explicitly. Pascal: need to look up in the
trickle RFC, if it's not there, it should be corrected. Pascal: example with
200 power meters going down, powering up all they start in the same time, they
start sending DIS -> lots of collisons. That's a real problem, it's not
unusual. Dominique: we need to define use-cases Rahul: If we stop resetting the
trickle timer, and the definition reseting the timer goes to set it to Imin and
we let nodes send DIS, the DIO trickle timer wont get reseted and the other
nodes will hear the DIOs and will stop sending DIS. Pascal: as soon as the DIO
is sent, the cacathony stops, but that's an IF. There is a weird moment where
everyone wants to talk and nobody listens. There needs to be a winner.
Dominique: what you're describing is a Mediam Access problem. We should be
careful to design a solution at Layer 3 for a Layer 2 problem. We  can help it,
but not pretend we solve it all.

Dominique: there was a spreading option in our draft '(dis-modifications) - in
this case all parents responded in the same time. Pascal: not because of
trickle Dominique: not governed by Trickle, because you have unicast immediate
responce. This is where we had the option to delay the response and spread it.
We need to discuss.

Ines: do we need a document that describes what happens in the case when such
nodes get restared? Ines: have a section in each of the documents in cases when
a node gets restarted - that seems to be a recurrent issue in many of the
discussed points

Rahul: add some considerations for future new options and which possible to
elide them. Define sequence number and sequence counters. Pascal: if you could
write that in mail I'll be able to respond

Ines: we can publish the merged document and we'll go for adoption

Pascal: Dominique, the ball is in your camp, please make sure behavior is "bit
to revert behavior of current RPL". Dominique: yes, believe this is already the
case, but will double-check and then publish new version of draft.

[11:11, expected 11:05]
| draft-ietf-roll-efficient-npdao-17         | 10 mn       | Rahul/Pascal      
          |

Rahul presenting

IESG last call, reviews, update
Carrying RPL status as DCO
What we have - RPL Status format change

Pascal: Status - 'E' bit not set - the future of DCO a lot brither - instead of
being always a killer for the path, it can also send informaiton, and so be
more useful. One sentence somewhere in that spec, specifying that the 'E' bit
is rejection, but otherwise does not invalidate the path, then DCO can be used
to propagate information. I'd like to see this change in this draft. In this
way we can signal non-error information down the path.

Example: not an outright rejection (e.g. parent can signal - I'm getting
overloaded, if possible, switch to other)

Alvaro: that's a big change.
No way to enforce that value doesn't get changed along the way.
Not opposed to you doing this stuff, but will need a lot of review.
We have to be clear on the cases.

Pascal: if we keep the text as it is, that may create incompatibility issue.
The point is - if a node doesn't understand a message, the E flag indicates -
ignore the message, do not destroy the route. If this E flag is not understood,
that would lead to nodes destroying routes in any case.

Rahul: no way to enforce, but same is true to NP-DAO mechanism.

Ines:  request to update draft and we set a WGLC when ready

[11:19, expected 11:15]
| draft-thubert-roll-turnon-rfc8138          | 15 mn       | Pascal            
          |

Pascal presenting

Need to update brownfield (previously deployed)  a network.
DAG of thousands of nodes is not possible..

The whole network needs to use the same functions. If there is a mix of new /
old software in the same network, that would cause difficulty in operation.
Avoid flag day. Be able to upgrade nodes as possible, then when all nodes are
upgraded, use a bit to turn the feature on. Compression is one of the things
the DODAG must be synchronized on. Its not the same thing as capabilities.
Capabilities indicates wheter the new sw can do it or not.

There is not a strong tie between the configuration turning the network on and
having a capability that says that is available, having capabilites is useful
thing but we can live without it, cause we have to manage the devices that are
not based on capabilities.

Draft is stable.
It's the addition of one bit, that should have been there from the start.

Michael: was previously not happy with this proposal. The disconnect between
capabilities / turning on is now explained. Michael: capability could be used
to ask whether functionality is available in node. Would be nice, wish the
capability draft were advanced enough. Michael: support doing this - the
use-case of having thousands of meters being deployed over a period of several
years makes sense.

Rahul: agree with the use-case. Is is possible to generalize this mechanism to
be used for other uses? Rahul: consuming bits in CIO. Pascal: will have CIO
extension to providing more space in the future. Michael: why don't we make
this doc Experimental? Thus, then we have allocation of bits revocable. 
Alternatively, we could reclaim these bits in 6550-bis.

Pascal: could also say MOP 7 is RPL v2, and 8138 is mandatory in RPL v2.

Pascal: concerned about re-using bits later in the IoT world. Don't expect
operators to reflash firmware in field device just because a bit was deprecated.

Pascal: MOP = 7 could deprecate the other 2 bits.

Michael: we don't have that many of these bits, that's why we are anxious about
allocating them *forever*. We want to have a way to reclaim them in the future.
Maybe the doc should way that it applies to MOP=7 (both bits sets) (Non-Storing
- stroing probably not, open to discussion), and that this bit is undefined for
other modes.

Pascal: plan is to change draft to say "applies only fro MOP below 7".
Alvaro: other bits dependant on MOP or just this one?
Pascal: thinks its a first time
Alvaro: because, that would mean creation of a registry. You are sort of adding
columns to the registry. Adding additional semantics to a bit creates
additional columns. The regsitry needs to indicate the MOP to which this
applies. Pascal: where do we put it? In which draft? Here we can do it in the
two drafts under discussion, but we'll need to specify the generic registration
mechanism in a new draft. infrastructure draft to create space. Other draft to
use the bits. Michael: new registry for MOP 7. Pascal: one more change to
useofrplinfo to indicate the MOP to which the draft applies. Rahul: now we have
a dependency on this on PDAO, non-SM as segments in PDAO.  We have dependency
on non-storing mode. We want the ndoes to know that 8138 is on. Pascal: when
you send P-DAO there should be bit. You can have a network in storing or
non-storing mode, and only a path within it can support the compression. Rahul:
need ref from np-dao to this doc? Pascal: don't think so. Could say
decompression is inherited from the DAG.

Call for adoption: 8 hands for, no hands against. None on jabber/meetecho.
Will confirm on mailing list.

[11:54, expected 11:30]
| Open Floor                                 | 30 mn       | Everyone          
          | No requests/comments from the room.

[11:54, expected 12:00] end of session, end of ROLL meeting