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

[Huaimo Chen <[e-mail]>]

Hi Jeffrey,

    Thank you very much for your questions.
    My answers are inline below with [HC].

Best Regards,
Huaimo
________________________________
From: Jeffrey (Zhaohui) Zhang <[e-mail]>
Sent: Tuesday, July 5, 2022 9:32 AM
To: '[e-mail]' <[e-mail]>; [e-mail] <[e-mail]>
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 https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bier-te-arch-13%23section-3.2.1&amp;data=05%7C01%7Chuaimo.chen%40futurewei.com%7C4ffe358070244f5f787e08da5e8ae5c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637926247908948675%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;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.

Thanks.

Jeffrey


Juniper Business Use Only