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

[Michael Menth <[e-mail]>]

BIER-FRR is also needed if a BFR-NBR is down. Here, the IGP cannot help.

BR, Michael

Am 22.03.2021 um 07:32 schrieb Tony Przygienda:
> AFAIS couple parties pointed out that most useful are considerations for
> BIER FRR in case there is no IGP with LFA in the network and for BIER-TE
> where IGP protection doesn't latch on AFAIS. which I agree with ...
> 
> -- tony
> 
> On Sun, Mar 21, 2021 at 9:20 PM Jeff Tantsura <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     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 <[e-mail]
>>     <mailto:[e-mail]>> 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
>>     <[e-mail] <mailto:[e-mail]>> 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/
>>         <https://mailarchive.ietf.org/arch/msg/bier/VsTPRmUi-26VSWrBPzdnLXzPvT0/>
>>
>>
>>         Best Regards,
>>         Huaimo
>>         ------------------------------------------------------------------------
>>         *From:* Greg Mirsky <[e-mail]
>>         <mailto:[e-mail]>>
>>         *Sent:* Wednesday, March 17, 2021 12:45 PM
>>         *To:* Huaimo Chen <[e-mail]
>>         <mailto:[e-mail]>>
>>         *Cc:* [e-mail] <mailto:[e-mail]> <[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
>>          
>>         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
>>         <[e-mail] <mailto:[e-mail]>>
>>         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 <[e-mail]
>>             <mailto:[e-mail]>>
>>             *Sent:* Tuesday, March 16, 2021 12:58 PM
>>             *To:* Huaimo Chen <[e-mail]
>>             <mailto:[e-mail]>>
>>             *Cc:* Michael Menth <[e-mail]
>>             <mailto:[e-mail]>>; [e-mail]
>>             <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
>>             *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
>>             <[e-mail]
>>             <mailto:[e-mail]>> wrote:
>>
>>                 Hi Michael,
>>
>>                     Thanks much for your valuable comments.
>>                     My responses are inline below with prefix [HC].
>>
>>                 Best Regards,
>>                 Huaimo
>>                 ------------------------------------------------------------------------
>>                 *From:* BIER <[e-mail]
>>                 <mailto:[e-mail]>> on behalf of Michael
>>                 Menth <[e-mail]
>>                 <mailto:[e-mail]>>
>>                 *Sent:* Tuesday, March 16, 2021 7:11 AM
>>                 *To:* [e-mail] <mailto:[e-mail]>
>>                 <[e-mail] <mailto:[e-mail]>>
>>                 *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
>>                 <https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fatlas.informatik.uni-tuebingen.de%2F~menth%2Fpapers%2FMenth20-Sub-6.pdf&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615768749%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oSLGnBnwcsrY2gaRZqG%2FLSMOYLNQcG0Mjm9NNVc6TUU%3D&reserved=0>
>>                 (under
>>                 revision)
>>
>>                 [HC]: Thanks much for your information.
>>
>>
>>                 Regards,
>>
>>                 Michael
>>
>>                 > 
>>                 > thanks
>>                 > 
>>                 > -- tony
>>                 > 
>>                 > On Tue, Mar 16, 2021 at 7:41 AM <[e-mail] <mailto:[e-mail]>
>>                 > <mailto:[e-mail]
>>                 <mailto:[e-mail]>>> 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&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615778703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8wxBypO3zOln7rLaSaXO446xFFfpJfOx4Lr6bKO15z4%3D&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
>>                 <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%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615788657%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=evcnoZLl57g4rLoio0gj2Q4XOa26a2cnX4Jt7%2B3Dogg%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
>>                 > [e-mail] <mailto:[e-mail]>
>>                 > 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
>>                 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615788657%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7kv2BUZk34Y7k9amlOAcHzacQ5ZlDqjGzb4mZWm%2FCXw%3D&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: [phone]
>>                 fax: [phone]
>>                 mailto:[e-mail]
>>                 <mailto:[e-mail]>
>>                 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
>>                 <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkn.inf.uni-tuebingen.de%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615798609%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dwQXPxovW3YS99oeGr3%2FdrYKfMFPSR94Xz1ihTfE2l4%3D&reserved=0>
>>
>>                 _______________________________________________
>>                 BIER mailing list
>>                 [e-mail] <mailto:[e-mail]>
>>                 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
>>                 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615798609%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=w5ocCaRoOrDQ%2BVSeW1%2Bl7MUnqp3TN6InBTmzXx00blc%3D&reserved=0>
>>                 _______________________________________________
>>                 BIER mailing list
>>                 [e-mail] <mailto:[e-mail]>
>>                 https://www.ietf.org/mailman/listinfo/bier
>>                 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615808573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CibFkXbi9yOCwGTwn8k8tIrMoZvvZgi8DL9EGHE%2Fzys%3D&reserved=0>
>>
>>             _______________________________________________
>>             BIER mailing list
>>             [e-mail] <mailto:[e-mail]>
>>             https://www.ietf.org/mailman/listinfo/bier
>>             <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615808573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CibFkXbi9yOCwGTwn8k8tIrMoZvvZgi8DL9EGHE%2Fzys%3D&reserved=0>
>>
>>     _______________________________________________
>>     BIER mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/bier
>>     <https://www.ietf.org/mailman/listinfo/bier>
> 
> 
> _______________________________________________
> BIER mailing list
> [e-mail]
> 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: [phone]
fax: [phone]
mailto:[e-mail]
http://kn.inf.uni-tuebingen.de