ROLL session at IETF 113 meeting
Meeting Material:
https://datatracker.ietf.org/meeting/113/session/roll
Agenda (UTC):
Minutes (UTC):
[12:00] Intro, WG Status
-
Note Well, Scribes, Agenda
-
no comment on agenda
-
WG status
-
NSA extension: AD evaluation, revision needed
- milestones: lagging by a year or 2, time to refresh
- proposing new dates (in years)
- Alvaro: my queue is deep, but you should progress as the WG can do,
and I will manage to reduce queue depth
- DAO Projection: Pascal: please start WGLC when you can, target
publication request May 2022
- Enrollment Priority: MCR: need to resolve what we need to do, doable
today, even. Sep 2022
- MOPEX: need several interim meetings to get to a final doc.
Implementations? Fall 2022.
- CAPEX: 2023
- DIS: 2023
-
YANG Model (was driven by Peter).
- MCR: I do not think we are going to finish it.
- Alvaro: need to change the charter to remove the item
- Alvaro: real question is how these networks are managed. Is it
YANG or something else? IESG focussed on manageability.
- MCR: we don't have on our charter a YANG model for RPL.
- MCR: this is about MPL, no deployments, do not think I can write a
management protocol for a protocol I have not implemented.
- Pascal: MPL used for WiSUN, WiSUN not using YANG. Until we have a
deployment that uses RPL and MPL and YANG, no resource to develop
this YANG model.
- Pascal: WiSUN uses CoAP-based management.
- Pascal: we could keep this in our charter, but not working on it
these days.
-
Source-Route Multicast: no progress. Pascal will see if it
integrates with multicast registration and MOP 5.
-
ACTION [chairs] update milestones, fix Enrollment Priority title.
Confirm on ML about YANG model.
-
AODV-RPL Status
-
open issues from Ben's IESG review and Pascal' s review
- Pascal: spent quite some time on this, 3 reviews. Slow progress from
the authors.
- Pascal believes it is unclear that this protocol works, as
specified.
- Pascal: I do not recommend to push the button for publication
request on this.
- Pascal: can do another review, but will not contribute.
- Alvaro: this went through WGLC, IETF LC, IESG evaluation, etc. Ben's
ABSTAIN can be read as "too much stuff missing, won't invest". Ben
is stepping down, will not spend more cycles on it.
- Alvaro: could technically push the button and get it through, but
it's not the right thing to do. Right thing to do is return it to
WG. Might sentence the document to death.
- Alvaro: too much concern has been expressed, have to push back to
the WG.
- Chairs agree.
- intro: basic RPL is dsitributed distance-vector proactive. AODV-RPL is
distributed reactive, this work is SDN-like controler-based routing
- slide 2 illustates notion of Track, Leg, Segment.
- RFC9008 specifies encapsulation that is taking place at Ingress of
Track (destinations are external destinations).
- in RAW, for energy/bandwith reason, need to select a subset of all
segments providing good enough reliability.
- got three thorough reviews.
- believes -24 fixes all GitHub issues. Multiple Targets left out, too
complex. Allowed to have multiple target options, but only first one
garanteed to be reached.
- Remous-Aris'es review still expected, should not block WGLC in the
meantime.
- Konrad's observation on interaction between new extension and Trickle
timer.
- Compromise to set the min priority at the root and not change it down
the DODAG
- will have to change DTSN if want to change priority
- MCR was reluctant to that
- think can solve the issue with extra lollipop counter, will put in
next revision
- not confident until put everything into implementation, no resource to
do this soon.
- Pascal: was one of proponents of setting fixed priority as you
propoagate down, demonstrated it could not work otherwise.
- Pascal: think lollipop is much needed, because might receive values of
different ages from different parents, and you don't which is fresh.
- Pascal: it does not balance the DAG, but other proposals did not
either.
- Pascal: the only way to balance is to look at the network from a
centralized perspective.
- MCR: worried more about nodes enrolling into parts of the graph that
do not having the capacity to support them. That is solved, right?
- Pascal: mapping priority into the beacon does. Now how do you do that?
- Pascal: many reasons for not wanting downward nodes to join. Because
of traffic? reduce traffic; Because of storing mode resources? use
non-storing; Because of non-storing mode resources? control the
beacon.
- MCR: could manipulate own beacon to protect own neighbor cache, true.
- Pascal: and descendants of your children not your problem, only
affects throughput.
- Pascal: keep the document simple. If neighborhodd cache problem,
control the beacon. If throughput problem, much more global problem.
- MCR: if value not changed from the root, do we still need lollipo
counter?
- Pascal: think yes, for the reason Konrad explainedd, might get
different values from different parents.
- MCR: are 4 bits enough?
- Pascal: I hope so. RFC6550 section 7 has 8 bits, do we ned that?
- MCR: two choices: add another byte, or steal from other fields.
- Pascal: to keep it simple, have a byte.
- ACTION MCR: will propose lollipop in -05, similar to 6550 Section 7.
- Ines: implementation on-going? will ask on the list.
- MCR on chat: I will implement, but I have other higher priority bugs,
so it might be some months before I can start.
- this work allows a node to register into a router and have the router
advertize address, for anycast and multicast.
- For multicast, we already had that in RPL with MOP 3, but we don't
have such a thing for non-storing mode.
- 6lo looked at extended 8505 (Extended Rgistration), no objection, now
extend to RPL. Goal is to extend RFC9010 (RUL) and RFC6550 (RPL).
- WiSUN 1.1 needs this.
- This draft uses MOP 5
- Q&A
- Question to Alvaro and Erik Kline: how do we do this work between ROLL
(RTG) and 6lo (INT)?
- Alvaro: ROLL chairs to talk to the 6lo chairs, and figure out way to
work together. One document, or two documents dependant on one
another.
- Pasacal: do you have preference for one or two documents?
- Alvaro: no preference.
- MCR: it wasn't clear in 6lo that this doc fit their charter. Was
reason to have several documents.
- Alvaro: it's common to have documents that span several WGs. Leave it
to you to decide. Will talk to Erik nonetheless.
- Dominique: sure, we'll do.
- Pascal: the big work is on the RPL side.
- ACTION: chairs engage with 6lo chairs.
[13:04] Meeting adjourns
Online exchanges
Ines Robles
Michael, about the red issue (change in min priority - topological
change) in your slide, the answer is no, right?
13:00:15
Adnan Rashid
are not both protocols dependent to each other? I mean rpl and
6lowpan-ND.
13:01:47
Carsten Bormann
6LoWPAN-ND is NOT dependent on RPL.
13:02:22
Adnan Rashid
yes.
13:02:37
but rpl is?
13:02:40
Ines Robles
yes.
13:02:37
but rpl is?
13:02:40
Carsten Bormann
RPL may want hosts, and needs ND then.
13:02:52
Adnan Rashid
ok