Hi Jeff, I’m branching off a separate thread for the extended communities discussion. Is this a good one from the draft for discussion?
/* BGP Extended Community Types. */ typedef bgp-ext-community-type { type union { type string { pattern 'route\-target:(6[0-5][0-5][0-3][0-5]|' + '[1-5][0-9]{4}|[1-9][0-9]{1,4}|[0-9]):' + '(4[0-2][0-9][0-4][0-9][0-6][0-7][0-2][0-9][0-6]|' + '[1-3][0-9]{9}|[1-9]([0-9]{1,7})?[0-9]|[0-9])'; /* * description * "Type 0x00, Sub-Type 0x02: Route-Target * route-target:(ASN):(local-admin) * 2 octets global administrator and 4 octets local * administrator."; * reference * "RFC 4360: BGP Extended Communities Attribute, * Section 4."; */ } …snip… type string { pattern 'route\-origin:' + '(4[0-2][0-9][0-4][0-9][0-6][0-7][0-2][0-9][0-6]|' + '[1-3][0-9]{9}|[1-9]([0-9]{1,7})?[0-9]|[0-9])' + '(6[0-5][0-5][0-3][0-5]|[1-5][0-9]{4}|' + '[1-9][0-9]{1,4}|[0-9])'; /* * description * "Type 0x02, Sub-Type 0x03: Route-Origin * route-origin:(ASN):(local-admin) * 4 octets global administrator and 2 octets local * administrator."; * reference * "RFC 5668: 4-Octet AS Specific BGP Extended Community, * Section 4."; */ } type string { // raw with 8 octets pattern 'raw:' + '([0-9A-Fa-f][0-9A-Fa-f]:){7}' + '[0-9A-Fa-f][0-9A-Fa-f]'; } } description "Type definition for extended community attributes. It includes a way to specify a 'raw' string that is followed by 8 bytes of octet string to support new and experimental type definitions."; reference "RFC 4360: BGP Extended Communities Attribute."; } Things can get tricky with unions in YANG, especially if things overlap. Are there values that one could configure as “raw:…” that overlap with the other union members? The raw value and the “other value” (that overlaps) would be considered completely different & separate tokens in YANG. In other words, it isn’t really valid to set a “raw” value in a NETCONF server, but then fetch the configuration and see a different value (i.e. auto converted by the server to the known non-raw equivalent). A more intuitive example for me is thinking about TCP ports. This is an example of a potentially problematic union: Union { Type uint16; Type enumeration { Enum ssh { Value 22; <- could actually be any other number (not significant) } } YANG sees the values “ssh” and “22” as completely separate independent values/tokens. If the typedef was used for state (config false) then it gets tricky to decide what to return for the value of a leaf of this type (when the port is 22). A human user sees 22 and ssh as the same thing, but YANG doesn’t. Maybe this issue doesn’t turn out to be a problem for this particular extended community typedef but I’m not sure (implementors could make a mistake with it). Jason From: Jeffrey Haas <jh...@pfrc.org> Sent: Thursday, April 13, 2023 4:44 PM To: Jason Sterne (Nokia) <jason.ste...@nokia.com> Cc: netmod@ietf.org Subject: Re: Unknown bits - backwards compatibility I wish to point you and others concerned on these points to the BGP YANG modeling for Extended Communities, which will have these problems in a different flavor: Known communities will render via the typedefs, unknown will render using the prefix 'raw'. (See typedef bgp-ext-community-type.) This headache is already a consideration in every BGP implementation that deals with extended communities in changing meaning. [>>JTS:] Can you point me to a repository or RFC where I can see this? I’m not familiar with where this YANG work is being done. Sorry for not including the URL. This document went to WGLC for IDR a few days ago. We'll be asking (yet yet yet again) for YANG doctor review. https://www.ietf.org/archive/id/draft-ietf-idr-bgp-model-16.html You'll find the typedef issue for extended communities in there, and also the field for unknown bits in the operational state that is the genesis for this conversation. -- Jeff
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod