Re: [Bier] WG adoption call for draft-chen-bier-frr-02

[Huaimo Chen <[e-mail]>]

Hi Jeffrey,

    Thanks for your comments.
    My responses are inline below with prefix [HC].

Best Regards,
Huaimo
________________________________
From: Jeffrey (Zhaohui) Zhang <[e-mail]>
Sent: Monday, March 29, 2021 10:26 PM
To: Huaimo Chen <[e-mail]>; Tony Przygienda <[e-mail]>; [e-mail] <[e-mail]>
Cc: BIER WG <[e-mail]>; BIER WG Chairs <[e-mail]>
Subject: RE: [Bier] WG adoption call for draft-chen-bier-frr-02


Shouldn’t it be the other way around – expand/merge first and then adopt?

[HC]: We will leave it to the chairs to decide whether we have consensus to adopt this draft.



In fact, the essence of draft-chen is the multiple per-nbr FRR BIFTs, which I don’t think should be included in the merged draft at all, for the following problems:

[HC]: I do not see the problems. See details below.



  1.  Scaling – we need one extra BIFT for each <neighbor, BIFT>. This not only means extra memory, but also additional processing overhead including downloading the tables to the forwarding plane.

[HC]: It seems that there is no scaling issue. The size of each BIFT is small and the number of neighbors of a BFR is also small. For example, for a network with 0.5k egress nodes (BFERs), and each BFR has 20 neighbors, the memory used on a BFR is about 0.5k * 20 = 10k (forwarding entries).

  1.  If two neighbors fail simultaneously yet both can be protected by a 3rd neighbor, per-nbr FRR BIFTs can only give protection for one of the first two neighbors. This is not an unusual situation – you could have two neighbors reached by the same link or the same line card, and the link/card fails.

[HC]: This is the case where two or more failures occur at the same time. The existing methods for protecting two or more simultaneous failures can also be used in per-nbr BIFT to protect two or more simultaneous failures.

  1.  Exactly when to switch back from a per-nbr FRR BIFT to the regular BIFT?

[HC]: Refer to the text below from the draft.



The draft says the following about #3:



   In general, when the routing protocol has re-converged on the new

   topology taking into account the failure of X, the BIRT is re-

   computed using the updated LSDB and the BIFT is re-derived from the

   BIRT.  Once the BIFT is installed ready for activation, it is

   activated to forward packets with BIER headers and the FRR-BIFT for X

   is de-activated.



Does that mean for each computation, you need to know and mark which failed neighbor that it takes care of, so that when the BIFT is sent down to forwarding plane you can decide if currently used FRR-BIFT can be switched back to the main BIFT?

[HC]: It seems that there are a few ways. One way is to keep track the failure. Another way is using a timer.



Also consider the following:



  1.  At moment T you switch to FRR BIFT for nbr X
  2.  At moment T+1ms a new BIFT is calculated, which takes care of a remote failure but not nbr X (nbr X is still considered up in this calculation) – would you switch FRR BIFT to the newly calculated main BIFT? If you don’t, the remote failure could lead to packet losses until the new main BIFT is used. If you do, you only get FRR protection for nbr X for 1ms.

[HC]: This is the case where two or more failures happen in the network in almost the same time. According to our switch back rule, it will not switch FRR BIFT back to main BIFT since the failure of nbr X is not considered yet. The main BIFT is recomputed considering the remote failure, the FRR BIFT is also recomputed considering the remote failure. Both the remote failure and local failure are protected.



Jeffrey



From: BIER <[e-mail]> On Behalf Of Huaimo Chen
Sent: Thursday, March 25, 2021 5:06 PM
To: Tony Przygienda <[e-mail]>; [e-mail] <[e-mail]>
Cc: BIER WG <[e-mail]>; BIER WG Chairs <[e-mail]>
Subject: Re: [Bier] WG adoption call for draft-chen-bier-frr-02



[External Email. Be cautious of content]



Hi Everyone,



    Michael, Steffan, Huaimo and Mike met to discuss the merge and we are in agreement that if draft-chen-bier-frr is adopted we will expand it to include a framework along with the tunnel and LFA based solutions.



Best Regards,

Huaimo

________________________________

From: BIER <[e-mail]<mailto:[e-mail]>> on behalf of Tony Przygienda <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, March 16, 2021 6:08 AM
To: zhang.zheng <[e-mail]<mailto:[e-mail]>>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>; BIER WG Chairs <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Bier] WG adoption call for draft-chen-bier-frr-02



+1



I think it's a good addition within the architecture for the case IGP is not used for signalling, e.g. when controller or static programming.



The draft must however explain in what scenarios it is used and quote the according IGP drafts to guarantee loop-free behavior (well, BIER will tie-break loops but we'll have 1x microloop & possibly not deliver payload if BIER FRR is not properly computed/intsalled). With that the draft should also pay attention to how the function is deployed/updated network-wide if IGP is not present



thanks



-- tony



On Tue, Mar 16, 2021 at 7:41 AM <[e-mail]<mailto:[e-mail]>> wrote:

A 2-week WG adoption call begins for the following draft:

https://datatracker.ietf.org/doc/draft-chen-bier-frr/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-chen-bier-frr*2F%26data%3D04*7C01*7Chuaimo.chen*40futurewei.com*7C79ac63710b47427a558d08d8e8638df2*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637514861570555970*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3DDiHvux0ZUYEJru10lVQ4mXvpYx3l8ujGInm7uEjjxTw*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!TtAnkZJhg9BEJjANzO6CusX7i7eQqvTJHdhaH0qrrPdtcykRPrUybhZeavPA3X4F%24&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc2be3c14c8ae4974448508d8f3233b24%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637526679941903109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o2%2Fs%2FQ%2BaGukBWCJgbA7%2FmPEZF0MG2euVpq41tq5YnBA%3D&reserved=0>

Please indicate your support or objection by March 30th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft.

Thanks,

Sandy (As WG secretary, on behalf of Greg/Tony)




Juniper Business Use Only