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

[Greg Shepherd <[e-mail]>]

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://datatracker.ietf.org/doc/draft-chen-bier-frr

..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 <[e-mail]>
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 <[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]> on behalf of Tony Przygienda <
> [e-mail]>
> *Sent:* Tuesday, March 16, 2021 6:08 AM
> *To:* zhang.zheng <[e-mail]>
> *Cc:* BIER WG <[e-mail]>; BIER WG Chairs <[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]> wrote:
>
> A 2-week WG adoption call begins for the following draft:
>
> https://datatracker.ietf.org/doc/draft-chen-bier-frr/
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-chen-bier-frr*2F&data=04*7C01*7Chuaimo.chen*40futurewei.com*7C79ac63710b47427a558d08d8e8638df2*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637514861570555970*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=DiHvux0ZUYEJru10lVQ4mXvpYx3l8ujGInm7uEjjxTw*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!TtAnkZJhg9BEJjANzO6CusX7i7eQqvTJHdhaH0qrrPdtcykRPrUybhZeavPA3X4F$>
>
> 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
>