Minutes IETF105: roll
minutes-105-roll-01
| 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 |
minutes-105-roll-01
+--------------------------------------------------------------------------------+
| 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