Subject: Re: [Roll] [Bier] comments on draft-bergmann-bier-ccast

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Jul 2016 07:09:12 +0200

Hi Tony,

thanks for taking note of this draft.

> Generally, not sure how it touches BIER specifically. It seems to
> specify RPL extensions. 

Indeed. We used the "WG name" BIER in the draft at the time we submitted
the first version because the BIER BOF was just happening and we weren't
sure where this would end up.  By now it is pretty clear this will end
up in ROLL (if at all), but resubmitting the draft to create a new -00
just for a WG name change is confusing.

> Yes, one could reuse the BIER bit mask to
> propagate a BLOOM filter instead of a perfect mask @ the benefit of 'set
> bit mask compression' vs. the cost of spurious transmissions as the
> draft acknowledges where the degenerate case is a full broadcast. The
> according BIER procedures/approach is nowhere to be found in the draft
> though ... 

No, as we are indeed focusing on RPL.

One very important thing we get from RPL is the rank, which allows us to
avoid forwarding loops even though the individual routers are pretty
much oblivious about the structure of the network (non-storing mode is
based on source routes from the root of the destination-oriented
directed acyclic graph, DODAG).  So I wouldn't immediately know how to
generalize the current approach to other underlying unicast routing
protocols.  But the use of bloom filters (instead of bitmaps) to
identify a set of outgoing interfaces is probably extractable, if that
is useful somewhere else.

> As nit I didn't find in 6550 anything talking about "storing mode" so a
> better reference is needed. 

Hmm, I find 81 places in there.  (But Ccast is for non-storing mode.)

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Jul 2016 02:13:18 -0700

Thinking more of it (fun to analyse ;-):

Without having done the math, i'd suspect this might be very efficient in
very large networks for small-receiver-sets. Aka: 2048 NFER/receivers, 64
bits bitstring, max normal number of receivers ca. 16 for a packet.

This could be very efficient in very large networks for "small-receiver-set".
Aka: 2048 BFER/receivers. Maybe typically 16 receivers.

This is not 100% tied to RPL. Consider a data-center with 100,000 VMs,
with thousands of 'vlans', each hosting a typically a quite limited
number of VMs. Instead of creating per-VLAN flood-state across the DC
(which AFAIK gets complicated with all the overlay options involved),
you could simply use maybe hmm... 256 ? bits bitstring. 

You need spanning tree forwarding (no redundancy). And you need some
logic figuring out the intermediate  interfaces in the bitstring. In
RPL, the root does this. In a DC this could be more tricky.

On Thu, Jul 21, 2016 at 07:09:12AM +0200, Carsten Bormann wrote:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

-- 
---
Toerless Eckert, [email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 21 Jul 2016 08:06:40 -0700

yep, all good discussion. Of all, I missed the possible looping for BIER of
false positives. That needs treatment before the whole idea is feasible I
think ...

-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky