Subject: [Roll] ietf 101 minutes

From: peter van der Stok <[email-masked]>
Date: Thu, 05 Apr 2018 11:15:43 +0200

Hi ROLL

the meeting minutes of ietf101 in London are uploaded to
https://datatracker.ietf.org/doc/minutes-101-roll/

Many thanks to Dominique and Georgios for the minute taking.

Have a look and correct factual mistakes.

many thanks,

peter
-- 
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Apr 2018 10:58:02 -0400

https://datatracker.ietf.org/meeting/101/materials/minutes-101-roll-00.txt

ROLL meeting
Thursday 21 March; 9h30 - 12h00

Peter and Ines: Introduction (10 minutes)             .

Papadopoulos: object function             (15 Minutes)
draft: draft-ji-roll-traffic-aware-objective-function-00

Papadopoulos: RPL DAG Metric Container    (15 minutes)
draft: draft-koutsiamanis-roll-nsa-extension-01

Rahul: discussion of open problems          (30 minutes)
draft-rahul-roll-rpl-observations-00

Carsten (and Pascal) use of BIER in RPL uni- and multicast (45 minutes)
draft-ietf-roll-ccast-01
draft-thubert-roll-bier-01

Michael (and xxxx): Parent selection before or after enrollment (30 minutes)
draft-richardson-6tisch-roll-enrollment-priority-00

5 MINUTES open MIC to discuss continuation

Note takers
- Dominique Barthel, Georgios Papadopoulos
- more welcome!

Meeting notes

[9:30] Meeting starts
[9:30] Introduction (chairs)
    * Note Well, note takers, blue sheets, Note Well
    * updated the milestone list to more realistic target dates
    * Active internet drafts
    * notice IPR on two drafts, mail was sent out. Please react
    * Peter: this time, long ROLL meeting. Many topics to discuss. Want to get some feedback on the length of this meeting
    
[9:36] draft-ji-roll-traffic-aware-objective-function-00
    Aris: is presenting his draft on Load Balancing
    * new routing metric container proposed.
    * simulation results
    * the proposal is developed over Contiki OS (and Cooja simulator)
    * number of DIOs sent as a measure of network stability: this proposal does a bit better than state of the art (i.e., MRHOF, Child Count draft)
    * open questions: packets or bytes? time units? assumption of homogeneous forwarding cpapacity of nodes, should we send capacity as well in DIO?
    * how to relate energy consumption to packets/bytes sent?
    * 
    * Shall this value be integrated with EB/IE, 
    * Giorgios: this is layer 3 info, should not get into EB
    * Rahul: interesting work, done something similar
    * Aris: let compare notes
    * MCR: your diagram on slide 12, how do you ensure node 7 attaches to 4 in order to allow 5 to accommodate 8? 
    * Michael: there should be more experiments with more children per parent, to see the impact of overloaded children per device
    * Rahul: OF here only takes packet transmission rate into account.
    * Aris: would use other metric as well, and this one as a secondary metric.
    * Charlie Perkins: 
    * Charlie: study stability
    
[9:49] RPL DAG Metric Container (MC) Node State and Attribute (NSA) object type, extension (Aris)
    * New TLV proposed in NSA object, for packet replication and elimination
    * already presented at Singapore
    * aim is determinism for reliability
    * The employed mechanism is the so-called Packet Replication and Elimination (PRE)
   * key point is to select the alternate parent to send replica to
   * idea is to pick alternate parent that has common ancestor with best parent.
   * new TLV contains IPv6 addresses so that ancestors can be learnt
   * wireshark dissector was written
   * drawback is size of IPv6 addresses that are sent. Compressed out some of it.
   * The idea is to keep the default parent and alternative parent so that to have the parents as close as possible to allow overhearing
   * MCR: to compress IPv6 addresses, look at 6LoRH header, code available
   * Carsten: your draft has NSA in the title ;-)
   * Peter: how does your proposal co-exist with other parent selection draft?
   * Aris: this is just a Constraint, not a metric. Can work with OFs
   * Pascal: the OF at IETF are simple, but more metrics exposed. OF should be piece of logic. Your OF would be one with high level of intelligence.
   * Peter: would be nice if this draft reflects how it interacts with OFs
   * Ines: this is of interest to ROLL, also needed by 6TiSCH
   * Pascal: 6TiSCH does not *need* this, but a solution that benefits from 6TiSCH would also benefit from this.

