Hi Maria,
On 23/06/2026 15:34, Maria Matejka wrote:
Howdy!
On Thu, Apr 16, 2026 at 05:30:05AM -0700, [email protected] wrote:
Internet-Draft draft-ietf-grow-yang-bgp-communities-08.txt is now
available. It is a work item of the Global Routing Operations (GROW)
WG of the IETF.
Title: A YANG Data Model for BGP Communities Author: Martin Pels
Name: draft-ietf-grow-yang-bgp-communities-08.txt
I’m reading the YANG module and I’m confused by a bunch of things, not
ordered by anything else than the time when I spotted these.
Thank you for reviewing the module! I'll try to clear up the confusion :-)
This is quite a raw dump of my confusion, no need to bother replying per
partes.
Why is “leaf format” outside of “grouping local-admin-fields” where the
description of “length” expects “local-admin-format” to exist?
I see how putting it inside the grouping makes more sense. I'll change that.
The field concept looks weird for RFC 4384, which is coincidentally used
in appendix A.2 as an example. There are also non-region values, which
do not respect the supposed field structure:
https://www.iana.org/assignments/bgp-data-collection-communities-std/
bgp-data-collection-communities-std.xhtml#bgp-data-collection-
communities-std-1
The purpose of the JSON examples is that they show how the model can be
used. The intention was not to provide a JSON for all of RFC4384 :-)
I’ve been walking over the communities during last several weeks
(partially because nobody told me about this draft) while working on
https://datatracker.ietf.org/doc/draft-marenamat-idr-bgp-attribute-
formatting/ and I’m now pretty convinced that while the field concept
itself looks promising, there are places where the structure is more
fine-grained than it looks on the surface.
Also, if you look into the current BGP YANG draft, the community
structure is not formally respected there, and instead the communities
are formatted as strings. That seems kinda orthogonal, but to apply the
definition, one would need to parse the string community back to binary
and then re-format using the definition.
Yes. Strings of digits is also how most operators define communities.
The binary usage in RFC4384 is an exception. The YANG communities model
supports both.
Also, in appendix A.1, the description would be more clean if it was a
union of identityref and string, instead of specifying a special meaning
of a single asterisk.
|"local-data-part-2": { "field": [ { "name": "ASN", "pattern": ".*",
"description": "*" } ] }|
I like this idea, but for usage with JSON I think it would be less
error-prone as a choice. Something like:
"description": "some description"
or
"description-ref": "ietf-bgp-communities:field-value"
This would prevent mistakes where "ietf-bgp-communities:field-value" is
interpreted as a literal string.
Also in A.2, the Sattelite flag (and there are more flags in EC’s) is
quite unhelpful to be 0/1, while it could be SAT if 1 … oh wait, what?
Where are we actually going to put the flag value? Also, should we
define RFC4384-EXTENDED-ORIGIN-xx/yy for each single country? Huh. And
for each ASN? Aha! The SAT is fixed to 0, so that there would be another
RFC4384-EXTENDED-ORIGIN-xx/yy-SAT specification? Maybe there should be
|"description": "Satellite"| in the example, instead of an asterix?
The current example explicitly matches only a terrestrial link (it
matches on "pattern": "0" for the satellite bit).
An example that matches on both would be:
{
"name": "Satellite",
"length": 1,
"pattern": ".*",
"description": "*"
}
which would either display "Satellite:0" or "Satellite:1".
The introduction and rationale (sec. 1 and 3) are quite explicitly
constraining the use to ASN-specific semantics, while at the same time
the examples are for RFC-specified values.
I picked these because they are documented examples of use cases for
encoding things in communities. The intent was not to standardize the
full JSON for how the model is to be used with these RFCs.
Maybe I’m reading it wrong, but now when I’m checking the already
existing published JSONs, I’m not so sure that this is gonna scale well
with multiple sources. For both cases, it seems to me that one could
simply define a mapping table between the site ID and its name, and
compose the name that way, instead of having lots of redundant data in
the JSON.
This is a trade-off between complexity of the format and redundancy.
I've received comments that the self-contained JSON is already too
complicated compared to a 1 community per line text file. Extending this
with mapping tables would complicate things even more, while it is not
required for most use cases.
If you look at examples what operators are currently doing with
communities[0] and compare that with the ones published using the YANG
model[1] you'll find that most of the former are quite simple, with a
limited amount of permutations.
For the AS197000 case the current model leads to a 28k JSON, or 12k
CBOR. Suppose that, in the extreme case, 100k autonomous systems publish
files this large, it would amount to ~1.2GB in total. Not insignificant,
which is why we opted for publishing references in the RPKI and not the
entire objects. But also not insurmountable.
> These mapping tables could also be recycled across multiple
> ASNs, or even maintained by IANA.
The current model focuses on the ability to publish what an AS has
defined, because every AS is currently doing their own thing. If there
is appetite for sharing definitions between ASNs, I suppose "grouping
local-admin-fields" could contain a union or choice between a "field"
list or a URL reference to a shared JSON?
Suggestions are welcome!
Huh. Do I understand correctly that the description is actually … not
used at all? What should I do if I wanna use the whole local-admin2
value in LC as flags? Is that expected to work like this?
|"name": "LARGE-CAT-COMMUNITY", ... "local-data-part-2": { "format":
"binary", "field: [ { "description": "*", "length": 1, "name": "meow",
"pattern": ".*", }, { "description": "*", "length": 1, "name": "nya",
"pattern": ".*", }, { "description": "*", "length": 1, "name": "wrrr",
"pattern": ".*", }, { "description": "*", "length": 1, "name": "tsss",
"pattern": ".*", }, ... ] }|
… and then display … what?
Assuming the values of the flags seen on the wire would be 1001, this
would display "meow:1 nya:0 wrr:0 tsss:1" ('*' indicates that the value
of the field should be used as description).
The RFC8195 example shows a case where the description is used:
"local-data-part-1": {
"field": [
{
"name": "Function",
"pattern": "4",
"description": "ASN-No-Export"
}
]
},
"local-data-part-2": {
"field": [
{
"name": "ASN",
"pattern": ".*",
"description": "*"
}
]
}
Given "64497:4:64498" this would translate to "Function:ASN-No-Export
ASN:64498"
Also, what if a user wants to filter by this data, or enter it? For a
single value, it’s easy. For a structural thing?
Can you give an example of this?
Thank you for clarifying this.
I hope it helps. And I'd love more ideas on how to better structure the
model.
Kind regards,
Martin
[0] https://github.com/NLNOG/lg.ring.nlnog.net/tree/main/communities
[1] https://github.com/NLNOG/lg.ring.nlnog.net/blob/main/community_urls.yml
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
