Destination Preference Attribute for BGP

Fri Aug 18 20:40:31 UTC 2023

On Fri, Aug 18, 2023 at 12:31 PM Robert Raszuk <robert at raszuk.net> wrote:

> Hi Jakob,
>
> On Fri, Aug 18, 2023 at 7:41 PM Jakob Heitz (jheitz) via NANOG <
> nanog at 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.  ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230818/3af3edf9/attachment.html>