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

From: Huaimo Chen <[email-masked]>
Date: Fri, 2 Jul 2021 17:20:00 +0000

Hi Greg,

    draft-chen-bier-frr-03 merging the two drafts is published.  Would you mind initiating an adoption call on it?

    Thanks much! Have a great long holiday weekend!

Best Regards,
Huaimo
________________________________
From: BIER <[email-masked]> on behalf of Greg Shepherd <[email-masked]>
Sent: Thursday, April 1, 2021 1:38 PM
To: BIER WG <[email-masked]>
Cc: BIER WG Chairs <[email-masked]>
Subject: Re: [Bier] WG adoption call for draft-chen-bier-frr-02

BIER WG,

>From my chair, there is clear WG consensus to merge the two drafts:

https://tools.ietf.org/html/draft-merling-bier-frr-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-merling-bier-frr-00&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352071085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=P0hqs4IQWSCRFo60P3%2Fj49EljVpA6BgHfCBkJLT0y5Y%3D&reserved=0>
https://datatracker.ietf.org/doc/draft-chen-bier-frr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-bier-frr&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352081039%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IAdm8Qi7HS3cY6hvIEDIp1MC14kjeuovOLfSEs8NNsw%3D&reserved=0>

We will have an adoption call on the new draft once published. The name of the new draft isn't all that important, other than it should accurately reflect the content of the draft. The author's name gets dropped once adopted anyway, so I'm not certain why there would be concern for who's 'taking' who's work. Especially since the discussion and documentation of the described mechanisms have a history in the WG:

  1.  When draft-chen was first presented, it was pointed out that draft-merling was already there: http://www.youtube.com/watch?v=AuzdpgePomA&t=33m51s<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DAuzdpgePomA%26t%3D33m51s&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352081039%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WIGZhaLGo6LmWyskRmaw%2BfrgGFchaL0evu5WFjV5BTQ%3D&reserved=0> and it was suggested to have a combined draft.
  2.  While draft-merling does not talk about LFA based, the authors and some vendors/operators discussed  LFA based FRR back in 2019.  Michael mentioned it in this email https://mailarchive.ietf.org/arch/msg/bier/VRYfB7S7g7xuooIwV9XQDAW56hU/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fbier%2FVRYfB7S7g7xuooIwV9XQDAW56hU%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352081039%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QiYe8HUFpMCHNhO7yAMw52zBOGT0rVHz%2FGCUXof4%2FUw%3D&reserved=0>, and it was already covered in their paper https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth20c.pdf<https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fatlas.informatik.uni-tuebingen.de%2F~menth%2Fpapers%2FMenth20c.pdf&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352090997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eE7XD3jDfHvELSKeQ%2BsLYGJkox7Zl0Inn3pHloMKu9Y%3D&reserved=0> (the link was in that email as well).

Considering this history, the honest approach would be to submit the combined draft as a new submission.

This new draft should be as all inclusive as possible of the FRR mechanisms for BIER. If there is nothing documented on the wire then the draft should be Informational. And as an Informational draft on FRR for BIER, there needs to be a section on how the BIER architecture relies on unicast reachability; ie, BFIB is built from the UFIB, and any FRR mechanism for unicast will be inherited by BIER. Then the case, and mechanisms described for non-IGP based BFIB will have context, and the draft will be a one-stop, comprehensive Informational document on BIER-FRR.

The recommendation to have Jeffrey hold the pen as Editor, was rooted in this expectation of a comprehensive draft. And to date, only Jeffrey Zhang and Greg Mirsky have constantly expressed this same goal of including a section documenting current IGP-based FRR mechanisms inherited by BIER. I have not discussed this with Greg, but I'm putting his name out there as another potential Editor/Author to assist in meeting the WG goals of a comprehensive draft. Pick one or not (if they are willing to help..), the WG goals for the draft remain.

Eventually the Authors' list will need to be edited, but that is not required for adoption, of course. Again, pick now, or pick later. It will be up to the list of combined Authors to decide who stays at the top. The recommendation to keep the Authors' names at the top from filling the page should be nothing new to anyone who has gone through the draft->publish process in the IETF.

