public
public copied to clipboard
openconfig
ieeefloat32 (YANG binary) usage and type handling
Before cutting a PR, I want to resurrect an old topic that has come up again recently (for discussion in an upcoming OpenConfig operator/community forum)
Past issues:
- https://github.com/openconfig/public/issues/261
- https://github.com/openconfig/public/issues/307
Now, reasoning in the above issues aside (user friendly) it seems we have a few very early model publishes that leveraged the ieeefloat32 type where they likely should be decimal64 (w/ fraction-digits) that gives us the same consumption model we are familiar with across other like model nodes. These are predominantly seen across "Power" and OSPF/ISIS (LSA/TLV values). This is a case where it seems we have over-complicated such types for no apparent reason so would like to visit assessment of such types if we want to adjust. This would be backwards incompatible and is likely we do not want to change the node names so we would have another decision on the rules regarding compatibility here.
Another closely related item here is the encoding rules w/ YANG -> proto3 types for a protocol such as gNMI. It seems we have never really outlined the type mapping in detail here and most are left to assumption/self-explanitory. For such a type above, the underlying YANG binary would be mapped to proto3 bytes which do complicate the consumption and deserialization significantly - each YANG typedef to a binary type could carry different sets of rules for encoding which need to be accounted for on any typedef (where known). In some cases this is justified, in others it seems we should revisit a YANG decimal64 type to be mapped to a proto3 double.
In any case, I'll carry the gNMI encoding rules to the reference repo for discussion where we should draw up a firm source of truth
I'll look in further detail when I get a moment, but a couple of notes:
- for yang -> proto schema conversion (i.e., generating
.protofiles from.yangones) we wrote a spec here. - for which field to use in gnmi there is a spec here
- for where IS-IS/OSPF used
ieeefloat32if I remember right it is often because the encoding on the wire is actually a ieee754 value. - there has been a discussion the other way -- which @gcsl initiated, whereby there was a discussion around moving completely away from
decimal64. specifically -- this looked to use the floating point values in gnmi, and avoid conversion overall. it's likely we should visit this in the same discussion.
Here are links regarding gNMI deprecating the Decimal64 message from gNMI at https://github.com/openconfig/gnmi/commit/d5360e33fc3b22effeaaaf55f345c1f950765bed. The motivation is documented at: https://github.com/openconfig/reference/blob/master/rpc/gnmi/decimal64-deprecation.md
Should fields defined as ieeefloat32 be delivered via double_val (seems the "natural" and efficient vehicle for floating point data) or bytes_val (since ieeefloat32 is a typedef to bytes)?
- there has been a discussion the other way -- which @gcsl initiated, whereby there was a discussion around moving completely away from
decimal64. specifically -- this looked to use the floating point values in gnmi, and avoid conversion overall. it's likely we should visit this in the same discussion.
It seems odd to read the decimal64 deprecation doc ("suitable only for doing taxes" [paraphrase]) while seeing recent fields in openconfig modeled as decimal64.
(To be clear, I buy the reasoning behind the deprecation and support it. I'm just curious why new modeling is using it.)
- there has been a discussion the other way -- which @gcsl initiated, whereby there was a discussion around moving completely away from
decimal64. specifically -- this looked to use the floating point values in gnmi, and avoid conversion overall. it's likely we should visit this in the same discussion.It seems odd to read the decimal64 deprecation doc ("suitable only for doing taxes" [paraphrase]) while seeing recent fields in openconfig modeled as decimal64.
(To be clear, I buy the reasoning behind the deprecation and support it. I'm just curious why new modeling is using it.)
The deprecation of decimal64 is related to gNMI proto encoding. OC Yang models may still use decimal. When marshalled to gnmi proto format, gnmi will transport a yang decimal value as double. See gnmi.proto
Sure, thanks, I understand that. It's just strange to see the strong deprecation (and implication of overall inutility/inefficiency) coupled with new fields modeled that way in OpenConfig.
More of a curiosity rather than a confusion or misunderstanding.
Juniper Business Use Only From: Darren Loher @.> Date: Wednesday, January 31, 2024 at 4:50 PM To: openconfig/public @.> Cc: Chris Cole @.>, Comment @.> Subject: Re: [openconfig/public] ieeefloat32 (YANG binary) usage and type handling (Issue #1042) [External Email. Be cautious of content]
- there has been a discussion the other way -- which @gcslhttps://urldefense.com/v3/__https:/github.com/gcsl__;!!NEt6yMaO-gk!EugOlRF7Bce9JXMEvmzrxycsFhhFnCzPjKaXwu7zBVIy1mX1O0GV5mY9kpns_y4TfZtcc_W7KUvjwB21bSh3N5c$ initiated, whereby there was a discussion around moving completely away from decimal64. specifically -- this looked to use the floating point values in gnmi, and avoid conversion overall. it's likely we should visit this in the same discussion.
It seems odd to read the decimal64 deprecation doc ("suitable only for doing taxes" [paraphrase]) while seeing recent fields in openconfig modeled as decimal64.
(To be clear, I buy the reasoning behind the deprecation and support it. I'm just curious why new modeling is using it.)
The deprecation of decimal64 is related to gNMI proto encoding. OC Yang models may still use decimal. When marshalled to gnmi proto format, gnmi will transport a yang decimal value as double. See gnmi.protohttps://urldefense.com/v3/__https:/github.com/openconfig/gnmi/blob/4423cef8388c00a029a2f26d3b407ad40321a892/proto/gnmi/gnmi.proto*L120-L123__;Iw!!NEt6yMaO-gk!EugOlRF7Bce9JXMEvmzrxycsFhhFnCzPjKaXwu7zBVIy1mX1O0GV5mY9kpns_y4TfZtcc_W7KUvjwB21poEKMF4$
— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/openconfig/public/issues/1042*issuecomment-1920033970__;Iw!!NEt6yMaO-gk!EugOlRF7Bce9JXMEvmzrxycsFhhFnCzPjKaXwu7zBVIy1mX1O0GV5mY9kpns_y4TfZtcc_W7KUvjwB21urSomHo$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ASRFX5SKYDM75AB4QWN5IPDYRK4BBAVCNFSM6AAAAABCSFHD22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRQGAZTGOJXGA__;!!NEt6yMaO-gk!EugOlRF7Bce9JXMEvmzrxycsFhhFnCzPjKaXwu7zBVIy1mX1O0GV5mY9kpns_y4TfZtcc_W7KUvjwB21VSczWG8$. You are receiving this because you commented.Message ID: @.***>