Re: [Bier] Rtgdir telechat review of draft-ietf-bier-te-arch-10

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B05433A08D7; Fri, 28 Jan 2022 09:10:50 -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 8axfRZObLTTH; Fri, 28 Jan 2022 09:10:46 -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 797783A08D6; Fri, 28 Jan 2022 09:10:43 -0800 (PST)
Received: from ( [IPv6:2001:638:a000:4134::ffff:51]) (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 3366858C4B2; Fri, 28 Jan 2022 18:10:37 +0100 (CET)
Received: by (Postfix, from userid 10463) id 2F6A94EA4BD; Fri, 28 Jan 2022 18:10:37 +0100 (CET)
Date: Fri, 28 Jan 2022 18:10:37 +0100
From: Toerless Eckert <>
To: Ines Robles <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Bier] Rtgdir telechat review of draft-ietf-bier-te-arch-10
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:10:51 -0000

Thanks, Ines

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 Ines Robles, Roman Danilyv

Thanks again for your review.


On Tue, Aug 24, 2021 at 11:16:55AM -0700, Ines Robles via Datatracker wrote:
> Reviewer: Ines Robles
> Review result: Has Nits
> Hello,
> I have been selected as the Routing reviewer for this draft. The Routing
> Directorate seeks to review all routing or routing-related drafts as they pass
> through IETF last call and IESG review, and sometimes on special request. The
> purpose of the review is to provide assistance to the Routing ADs. For more
> information about the Routing Directorate, please see
> ​
> It would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through discussion
> or by updating the draft.
> Document: draft-ietf-bier-te-arch-10
> Reviewer: Maria Ines Robles
> Review Date: 2021-08-24
> IETF LC End Date: 2021-08-24
> Intended Status: Standards Track
> Summary:
> This document describes per-packet stateless strict and loose path steered
> replication and forwarding for Bit Index Explicit Replication packets
> (RFC8279), BIER Tree Engineering (BIER-TE), intended to be used as the path
> steering mechanism for Traffic Engineering with BIER. BIER-TE introduces a new
> semantic for bit positions (BP) that indicate adjacencies.
> This document is basically ready for publication. I have some minor
> questions/comments.
> Major Issues: No major issues found.
> Minor Issues: No minor issues found.
> Nits/Comments/Questions:
> - Expand SI at first use --> Set Identifier (SI)?
> - Expand SD at first use --> Sub Domain (SD)?


> Page 7: Question, in the sentence: " send in addition to BFR6 via BFR4
> also a copy to BFR3, the BitString needs to be (p2,p5,p8,p10,p12,p13)..." --> 
> should it be added p15 as well, (p2,p5,p8,p10,p12,p13,P15) ?


> Page 7: " many of which are based on assumptions..." --> it would be nice if
> you could state examples of the assumptions, which assumptions?

Changed to:

based on out-of-band knowledge about the required multicast traffic
paths and bandwidth consumption in the network, such as from pre-deployment planning

> Page 8: "BFR4 and from BFR4 to BFR uses (p1,p2,p3,p4,p6).  -->  BFR4 and from
> BFR4 to BFR6 uses (p1,p2,p3,p4,p6).

Fixed (already by another review).

> Page 8: Question, in Figure 2,  You have p6 as forward_routed() to BFR6, and as
> local_decap. Is this correct? Is this reuse of bit positions case?

Great catch. That reuse of the same bit would only work if
the prior hops BFR3 or BFR4 would not reset BP p5 or p6 with DNC.
But this demo was meant to be simple, so i forgot adding p9 on
BFR6 to local_decap() the packet there. Fixed in text and picture.

> Page 9: "...undesired duplicates or loops as explained further down in the
> text."  --> (nice to reference the section where it is explained, Section 5.2)


> Page 10: "See for example See Section 5.1.3...." --> delete the second See

Fixed already by other reviewer.

> Question: Is there specific security considerations when having overlay BIER-TE
> topology?

Excellent point. Added the following paragraph:

<t>BIER-TE forwarding explicitly supports unicast "tunneling" of BIER packets via forward_routed()
adjacencies. The BIER security model is defined by a subsets of interfaces on a BFR
that connect to other BFR of the same BIER domain. For BIER-TE, this security model equally applies
to such unicast "tunneled" BIER packets. This does not only include the need to filter
received unicast "tunneled" BIER packets to prohibit injection of such "tunneled" BIER
packets from outside the BIER domain, but also prohibiting forward_routed() adjacencies
to leak BIER packets from the BIER domain. It SHOULD be possible to configure
interfaces to be part of a BIER domain solely for sending and receiving of unicast
"tunneled" BIER packets even if the interface can not send/receive BIER encapsulated packets.</t>

> Thank you for this document,

Thank you very much for the review!


> Ines.