Minutes IETF102: roll
minutes-102-roll-00
| Meeting Minutes | Routing Over Low power and Lossy networks (roll) WG | |
|---|---|---|
| Title | Minutes IETF102: roll | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2018-07-18 |
minutes-102-roll-00
+--------------------------------------------------------------------------------------------------------+
| AGENDA ROLL IETF 102
|
+--------------------------------------------------------------------------------------------------------+
| Date: Tuesday, July 17, 2018 (EDT)
| |
| | Time: 9:30 - 12:00 -
150 minutes - Morning session I
| |
| | Place: Duluth - 2nd Floor/Convention Floor
|
+--------------------------------------------------------------------------------------------------------+
Agenda
Time | Topic
| Presenter |
+---------------+----------------------------------------------------------------------------+------------+
| 9:30 - 9:40 | WG Status - Introduction
| Peter | | (10 min) |
| |
+---------------+----------------------------------------------------------------------------+------------+
| 9:30 - 10:10 | BIER-ROLL Design team
| Toerless | | (30 min) |
| |
+---------------+----------------------------------------------------------------------------+------------+
| 10:10 - 10:20 | Efficient Route Invalidation
| Rahul | | (10 min) |
draft-ietf-roll-efficient-npdao-03 |
|
+---------------+----------------------------------------------------------------------------+------------+
| 10:20 - 10:30 | Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks
(LLNs) | Charlie | | (10 min) | draft-ietf-roll-aodv-rpl-04
| |
+---------------+----------------------------------------------------------------------------+------------+
| 10:30 - 10:45 | Root initiated routing state in RPL
| Pascal | | (15 min) | draft-ietf-roll-dao-projection-04
| |
+---------------+----------------------------------------------------------------------------+------------+
| 10:45 - 11:00 | RPL Observations
| Rahul | | (15 min) |
draft-rahul-roll-rpl-observations-01 |
|
+---------------+----------------------------------------------------------------------------+------------+
| 11:00 - 11:10 | RPL DAG Metric Container Node State and Attribute object type
extension | Aris | | (10 min) |
draft-koutsiamanis-roll-nsa-extension-02 |
(Remotely) |
+---------------+----------------------------------------------------------------------------+------------+
| 11:10 - 11:20 | Traffic-aware Objective Function
| Aris | | (10 min) |
draft-ji-roll-traffic-aware-objective-function-01 |
(Remotely) |
+---------------+----------------------------------------------------------------------------+------------+
| 11:20 - 11:35 | A YANG model for Multicast Protocol for Low power and lossy
Networks (MPL) | Peter | | (15 min) | draft-ietf-roll-mpl-yang-01
| |
+---------------+----------------------------------------------------------------------------+------------+
| 11:35 - 11:50 | Routing for RPL Leaves
| Pascal | | (15 min) |
draft-thubert-roll-unaware-leaves-05 |
|
+---------------+----------------------------------------------------------------------------+------------+
| 11:50 - 12:00 | Open Floor
| Everyone | | (10 min) |
| |
+---------------+----------------------------------------------------------------------------+------------+
Meeting notes
[9:30] Meeting starts
* Jiye helping replace Inès at this meeting
* Blue sheets, notetakers, Jabber scribe, Note Well
* Agenda : no change requested from the room
[9:31] WG Status - Introduction (Peter)
* use of rpl info is in AD evaluation.
* Alvaro (AD): about half-way through.
* two open tickets. will be addressed today.
[9:36] BIER-ROLL Design team (Toerless)
* Last meeting, Carsten and Pasal presented their drafts. Carsten compress
bit streams with Bloom filters. * with BIER-TE, bits can idicate hop by
hop. * Carsten: * considering interest, Design Team formed. Wiki page.
Adminitrativia took time. * Toerless' own analysis follows. * Use case :
with IP multicast, bit field at application layer to turn on eahc light.
With BIER, bits at the nw layer. * Greg Shepherd: * with Bloom filter,
packet may reach un-intended nodes. * Carsten: you just described why Bloom
filters is not what you want for identifying nodes. Only to identify
forwarders. Okay to have occasional false positives * Pascal Thubert:
advantage of BIER is a state per child instead of a state per leaf.
Significant adavantage. * Toerless: agreed, did not repeat it. * duplicate
paths * Carsten: RPL builds DAG. Additional per packet state to reduce
exponential width. * Pascal: info on RPL: loop-less not because of perfect
DAG but also dataplane validation with the O bit. * Toerless: many
mechanisms, wil need to sort out between them. * Carsten: no way to
preventreceiving duplicates.\ * Toerless: IETF does not like mechanisms
thatcreate persistent duplicates. * Carsten: one observation is how you
process the duplicates. Another observation ... ?? * Toerless resumes slide
presentation, non-Bloom stuff. * Pascal: some PHY layers have limited frame
sizes, like 120 bytes (IEEE 15.4) or less. Places limit on bitstring. *
Carsten: in constraincast, only allocate bits for the output interfaces of
ndoes that forward. * Carsten: a use-case is ligthing system with hundreds
of nodes and small paylaods. 32 bytes for the Bloom filter was
the benchmark, more is getting difficult.
* Pascal: a lot we can do for unicast. For unicast, bitmap not in the
packet, everything is compressed (6loRH). * Toerless: lossless compression?
* Pascal: yes. FOr unicast, BIER is a compression method much better than,
say, 6LoWPAN. * Toerless: what about multicast? * Pascal: for a few
destinations, still efficient compression. * Carsten: compression technique
influences architecture beacause if compressing bits or addresses, very
different approach. * Carsten: 128 bits per interface in IPv6, * Toerless:
history at ROLL of method of signalling end-node driven. If
root-controlled, can do other stuff like renumbering, etc. * Carsten: in
our use-case, controller outide the RPL domain. * Toerless: throw the
concerns at me / the DT so we can address them. * Carsten: root node could
be a CoAP proxy. Root node would have to find the BIER bits needed to reach
the destinations. * Toerless: BIER WG would be happy to work on a use case.
* Pascal: normal BIER in storing mode, and BIER-TE in non-storing mode. *
Closing remarks: lots of cool things can be done. Would need a few typical
topologies to look at and evaluate the appropriate BIER solutions. *
Pascal: agree on root-inititiated bitmap assignement. Already the way to
get a short address and other info/state. Same flow. Totally consistent *
Pascal: regarding RPL compression, it is RFC8138, just waiting for BIER. *
Peter: thanks to Toerless for setting the Design Team, expecting to see
work. If anybody wants to join, let Toerless or the chairs know.
[10:10] Efficient Route Invalidation (Rahul)
* no recent change to the draft, comments received (Georgios, Pascal).
* WGLC is over.
* Peter: would expect more reviews following all the discussions. Another
review? * Pascal: many WGs have had WGLC in the last 2 weeks. Very busy
times. * Peter: volunterr? * Remy volunteers. Thanks
[10:14] Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs) (Charlie)
* WGLC
* uncovered error condition, extremely rare but can happen.
* as a result, DT came up with version -04.
* recall that value of OADV-RPL is with assymetric links.
* could not figure out how multicast in 6995 supposed to work, would be
extremely inefficient with OADV-RPL, just disallowed it. * Pascal: good
work. Confused with pairing of RPL instances. Matching two t-uples. *
Pascal: IP address of the root, in response associate own address. * Remy:
two originators * Pascal: in the route reply, should have a field to add
own id, for pairing. * Remy: multiple requests, multiple instance pairs. *
Will take it offline * Rahul: pairing of DoDAGID central to this draft,
needs to be known at each intermediate node. * Charlie: we don't introduce
very much overhead for this pairing. * Rahul: in this draft, shifting.
Still collisions on InstanceIDs are possible. * Pscal: local assignement,
first bit tells direction. * Peter: we need more reviews for this draft *
Pascal volunteers. * Peter: another volunteer? * none
[10:32] Root initiated routing state in RPL (Pascal)
* discussion on ML about implementation complexity.
* Michael asked about mechanism to know capabilities of device. In the
protocol or out of band? * In this document or another document? * Rahul:
different draft. * Pascal: IMO, this draft is about establishing route.
How get to know what to establish is another draft. * risk of loops with
loose Source Route, wrote text to say what the requirements are. Still
thinking about something like the o-bit. * how do we signal Mode of
Operation? Only 3 bits, which are already saturated. * Shows list of
discussion items. Invites discussion. * projected route is not necessarily
the same mode as the RPL netwrok around it: eg project stroing into
non-storing network. * Pascal: historic over-simplification that modes
cannot be mixed. How do we introduce mixed mode back. * Rahul: each mode
has own benefit. In our implementation, want to have both.
[10:45] RPL Observations (Rahul)
* feedback on smart meter smart grid deployement with 1000 nodes.
* DTSN. Should it be lollipop counter or not?
* recommends yes, needs to write to flash memory only in the linear region.
* Pascal: drawinng in slide is inaccurate.
* Pascal: this discussion is very valuable. Should be in a 6550-update
draft. What do the chairs think? * Peter: was mentionned a few times
before. Will think about it. * when should DTSN be incremented? Pros and
cons discussed. E.g., on parent change. * Pascal: depends on reason for
re-parenting. If node moved, in stable environement, good chances that
children are still there below, should send DAO upward on behalf of the
children. In a more dynamic envirnement, children probably no longer under
that node. * DAO-ACK. In storing mode, how does the node know the DAO has
made it to the root? Contiki changes behavior to end-to-end
acknowledgement. * Pascal: intend was to acknowledge hop by hop,
immediatley. If DAO cannot be sent upward, intermediate node needs to
reparent. Or posion downward if cannot. * Rahul: intermediate node goes
away after sending DAO-ACK donward and before sending DAO upward. Cannot
poison. * Pascal: a node has to monitor its parents. If new parent, send
DAO again. * Pascal: if no parent with enough storage for your DAO, this is
a netwrok problem, not a protocol problem * Rahul: might the reason why
people are moving away from storing mode. * Simon Duquennoy * Pascal: RPL
design assumption that every node must have enough memory space for ... *
Pascal: would definitely need to clarify what RPL is supposed to do *
Rahul: still possible to do a much better mechanism. E.g. sending the
DAO-ACK all the way fro the top. Could aggregate DAOs up, maybe even ACKs
downward. * Pascal: this is really different, warrants a discussion on the
ML. * another few observations. * Peter: authors asked for adoption.
Discussion on this. Reviez qnd write optinion on MLon adoption * Pascal:
great work. But not sure that would be a WG document. Repository of
observations. Why send to IESG. * Alvaro: adoption does not mean that it
gets published. Adoption can ensure this is stable. Anyway, dont sent to
IESG document contianing observations.
[11:10] RPL DAG Metric Container Node State and Attribute object type extension
(Aris from remote)
* -02 update.
* published Contiki implementation and Wireshark dissectors.
* a few issues have been raised, will discuss them
* aiming at determinism: reliable comm, low jitter.
* mechanism for alternative parent selection with path that does not
diverge too much from that via preferred parent. * Uses DMC in DIO.
Introduces optional TLV in NSA option of DMC. * shows Wireshark dissection.
Option carries (at least) 2 IPv6 addresses * compression with 6LoRH. to be
implemented in Contiki * strict-medium-relaxed selection algrithm. Relaxed
leads to flooding (Ad-Hoc Now 2018 paper). * Peter: is implementation
available? * Aris: * Peter: who has read this draft? 3 * Pascal: wired-kind
of thinking does not apply to wireless. This is the first effort that
thinks wireless. Overhearing amkes the packet progres. * Pascal: kind of
revolution, pay attention.
[11:25] Traffic-aware Objective Function (Aris)
* Objective Function for load balancing.
* draft introduces Packet Transmission Rate metric. To be sent through DIO
container. * would be used to select parent that has less load. * proposes
to add Child Count or PTR in negative DAO-ACK. * other issues being raised,
drafts in preparation. * Peter: several individual drafts asking for WG
adoption. WG has a lot on its plate already. * Peter: will send mail on ML
listing th enew drafts and asking for interest and reviews.
[11:33] A YANG model for Multicast Protocol for Low power and lossy Networks
(MPL) (Peter)
* recents changes
* Peter working alone, looking for peer review, comments, contributions,
collaborative works. * will not work further on this unless gets
contributions * Rahul: appropriate for observation measurments * Peter:
observable and settable.
[11:35] Routing for RPL Leaves (Pascal)
* this draft enables a node that is not aware of RPL at all to be a host in
a RPL network. * keepalives : DAO, DAR/DAC * 6LoWPAN has registrar which is
LBR. In RPL, Border router is the root. Should they be the same? * design
decision that root is identical to 6LBR or not necessarilry. * opinion
sought. * changes in 6LoWPAN-DN * in 6LoWPAN-ND, Charlie did a lot of great
editorial work. * orginial 6LOWPAN-ND only to register to 6BBR. Now, two
routing protocols that use routing registrar (RPL, RIFT). * in 6550, a leaf
understands RPL but does not forward packets. * a RPL unaware leaf (R flag)
does not know RPL. * uses the newly introduced opaque field in 6LoWPAN-ND
to carry the InstanceID. * in address-protection odraft, introduce a ROVR
to prevent injection of malicious DAR * Rahul (relaying Absussalum on
Jabber): * root could send the keepalive EDAR to the 6LBR, and NS(EARO) to
6BBR. * if 6LBR and root are always the same, can simplify this a lot. *
Pascal: call for adoption? * Peter: will be listed in the same email
[11:49] Open Floor
* Rahul: anybody working on integrating RPL into Linux kernel? Or any other
routing protocol? * Toerless: have you been to NetDev? * Rahul: yes, was
there. * Pascal: talk to Michael. * Rahul: will do. Question on ruting
table integration into Linux kernel.
[11:51] Meeting adjourns