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

I have exactly same comment.
In the past we have witnessed complex and often quite harmful interactions of different protection schemes in multi-layer networking.
Think IPFRR on top of SDH/Optical protection. Unless properly coordinated, race conditions and unnecessary service degradation would often be observed.
Please spend some time on thinking how different surfaces interact and what would be required to make it work.

Regards,
Jeff

> On Mar 21, 2021, at 10:06, Greg Mirsky <gregimirsky@gmail.com> wrote:
> 
> 
> Hi Huaimo,
> perhaps my question was not clearly stated. Let me re-phrase it and add more detail to the scenario.
> As understand the discussion about using IP FRR and BIER FRR concurrently in the same BIER domain, you are of the opinion that such a combination is useful while others have expressed some reservation of its practicality. Do I understand that part of the discussion correctly?
> If we consider multi-layer protection schemes, using IP FRR and BIER FRR is one of its examples, we should consider operational issues that a multi-layer scenario introduces. Particularly, coordination of timers that determine detection of the network failure and trigger the protection switchover. Such coordination of OAM parameters and the expected switchover intervals intended to avoid unnecessary loss of data packets caused by the excessive of protection switchover in an overlay network.
> I missed finding that being discussed in the e-mail you've pointed out. Perhaps you can quote the part that you believe addressed my question.
> 
> Regards,
> Greg
> 
>> On Fri, Mar 19, 2021 at 9:47 PM Huaimo Chen <huaimo.chen@futurewei.com> wrote:
>> Hi Greg,
>> 
>>     Thanks for your comments/questions. 
>>     My responses to another email below should address/answer them.
>> 
>> https://mailarchive.ietf.org/arch/msg/bier/VsTPRmUi-26VSWrBPzdnLXzPvT0/
>> 
>> 
>> Best Regards,
>> Huaimo
>> From: Greg Mirsky <gregimirsky@gmail.com>
>> Sent: Wednesday, March 17, 2021 12:45 PM
>> To: Huaimo Chen <huaimo.chen@futurewei.com>
>> Cc: bier@ietf.org <bier@ietf.org>; BIER WG Chairs <bier-chairs@ietf.org>
>> Subject: Re: [Bier] WG adoption call for draft-chen-bier-frr-02
>>  
>> Hi Huaimo,
>> it seems that you are suggesting using IP FRR and BIER FRR in the same domain. Is my understanding correct? Multi-layer protection in a network may work but, in my opinion, overcomplicated network management and operation. Would you expect that BIER FRR is more responsive to a network failure than IP FRR? What benefits could be in such a scenario? Which parameters, in your opinion, need to be coordinated between IP and BIER layers? I think that if the document includes the concurrent use of IP FRR and BIER FRR it should provide more detail on how such a scenario could be realized.
>> 
>> Regards,
>> Greg
>> 
>> On Tue, Mar 16, 2021 at 10:27 AM Huaimo Chen <huaimo.chen@futurewei.com> wrote:
>> Hi Tony,
>> 
>>     Even though there is IGP running in the network and the underlay IP FRR is provided, the BIER FRR seems still needed. All the BIER packets are forwarded using the BIFTs. They are not forwarded using the normal FIBs with IP FRR support.  When a failure happens in the network, the BIER packets will still be forwarded using the old BIFTs without considering the failure until the old BIFT is recomputed and updated based on the new network topology after the failure. During this period (from the time of the failure to the time at which the BIFTs are updated), the BIER packets may be lost.
>> 
>> Best Regards,
>> Huaimo
>> From: Tony Przygienda <tonysietf@gmail.com>
>> Sent: Tuesday, March 16, 2021 12:58 PM
>> To: Huaimo Chen <huaimo.chen@futurewei.com>
>> Cc: Michael Menth <menth@uni-tuebingen.de>; bier@ietf.org <bier@ietf.org>
>> Subject: Re: [Bier] WG adoption call for draft-chen-bier-frr-02
>>  
>> we need a framework here ;-) 
>> 
>> when IGP calculates the underlying FRR it's always a better solution. Nothing is faster than IGP and anything calculated as "better FRR" or "backup FRR" will not have the topology to do a better job/faster than IGP can. So AFAIS the only real use case here is BIER without IGP signalling but correct me if I'm wrong
>> 
>> -- tony 
>> 
>> 
>> On Tue, Mar 16, 2021 at 5:02 PM Huaimo Chen <huaimo.chen@futurewei.com> wrote:
>> Hi Michael,
>> 
>>     Thanks much for your valuable comments.
>>     My responses are inline below with prefix [HC].
>> 
>> Best Regards,
>> Huaimo
>> From: BIER <bier-bounces@ietf.org> on behalf of Michael Menth <menth@uni-tuebingen.de>
>> Sent: Tuesday, March 16, 2021 7:11 AM
>> To: bier@ietf.org <bier@ietf.org>
>> Subject: Re: [Bier] WG adoption call for draft-chen-bier-frr-02
>>  
>> Hi Tony, all,
>> 
>> Am 16.03.2021 um 11:08 schrieb Tony Przygienda:
>> 
>> > 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.
>> 
>> Right. The solution may make sense if the routing underlay does not
>> offer FRR capabilities.
>> 
>> [HC]: When the routing underlay supports IP FRR, the BIER should also 
>> provide BIER FRR since the BIER packets are forwarded using the BIFTs. 
>> When failures happen in the network, the BIER packets are still forwarded 
>> using the old BIFTs until the old BIFTs are updated according to the 
>> updated network topology after the failures.
>> 
>> > 
>> > 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
>> 
>> I agree. in the absence of an IGP, the "native BIER-FRR on bier layer"
>> must be set by a controller.
>> 
>> [HC]: I agree too.
>> 
>> So, below the line, an applicability statement would be helpful. What
>> are those cases?
>> - IGP running but without FRR on the routing underlay?
>> - No IGP and no FRR on the routing underlay?
>> 
>> [HC]: When IGP is running in the network, each BFR in the network calculates,
>> installs and/or updates its BIER FRR BIFTs. The BIER FRR in the draft is 
>> independent of the underlay IP FRR. 
>> When no IGP is running in the network, the BIER controller for the network
>> calculates, installs and/or updates the BIER FRR BIFTs into BFRs in the network,
>> regardless of whether the routing underlay FRR is provided.
>> 
>> 
>> However, if the controller takes care of BIER-FRR, what could be reasons
>> for missing FRR on the routing underlay? If there is a FRR on the
>> routing underlay (also provided through a controller), tunnel-based
>> bier-frr solves the problem in a transparent way.
>> 
>> [HC]: The BIER FRR in the draft is independent of the underlay IP FRR.
>> Regardless of whether the routing underlay FRR is provided, the 
>> BIER FRR BIFTs are computed in the same way.
>> 
>> BTW, we studied protection variants for controller-based infrastructures
>> (for routing underlays, not for BIER). Challenge is to keep state low.
>> LFA-based solutions help a lot and outperform others. 100% protection is
>> possible with only little additions. Results are available:
>> https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fatlas.informatik.uni-tuebingen.de%2F~menth%2Fpapers%2FMenth20-Sub-6.pdf&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C5d3cb8163c7f4a1557e608d8e86c408f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637514898966623524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=03cc%2BIvdV%2BCg%2F0PCFulWzuCa0h4I5sBqn8K5QPT5BR8%3D&amp;reserved=0 (under
>> revision)
>> 
>> [HC]: Thanks much for your information.
>> 
>> 
>> Regards,
>> 
>> Michael
>> 
>> > 
>> > thanks
>> > 
>> > -- tony
>> > 
>> > On Tue, Mar 16, 2021 at 7:41 AM <zhang.zheng@zte.com.cn
>> > <mailto:zhang.zheng@zte.com.cn>> wrote:
>> > 
>> >     A 2-week WG adoption call begins for the following draft:
>> > 
>> >     https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-bier-frr%2F&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C5d3cb8163c7f4a1557e608d8e86c408f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637514898966623524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=797z0ndM2IahVL2y9xPoY%2BOU5x4%2F3w1FaSWfoF%2BC6pQ%3D&amp;reserved=0
>> >     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-bier-frr%2F&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C5d3cb8163c7f4a1557e608d8e86c408f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637514898966623524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=797z0ndM2IahVL2y9xPoY%2BOU5x4%2F3w1FaSWfoF%2BC6pQ%3D&amp;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
>> > BIER@ietf.org
>> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C5d3cb8163c7f4a1557e608d8e86c408f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637514898966623524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=aZ6%2BjQBpo7k81fqf%2FnYdfer7mS45RlhB0lPT7%2B%2BVm6I%3D&amp;reserved=0
>> > 
>> 
>> -- 
>> 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:menth@uni-tuebingen.de
>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkn.inf.uni-tuebingen.de%2F&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C5d3cb8163c7f4a1557e608d8e86c408f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637514898966623524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2gozTq4XIXnxQu2P62mtFSGOEID93679cjqQeAQOPbo%3D&amp;reserved=0
>> 
>> _______________________________________________
>> BIER mailing list
>> BIER@ietf.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C5d3cb8163c7f4a1557e608d8e86c408f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637514898966623524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=aZ6%2BjQBpo7k81fqf%2FnYdfer7mS45RlhB0lPT7%2B%2BVm6I%3D&amp;reserved=0
>> _______________________________________________
>> BIER mailing list
>> BIER@ietf.org
>> https://www.ietf.org/mailman/listinfo/bier
>> _______________________________________________
>> BIER mailing list
>> BIER@ietf.org
>> https://www.ietf.org/mailman/listinfo/bier
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier