> it's really about efficiently *parsing and updating* communities-- Absolutely correct.
Inefficient implementations of how communities are used in inbound or outbound policies can do a lot of harm - no doubt about that - and as you say some surface in least convenient moments. But the point I was making is that this is not the fault of the Community Attribute itself but rather the poor implementation choice. Kind regards, RR On Fri, Aug 18, 2023 at 10:40 PM Matthew Petach <mpet...@netflight.com> wrote: > > > On Fri, Aug 18, 2023 at 12:31 PM Robert Raszuk <rob...@raszuk.net> wrote: > >> Hi Jakob, >> >> On Fri, Aug 18, 2023 at 7:41 PM Jakob Heitz (jheitz) via NANOG < >> nanog@nanog.org> wrote: >> >>> That's true Robert. >>> >>> However, communities and med only work with neighbors. >>> >>> Communities routinely get scrubbed because they cause increased memory >>> usage and convergence time in routers. >>> >> >> Considering that we are talking about control plane memory I think >> the cost/space associated with storing communities is less then >> negligible these days. >> >> And honestly with the number of BGP update generation optimizations I >> would not say that they contribute to longer protocol convergences in any >> measurable way. >> >> To me this is more of the no trust and policy reasons why communities get >> dropped on the EBGP peerings. >> >> Cheers, >> R. >> >> > Hi Robert, > > Without naming any names, I will note that at some point in the > not-too-distant past, I was part of a new-years-eve-holiday-escalation to > $BACKBONE_ROUTER_PROVIDER when the global network I was involved with > started seeing excessive convergence times (greater than one hour from BGP > update message received to FIB being updated). > After tracking down development engineer from $RTR_PROVIDER on the new > years eve holiday, it was determined that the problem lay in assumptions > made about how communities were stored in memory. Think hashed buckets, > with linked lists within each bucket. If the communities all happened to > hash to the same bucket, the linked list in that bucket became extremely > long; and if every prefix coming in, say from multiple sessions with a > major transit provider, happened to be adding one more community to the > very long linked list in that one hash bucket, well, it ended up slowing > down the processing to the point where updates to the FIB were still > trickling in an hour after the BGP neighbor had finished sending updates > across. > > A new hash function was developed on New Year's day, and a new version of > code was built for us to deploy under relatively painful circumstances. > > It's easy to say "Considering that we are talking about control > plane memory I think the cost/space associated with storing communities is > less then negligible these days." > The reality is very different, because it's not just about efficiently > *storing* communities, it's really about efficiently *parsing and updating* > communities--and the choices made there absolutely *DO* "contribute to > longer protocol convergences in any measurable way." > > Matt > (the names have been obscured to increase my chances of being hireable in > the industry again at some future date. ;) > > >