[10:01] draft-rahul-roll-rpl-observations-00 (Rahul)
    * just observations of issues, no solution here
    * Smart Meter networks, 60 hops, thousands of nodes
    * issues mostly related to storing mode
    * how to handle DTSN increment? want to also check how BIER does
        * issue is DAO not getting through to the Border Router. Need for some redundancy. Re-transmit at every DIO Trickle timer interval?
        * has seen 10% of nodes not joined, for a long time.
        * on parent switch, should node increment DTSN
*  * (Dilemma 2) On parent switch, should node increase its DTSN?
        * DAO-ACK: could be a solution if were handled properly. Current RPL spec has multiple interpretations possible.
        * Contiki (new) implemented DAO-ACK hop-by-hop. RioT implements end-to-end.
        * RPL spec say aggregated target is possible, but how to handle failure?
        * problem will show on multiple hops, not simple one-hop network
        * third proposal: downside is aggregated ACKs is not possible.
    * handling node reboots: how is RPL state is maintained.
        * not acceptable to write to flash repeatedly (endurance issue). Incrementing DTSN 5 times a day is a problem, reportedly
        * Carsten: what level of ?? are you considering? 
        * Rahul: numbers in the draft, please look at them and comment
    * handling resource unavailability
        * neighbor cache full, routing table full: how do you signal it?
        * impacted packet delivery rate in this experiment. Some ideas for workaround, but would like to hear about other's experience.
    * MCR: excellent work, should adopt it. Lots of useful points. Hadn't realized that the spec was ambiguous.
    * MCR: one document with solution: e.g. DTSN increment is clearly a bug in the spec.
    * MCR: another document to discuss issues we don't have a solution for.
    * Pascal: agrees to thank for the work, not so much for the rest that michael said.
    * Pascal: a bit of history: left a few things open when writing spec because did not know what to decide. Don't rush to immediate solution.
    * Pascal: RPL is not just for wireless. It's a routing protocol. Also used on wires.
    * Pascal: explains thinking about DAO-ACK. We need something to solve the end-to-end delivery.
    * Pascal: version rebuilds everything, DTSN " repaints" the DAODAG. Discrepancy is found when seeing traffic from unknown node. 
    * Pascal: wanted capability to rebuild the network intelligently by having a timer that is long enough so that ...., never specified that.
    * MCR: seems Pascal agrees. Just clarified a lot of things. 6550 did not capture that clearly. Low hanging fruit document should only include non-controversial points.
    * MCR: a bunch of knowledge just exposed, glad it's captured on tape. Want to capture it in text quickly.
    * Rahul: will go to the mailing list to get consensus on what is non-controversial
    * Ines: a document for the problem statement and links to solutions
    * Pascal: problem statement does not need to be published
    * Peter: draft could expire.
    * Rahul: understand could maintain this draft as long as needed, and develop solutions in other documents?
    * Carsten: in the past in RoHC WG, have kept a standing doc for 5 years.

[10:31] draft-ietf-roll-ccast-01 (Carsten)
    * this is more than 5 years old.
    * thought it would be good to have multicast for non-storing mode.
    * result of a " constrained-cast"  reseach project.
    * in 2014, BIER appeared, revived interest.
    * Carsten shows tutorial slide. Efficient representation of lists of data. Bloom filters, dating back 1970's.
    * False positives create spurious transmissions, energy consumption. How bad is it? In dense network, gets worse. Still, can leave with some of it
    * False positives depend on number of bits allocating. Two many bits is also a problem.
    * Matt Gillmore (Itron): 
    
