Subject: [Roll] Does BIER ROLL?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Nov 2017 09:05:51 +0000

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 2 Nov 2017 10:21:55 +0100

> What do others think?

I for one would like to understand the IPR landscape some more before we focus on specific branches of this interesting design tree.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Nov 2017 10:10:17 +0000

For one, Cisco has IPR on both BIER and on the RPL BIER draft.

(IANAL but...) Cisco's terms in the above case are defensive RAND. 

You'll find the whole list of IETF declarations on BIER here:
https://datatracker.ietf.org/ipr/search/?draft=&rfc=8237&doctitle=BIER&submit=doctitle&group=&holder=&iprtitle=&patent=

There is also IPR related to RPL in general, and in particular Cisco's IPR:
https://datatracker.ietf.org/ipr/search/?draft=&rfc=8237&doctitle=RPL&submit=doctitle&group=&holder=&iprtitle=&patent=

My draft is at the intersection obviously:
https://datatracker.ietf.org/ipr/3049/
 
Apparently the IPR has not blocked IETF work on RPL and BIER, including opensource.

Take care,

Pascal

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: jeudi 2 novembre 2017 10:22
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] Does BIER ROLL?

Grüße, Carsten

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Nov 2017 08:30:38 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > 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 think that the WG took small steps forward without excluding additional ones.

    > 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 agree that it's a discussion we should have.

    > - 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.

Is the 6LoRH one the compression specification from your document?

    > 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.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Nov 2017 13:04:49 +0000

Hello Michael 

Agreed.

> Is the 6LoRH one the compression specification from your document?

We have https://tools.ietf.org/html/draft-thubert-6lo-bier-dispatch-03 that is designed for it. Point is, having it separate enables to send that doc to 6lo for validation. OTOH, it is an other draft to take through IESG.

Take care,

Pascal

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]] 
Sent: jeudi 2 novembre 2017 13:31
To: Routing Over Low power and Lossy networks <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>
Subject: Re: Does BIER ROLL?

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

---

From: peter van der Stok <[email-masked]>
Date: Fri, 03 Nov 2017 08:10:09 +0100

I surely wanted to discuss this topic during the 15 mins reserved for 
new topics and relations.
Personally, (no hat) I think the subject is important when RPL networks 
grow.

Peter

Pascal Thubert (pthubert) schreef op 2017-11-02 11:10:
> I for one would like to understand the IPR landscape some more before
> we focus on specific branches of this interesting design tree.
> 
> Grüße, Carsten
> 
>

---

From: peter van der Stok <[email-masked]>
Date: Mon, 06 Nov 2017 09:50:45 +0100

Hi Pascal, Carsten, and Michael,

I agree that we should have this discussion.
But the discussion will take some time and I think that the ietf100 slot 
will be much too short to handle all proposed topics.
I should like to have a short discussion that confirms the work is 
necessary, and determines the people to work on it.
Probably, a composing a design group would be best (IMO).

Peter