Re: [Bier] Robert Wilton's Discuss on draft-ietf-bier-te-arch-10: (with DISCUSS and COMMENT)

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4152C3A08D6; Fri, 28 Jan 2022 09:08:46 -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 F3oJ9Lqd7VtI; Fri, 28 Jan 2022 09:08:42 -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 08E4F3A090B; Fri, 28 Jan 2022 09:08:42 -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 B3B7F58C4B3; Fri, 28 Jan 2022 18:08:37 +0100 (CET)
Received: by (Postfix, from userid 10463) id B045A4EA4BD; Fri, 28 Jan 2022 18:08:37 +0100 (CET)
Date: Fri, 28 Jan 2022 18:08:37 +0100
From: Toerless Eckert <>
To: Robert Wilton <>
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] Robert Wilton's Discuss on draft-ietf-bier-te-arch-10: (with DISCUSS and 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:08:47 -0000

Thanks, Robert

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.

No diffs resulting from your feedback, but

Full diff from -11 to -12:

Thanks again for your review.


On Wed, Aug 25, 2021 at 06:50:54AM -0700, Robert Wilton via Datatracker wrote:
> Robert Wilton has entered the following ballot position for
> draft-ietf-bier-te-arch-10: Discuss
> 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:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Hi,
> I would like to please double check with the authors, responsible AD, and IESG
> that publishing this as standards track is the right choice (as opposed to
> experimental).
> >From the first line of the introduction:
> "BIER-TE is based on architecture, terminology and packet formats with
>    BIER as described in [RFC8279] and [RFC8296].
> Both RFC 8279 and RFC 8296 are experimental RFCs, hence (1) I wanted to check
> that by publishing this draft as Std Track, that this draft isn't being built
> on an unstable footing.
> This draft has a normative reference to RFC 8279, but only an informative
> reference to RFC 8296.
> Hence, I further wanted to check:
> (2) Should RFC 8296 really be a normative reference?
> (3) The IETF LC announcement didn't seem to flag the downref to RFC 8279.  RFC
> 8067 says that is not strictly required, but in this case I think that would
> have been useful.
> I can see from the document history that the WG has flip-flopped on whether
> this document should be experimental or stds track, but I couldn't quickly find
> this discussion, and it wasn't covered in shepherds writeup.  If it is possible
> for someone to provide a quick summary as to why it is okay and right to
> publish this as standards track that would be appreciated.

I think the questions about the intended status (STD) have been answered
by others in the email discussion.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thanks for your work on this document.
> I'm not an expert on the BIER technology, and I didn't have the time to
> properly read the core references before reviewing this document.  However, I
> didn't spot any obvious issues on the text, beyond the question on the document
> status.  But I also appreciated the detailed section on the operational
> considerations related to managing the bit position assignments, which I
> interpret not as a strict requirement of this specification, but likely to be
> very helpful to controller implementations and operators.

Yes. Thanks a lot to Alvaro to help push me to restructure the document
in -10 so this now is clearer. There is a lot of controller complexity when
you want to save bits, which may be fine (controllers are "just" software).

Given how i have seen a lot of SR folks argue that
8 SR steering entries = 8 * 128 = 1024 bits are no deployment/overhead problem, i
would of course advise to keep BIER-TE deployments simple by using such long
bitstrings where needed ;-))


> Regards,
> Rob