The current ETH model defines the bandwidth as an uint64 in kilobits-per-second.
The rationale for this choise has been the fact that the IEEE floating point representation is not very user-friendly especially for a text-oriented language as YANG.
One possible issue (to be discussed) is that writing Gbps values using the kpbs units would still result in an integer number which is not that much user-friendly.
A possible solution for this issue could be to represent the banwdith as a tuple (measurement unit, value).
Another possible issue (to be discussed) is that the IEEE representation is widely used in underlying TE data plane and control plane and the conversion between integer/decimal and IEEE floating point representations is not lossless: translating a value from integer/decimal to IEEE floating point and back to integer/decimal would result in a different integer/decimal value.
It the lack of lossless translation really a problem?
Since with NMDA, configuration and reported state are separated, the configured and reported bandwidth values might be slightly different.
If the lack of lossless translation is a big issue, a possible solution could be to encode ETH bandwidth as a triplet of (value, measuring unit and IEEE floating point). The client can choose to configure the floating point or the rate. The server can always report the floating point (as the actual value implemented in the underlying TE data and control planes) and, when possible, it can report the actual value/unit (e.g., the value configured by the client if consistent with the actual value in the underlying TE data and control plane).
The current ETH model defines the bandwidth as an uint64 in kilobits-per-second.
The rationale for this choise has been the fact that the IEEE floating point representation is not very user-friendly especially for a text-oriented language as YANG.
One possible issue (to be discussed) is that writing Gbps values using the kpbs units would still result in an integer number which is not that much user-friendly.
A possible solution for this issue could be to represent the banwdith as a tuple (measurement unit, value).
Another possible issue (to be discussed) is that the IEEE representation is widely used in underlying TE data plane and control plane and the conversion between integer/decimal and IEEE floating point representations is not lossless: translating a value from integer/decimal to IEEE floating point and back to integer/decimal would result in a different integer/decimal value.
It the lack of lossless translation really a problem?
Since with NMDA, configuration and reported state are separated, the configured and reported bandwidth values might be slightly different.
If the lack of lossless translation is a big issue, a possible solution could be to encode ETH bandwidth as a triplet of (value, measuring unit and IEEE floating point). The client can choose to configure the floating point or the rate. The server can always report the floating point (as the actual value implemented in the underlying TE data and control planes) and, when possible, it can report the actual value/unit (e.g., the value configured by the client if consistent with the actual value in the underlying TE data and control plane).
Imported from: https://github.com/haomianzheng/IETF-ACTN-YANG-Model/issues/4