[10:40] draft-thubert-roll-bier-01 (Pascal, Toerless Eckert)
    * has backup slides to explain how BIER works with RPL, look at them at the back of the presentation or ask me to present them
    * can be used in storing or non-storing, unicast or multicast
    * Carsten: *set* vs. *sequence*
    * Pascal: set out to write a doc showing how all 4 cases can be done.
    * with bitmap, amount of storage is related to number of children, which can be controlled. Could revive storing-mode.
    * BIER-TE specifies bits for each hop to follow. False positive create forwarding to wrong path
    * Toerless: don't we want rough characterization (overhead, resources) before writing the drafts?
    * Pascal: Bit-by-bit fits the BIER architecture. Bloom filter needs some adaptations.
    * Carsten: comparing different metrics: good way to compress bit fields. Number hosts (storing mode) of forwarding nodes (non-storing mode).
    * Pascal: 200 hosts, how many bits do I need?
    * Toerless: 
    * Carsten: bit assignment can be managed with RPL, with ND.
    * Carsten: could look at more ways to compress bitmaps. Could get efficiency close to that of Bloom filters.
    * Carsten: I' m interested in non-storing mode
    * Pascal: could use 
    * Carsten: non-storing case is slightly simpler, because the actual source is always the root. 
    * Pascal: with Bloom, creates a problem. By contrast, bit by bit allows to send multicast from inside the network. This is a differentiating point
    * Pascal: work to be done at BIER: allocation of bit to address, 
    * still work to be done to compress RPL control plane messages (DIO, DAO, ...)
    * Toerless: what 's the packet format? can we replace IPv6 header with BIER header?
    * Pascal: compressed form, but packet complies with the IPv6 architecture. Can always reconstruct the full IPv6 packet using the implicits.
    * Pascal goes through RPL tutorial slide. Bit allocation. Aggregating bits in DAO operation.
    * Giorgios: what do you do if too many nodes?
    * Pascal: Bier can do groups.
    * Pascal explains how to forward messages based on bitmaps.
    * can be made reliable with ACK, which are OR'ed together as they go back up.
    * Peter: is there interest in the working group for this work? Humm now: humms heard.
    * Peter: anybody opposed? Speak up now.
    * Carsten: IPR?
    * Peter: propose to start design team.
    * Carsten: send lawyers
    * Toerless: isn't it always the case? Can create a design team and see later if proposed options are covered with IPR.
    * Peter: suggest Carsten, Pascal, Toerless, Olaf, Greg, Ijsbrand (Cisco), Giorgios, Emmanuel.
    * Peter: Toerless to coordinate.
    * Peter: DT to create doc with alternatives, IPR info.
    
[11:16] draft-richardson-6tisch-roll-enrollment-priority-00 (Michael)
    * set of requirements coming from 6TiSCH to do in ROLL.
    * not specific to 6TiSCH, though.
    * Problem is network selection. Given a node that can hear many routers belonging to several networks, which one to select?
    * Would like to not have to try all routers, but rather know which network they belonging too without revealing too much.
    * We need to do DODAG selection, inside a network.
    * if different PANIDs, probably different keys.
    * Carsten: if secret handshake, none of the two parties disclose anything to a third party. 
    * Michael: not quite the same problem.
    * our objective is node not going through all networks
    * Carsten: done with SSID
    * MCR: no SSID in 15.4. Has PANID, but too short and other problems.
    * in 6TiSCH, IE to contain
        * proxy priority: reflects resources allocated for unknown nodes wanting to join
        * R says if it will answer unicast Router Solicitation
        * network ID
        * DODAG priority: reflects willingness to accept new traffic.
    * Carsten: this reveal node is trying to join
    * MCR: secret handshake in zero-touch way, would love it
    * Thomas: emphasizes waste of energy of blind search. This helps a lot. Real use case.
    * Pascal: agrees with Thomas. Mostly interested in DODAG priority. In the field, we see instability in structures that we build. Oscillations.
    * Pascal: load at the root is the load of thee network. Work to do is to end up with balanced situation
    * need new metric container. Will be transmitted unchanged as DIOs go down the network.
    * new DIO configuration option. To convey the new network ID.
    * Pascal: your new metric does for the whole network what an OF does for a node. 
    * Pascal: number of node left, amount of bandwidth left. Not so much percentages, because could translate to different absolute values.
    * MCR: in storing mode, as RPL is now, we don't know the load of the nodes
    * Peter: can you say again what this documennt is exactly about?
    * MCR this is just the description of a DIO container. Maybe suggest way of calculating this metric.
    * Peter: parent selection in another document? 
    * MCR: true.
    * Peter: who's read? who's willing to review? who thinks we should adopt?
    * Ines: we'll go to the mailing list.
    