I hope this clarifies the recommended direction for this work and these drafts. Thank you all for staying engaged and contributing to the process.

Cheers,
Shep
(Chairs)

On Tue, Mar 30, 2021 at 9:10 AM Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:
I agree with Jeffrey. The two drafts should be merged into a new draft, which we will then call to adopt. I suggest that the authors of each of the two docs:

https://tools.ietf.org/html/draft-merling-bier-frr-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-merling-bier-frr-00&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352090997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1QI9ygoEIC2wDhljxj5FNVvi%2FtZad4BDgmpncmD%2FoEE%3D&reserved=0>
https://datatracker.ietf.org/doc/draft-chen-bier-frr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-bier-frr&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352100958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZQFHd6k9kewCCKdCmA2IAYuR9NFFAVmt4fj5CJ03Rk4%3D&reserved=0>

..contribute two authors to the merged doc effort, and have Jeffrey hold the pen as editor/author.

All agreed?

Thanks,
Greg
(Chairs)

On Mon, Mar 29, 2021 at 7:26 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:

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

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:

  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.
  2.  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.
  3.  Exactly when to switch back from a per-nbr FRR BIFT to the regular BIFT?

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?

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.

Jeffrey

From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of Huaimo Chen
Sent: Thursday, March 25, 2021 5:06 PM
To: Tony Przygienda <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>; BIER WG Chairs <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> on behalf of Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 16, 2021 6:08 AM
To: zhang.zheng <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>; BIER WG Chairs <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352100958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yVkZZVM9xkazCk5cU0dBgOmcuU9UGxyCnwOiSYGjqYI%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

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 5 Jul 2021 06:32:39 -0700

Huaimo,

Thank you for combining the drafts. At first read I'm concerned the
direction given was not fully realized. There is no architecture section
describing BIER inheriting FRR functions from unicast as asked. And the FRR
mechanisms described are still called 'extensions', which would imply
changes to BIER. These are not changes, but implementation choices.

Are these changes coming?

Thanks,
Greg

On Fri, Jul 2, 2021 at 10:20 AM Huaimo Chen <[email-masked]>
wrote:

