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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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= >>> [email protected]>, 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 >>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/bess >>> >>> _______________________________________________ >>> BESS mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/bess >>> >>
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
