Tiger,
On 5/19/26 23:14, Tiger Xu wrote:
A few terse technical comments on the draft itself:
Section 3: Your requested encoding is impossible in RFC 4360 extended
communities. You have six octets to work with. You both global and
local-admin fields that require 4-octets each.
[Tiger] In our current implementation, the 2-byte local-admin field of
the IPv4-address-specific extended community is filled with the path
bandwidth value in units of GB/s, using the IEEE 16-bit half-precision
floating-point format. However, your above comment makes me rethink
the possibility of using the ASN-specific extended community, which
has a 4-byte field to convey the path bandwidth value in the IEEE
32-bit single-precision floating-point format.
If the intention is to keep the 16-bit format, I'd suggest clarifying
the encoding in the draft.
With a 4-byte encoding, the format of the path bandwidth extended
community would be essentially identical to the link-bandwidth extended
community. That's already known to have decimal precision issues but is
well understood.
Security/Operational considerations: Your desire in this draft is to
use transitive extended communities. Unlike the hop-by-hop
(re-)generated non-transitive extended communities used by DMZ, you
have attribute escape issues to address:
- If a given node doesn't "do math" on the community because it
doesn't understand it, how does that impact the use case?
- You need to protect the deployment against receiving such
communities from outside the deployment.
- You need to discuss how you remove the communities when the routes
are being sent outside the deployment.
[Tiger]The path bandwidth attribute is targeted for AI back-end data
center network scenarios, and therefore there is no such risk. Anyway,
I will add some text to explain this consideration.
Thanks. While the intention of many of these "walled garden" features
is that "this can't possibly leak", we are regularly seeing things
leak. See also the discussion on community cleanup in the other thread
for things that aren't expected to leak.
-- Jeff
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