[11:43] Open mic
    * Aris: finds all problems discussed very interesting. What about replicability? how to share information that would allow to reproduce situation in simulation
    * Rahul: agree it's a big issue. Working on a framework specifically for this. Whitefiled? framework.
    * MCR: F-interop is also very cool.
    * MCR: been the case in ROLL WG that issues were reported but no detailed info was available to simulate/replicate issue.
    * MCR: Cooja runs Contiki, does not allow to compare RIOT and Contiki implementations.
    * Thomas: there's a lot to verify. F-interop to verify interoperability. For performance, 6TiSCH python simulator and interface. Allows to enter a scenario and get graphs.
      Only part of the answer to your question, but still something.
    * Ines: introduces tomorrow's meeting.
    * Peter welcome feedback on time of this meeting. Do you prefer longer or shorter one?     
    
[11:51] meeting ends

=====
Friday meeting

Friday 23/3 9h30-11h30

Ines+Peter: Introduction (5 min)

Charlie: Asymmetric AODV-P2P-RPL in LLNs (15 mins)
draft-ietf-roll-aodv-rpl-02 

Pascal: ND only device connects to RPL DODAG. (20 mins)
draft-thubert-roll-unaware-leaves-01

Rahul: DCO performance report (15 mins)
draft-ietf-roll-efficient-npdao

Pascal: Objective function specification and selection for parent selection, DAG selection  (30 minutes)
draft-thubert-roll-unaware-leaves-01

Pascal: Root initiated routing state in RPL      (15 mins)
draft-ietf-roll-dao-projection-02 

Dominique: state of Dis-modifications (5 min)
draft-ietf-roll-dis-modifications-00

xxxxx: RPL-load balancing (15 mins)
draft-qasem-roll-rpl-load-balancing-02

15 MINUTES DISCUSSION: All: Discussion on new subjects
Which topics and priority,
Authors,
Reviewers.

[9:30] Meeting starts

