Re: [Bier] Comments on draft-ietf-bier-te-arch-03

[Dirk Trossen <[e-mail]>]

Yep, started the work based on work published in SIGCOMM2009, using BF in general. But we practically didn't implement them but used the bitposition simple version 😉 The text below does make sense, thanks!

Dirk

-----Original Message-----
From: Toerless Eckert <[e-mail]> 
Sent: 28 October 2019 17:25
To: Dirk Trossen <[e-mail]>
Cc: [e-mail]
Subject: Re: [Bier] Comments on draft-ietf-bier-te-arch-03

On Wed, Oct 23, 2019 at 03:10:16PM +0000, Dirk Trossen wrote:
> 
> [DOT] Note that the ICC paper talks about utilizing simple bitpositions to avoid false positive altogether - in fact, in our utilization of this solution, we've never used BF for that reason and stuck with the bitposition, aligning this solution pretty much with the BIER-TE one - which is one of the reasons for us to look at BIER(-TE) as another possible transport mechanism. So maybe adding a sentence like "Both approaches foresee the use of unique bitpositions per link to avoid said false positive and loop avoidance issues, bringing the approaches more in line with the proposed BIER-TE solution."?

Haha. Now i see. So basically one uses one bloom filter 1 hash function
L(e) = (1<<e), and m (size of bloom filter) > 2^e-max, and e voila, BIER-TE can be called a Bloom Filter solution, and thats what the ICC paper describes.

So, how about this rewrite of the paragraph (for rev -05):

<t>Note that related work, <xref target="I-D.ietf-roll-ccast"/> uses bloom filters to represent leaves or edges of the intended delivery tree.  Bloom filters in general can support larger trees/topologies with fewer addressing bits than explicit bitstrings, but they introduce the heuristic risk of false positives and cannot reset bits in the bitstring during forwarding to avoid loops. For these reasons, BIER-TE  uses explicit bitstrings like BIER. The explicit bitstrings of BIER-TE can also be seen as a special type of bloom filter, and this is how related work <xref target="ICC"/> describes it.</t>


> >      *   Section 8 compares SR and BIER-TE, which I like seeing in the draft. I would argue that the possibility for creating opportunistic multicast relations (through a simple binary OR of unicast relations) is a significant advantage over SR. Here, a possible link to the 'HTTP multicast overlay' draft (see link above) might be useful, which makes use of this capability.
> 
> Added at end of section:
> 
> <t>Both BIER and BIER-TE allow BFIR to "opportunistically" copy 
> packets to a set of desired BFER on a packet-by-packet basis. In BIER, 
> this is done by  or'ing the BP for the desired BFER. In BIER-TE this 
> can be done by or'ing for each desired BFER a bitstring using the 
> "independent branches" approach described in <xref target="bfr-id"/> 
> and therefore also indicating the engineered path towards each desired 
> BFER. This is the approach that <xref target="I-D.ietf-roll-ccast"/> 
> relies on.</t>
> 
> [DOT] Could also add the multicast response draft here for completeness.

Yepp. had already fixed that -> s/roll-ccast/multicast-http/

> >   3.  Nitpicks:
> >      *   P4p1l1: "adjacencies" change to "adjacencies"
> >      *   P5p1l2: "6 BFR..." to "6 BFRs..." (with my working assumptions that an acronym is singular)
> >      *   P5p1l2: "All BFR..." change to "All BFRs..."
> >      *   P6p1l4: "...BFR1 to to send..." change to "...BFR1 to send..."
> >      *   P6p3l3: "...in the prior casse." change to "...in the prior case."
> >      *   P7p3l1: "...consists of the BIFT of all the the" change to "...consists of the BIFT of all the"
> >      *   P9p3l1: "During 'bring-up..." change to "During set-up..." or "During initial configuration..."
> >      *   P13p2l4: "The can be used" change to "They can be used"
> >      *   P13p6l1: "...to the BIER BIFT and are are" change to "...to the BIER BIFT and are"
> >      *   P17p2l6: "This Basic BIER-TE requirements make..." change to "These basic BIER-TE requirements make..."
> >      *   P21p1l3: "example is not mean as a likely setup" change to "example is not meant as a likely setup"
> >      *   P29p1l1: "which lead to" change to "which leads to"
> >      *   P30p6l1: "For non-leaf BFER, ..." change to "For a non-leaf BFER, ...."
> >      *   P30p7l1: "As explained earlier in the document, leaf BFER do..." change to "As explained earlier in the document, leaf BFERs do..."
> 
> Thank you so much.


Thanks for the detailled review and recommendations. 

Cheers
    Toerless


> 
> > I hope this is useful.
> 
> Very much so.
> 
> Cheers
>     Toerless
> 
> > Best,
> > 
> > Dirk
> 
> 

--
---
[e-mail]