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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Huaimo,

Please see zzh> below.



Juniper Business Use Only
From: BIER <[e-mail]> On Behalf Of Huaimo Chen
Sent: Tuesday, July 5, 2022 10:27 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; '[e-mail]' <[e-mail]>; [e-mail]
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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, July 5, 2022 9:32 AM
To: '[e-mail]' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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.

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 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<https://urldefense.com/v3/__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__;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