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

Carsten Bormann <cabo@tzi.org> Wed, 22 December 2021 18:11 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A12D3A059F; Wed, 22 Dec 2021 10:11:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DW14h9erSwU; Wed, 22 Dec 2021 10:11:16 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52F43A0524; Wed, 22 Dec 2021 10:11:09 -0800 (PST)
Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JK1bb3shmzDCbt; Wed, 22 Dec 2021 19:11:07 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <162996119973.19003.11174569450531796563@ietfa.amsl.com>
Date: Wed, 22 Dec 2021 19:11:07 +0100
Cc: The IESG <iesg@ietf.org>, gengxuesong@huawei.com, draft-ietf-bier-te-arch@ietf.org, Alvaro Retana <aretana.ietf@gmail.com>, bier-chairs@ietf.org, Benjamin Kaduk <kaduk@mit.edu>
X-Mao-Original-Outgoing-Id: 661889466.911707-ccb21a70ecbd3efa11ca8c53fd8a5664
Content-Transfer-Encoding: quoted-printable
Message-Id: <22F4DE19-5788-46B0-83B6-CE4250D71ABA@tzi.org>
References: <162996119973.19003.11174569450531796563@ietfa.amsl.com>
To: bier@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/cLX01pz8Ad4lm5l8MDxNT-rSBjM>
Subject: Re: [Bier] Benjamin Kaduk's Discuss on draft-ietf-bier-te-arch-10: (with DISCUSS and COMMENT)
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Dec 2021 18:11:21 -0000

On 2021-08-26, at 08:59, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
> 
> pseudocode in Figure 6

I’m sorry, I’m not an expert about BIER-TE, so take the below with a grain of salt.

I ran into the pseudocode in a discussion we had about including pseudocode in an RFC.

The code I find is “almost C”; I don’t understand why you didn’t go the last mile so you can check what you did.

An indicator that gives away the code might have problems is the different spacing for
       SI=GetPacketSI(Packet);
       Offset=SI*BitStringLength;
(no spaces around operators) vs. much, but not all, of the rest.

But more importantly, what does this pseudocode mean:

           foreach adjacency BIFT[Index+Offset] {

Is there an “in” missing?
I learn from the explanation that the code "loops over the adjacencies because there may be more than one adjacency for a bit”, so maybe there is a mapping from a bit position (not the bit itself, which is 1 or 0) to a list of adjacencies?

What is the difference between commas inside and outside the {}?

                   case forward_routed({VRF},l3-neighbor):
                       SendToL3(PacketCopy,{VRF,}l3-neighbor);

These are questions that an implementer who is tasked to look at this pseudocode will have in all likelihood, so I would expect that the WG wants this clarified.

Grüße, Carsten