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:
[..]
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
https://datatracker.ietf.org/doc/draft-ietf-grow-yang-bgp-communities/ 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/D727FQQX...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RN2G5OVZ...