> Hi Greg,
>
>     draft-chen-bier-frr-03 merging the two drafts is published.  Would
> you mind initiating an adoption call on it?
>
> ------------------------------
> *From:* BIER <[email-masked]> on behalf of Greg Shepherd <
> [email-masked]>
> *Sent:* Thursday, April 1, 2021 1:38 PM
> *To:* BIER WG <[email-masked]>
> *Cc:* BIER WG Chairs <[email-masked]>
> *Subject:* Re: [Bier] WG adoption call for draft-chen-bier-frr-02
>
> BIER WG,
>
> https://tools.ietf.org/html/draft-merling-bier-frr-00
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-merling-bier-frr-00&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352071085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=P0hqs4IQWSCRFo60P3%2Fj49EljVpA6BgHfCBkJLT0y5Y%3D&reserved=0>
> https://datatracker.ietf.org/doc/draft-chen-bier-frr
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-bier-frr&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352081039%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IAdm8Qi7HS3cY6hvIEDIp1MC14kjeuovOLfSEs8NNsw%3D&reserved=0>
>
> We will have an adoption call on the new draft once published. The name of
> the new draft isn't all that important, other than it should
> accurately reflect the content of the draft. The author's name gets dropped
> once adopted anyway, so I'm not certain why there would be concern for
> who's 'taking' who's work. Especially since the discussion and
> documentation of the described mechanisms have a history in the WG:
>
>    1. When draft-chen was first presented, it was pointed out that
>    draft-merling was already there:
>    http://www.youtube.com/watch?v=AuzdpgePomA&t=33m51s
>    <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DAuzdpgePomA%26t%3D33m51s&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352081039%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WIGZhaLGo6LmWyskRmaw%2BfrgGFchaL0evu5WFjV5BTQ%3D&reserved=0>
>    and it was suggested to have a combined draft.
>    2. While draft-merling does not talk about LFA based, the authors and
>    some vendors/operators discussed  LFA based FRR back in 2019.  Michael
>    mentioned it in this email
>    https://mailarchive.ietf.org/arch/msg/bier/VRYfB7S7g7xuooIwV9XQDAW56hU/
>    <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fbier%2FVRYfB7S7g7xuooIwV9XQDAW56hU%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352081039%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QiYe8HUFpMCHNhO7yAMw52zBOGT0rVHz%2FGCUXof4%2FUw%3D&reserved=0>,
>    and it was already covered in their paper
>    https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth20c.pdf
>    <https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fatlas.informatik.uni-tuebingen.de%2F~menth%2Fpapers%2FMenth20c.pdf&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352090997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eE7XD3jDfHvELSKeQ%2BsLYGJkox7Zl0Inn3pHloMKu9Y%3D&reserved=0>
>    (the link was in that email as well).
>
> This new draft should be as all inclusive as possible of the
> FRR mechanisms for BIER. If there is nothing documented on the wire then
> the draft should be Informational. And as an Informational draft on FRR for
> BIER, there needs to be a section on how the BIER architecture relies on
> unicast reachability; ie, BFIB is built from the UFIB, and any FRR
> mechanism for unicast will be inherited by BIER. Then the case, and
> mechanisms described for non-IGP based BFIB will have context, and the
> draft will be a one-stop, comprehensive Informational document on BIER-FRR.
>
> The recommendation to have Jeffrey hold the pen as Editor, was rooted in
> this expectation of a comprehensive draft. And to date, only Jeffrey Zhang
> and Greg Mirsky have constantly expressed this same goal of including a
> section documenting current IGP-based FRR mechanisms inherited by BIER. I
> have not discussed this with Greg, but I'm putting his name out there as
> another potential Editor/Author to assist in meeting the WG goals of a
> comprehensive draft. Pick one or not (if they are willing to help..), the
> WG goals for the draft remain.
>
> Eventually the Authors' list will need to be edited, but that is not
> required for adoption, of course. Again, pick now, or pick later. It will
> be up to the list of combined Authors to decide who stays at the top. The
> recommendation to keep the Authors' names at the top from filling the page
> should be nothing new to anyone who has gone through the draft->publish
> process in the IETF.
>
> I hope this clarifies the recommended direction for this work and these
> drafts. Thank you all for staying engaged and contributing to the process.
>
> Cheers,
> Shep
> (Chairs)
>
>
>
> On Tue, Mar 30, 2021 at 9:10 AM Greg Shepherd <[email-masked]> wrote:
>
> I agree with Jeffrey. The two drafts should be merged into a new draft,
> which we will then call to adopt. I suggest that the authors of each of the
> two docs:
>
> https://tools.ietf.org/html/draft-merling-bier-frr-00
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-merling-bier-frr-00&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352090997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1QI9ygoEIC2wDhljxj5FNVvi%2FtZad4BDgmpncmD%2FoEE%3D&reserved=0>
> https://datatracker.ietf.org/doc/draft-chen-bier-frr
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-bier-frr&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352100958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZQFHd6k9kewCCKdCmA2IAYuR9NFFAVmt4fj5CJ03Rk4%3D&reserved=0>
>
> On Mon, Mar 29, 2021 at 7:26 PM Jeffrey (Zhaohui) Zhang <
> [email-masked]> wrote:
>
> 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:
>
>
>
>    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.
>    2. 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.
> 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?
>
>
>
>    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.
>
>
>
> Jeffrey
>
>
>
> *From:* BIER <[email-masked]> *On Behalf Of *Huaimo Chen
> *Sent:* Thursday, March 25, 2021 5:06 PM
> *To:* Tony Przygienda <[email-masked]>; [email-masked] <
> [email-masked]>
> *Cc:* BIER WG <[email-masked]>; BIER WG Chairs <[email-masked]>
> *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 <[email-masked]> on behalf of Tony Przygienda <
> [email-masked]>
> *Sent:* Tuesday, March 16, 2021 6:08 AM
> *To:* zhang.zheng <[email-masked]>
> *Cc:* BIER WG <[email-masked]>; BIER WG Chairs <[email-masked]>
> *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 <[email-masked]> wrote:
>
> 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%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352100958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yVkZZVM9xkazCk5cU0dBgOmcuU9UGxyCnwOiSYGjqYI%3D&reserved=0>
>

