Re: [Bier] Dirk/*: Re: WGLC - draft-ietf-bier-te-arch (was: Re: Comments on draft-ietf-bier-te-arch-03)

[Dirk Trossen <[e-mail]>]

Toerless, all,

Apologies, my organizational change temporarily disconnected me from that discussion. From my side, this is a +1 regarding progress of the draft to next stage! 

Best,

Dirk

-----Original Message-----
From: BIER [mailto:[e-mail]] On Behalf Of Toerless Eckert
Sent: 18 February 2020 16:34
To: Dirk Trossen <[e-mail]>
Cc: [e-mail]
Subject: [Bier] Dirk/*: Re: WGLC - draft-ietf-bier-te-arch (was: Re: Comments on draft-ietf-bier-te-arch-03)

Btw: Don't think i have seen a comment from you re. the actual WGLC for bier-te,  to progress the document to IESG.

Anybody else on the list of course equally encouraged to... ;-)

Cheers
    Toerless

On Tue, Oct 29, 2019 at 11:56:40AM +0000, Dirk Trossen wrote:
> 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]
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier

--
---
[e-mail]

_______________________________________________
BIER mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bier