Re: [Bier] Questions about draft-ietf-bier-te-ospfv3

'Toerless Eckert' <> Mon, 08 August 2022 09:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9482BC15A737; Mon, 8 Aug 2022 02:06:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.658
X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9gmV_M8o8AYK; Mon, 8 Aug 2022 02:06:28 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 6D6D9C159489; Mon, 8 Aug 2022 02:06:27 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id DD7DE549FF5; Mon, 8 Aug 2022 11:06:21 +0200 (CEST)
Received: by (Postfix, from userid 10463) id C6C184EB6C0; Mon, 8 Aug 2022 11:06:21 +0200 (CEST)
Date: Mon, 08 Aug 2022 11:06:21 +0200
From: 'Toerless Eckert' <>
To: "Jeffrey (Zhaohui) Zhang" <>
Cc: Huaimo Chen <>, "''" <>, "" <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <>
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: Mon, 08 Aug 2022 09:06:31 -0000

Thanks, Jeffrey

I think were in sync with the open questions and issues against both
ISIS and OSPF drafts for IGP -> TE signalling.

Huaimo/*: Let me know if you folks writing those two drafts need help,
as i said, i would be happy to also have us start an informational
explanation doc how to use IGP information for TE which could then
be used as a common reference in those stds track drafts.

I'd also like to note that the use of IGP for CGM2-RBS (draft-eckert-bier-cgm2-rbs)
would become a lot more interesting than for BIER-TE, because in RBS,
it would be alot more likely that one could assign the bits on a
BFR all locally, so deployment models without a central controller are
a lot more attractive there.


On Sun, Aug 07, 2022 at 01:53:13PM +0000, Jeffrey (Zhaohui) Zhang wrote:
> Hi Huaimo,
> Please see zzh> below.
> Juniper Business Use Only
> From: BIER <> On Behalf Of Huaimo Chen
> Sent: Tuesday, July 5, 2022 10:27 PM
> To: Jeffrey (Zhaohui) Zhang <>; '' <>;
> Subject: Re: [Bier] Questions about draft-ietf-bier-te-ospfv3
> [External Email. Be cautious of content]
> 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.
> Zzh> It would be good to point out the use cases for distributing the information via IGP: a) BFIRs finds out the bitstring by themselves instead of relying on controller; b) FRR.
> 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<*3A*2F**2Fdoc*2Fhtml*2Fdraft-ietf-bier-te-arch-13*23section-3.2.1&amp;data=05*7C01*7Chuaimo.chen**7C4ffe358070244f5f787e08da5e8ae5c1*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637926247908948675*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&amp;sdata=LzsTdOh3WmgUxFZRW3sn906JwsmkwuJrBRVROD5BoUQ*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!B5bLqVAwl6tt2cY5ovMRS3TzxGueCiVPVlYIFnJOiHyKob1gt-qViY1o0v0ujGKgYAgsLwfsBakDrTPzIftbfnzG$> 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.
> Zzh> What about MT/BAR/IPA fields 😊
> 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.
> Zzh> It’s ok to use IGP but it is not necessarily more efficient. The bit position assignment is centrally planned and done (unlike the local MPLS labels) and all BFRs need to have the same information and that does not change with node/link up/down. Each BFR needs to learn its own bit position information “out of band” anyway (can’t be through IGP), so it may actually be better for it to learn all information “out of band” in the SDN era (in the old days it is indeed better for each router to learn its own information and then flood). Having said that, this is not to say that we must not use IGP.
> 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.
> Zzh> I talked about both routed adjacency and one bit position for p2p links (just want to make sure).
> Zzh> Thanks.
> Zzh> Jeffrey
> 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.
> Thanks.
> Jeffrey
> Juniper Business Use Only