* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Roll Status Pages

Routing Over Low power and Lossy networks (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2008-Feb-15 —  

IETF-102 roll minutes

Session 2018-07-17 0930-1200: Duluth - Audio stream - roll chatroom


minutes-102-roll-00 minutes

          |                                          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
                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
              * 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
              * 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
              * 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)
              * 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
              * 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
              * 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
              * 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
          [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
              * 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
          [11:51] Meeting adjourns

Generated from PyHt script /wg/roll/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -