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

I correct myself a bit here ;-) _IF_ the assumption is that _every_ node is
somehow directly connected to the controller and reports topology this can
be faster than IGP. very expensive proposition and pretty fragile but no
account for taste often. Bears all discussing out in a framework & spell
use cases clearly AFAIS

-- tony

On Tue, Mar 16, 2021 at 5:58 PM Tony Przygienda <tonysietf@gmail.com> wrote:

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