[bess] Re: Some comments on carrying bandwidth in BGP, and also on draft-xu-idr-fare-04 (was Re: [Idr] Working Group Last Call on draft-ietf-bess-ebgp-dmz)

[Jeffrey Haas <[e-mail]>]

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