[9:31] Routing for RPL Leaves (Pascal)
    * original idea was low cost nodes roaming through 6LRs.
    * called a leaf, is RPL-unaware. Does not know RPL is being used. Only uses 6LoWPAN ND
    * had to change 6LoWPAN-ND because fabric has to know what is the latest location, so that it can route to the leaf
    * comparing timestamps does not work because tolerance on timers and mobility speed unknown
    * now, source generates a sequence. Ordering becomes obvious
    * also change source address validation. Address could be spoofed (stolen) and traffic diverted.
    * association mechanism mimicking that of 802.11. Leaf pro-actively installs  state in the 6LR (equal to AP in 802.11) so that the 6LR knows has to forward multicast
      traffic for this leaf
    * this supports RPL but also any other similar routing protocol
    * Pascal shows the address validation mechanism. ROVR is token to prove ownership of address. Only proves address on first hop
    * new spec: leaves set the R bit to 1 to instruct 6LR to inject this address into routing
    * Transaction ID is a sequence counter to be injected into the DAO Path Sequence Number.
    * Rahul: Path Sequence is optional
    * Pascal: believe it is mandatory. Otherwise, we have a problem
    * Rahul: will check.
    * Registration lifetime: in ND, expressed in minutes. In RPL, configuration that tells the time-unit.
    * Rahul: Transit Info not mandatory
    * Pascal: will check
    * Rahul: none of the open source RPL implementation currently use Path Sequence.
    * Pascal: if the MUST is missing, this is a bug. We'll look at it offline.
    * Pascal: still lacking a reference open-source implementation of RPL. Do not judge the quality of RPL by the quality of some implementations out there.
    * shows message exchange diagram. New spec mandates 6CIO option from 6LBR down to the 6LRs.
    * Peter (from the floor): what happens if we mix 6LR with and without the new option?
    * Pascal: the spec discusses this. It works. On security side, weaker because smaller keys. Spec recommends a leaf attaches to a "new" 6LR. An old 6LR on the way from the attachment 6LR and 5LBR is okay.
    * signaling is in the 6775-update doc, how proxy operation is done is in the backbone doc.
    * Got reviews from IESG, not quite closed yet but looking good.
    * shows diagram on address validation: protects the legitimate owner against other nodes trying to steal that address.
    * re-iterates that only first hop is protected, RPL is not.
    * we'll discuss on the mailing list on Rahul draft (DAO-ACK).
    * Pascal: if you're implementing RPL, understand that when a 6LR accepts a DOA from a child, it takes responsibility for transmitting ii up.
    * is the RPL root the LBR? technically, could be separate. In Pascal's mind, should be the same
    * big discussion that needs to be had: do we MUST that 6LBR and RPL root are one?
    * proposes to use RPL DAO to accomplish what DAR/DAC does.
    * remember that RPL will not do DAD, since ROVR doesn't go to Root.
    * summary: very simple node roams smoothly across meshed 6LRs, many DODAGs.
    * on terminology: RPL defines "leaf", a node that understands RPL but does not route. This draft defines "unaware-leaf", a node that doesn't even understand RPL.
    * pre-requisite: 6775-update, IP-in-IP, RPI header
    * if 6LBR was not RPL root: could make it work, no too sure.
    * do we have a use case for it?
    * Peter: who has read the draft? a few hands?
    * Peter: is this 6Tisch-related? useful to 6TiSCH, but not even routing-related.
    * Pascal: simple work, but really important. Most of it done at 6lo.
    * Pascal: had this dream from the start, could not implement it with RPL, now can.
    * work not quite done yet, if you are interested, join in.

[10:15] Asymmetric AODV-P2P-RPL in LLNs (Charlie)
    * allows asymmetrical routes between nodes pairs.
    * went into last call, got lots of comments
    * most extensive comments: some features of P2P-RPL not implemented in OADV-RPL. As a result, attempted to include these.
    * discussion on use of DSTN for sequence number.
    * Pascal: two sequence counters coming down from the root. One when new DAODAG is built (version number), rebuilding a new DODAG including reparenting.
    * DTSN is to refresh the state associated to current topology.
    * what exactly is your destination sequence number?
    * Charlie: not sure, will have it as a separate discussion.
    * will suggest using OADV's feature to deal with uni-directional links.
    * this draft was published quickly to meet the submission deadline. Will get a revised version soon.
    * Pascal: original P2P-RPL used DIO for RReq and DAO as RReply. Needs a certain degree of bidirectionality.
    * Pascal: Charlie, your work is the only one that uses DIO both ways to discover the route. This is good:
      P2P-RPL uses DIO in one way and DAO the other way, does not work as well in presence of asymmetrical links.
    * Pascal/Dominique: discussion on the causes for asymmetry.
    * this draft defines new RREQ/RREP option. Imported from 6997
    * new target option.
    * had discussion on pairing of InstanceIDs (one for each direction). << missed part of it>>>>
    * to be done
        * citing 6997 cannot be normative, because it's experimental.
        * InstanceID conflicts
        * import black-hole link detection of OADV?
    * Rahul: you said asymmetrical link detection is out of scope.
    * Charlie: could make it in scope
    * Rahul: the probing of links for asymmetry should not be in scope
    * Charlie: the metric should be there
    * Pascal: doesn't seem we need to do anything. Building another DAG, using DIO. If a link is asymmetrical, flooding will not happen, that's it.
    * Peter: would like this document to be completed. Have this discussion on the mailing and get to a conclusion in the next few weeks.
    
