Minutes for ROLL at IETF-96
minutes-96-roll-2

AGENDA ROLL - IETF 96

15:50-17:20        Wednesday Afternoon session II

Time: 90 minutes

Topic                                                                          
    Time                        Presenter

Status of the working group  -----------------------------------------------
15:50  - 15:52  (2 min.) --------- Peter/Ines

Use of rpl info draft -  draft-ietf-roll-useofrplinfo ----------------------
15:52  - 16:10  (18 min.) -------- Michael Richardson

DIS Modifications - draft-gundogan-roll-dis-modifications ------------------
16:10  - 16:20  (10 min.) -------- Cenk Gündogan

Source-Routed Multicast for RPL - draft-bergmann-bier-ccast ----------------
16:20  - 16:35  (15 min.) -------- Carsten Bormann

Mpl Forwarder select - draft-vanderstok-roll-mpl-forw-select ---------------
16:35  - 16:45  (10 min.) -------- Peter van der Stok

AODV-RPL - draft-satish-roll-aodv-rpl --------------------------------------
16:45  - 16:55  (10 min.) -------- Charles Perkins

No-Path DAO Problem Statement - draft-jadhav-roll-no-path-dao-ps-00 --------
16:55  - 17:05  (10 min.) -------- Rahul Jadhav

Charter discussion + AOB ---------------------------------------------------
16:05  - 17:20  (15 min.) -------- Peter and Ines

=====
Meeting starts 15:50
Note Well
Agenda

[15:51] Status of the working group (Peter/Ines)
Milestones
WG Drafts, related drafts

[15:52] DIS Modifications (Cenk Gündogan)
Recap on what DIS is. Explains current state.
Rahul : RFC6550 does forbid to send CO in multicast DIO. Can configuration
option can be sent as part of multicast option Cenk: Yes Cenk explains case of
node joining the network, with current situation (RFC6550). Does not know
routers, hence uses multicast DIS, hence multicast DIOs and Trickle timer
reset. Lots of activity. Wants to improve this behavior by having quiter
behavior. 3 behaviors to improve: - DIS type and Trickle timer
  Proposes DIS flags to have better control on responses. Also response
  spreading in time if collisions are expected.
- Selectivity of DIS requests
  Explains current behaviour of selectivity of multicast DIS messages and
  proposed improved behavior. Rahul: multicast DIO may make more sense. Pascal:
  agrees with this. Question: gives the control to device instead of to the
  network? Dominique: some networks are planned, density is known, desired
  behavior is provisioned into the nodes.
- Information carried by unicast DIO. Desired: be able to tell in the DIS which
information should be included in DIO response
  Proposed R flag and TLV to do that.
Concludes with current proposals.
Questions postponed to charter discussion
Emmanuel Baccelli: implementation already available in RIOT, play with it!

[16:06] Use of rpl info draft (Michael)
Meant to document when to use IP-in-IP, when to use RPI option, when to use RH3?
Useful to document, as well as to prepare work on compression of these.
Now 2460bis might change the premises of this!
The 6man wg put a note saying *nodes* along the path will examine and process
the Hop by Hop option if explicitely configured to do so. Pascal: this is about
routers. Still cannot insert or delete an extension header (such as RH3).
Pascal: "insertion ... * can result * .. " doesn't mean you aren't allowed to
do it. Michael goes through illustrative graph. From RPL-aware node to
non-RPL-aware node, with current situation and then with 2460bis.
  Don Sturek: what DAO option did node E use to tell everybody about node G?
  Pascal: ... E bit = external.
  Michael: in the absence of information that node G is RPL-aware, node F has
  to assume that this is the case and use IP-in-IP. Don: how does F know G is
  part of the same RPL domain? Michael: text assumes that if same prefix, is in
  hte DODAG. Don: bad assumption. E.g. other DODAG ....<< please fill in>>>
  Michael: agreed. Must pessimistically use IP-in-IP.
Michael goes through second example. Without and with 2460bis. Notice that
packet received is from un-anticipated node, but payload ok. Third example:
going out to the internet. No change in node-to-node in non-storing mode,
always had to send to the root anyway. Michael solicits help to word the
explanation. Also about the E bit propagation. Don: in the example, how could
you use link local addresses? Michael: in this exemple, IP-in-IP is hop by hop,
destination is neighbor. E.g. node E to node B. Header only goes a single hop.
So could use link-local address. May compress better (MAC address). Pascal:
some devices may have more than one radio. Link-local might be only choice.

