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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BCB9C15C6B9; Tue, 5 Jul 2022 18:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, RCVD_IN_DNSWL_BLOCKED=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 OWgCBkvyZsCm; Tue, 5 Jul 2022 18:32:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 599A1C157B49; Tue, 5 Jul 2022 18:32:53 -0700 (PDT)
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 4Ld29H1GgZz4xVnk; Wed, 6 Jul 2022 09:32:51 +0800 (CST)
Received: from ([]) by with SMTP id 2661WZJA059156; Wed, 6 Jul 2022 09:32:35 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid203; Wed, 6 Jul 2022 09:32:35 +0800 (CST)
Date: Wed, 06 Jul 2022 09:32:35 +0800
X-Zmail-TransId: 2afa62c4e6333b49fdce
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-MAIL: 2661WZJA059156
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04- with ID 62C4E643.000 by FangMail milter!
X-FangMail-Envelope: 1657071171/4Ld29H1GgZz4xVnk/62C4E643.000/[]/<>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 62C4E643.000/4Ld29H1GgZz4xVnk
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 01:32:56 -0000

Hi Jeffrey, 
About your last comments about "BIFT-ID" signaling, a newly submitted draft ( will do this work. 
And drafts of OSPF ( and IS-IS ( do it as well. 
In case the link BP is advertised in IGP, the associated BIFT-ID needs to be advertised also. 
Though the these work can all be done by controller:

日 期 :2022年07月05日 21:33
主 题 :[Bier] 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.
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 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.
It seems to me that the information should be signaled from a controller/orchestrator directly to targeted individual BFRs using other Netconf/PCEP/BGP.
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.
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?
Juniper Business Use Only
BIER mailing list