[Roll] Does BIER ROLL?

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear all ;

At the last IETF, I presented how BIER can be used in RPL for storing mode-unicast, multicast, and reliable multicast. I published https://tools.ietf.org/html/draft-thubert-roll-bier-00 to explain it in more details.
In that draft, I position Bloom Filters as a bitmap compression option. I left open a number of questions for which I guess that protocol elements are needed:
6.2.1.  Computing and Saving Bloom Filters
6.2.2.  Forwarding based on Bloom Filters
6.2.3.  Hash Functions Distribution

And then we have a WG doc, https://tools.ietf.org/html/draft-ietf-roll-ccast-01 that focusses on non-storing multicast with Bloom only. You'll note that ccast does not yet address the questions above on Bloom, and that there's a lot of remaining work just for Bloom.

As you see, there is a 3D matrix here, mode * routing * compression, IOW storing vs. non-storing mode * reliable multicast vs. multicast vs. unicast * flat vs. Bloom vs. ? which appears to have at least 12 combinations. But in fact, I'd argue that the three dimensions are orthogonal and can be treated separately.

The current position of the WG, which has a single WG doc, ccast, that covers only one combination only, seems lacking to me. Did we think that through?

I think not. I think we understood the benefits of bitmaps but did not clearly studied the scope we wanted to cover.

I'd like to discuss the options at the next IETF and decide which WG doc(s) we really want to cover the 3 dimensions.

I can see at least:

-         A) 2 docs, whereby I remove compression from mine, and we keep ccast as is.

-         B) One document with all dimensions in it

-         C) 2 docs, one without Bloom compression and one that focusses on the Bloom compression for all (modes*routing) including non-BIER

-         D) 3 docs, the 2 above, and the 6LoRH separate.


I like C) and D), because there is a lot that's needed for Bloom, in particular the distribution of hash functions, that is very special to that technique. Also Bloom can compress anything. We could for instance hash the IPv6 address on the outgoing port that needs to forward in non-storing to specify the multicast tree in non-storing mode, and hash the destination in storing mode, since the Bloom filters are additive.

What do others think?

Pascal