Re: Publishing BGP communties for your network (Re: What's up with BGP communities?)

[Tom Beecher via NANOG <nanog () lists nanog org>]

Geofeeds are useful because they cut out the middleman in terms of geo
info, and provide a mechanism for someone to detect and react to that
change quickly, since a very large use case for these is targeted content
and advertising. Waiting weeks for a geodb to detect and publish a change
costs money ; pulling the feed from the source of truth is worth the effort
to create tooling and automation around it.

BGP communities don't see anywhere near the same volume of change. An ASN
may add/remove locations as they build their network, which then changes
location comms, but those things happen over long time horizons. Customer
actions comms may be added or deleted, but again over a long period of
time. There is no ROI to develop tooling around hypothetical BGP comm feeds
; this data never needs to be updated in real time if it changes.

Beyond that, even if we did assert that a BGP community feed similar to
geofeeds existed, the only thing it should EVER be used for is detection
that a given ASN's communities have changed. It should NEVER be integrated
with policy/config generation, unless you enjoy nuking your own network.

On Mon, Jan 26, 2026 at 2:04 PM Callahan Warlick <callahanwarlick () gmail com>
wrote:

> > an entire YANG model for these is not especially
> beneficial
>
> Having some structure for specific usecases of bgp communities might be
> useful- e.g. geo-based origin communities. This could be accomplished in a
> way similar to what was done for ip geolocation via rfc8805- which I've
> found is very useful for maintaining these datasets over time from known
> publishers.
>
> For more varied or generic community usecases, I totally agree that a
> unified model might be more difficult and less beneficial.
>
> On Mon, Jan 26, 2026 at 1:52 PM Tom Beecher via NANOG <
> nanog () lists nanog org> wrote:
>
> > > And for LGs the above repo has them all :) Only other source is
> > > https://bgp.tools <https://bgp.tools/> which has sometimes more details
> > > on some networks when folks have entered them manually there.
> >
> >
> > BGP.Tools is not the only source. onestep.net used to be the defacto
> > source
> > that collated most of these.
> >
> > I agree though that an entire YANG model for these is not especially
> > beneficial. We store communities in a similar way, text file that is human
> > readable but also parseable to translate when needed.
> >
> > I could see a use case for this to detect WHEN an AS's published
> > communities **CHANGED** without having to go look for that, but with as
> > infrequently as most do it's kinda meh.
> >
> > On Mon, Jan 26, 2026 at 11:36 AM Jeroen Massar via NANOG <
> > nanog () lists nanog org> wrote:
> >
> > > > On 25 Jan 2026, at 18:31, Martin Pels via NANOG <
> > nanog () lists nanog org>
> > > wrote:
> > > > [..]
> > https://datatracker.ietf.org/doc/draft-ietf-grow-yang-bgp-communities/
> > > > Using the model described here, networks can publish a JSON file with
> > > descriptions for the communities they use for their Autonomous System.
> > >
> > > I thought everybody just added a simple text file to:
> > >  https://github.com/NLNOG/lg.ring.nlnog.net/tree/main/communities
> > > and called it a day? That file format is simple, succint and readable by
> > > humans.
> > >
> > > Is the intent of that YANG document to let a computer parse it and do
> > > automatic setting of action communities? Or is it just to see what the
> > > label is?
> > >
> > >
> > > For my own looking glass what I do is I parse the above directory and
> > > translate it to a little lookup array. The two YANG ones from RIPE I
> > parse
> > > in a similar way, similar to what the NLNOG LG does, all the YANG
> > markup is
> > > just tossed though.
> > >
> > >
> > > But in the end, for most purposes it is to turn the numbers into a label
> > > so that one can see what the community means. And unless it is an action
> > > policy, no computer will be acting upon those communities as one has to
> > > understand the full intent (and no, an LLM will not get that yet, and
> > > please do not let a LLM close to BGP :) )
> > >
> > > Thus they should be good for humans setting an action community or
> > viewing
> > > what the community means.
> > >
> > > Any other purposes and thus reason why to make it more complex than
> > that?
> > > A WHOIS/RPSL way of being able to indicate where one stores their
> > > community.txt file for easy discovery would be cool though. Though that
> > is
> > > likely something https://www.peeringdb.com <https://www.peeringdb.com/>
> > > could do and then it is solved too.
> > >
> > > And for LGs the above repo has them all :) Only other source is
> > > https://bgp.tools <https://bgp.tools/> which has sometimes more details
> > > on some networks when folks have entered them manually there.
> > >
> > > Regards,
> > >  Jeroen
> > >
> > > _______________________________________________
> > > NANOG mailing list
> > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/D727FQQXYPR3KVC4EAENVAXGVE5JC4O7/
> > >
> > _______________________________________________
> > NANOG mailing list
> >
> > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/RN2G5OVZLP7SHCOHAFW4X35HFAIGNSOT/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/S7T23AEJXJJLFRMN2W67ARNSXIWUFFBG/