---

From: Michael Menth <[email-masked]>
Date: Tue, 6 Jul 2021 00:14:44 +0200

Dear Greg and all,

sorry for the inapt wording, we should avoid the term "extensions"
and use an appropriate one that clearly shows that BIER-FRR sticks to
the common BIER forwarding algorithm. BIER-FRR just defines backup
entries that need to be applied in case the primary entries do not work
(BEA = backup entry active).

In Section
https://datatracker.ietf.org/doc/html/draft-chen-bier-frr-03#section-3.1
we show that active backup entries should be processed before
normal (primary) entries are processed to avoid redundant packet
copies. Examples are given. Prioritized processing of active backup
entries is achieved by the two implementation choices in the consecutive
subsections: the one uses a single backup BIFT, the other uses multiple
backup BIFTs. The first has been implemented in [1], the second was
proposed in [3].

Regarding inheritance of BIER-FRR from IP-FRR:

1) In theory, one could define backup entries for BIER almost
arbitrarily as long as they do their job. However, it is helpful to
stick to known paradigms and to know what magic happens. Therefore, we
have defined two operation modes that may be selected and that inherit
in different sense from IP-FRR.
2) The first operation mode is tunnel-based BIER-FRR. In case of a
failure, it tunnels BIER traffic over the underlay so that it can
directly benefit from FRR mechanisms on the underlay. It was proposed in
[2] and implemented in [1].
3) The second operation mode is LFA-based BIER-FRR. It implements
LFA-based FRR on the BIER layer - same concept as on the IP layer.
However, only BFRs can serve as BIER-LFAs, therefore, not every LFA on
the IP layer can be utilized as a BIER-LFA on the BIER layer. That's why
a distinction is needed. But conceptually BIER-LFAs are inherited from
IP-LFAs. A special case of this mode was suggested in [3]. The document
in [4] gives more insights into IP-based LFAs and their protection
coverage depending on protection levels.

We expected this discussion and provided a comparison in
https://datatracker.ietf.org/doc/html/draft-chen-bier-frr-03#section-6
1) A comparison of LFA-based BIER-FRR and LFA-based IP-FRR
2) A comparison of both proposed operation modes that both have pros and
cons.

[1] https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9361548
[2] https://datatracker.ietf.org/doc/html/draft-merling-bier-frr-00
[3] https://datatracker.ietf.org/doc/html/draft-chen-bier-frr-02
    (-02 and earlier)
[4] https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth21e.pdf

We're happy to discuss.

Kind regards,

Michael

