[Idr] Comments on draft-li-idr-link-bandwidth-ext

[Jeffrey Haas <[e-mail]>]

[Speaking as an individual contributor.]

Authors,

Thanks for your presentation of draft-li-idr-link-bandwidth-ext at IETF 112.
Microphone discussion captured many of the key points about your draft.  I'd
like to take this opportunity to list some of those points and add others.

It is understood that a 32-bit floating point value has issues with
granularity.  This often leads to interesting mismatches in configured
intent vs. the number encoded in a BGP link-bandwidth community.

This granularity issue in particular makes policy challenging to write.
Even simple algebraic comparisons such as greater-than/lesser-than may be a
mis-match based on these granularities.

For the simple case that link-bandwith is typically used for, it's been
"good enough".  This is typically for providing a general weight for BGP ECMP.

Currently, we already have an industry mismatch regarding link-bandwidth
extended community encoding IDR needs to address: The draft lists
non-transitive encoding, but there also exists transitive encodings.  Due to
how BGP extended communities are encoded, these aren't compatible.

Adding additional encodings for link-bandwith, transitive or not, will add
to this confusion.  This isn't to say the work isn't worth doing, it simply
means it is a necessary discussion point.

I do wish to contribute a small thing that may address a complexity in your
proposal.  With the encodings in your draft, it is possible to have
encodings for the same value using different SubTypes.  This isn't
desirable.

IEEE 754 has a format, "decimal32"[1] that addresses part of the
considerations in your draft.  Values are available in base 10 and not
subject to some of the forms of rounding error, the impacts of which are
discussed above.

It doesn't solve the one single format on the wire for a number.  There may
be some opportunity to pick specific encoding rules for something like
decimal 32 such that the on-the-wire format gains consistency.  We would
want that with your proposal as well.

-- Jeff

[1] https://en.wikipedia.org/wiki/Decimal32_floating-point_format