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