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

Alvaro Retana <> Tue, 20 July 2021 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4DED3A2EF5; Tue, 20 Jul 2021 12:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JIIgVDg1GWu6; Tue, 20 Jul 2021 12:20:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C1A1C3A2EF2; Tue, 20 Jul 2021 12:19:57 -0700 (PDT)
Received: by with SMTP id ca14so29860522edb.2; Tue, 20 Jul 2021 12:19:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=8+Ore8GjzImyJfIUDtQTG5SmbbI7JfY+JSQPAG5YxYc=; b=cSIBambLvse2adsejmGDx5TAbH3ts+tiraTPtkFT7Kf+kbkkgqhNy5prSyqgwoj8og fX8nCRQgc7Pt4hQYdMVnb60SA16Jw4oOpifUVnpJlFFN0SokZ2Q6x6yGsXbMBzkoHqp9 b4QWuJFjZSZ5zymX1jdKSDccmMHySg0boAyLjBZwB0AmxKrSldu7HvfjK21JNjudXzMj S3NyE4q1KaUchUYtrhipEbQkDgrb8h1tmPUbxz452tYIzQelrgFvKe2T8CpYZYIoZ76Z 4OMgtBEUL3TbIDYyaoMHzxRoq3+JX3fdl5F0AIuXeKWIhZT+XfOh7S+V7sVn5WLqnel8 VUrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=8+Ore8GjzImyJfIUDtQTG5SmbbI7JfY+JSQPAG5YxYc=; b=KGg8+ZLSiH+JHG+punDscqTvAOaePbk44lGZ0IPEt71s1XQWiTehdYYkVgjzVBnsHN PuMyF8EGNfxrFqtkw4xJlTCUCxAZmEz0a0AP1ElS9+IeXtAbN4Ti3fIjntyYDxnroggu 7go8gbWVO/UXnwQRWnY5COPTB9R8qLicpIKQi+F2FG14Hs0AHCPL76Uujhl93D7ILSbc 8XYyJxYzFaPqo8Zdn1pREuxWtH+3CabhaicOvyWm1Dh0uPAwhP3I7fCTEu03PKx0kX2z ysKGzBvga3wMiReWqKxgWB7J4uxjNzN55KQBqI+XXNfsKfRY/qXRGnhTaZDZDMzlD+ex Ct6A==
X-Gm-Message-State: AOAM532wozq4H8dafFfjnbufttT5qBzYUgStNzrZGMwgw8rJgHyUzdID rb+UmglOVQI0gEYt6kwjvDMTAAWRiuJI3iVHpXc=
X-Google-Smtp-Source: ABdhPJz6/slL9cICt8i9hYEijOz2LH7EoLx4F2Cru9VdPilQpUiGmoNMxU1AwbNCVq0e8CuKMs372DKVOqW6771uVAs=
X-Received: by 2002:aa7:ca05:: with SMTP id y5mr43246473eds.353.1626808795407; Tue, 20 Jul 2021 12:19:55 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Tue, 20 Jul 2021 15:19:54 -0400
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Tue, 20 Jul 2021 15:19:54 -0400
Message-ID: <>
To: Toerless Eckert <>
Cc:, "Gengxuesong (Geng Xuesong)" <>, BIER WG <>, BIER WG Chairs <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Bier] AD Review of draft-ietf-bier-te-arch-09
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Jul 2021 19:20:09 -0000

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



> 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



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

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