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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC1643A0898; Fri, 28 Jan 2022 09:07:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0wTG60puroZe; Fri, 28 Jan 2022 09:07:05 -0800 (PST)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABF743A088D; Fri, 28 Jan 2022 09:07:04 -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 D439C58C4B2; Fri, 28 Jan 2022 18:06:55 +0100 (CET)
Received: by (Postfix, from userid 10463) id C8CFD4EA4BD; Fri, 28 Jan 2022 18:06:55 +0100 (CET)
Date: Fri, 28 Jan 2022 18:06:55 +0100
From: Toerless Eckert <>
To: Zaheduzzaman Sarker <>
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] Zaheduzzaman Sarker'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:07:09 -0000

Thanks, Zaheduzzaman 

Detailed replies for your comments below inline. It should resolve all your concerns.
These have been integrated into draft rev -12.

Full diff from -11 to -12:

Diff with just the deltas for your comments:

Thanks again for your review.


On Thu, Aug 26, 2021 at 05:15:48AM -0700, Zaheduzzaman Sarker via Datatracker wrote:
> Zaheduzzaman Sarker 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 for the efforts on this document. Due to lack of time on my side
> (apologies) I quickly read through the document and didn't find any transport
> related issue sticking out. I agree with TSVART reviewer (Thanks Tommy Pauly)
> that this seems useful to reduce duplicate packets to avoid unnecessary effects
> in the higher layers.
> I have two clarification questions:
> * Section if there is 6 SIs in the example then why does the it loops
> through only 5 of them? see the text below -
>     On all area edge BFR, bea in
>    BIFT:SI=k|k=2...6 is populated with forward_routed(BFRka) and beb in
>    BIFT:SI=k with forward_routed(BFRkb).
>    For BIER-TE forwarding of a packet to a subset of BFERs across all
>    areas, a BFIR would create at most 6 copies, with SI=1...SI=6,

The explanation was the last sentence in the paragraph:

| For this setup we do not consider area 1 because we assume the BIER-TE
| setup is just for sending traffic from area 1 into area 2...6,
| for example bcause the broadcast headends are in area 1 for an IPTV BIER-TE setup.

But i think i was confused here and optimized to much and made it inconsistent
with the rest of the text. So i removed that sentence and changed the ranges to ..=1...6

> * This might be completely my misunderstanding, however, I understood that
> BIER-TE supports multiple domains and subdomains, where multiple domains may
> not be under same implementer.

Domains and Subdomains are primarily operator related. A Domain belongs to
one (potentially federated/orchestrated) operator, subdomains are just
a way within a domain to scale and to enable different modes, such as
running BIER and BIER-TE in parallel.

> In that case, would their not be issues for
> BIER-TE controllers to show robust behavior if there is no default ECMP
> algorithm?

Remember that ECMP is used in IP unicast since the inception of IP,
and AFAIK, we never standardized an ECMP algorithm. I did have a good amount
of encounter with multi-vendor IP networks and multiple ECMPs being used,
and it always was some amount of pain, but primarily to the point of
getting documentation for the algorithms so that one could calculate/plan
traffic flows. Hence i choose here in this architecture spec to only
define the framework for BIER-TE ECMP and mandate documentation.
If there is interest in a standardized ECMP algorithm, we can easily do
this as a followup spec.

Anothre reason for not wanting to demand a particular algorithm was that
in the context of IP multicast we revisited a few and got good measurement
feedback only years later (complaining about what we felt to be good to
not be so good in the end). Meaning that if we wanted to do this, it might
be something to take its own timeline as an RFC.

> Also the implementer is expected to document their ECMP of choice, I
> didn't understand in what format and to who the documentation applies.

I did improve the relevant text in the section including to add the statement,
that the example ECMP algorithm shown is represented in a form sufficient
to serve as documentation.

> Also there is no discussions on what happens if there is no such documentation.

Yes. Unfortunately?, we do not have an IETF inquisition department
for bad implementers. But that too is not new for this - not even normative -

Thanks again