Re: [Bier] Questions about draft-ietf-bier-te-ospfv3 Wed, 06 July 2022 06:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5826FC15AD47; Tue, 5 Jul 2022 23:20:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FN3jwHeKyuRY; Tue, 5 Jul 2022 23:20:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 429DDC15A74C; Tue, 5 Jul 2022 23:20:10 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4Ld8Xn3RBYz8R039; Wed, 6 Jul 2022 14:20:09 +0800 (CST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4Ld8XC2pdrz4y0v4; Wed, 6 Jul 2022 14:19:39 +0800 (CST)
Received: from ([]) by with SMTP id 2666JWmB070515; Wed, 6 Jul 2022 14:19:32 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid203; Wed, 6 Jul 2022 14:19:32 +0800 (CST)
Date: Wed, 06 Jul 2022 14:19:32 +0800
X-Zmail-TransId: 2afa62c529742133e991
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-MAIL: 2666JWmB070515
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04- with ID 62C52999.000 by FangMail milter!
X-FangMail-Envelope: 1657088409/4Ld8Xn3RBYz8R039/62C52999.000/[]/<>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 62C52999.000/4Ld8Xn3RBYz8R039
Archived-At: <>
Subject: Re: [Bier] Questions about draft-ietf-bier-te-ospfv3
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Jul 2022 06:20:16 -0000

Hi Huaimo, 
Please find the BIER-TE BIFT-ID signaling in these drafts:

收件人:Jeffrey (Zhaohui) Zhang;'';;
日 期 :2022年07月06日 10:27
主 题 :Re: [Bier] Questions about draft-ietf-bier-te-ospfv3
BIER mailing list

Hi Jeffrey,
Thank you very much for your questions.
My answers are inline below with [HC].
Best Regards,Huaimo
From: Jeffrey (Zhaohui) Zhang <>
Sent: Tuesday, July 5, 2022 9:32 AM
To: '' <>; <>
Subject: Questions about draft-ietf-bier-te-ospfv3
Hi Huaimo,
I am catching up some BIER reading and have some questions here. I am sorry if they have been raised and answered before - please just give me a link to the archive in that case.
I noticed that the WG version is not linked to draft-chen version.
If I understand it correctly, BIER-TE BIFTs are not calculated but programmed based on planning. On each BFR, a bit-position is assigned to a link that is used for BIER-TE forwarding purposes, or to a "tunnel" that leads to a remote BFR (i.e., routed adjacency).  That information is only useful locally (in the BIFT) and on the controller that determines the bitstring to use. Other BFRs won't use that.
[HC]: The bit-position assigned to a link is used for BIER-TE forwarding through BIER-TE BIFTs. It is also used for other purposes. For example,  when we want to provide fast re-route protections against node and link failures for BIER-TE paths, a node as a PLR should know the bit-positions of the links on the other nodes such as the next hop and next next hop nodes.
Therefore, flooding that information in IGP does not seem to be useful (unless each BFIR determines on its own what BitString to use)? For the same reason, signaling MT/BAR/IPA information does not seem to be useful either.  While;;sdata=LzsTdOh3WmgUxFZRW3sn906JwsmkwuJrBRVROD5BoUQ%3D&amp;reserved=0  does not preclude distributed model (e.g., each BFIR determines on its own what BitString to use to identify a tree), it does not seem to be an expected scenario; if this document intends to address that it should be made clear.
[HC]:  Refer to the answer above.

It seems to me that the information should be signaled from a controller/orchestrator directly to targeted individual BFRs using other Netconf/PCEP/BGP.
[HC]: It seems that using a controller to assign/configure bit positions of the links on each of BFRs is OK. But using IGP to distribute the bit  positions is more efficient after the bit positions are assigned/configured on the links of a node.

Besides that, the signaling in the draft does not cover "routed adjacency". For the direct p2p links, it assumes different bits are assigned for the two BFRs connected by the link. However, that is different from the following in BIER-TE arch spec:
5.1.1.  P2P Links
On a P2P link that connects two BFRs, the same bit position can be
used on both BFRs for the adjacency to the neighboring BFR.  A P2P
link requires therefore only one bit position.
[HC]: We will consider this.

It is also not clear if BIFT-ID ranges need to be signaled (so that when BFR1 sends traffic to BFR2 according to the programmed BIFT, it knows what BIER label to use). I assume the BIFT-IDs (to be used to reach a neighbor) can also be signaled from the controller  as part of local BIFT entries?
[HC]: Using IGP to distribute/signal BIFT-ID ranges seems more efficient than using the controller.

Juniper Business Use Only