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. 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? 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 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. 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": "*" } ] } 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 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. 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. These mapping tables could also be recycled across multiple ASNs, or even maintained by IANA. 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? 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? Thank you for clarifying this. -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
