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 <[email protected]>
Sent: Thursday, April 13, 2023 4:44 PM
To: Jason Sterne (Nokia) <[email protected]>
Cc: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
