> 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 <[email protected]> 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 < > [email protected]> wrote: > > > > > > > > On 25 Jan 2026, at 18:31, Martin Pels via NANOG <[email protected] > > > > 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/[email protected]/message/D727FQQXYPR3KVC4EAENVAXGVE5JC4O7/ > > > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/[email protected]/message/RN2G5OVZLP7SHCOHAFW4X35HFAIGNSOT/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/42JMOOJSYFOLFIKFTUQZO7XTMZFL2OPQ/