[10:38] Route invalidation, experiment report (Rahul)
    * remember NPDAO sent downstream
    * DCO and NPDAO operating at same time in the network.
    * report link sent on the mailing list a month and half ago
    * two topologies, 50 and 100 nodes. All nodes are started at same time.
    * much less stale entries with DCO than with NPDAO.
    * control overhead better for DCO as well.
    * analysis of what happens on parent switching (identical in Contiki and RIOT). Send NPDAO immediately, schedule a new DAO for later. Hence route downtime.
    * Pascal: Contiki and RIOT implementations are not RPL. Don't state the quality of RPL based on these implementations.
    * Rahul: with DCO, ....
    * Pascal: you may be sending two DAOs, one gets slowed down, your DCO gets earlier. Don't be too quick in sending the uplink
    * Pascal: another point: traditional in LS to cleanup the bad state left over on mobility. From hearsay, proven to be complex. Should research on this.
    * Pascal: bad history of doing this in other routing protocols.
    * Alvaro: in other protocols, do flush. Problem is flushing for somebody else that's no longer there. State expires. Connectivity fails.
    * Alvaro: there has been proposals on proxying, nobody very happy with this.
    * Pascal: keep a note that we should experiment with this before standard RFC. I feel this is safe, but needs a check
    * Rahul: still kept the bit ....
    * Rahul: next steps
        * text changes (Destination Cleanup Object), but no semantic change for a long time.
        * would like to WGLC this
    * Peter: also wants this
    * Peter: perf report in appendix?
    * Peter: if you have publication elsewhere, you can also refer to it.
    * Pascal: Cisco and Huawei both have IPR on this.
    * Rahul has invited Pascal to join the work on this.

[10:56] Root initiated routing state in RPL (Pascal)
     * two implementations under way. One by Huwaei, one 
     * invited Huawei (whom?) and Matt Gillmore to this draft.
     * not much progress recently
     * Need to discuss size of MoP, 3 bits. AODV uses a new MOP as well. We'll be short on bits pretty soon.
     * Charlie: discussion also holds for AODV-RPL. Should it use new MOP or new message numbers?
     * Pascal: 8 MOP values. 4 consumed in the base spec. 1 is experimental, can be claimed back. Leaving 5.
     * Remaining questions
         * how is the topology known to the root? non-storing, DAOs tell the DODAG. storing, not much.
         * how are node capabilities know to the root? extend the DAO to include things such as memory size?
         * Rahul: 
         * Pascal: constrained nodes usually don't do storing mode. If you do storing mode, do it well. If node reparents, need to be able to reconstruct state.
         * mixed modes?
         * loop avoidance
    * Peter: could you reduce document to non-storing mode and avoid all the storing-mode related problems?
    * Pascal: answer is no. Initial motivation was to build networks with long lines of nodes, want to compress this line with local storing mode. Send in non-storing mode only to the beginning of the line.
    * Rahul: loop avoidance will be updated in this draft

[11:08] Status of draft-ietf-roll-dis-modifications-00
    * interest for this work re-iterated on the mailing list.
    * Dominique and Cenk will allocate resource to work on this by the summer
    * Pascal willing to help
    * discussion whether this draft should just provide the flags and options or should also recommend the use of each mode and option for different real-world situations
    * Pascal: we've had these discussions in hallways on multiple instances since Maastricht.
    * not much resource available to that.
    * Pascal: could target the experimental track and publish quickly
    * Dominique: will revive this discussion on the mailing list and move forward.

[11:23] meeting closed

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Apr 2018 12:14:24 -0400

>     * how to handle DTSN increment? want to also check how BIER does

..

    >     * MCR: excellent work, should adopt it. Lots of useful
    > points. Hadn't realized that the spec was ambiguous.

