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 <
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
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
nanog@lists.nanog.org> parse 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/D727FQQX...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RN2G5OVZ...