Re: [Bier] Martin Duke's No Objection on draft-ietf-bier-te-arch-10: (with COMMENT)

Toerless Eckert <> Fri, 28 January 2022 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41A773A0A80; Fri, 28 Jan 2022 09:11:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TpZYNlT0p02n; Fri, 28 Jan 2022 09:11:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5653C3A09D3; Fri, 28 Jan 2022 09:11:30 -0800 (PST)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D88C58C4B2; Fri, 28 Jan 2022 18:11:26 +0100 (CET)
Received: by (Postfix, from userid 10463) id 3A1F94EA4BD; Fri, 28 Jan 2022 18:11:26 +0100 (CET)
Date: Fri, 28 Jan 2022 18:11:26 +0100
From: Toerless Eckert <>
To: Martin Duke <>
Cc: The IESG <>,,,, Xuesong Geng <>,
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Bier] Martin Duke's No Objection on draft-ietf-bier-te-arch-10: (with COMMENT)
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: Fri, 28 Jan 2022 17:11:42 -0000

Thanks, Martin

Detailed replies for your comments below inline.
It should resolve all your concerns.
These have been integrated into draft rev -12
which the authors feel is ready for RFC editor.

Full diff from -11 to -12:

Diff with just the deltas for comments by Robert Sparks, Yingzhen Qu and Martin Duke.

Thanks again for your review.


On Tue, Aug 17, 2021 at 12:02:40PM -0700, Martin Duke via Datatracker wrote:
> Martin Duke has entered the following ballot position for
> draft-ietf-bier-te-arch-10: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thanks to Tommy Pauly for the TSVART review.
> (2.1) s/p1...p14/p1...p15


> (4.4) I had to read this section several times to understand the F-BM logic.

Yes. F-BM is the biggest trick in rfc8279 BIER logic and the challenge
here was to find the minimum change to support BIER-TE which doesn't
need the trick but may want to be implemented as easy s possible
on hardware designed for BIER.

> Here are some suggestions to clarify it:
> s/F-BM is handled as follows/F-BM is generated as follows: "handled" is similar
> "processed", which is not what I think you mean.

replaced with:

The following points describe how the forwarding bit mask (F-BM) for each BP is configured in the BIFT and how this impacts the BitString of the packet being processed with that BIFT:

> "All bits with an adjacency.. has only those bits set for which this BFR does
> not have an adjacency." This sentence was very confusing for me until I grasped
> that there were two different bitmaps here: the first reference to 'bits' is
> the BitString, the second reference is the F-BM, which has no direct relation
> to the BitString. More introductory text to specify the two bitmaps, and be
> clear about which bitmap each reference to 'bit' refers to, would be helpful.

Replaced first two bullet points with:

  <t>The F-BMs of all BIFT BPs without an adjacency have all their bits clear. This
  will cause [3] to skip further processing of such a BP.</t>
  <t>All BIFT BPs with an adjacency (with DNC flag clear) have an F-BM
  that has only those BPs set for which this BFR does not have an adjacency.

> (5.1) What does "(4.1, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8)" mean?

Was an outdated list of references to sections describing the points of optimization
mentioned. List was not updated but removed by recommendation of another reviewer.

> (5.1.3) Another situation where Leaf BFER's can't fully collapse into one
> codepoint is if there are two local_decap() interfaces. Or does this concept
> not logically exist?

The forwarding rules suggest that the local_decap({VRF}) can have something
like a VRF parameter. In that respect you could think of one local_decap()
BP per VRF, but i think that would be inefficient use of BP space. But
it might be appropriate in certain deployments. But even then could you
share those BP across all Leaf BFERs by just configuring their BIFT all
with the same e.g.: 5 bits for 5 VRFs (if they have all the same 5 type of

Thanks a lot for the review!