[16:28] Source-Routed Multicast for RPL (Carsten Bormann)
these slides fell off IETF95 meeting.
In storing mode, RPL multicast creates state everywhere.
What about non-storing mode? Source routing needs to enumerate all forwareders
and listeners. BIER WG for bit-indexed multicast replication. Enumeration in
bit map. Needs stable map of all routers (??) This draft proposes to use Bloom
filter. Makes use of hash function, so false positives create spurious
transmission. This wastes energy, but behavior still functionally correct. How
bad is energy waste? To be compared to energy saved by sending less packets.
Goes through numerical analysis. Up to 100 forwarders still ok under simulated
conditions. Introduces MLAO. Might use a 6LoRH header. Implemented in Contiki
in 2013 (along with a non-storing mode!) Rahul: for Bloom fileter to work, set
of hash functions have to be standardized. Carsten: yes, or use a parameter.
Olaf: we used SHA256 Rahul: Carsten: SHA256 may be already in your node. Needs
a little more work and decide for one. xxx: number of links? Carsten: decision
on each outgoing interface. Depends on what you call links. Carsten: designed
so that bitmap filled on average in half. Counting the forwarders that get the
packet. xxx: Emmanuel Baccelli: most wireless nodes usually have one outgoing
interface. Carsten: dense network and multicast to 80% of nodes, lots of false
positive, but not that bad because message already goes to most nodes. xxx:
algorithm to compute the number of bits given the info known on the network?
Ines: short on time, bring this discussion to the mailing list Olaf Bergmann:
these numbers represent a theoretical probability of collision. Pascal: one
desicsion is Bloom vs bits. Also indicating outgoing interface vs destination.
In Bier.. Carsten: that would work for storing mode.

[16:46] Mpl Forwarder select (Peter van der Stok)
situation is dense network with MPL forwarding which creates Lots of
forwarding. Would like to reduce the number of forwarders. Wants algorithm that
automatically selects the forwarders. Network is assumed to be relatively
stable. Goes through state to be maintained and protocol Selection algortihm
is: order neighbors, when own node at top, select yourself. Simulations seem
good. Stability criterion to have the algorithm  work corre ctly is not well
defined yet. Handling of node departure still to be investigated. Justin Dean
(chair of MANET): trying to build prices at MANET right now that could be
useful to you.

[16:52] AODV-RPL (Charles Perkins)
AODV good scalability characteristics. Would do a good job at point to point
networkin in LLN. Copes with bidirectional but asymmetric links. This extends
P2P-RPL RFC6997 Would be interesting to know proportion of RPL networks doing
non-storing vs storing. Argues that a little more memory saves a lot of
transmission. Proposes a new RPL Mode of Operation (MOP) that allows
Route-Requests and Route-Reply's Construct a DODAG in each direction.
Route-Request from OrigNode to TargNode enables data from TargNode to OrigNode.
Emmanuel Baccelli: does S bit set mean RFC6997 behavior? CP: no because want to
get rid of distance vector. Charles goes through illustrated examples. S bit
according to symmetric/asymmetric assumption on the links. Steers different
protocol behavior. Charles solicits feedback on the draft.

[17:02] No-Path DAO Problem Statement (Rahul Jadhav)
This draft explains the problems and requirements.
Recap on NoPath DAO.
NPDAO sent to the parent. Loss of link to parent is main reason for havong to
send NPDAO in the first place, so this doesn't work. RFC6550 has a vague
statement about this. This draft intends to clarify this. For example, a node
could send NPDAO on behalf of another one. Does it have the state required?
Example of situations that work. Former parent has PathSequence. Discussion on
PathSequence number increment. Lists requirements. Q&A Charles: increment by 2
because ... Rahul: not stated in RFC. .. Charles: seems can be made to work,
will think about it.

[17:10] Charter discussion (Peter+Ines)
Charter is discussed on the mailing list, grateful for all the comments
received. Reduced the historical part. Peter reads the currently proposed text.
  Carsten: are these term defined in RPL terminology draft/RFC? Cite it and
  this charter can be made even shorter. Peter: will do. Charles: if interest
  in AODV-RPL draft, would fall under "improving ..." sentence? Peter: yes.
  Pascal: P2P-RPL was experimental draft for a reason Carsten: was experiemnt
  succesful? Emmanuel: too early to state. More experiment required. Still
  interested in the new proposal as presented by Charles. Justin Dean: add
  MANET to the list of WG to align with, especillay regarding the multicast
  work. Carsten: use YANG will decrease repulsion to MIB. Carsten:
  BIER-forwarding is very specific. Instead of "such as ...", put "See ...".
  Alvaro: Even avoid that. ... PIM (protocol for Internet multicast) ...
Anything to add?
Michael: forgot to ask WG wheter we should assume 2460bis or not to steer our
work? Do we work with what we had or to we wait to clearly make their mind?
Pascal: they have a deadline. We can wait. Ines: milestones: we will add
AODV-RPL. We'll bring the milestones to the mailing list and get feedback. If
support for the drafts, we will add them to the milestones.

[xx:xx] AOB

[17:22] meeting concludes.