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

[Michael Menth <[e-mail]>]

Hi Jeffrey, all,

your proposal was also the conclusion two years ago when I brought up
the topic in the working group:

"The BIER FRR mechanism - be it tunnel-based or re-implementing LFAs on
the BIER layer - is a local mechanism and does not require cooperation
from other nodes. Probably both mechanisms can be even mixed within the
same network. Therefore, there is not need for standardization."

I think this is not documented in any IETF drafts or even meeting
minutes, it was just a conclusion from some side meetings. That was also
the reason why we did not progress the draft on tunnel-based bier-frr.

Nevertheless, it may be helpful to at least document both existing
bier-frr approaches as an informational draft so that manufacturers can
easily point to an implemented solution. This is helpful as both
solutions have pros and cons. A lot of contents is already in that paper
in which we summarized our understanding of the discussions two years ago:
https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth20c.pdf
Some of its content may be useful for an overview draft of bier-frr methods.

Regards

Michael

Am 16.03.2021 um 19:23 schrieb Jeffrey (Zhaohui) Zhang:
> If you consider BIFT and unicast FIB, they are actually very similar
> (ignoring the SI/sub-domain and bier label aspects). The only
> differences are:
> 
>  
> 
>  1. (bfr-id % bitstringLength) or prefix as key
>  2. F-BM associated with a BFR-nbr in BIFT
> 
>  
> 
> Each BIFT entry is built according how to reach a corresponding BFER,
> and the F-BM is obtained by setting the bits for all the BFERs that are
> reached by the BFR nbr.
> 
>  
> 
> So, however you do FRR for unicast (LFA or tunnel based link/node
> protection or whatever) and whether it is IGP or BGP or whatever, you
> can just build the BIER FRR forwarding state the same way, and update
> the F-BM for the backup nbr accordingly.
> 
>  
> 
> That’s why I keep saying that there is not much to standardize on BIER
> FRR. It seems that this topic keeps coming up, so perhaps I should write
> an information draft to elaborate the above principle and how it works
> with various protection mechanisms.
> 
>  
> 
> Jeffrey
> 
>  
> 
> *From:* BIER <[e-mail]> *On Behalf Of * Huaimo Chen
> *Sent:* Tuesday, March 16, 2021 1:28 PM
> *To:* Tony Przygienda <[e-mail]>
> *Cc:* [e-mail]; Michael Menth <[e-mail]>
> *Subject:* Re: [Bier] WG adoption call for draft-chen-bier-frr-02
> 
>  
> 
> *[External Email. Be cautious of content]*
> 
>  
> 
> 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://urldefense.com/v3/__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*7C2b86f5e805f04cf24c1008d8e89cdcd4*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637515107733090092*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=CNKcultin43VrTAvr*2BFH7V1FrMALSvaSpfmEiHcKm*2Fg*3D&reserved=0__;JSUlfiUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!SBpWq7LIP13dlIX5P6U98cqIp8gTMP5_gelzA7rNyBrhf7h6mMn6N6YLFKhaK3F2$>
>     (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://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*7C2b86f5e805f04cf24c1008d8e89cdcd4*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637515107733090092*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=4v2q4ToPT83pQYu5Fdwpc04pIcWrlihqy5m8YjgkVMA*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SBpWq7LIP13dlIX5P6U98cqIp8gTMP5_gelzA7rNyBrhf7h6mMn6N6YLFNWNaFXu$>
>     >    
>     <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://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*7C2b86f5e805f04cf24c1008d8e89cdcd4*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637515107733100045*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=koqOJ4RFqPhBPl81t259PjxeQ6TxmcdtMMqgC0XXDzQ*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SBpWq7LIP13dlIX5P6U98cqIp8gTMP5_gelzA7rNyBrhf7h6mMn6N6YLFF8NiiJX$>>
>     >
>     >     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://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fbier&data=04*7C01*7Chuaimo.chen*40futurewei.com*7C2b86f5e805f04cf24c1008d8e89cdcd4*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637515107733110014*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=54DHmen2Kbqxu0LRWeuGlVBQbIepvbs1MqJHtfd6Wh8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SBpWq7LIP13dlIX5P6U98cqIp8gTMP5_gelzA7rNyBrhf7h6mMn6N6YLFMxV4XUQ$>
>     >
> 
>     -- 
>     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://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=http*3A*2F*2Fkn.inf.uni-tuebingen.de*2F&data=04*7C01*7Chuaimo.chen*40futurewei.com*7C2b86f5e805f04cf24c1008d8e89cdcd4*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637515107733110014*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=JxeRMSG7j*2FOyGLbPa*2BzGXw6kmFMVp5QqUTHjBEi69L8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SBpWq7LIP13dlIX5P6U98cqIp8gTMP5_gelzA7rNyBrhf7h6mMn6N6YLFMoeJ9A-$>
> 
>     _______________________________________________
>     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://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fbier&data=04*7C01*7Chuaimo.chen*40futurewei.com*7C2b86f5e805f04cf24c1008d8e89cdcd4*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637515107733119960*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=t3kSFKDwKsa46DGRbO8YW1nyUrPEFKa5JsBBFmOsoBU*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SBpWq7LIP13dlIX5P6U98cqIp8gTMP5_gelzA7rNyBrhf7h6mMn6N6YLFEmh99Af$>
> 
>     _______________________________________________
>     BIER mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/bier
>     <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fbier&data=04*7C01*7Chuaimo.chen*40futurewei.com*7C2b86f5e805f04cf24c1008d8e89cdcd4*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637515107733129927*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=5GMZctOBdR6ynmvuwvZlL2O2*2FIFbQWVFmmk*2FJwKnHxE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!SBpWq7LIP13dlIX5P6U98cqIp8gTMP5_gelzA7rNyBrhf7h6mMn6N6YLFLvTCBdE$>
> 
> 
> Juniper Business Use Only
> 

-- 
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