The implementation of Link Bandwidth in FRR uses a transitive community to signal & perform an automatic accumulation at the AS boundary. This seems useful as it obviates the need for additional info (configuration) at each AS boundary to generate a new community using accumulated values.
From: Arie Vayner <ar...@vayner.net> Sent: Tuesday, July 6, 2021 10:13 PM To: Jeff Tantsura <jefftant.i...@gmail.com> Cc: bess@ietf.org; Satya Mohanty (satyamoh) <satyamoh=40cisco....@dmarc.ietf.org>; Gyan Mishra <hayabusa...@gmail.com>; vi...@cumulusnetworks.com Subject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft External email: Use caution opening links or attachments The way I see this implementation, this is not really a transitive community. The values are consumed within the local AS, and then a new community is generated, based on accumulated values, at the AS boundary. Tnx Arie On Fri, Jul 2, 2021 at 2:52 PM Jeff Tantsura <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>> wrote: Arie, The way the draft reads, it is quite clear that IANA allocated Link Bandwidth Ext. Community (0x4004) should be used (and formally changed to transitive), I'd be rather surprised if it is not the case ( that would make implementations non interoperable). I'm in the process of reviewing all existing implementations and will come back on this one. Implementers - please do respond (FRR incl) Practically - if there's wg consensus (I don't think this is needed, given there's a number of working implementations) to use a new extended community the document should become standard track with the formal IANA allocation request. Thanks, Jeff On Tue, May 25, 2021 at 1:16 PM Arie Vayner <ar...@vayner.net<mailto:ar...@vayner.net>> wrote: Jeff, Actually, the way this draft is written, and how the implementations I'm aware of are implemented, this is not really a transitive community. It is a new community that is being generated on the AS boundary. The community value is not carried over, but is calculated based on an cumulative value of other received communities, and then advertised as a new value across the AS boundary. Tnx, Arie On Tue, May 25, 2021 at 12:55 PM Jeff Tantsura <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>> wrote: Hi, I support adoption of the draft as Informational, please note, that request to change transitivity characteristics of the community is requested in another draft. Gyan - please note, while pretty much every vendor has implemented the community and relevant data-plane constructs, initial draft defines the community as non transititive, some vendors have followed that while some other have implemented it a transitive (to support obvious use case - eBGP in DC). Cheers, Jeff On May 22, 2021, 8:38 AM -0700, Satya Mohanty (satyamoh) <satyamoh=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>>, wrote: Hi all, On behalf of all the authors, we request a discussion of the draft https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-ebgp-dmz-03&data=04%7C01%7Cvivek%40nvidia.com%7Cbd4da59efe9f4e1f0d9f08d94105eae1%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637612316410191808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=PviDsxhP3fdpeiaJ7kpLTfHhvW7CnRKckImnUhiR4PY%3D&reserved=0> and subsequent WG adoption. This draft extends the usage of the DMZ link bandwidth to scenarios where the cumulative link bandwidth needs to be advertised to a BGP speaker. Additionally, there is provision to send the link bandwidth extended community to EBGP speakers via configurable knobs. Please refer to section 3 and 4 for the use cases. This feature has multiple-vendor implementations and has been deployed by several customers in their networks. Best Regards, --Satya _______________________________________________ BESS mailing list BESS@ietf.org<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=04%7C01%7Cvivek%40nvidia.com%7Cbd4da59efe9f4e1f0d9f08d94105eae1%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637612316410191808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=HWlek2Zt35r0IgoR1MBAx5DHb0%2BWHFHprK83YMfVJrg%3D&reserved=0> _______________________________________________ BESS mailing list BESS@ietf.org<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=04%7C01%7Cvivek%40nvidia.com%7Cbd4da59efe9f4e1f0d9f08d94105eae1%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637612316410201802%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=gTiNHeeaBSHI4ElNKHprFeU%2FrvYc4A6dvW6mSkaMVCE%3D&reserved=0>
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
