Re: Destination Preference Attribute for BGP

[Robert Raszuk <robert () raszuk net>]

> 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 <mpetach () netflight com>
wrote:

> On Fri, Aug 18, 2023 at 12:31 PM Robert Raszuk <robert () 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.  ;)