Minutes IETF102: roll
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