Re: [Bier] AD Review of draft-ietf-bier-te-arch-09

[Alvaro Retana <[e-mail]>]

On July 9, 2021 at 9:34:31 PM, Toerless Eckert wrote:


Toerless:

Hi!

...
> The -10 version should resolve all the concerns you raised.

It does!  Thank you for the changes and updates!!


I have some replies below.  I am also sending (separately) a review of
-10.  Both sets of comments are mostly minor issues and nits, which
can be addressed with other comments, so I'm starting the IETF LC.

I see that you have time at the WG's meeting next week to talk about
this draft.  The changes are mostly editorial/clarifications, so I
don't think we need any further action inside the WG beyond an extra
look.


Thanks!

Alvaro.



...
> > 172 1. Introduction
...
> > 186 Note that related work, [I-D.ietf-roll-ccast] uses Bloom filters
> > 187 [Bloom70] to represent leaves or edges of the intended delivery tree.
> >
> > 189 Bloom filters in general can support larger trees/topologies with
> > 190 fewer addressing bits than explicit bitstrings, but they introduce
> > 191 the heuristic risk of false positives and cannot reset bits in the
> > 192 bitstring during forwarding to avoid loops. For these reasons, BIER-
> > 193 TE uses explicit bitstrings like BIER. The explicit bitstrings of
> > 194 BIER-TE can also be seen as a special type of Bloom filter, and this
> > 195 is how related work [ICC] describes it.
> >
> > [minor] I don't see any value in including these last 2 paragraphs:
> > you're basically telling the reader that someone else didn't chose the
> > same approach.
>
> No, that is not the important message of these paragraphs. The important
> message is that bloom filters have been proposed as a way to better scale
> bitstring forwarding (fewer bits in packet to represent mor bits in
> topology), but that this BIER-TE proposal can not use such (compressing)
> heuristic solution because the false positives would likely cause loops.

Ok -- I still don't find it useful to point at proposals that cannot
be used.  This is just a minor comment, not a showstopper.


...
> > 733 3.4. Basic BIER-TE Forwarding Example
> >
> > 735 [RFC Editor: remove this section.]
> >
> > 737 THIS SECTION TO BE REMOVED IN RFC BECAUSE IT WAS SUPERCEEDED BY
> > 738 SECTION 1.1 EXAMPLE - UNLESS REVIEWERS CHIME IN AND EXPRESS DESIRE TO
> > 739 KEEP THIS ADDITIONAL EXAMPLE SECTION.
> >
> > [] I don't mind the extra example.
>
> Let's see, for now its gone. If additional review bring up questions where
> he example would help, i will revive. But document is long enough that
> an even more complex example doesn't seem to be helpful for reviewers to get
> through the doc.

You left it in -- which I don't mind.  Either leave it in or not, but
please don't make it a popularity contest ;-) ("ALVARO RETANA DID NOT
MIND ANOTHER EXAMPLE.")


...
> > 1732 8. BIER-TE and Segment Routing
> >
> > [] What is the purpose of this section? It seems to somehow compare
> > BIER/BIER-TE with SR -- but, why? In the context of this document,
> > why is mentioning SR needed? At times the text seems to even try to
> > position BIER-TE as some type of SR alternative. Even then it talks
> > about how they can "naturally be combined"...
> >
> > I don't understand the purpose and think it would be better to remove it.
>
> To me, BIER and BIER-TE are really the multicast extension for SR
> because both are source-routed, per-hop, per-tree stateless:
> BIER for the most common SR deployment of "get rid of LDP", eg. without
> explicit path steering, and BIER-TE when you do want explicit path steering.
>
> The core purpose of the section is of course "Upsell BIER/BIER-TE into
> SR networks". Yes, BIER/BIER-TE fits perfectly into your SR network.
>
> Of course, with BIER being its own working group and SPRING likely
> claiming exclusive ownership of anything in IETF branded in conjunction
> with "SR", i choose less direct explanations through terms like
> "same design philosophy", which makes it somewhat difficult to read.
>
> The other part is pointing to the fact that
> SR is great for routed adjcencies to save bits when you only want steering
> without a replication.
>
> If you think the purpose is fine but the text sucks, i'd like
> to attempt to improve on next rev. If you think he purpose suck,
> and we should not can not upsell BIER/BIER-TE to SR networks, then
> how abot moving it into an appendix first and then let further IETF
> review decide final outcome ?

This is an architecture document -- I don't think the purpose fits in it.

But I'm ok with moving the text to an appendix as a first step.
Please remove the SR mention form the Abstract.