Am 05.07.2021 um 15:32 schrieb Greg Shepherd:
> describing BIER inheriting FRR functions from unicast as asked. And the
> FRR mechanisms described are still called 'extensions', which would
> imply changes to BIER. These are not changes, but implementation choices.
> 
> On Fri, Jul 2, 2021 at 10:20 AM Huaimo Chen <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi Greg,
> 
>         draft-chen-bier-frr-03 merging the two drafts is
>     published.  Would you mind initiating an adoption call on it?
> 
>     ------------------------------------------------------------------------
>     *From:* BIER <[email-masked] <mailto:[email-masked]>>
>     on behalf of Greg Shepherd <[email-masked] <mailto:[email-masked]>>
>     *To:* BIER WG <[email-masked] <mailto:[email-masked]>>
>     *Cc:* BIER WG Chairs <[email-masked]
>     <mailto:[email-masked]>>
>     We will have an adoption call on the new draft once published. The
>     name of the new draft isn't all that important, other than it should
>     accurately reflect the content of the draft. The author's name gets
>     dropped once adopted anyway, so I'm not certain why there would be
>     concern for who's 'taking' who's work. Especially since the
>     discussion and documentation of the described mechanisms have a
>     history in the WG:
> 
>      2. While draft-merling does not talk about LFA based, the authors
>         and some vendors/operators discussed  LFA based FRR back in
>         2019.  Michael mentioned it in this email
>     FRR mechanisms for BIER. If there is nothing documented on the wire
>     then the draft should be Informational. And as an Informational
>     draft on FRR for BIER, there needs to be a section on how the BIER
>     architecture relies on unicast reachability; ie, BFIB is built from
>     the UFIB, and any FRR mechanism for unicast will be inherited by
>     BIER. Then the case, and mechanisms described for non-IGP based BFIB
>     will have context, and the draft will be a one-stop, comprehensive
>     Informational document on BIER-FRR.
> 
>     The recommendation to have Jeffrey hold the pen as Editor, was
>     rooted in this expectation of a comprehensive draft. And to date,
>     only Jeffrey Zhang and Greg Mirsky have constantly expressed this
>     same goal of including a section documenting current IGP-based FRR
>     mechanisms inherited by BIER. I have not discussed this with Greg,
>     but I'm putting his name out there as another potential
>     Editor/Author to assist in meeting the WG goals of a comprehensive
>     draft. Pick one or not (if they are willing to help..), the WG goals
>     for the draft remain.
> 
>     required for adoption, of course. Again, pick now, or pick later. It
>     will be up to the list of combined Authors to decide who stays at
>     the top. The recommendation to keep the Authors' names at the top
>     from filling the page should be nothing new to anyone who has gone
>     through the draft->publish process in the IETF. 
> 
>     I hope this clarifies the recommended direction for this work and
>     these drafts. Thank you all for staying engaged and contributing to
>     the process.
> 
>     Cheers,
>     Shep
>     (Chairs)
>      
> 
> 
>         I agree with Jeffrey. The two drafts should be merged into a new
>         draft, which we will then call to adopt. I suggest that the
>         authors of each of the two docs:
> 
>         On Mon, Mar 29, 2021 at 7:26 PM Jeffrey (Zhaohui) Zhang
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             Shouldn’t it be the other way around – expand/merge first
>             and then adopt?____
> 
>             __ __
> 
>             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:____
> 
>             __ __
> 
>              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.____
>              2. If two neighbors fail simultaneously yet both can be
>                 protected by a 3^rd 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.____
>              3. Exactly when to switch back from a per-nbr FRR BIFT to
>                 the regular BIFT?____
> 
>             __ __
> 
>             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?____
> 
>             __ __
> 
>             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.____
> 
>             __ __
> 
>             Jeffrey____
> 
>             __ __
> 
>             *From:* BIER <[email-masked]
>             <mailto:[email-masked]>> *On Behalf Of *Huaimo Chen
>             *To:* Tony Przygienda <[email-masked]
>             <mailto:[email-masked]>>; [email-masked]
>             <mailto:[email-masked]> <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc:* BIER WG <[email-masked] <mailto:[email-masked]>>; BIER
>             WG Chairs <[email-masked] <mailto:[email-masked]>>
>             *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 <[email-masked]
>             <mailto:[email-masked]>> on behalf of Tony Przygienda
>             <[email-masked] <mailto:[email-masked]>>
>             *To:* zhang.zheng <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc:* BIER WG <[email-masked] <mailto:[email-masked]>>; BIER
>             WG Chairs <[email-masked] <mailto:[email-masked]>>
>             *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 <[email-masked]
>             <mailto:[email-masked]>> wrote:____
> 
>                 A 2-week WG adoption call begins for the following
>                 draft:____
> 
>                 <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%7C93d2f294e6394173ee3308d8f53503e2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637528955352100958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yVkZZVM9xkazCk5cU0dBgOmcuU9UGxyCnwOiSYGjqYI%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)____
> 
>                 __ __
> 
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
> 

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de