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

["Gengxuesong (Geng Xuesong)" <[e-mail]>]

Hi Jeffrey,

I just want to avoid mixing all the discussions together and getting back again. Getting agreement to the following questions may be helpful (also could be found in my previous comments):

1.       Is BIER FRR necessary?

(It has been discussed in the discussion of draft-merling. And it is raised again. )

2.       Is BIER FRR implementation dependent so not supposed to be standardized?

(I think we all agree that fast reroute algorithms are kind of implementation dependent without signaling. Being simple or rich depends on the idea itself.)

3.       How to deal with 2 existing documents about BIER FRR?

( It depends on WG. When I read these 2 documents, I find they are reasonable and independent methods about implementing BIER FRR. They could be considered to be adopted together)

Best
Xuesong

From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: Thursday, March 18, 2021 7:42 PM
To: Gengxuesong (Geng Xuesong) <[e-mail]>; Tony Przygienda <[e-mail]>; Aijun Wang <[e-mail]>
Cc: [e-mail] <[e-mail]>; BIER WG <[e-mail]>; BIER WG Chairs <[e-mail]>
Subject: RE: [Bier] WG adoption call for draft-chen-bier-frr-02

There is a difference between RFC5286 and this.

Even though LFA does not require signaling, it was a significantly new way of doing FRR. You can also notice the both RFCs are have rich content describing the principles and methods of LFA.

With BIER FRR, since it builds on top of mature tunnel or LFA based protection, once the principle is described with the reference model of “BIFT entries with ECMP/primary/backup branches” (which is similar to unicast case), there is really no need for additional specification. Whether using a single table or per-nbr table or other methods is implementation detail, and as we have seen, the per-nbr table method has its limitations.

As the co-authors of draft-merling can confirm, they looked into BIER FRR two years ago and we came to the same conclusion that there is no need for standardization. Even though draft-merling does not talk about LFA-to-BFER based protection, we actually also discussed that (because Juniper’s design actually supports both).

draft-merling was not even updated because of that conclusion. Now with the strong push for draft-chen, I agree that a joint informational draft is desired. Adding content of LFA-to-BFER and controller aspects does not change the fact that there is no need for standardization.

Jeffrey

From: BIER <[e-mail]<mailto:[e-mail]>> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Thursday, March 18, 2021 4:13 AM
To: Tony Przygienda <[e-mail]<mailto:[e-mail]>>; Aijun Wang <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; 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

[External Email. Be cautious of content]

Hi Tony,

Sorry for stepping in. But I’m really confused why this document is called “implementation dependent”. Especially so many fast reroute algorithms have been standardized in history, as  RFC5286 or RFC7490.
LFA BIER FRR mechanism introduce multiple FRR BIFTs because calculating FRR BIRT makes the F-BM different for different BFR-NBR failure, if the problem is about “multiple BIFTs” . If there is any other concern, could you raise some examples from the document?

Best
Xuesong


From: BIER [mailto:[e-mail]] On Behalf Of Tony Przygienda
Sent: Thursday, March 18, 2021 3:52 PM
To: Aijun Wang <[e-mail]<mailto:[e-mail]>>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>; zhang.zheng <[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

As others pointed out it's not clear we need to "standardize" this for the simple reason this is _very_ implementation dependent. "Standardizing" is important if interoperability is important, in this sense if this draft talks about different schemes interoperating, gotchas etc, yes, there may be an angle there. Starting from a model aligned with Menthe, describing alternate techniques [like multiple BIFTs with compression etc] if the technical problems/discussions with those can be ironed out is a good thing since it will document possible approaches/issues etc but what track this is best published on should be discussed bit down the road especially after implementation/experience with different approaches.

-- tony

On Thu, Mar 18, 2021 at 3:56 AM Aijun Wang <[e-mail]<mailto:[e-mail]>> wrote:
Hi, All:

As co-author of this draft, I support its adoption.
I am not aware of any IPR that applies to this draft.

Some technical discussions and clear statements for the implementation are necessary, standardize them can accomplish the consistent behavior across the network wide.

Best Regards

Aijun Wang
China Telecom

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Tuesday, March 16, 2021 2:41 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Bier] WG adoption call for draft-chen-bier-frr-02


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:/datatracker.ietf.org/doc/draft-chen-bier-frr/__;!!NEt6yMaO-gk!V5199OPdTs4Bxoq-lYOVeVZgmWre2iDBQdHYg41o0hcR3UFM0WtPoxyMFbfLA3Ox$>

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