My impression is that there is some clarification needed in 6550.
I don't know if this should be done as errata or as an Updates, bacause
I haven't internalized the scale of the issue.

    >     * MCR: seems Pascal agrees. Just clarified a lot of things. 6550
    > did not capture that clearly. Low hanging fruit document should only
    > include non-controversial points.
    >     * MCR: a bunch of knowledge just exposed, glad it's captured on
    > tape. Want to capture it in text quickly.

What I took home from the discussion is that DAO-ACK SHOULD be used on
networks where this is no L2 confirmation.  That it's not end-to-end
(which is what I implemented!), and if we want end-to-end ACK, it
would be a new extension.

    >     * Rahul: will go to the mailing list to get consensus on what is

Just a reminder...  Here a a few options that I was thinking about:

1) It's time to do rfc6550bis.  This could be a non-trivial amount of work.
   It can be bounded in time, but it's hard to do.

2) We should write a document that Updates RFC6550.
2a) The *WG* creates a design team to create a low-hanging fruit document.
    It would start with a document (already adopted by the WG. The DHCP WG
    did this wrong in my opinion) that is essentially starts empty.
    The design team would scavenge content from Rahul's document and
    apply WG consensus to it being non-controversial.  Lather.Rinse.Repeat.

2b) We adopt Rahul's document, or a version of, and then discover which
    parts are controversial, and remove them until we have a simple
    document.  If left with empty set, STOP.

    Constroversial items go into new documents.

3) We adopt Rahul's document as a BCP and it contains non-normative
   language only.

    >     * Rahul: understand could maintain this draft as long as needed,
    > and develop solutions in other documents?

That's reasonable for some things, but not for others.

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 6 Apr 2018 00:58:28 +0800

Hi Michael,

I agree to all of the things that you mentioned.

There are few more points that we had not added in the observations draft because of lack of time for Ietf101. We wanted to add only after getting some performance figures and more clarifications. Expect an update for the observations draft in couple of weeks.

Thanks for initiating the discussion.

Regards,

Rahul

Rahul Jadhav

邮箱：[email-masked]

签名由 网易邮箱大师 定制

On 04/06/2018 00:14, Michael Richardson wrote:

>     * how to handle DTSN increment? want to also check how BIER does

...

>     * MCR: one document with solution: e.g. DTSN increment is clearly a

> bug in the spec.

>     * MCR: another document to discuss issues we don't have a solution

> for.

>     * Pascal: explains thinking about DAO-ACK. We need something to

> solve the end-to-end delivery.

>     * Rahul: will go to the mailing list to get consensus on what is

> non-controversial

language only.

>     * Carsten: in the past in RoHC WG, have kept a standing doc for 5

> years.

--

_______________________________________________

Roll mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/roll

---

From: peter van der Stok <[email-masked]>
Date: Mon, 09 Apr 2018 09:39:50 +0200

> That's reasonable for some things, but not for others.
Right, so we wait for Rahul's new document and then start collecting 
opinions about future work.

thanks Rahul.

Peter

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 9 Apr 2018 21:15:07 +0200

yes to update 6550,

> 3) We adopt Rahul's document as a BCP and it contains non-normative

agree with 1, 2 but no.3  disagree so suggest informational if
non-normative, but if BCP then normative.

> yes,

AB

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Mon, 23 Apr 2018 09:09:23 +0000

Hello ROLL, 

As discussed, the document is updated (with some new section additions) while retaining all the previous sections.
https://tools.ietf.org/html/draft-rahul-roll-rpl-observations-01

Regards,
Rahul

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: 09 April 2018 15:40
To: Routing Over Low power and Lossy networks <[email-masked]>
Cc: Michael Richardson <[email-masked]>
Subject: Re: [Roll] DTSN increment and DAO-ACK

> That's reasonable for some things, but not for others.
Right, so we wait for Rahul's new document and then start collecting opinions about future work.

thanks Rahul.

Peter