Hi Jeff,
Please see inline with tag [saumya]
On Wed, Aug 06, 2025 at 07:07:59PM +0000, Dikshit, Saumya wrote:
> I support the progression of this draft. Though I have few
> queries/clarifications:
>
> Is the definition of a link restricted to the underlay physical links or also
> mapped to logical ones like TE-links mapping to a tunnel.
> For example, a bandwidth tied to a VPN tunnel stitching two fabrics over WAN.
> (like a multisite deployment).
>
> Can we clarify the definition of the “link” if it’s not implicit.
>From the first part of the draft:
>: The Link Bandwidth Extended Community is defined as a BGP extended community
>: that carries the bandwidth information of a router, represented by BGP
>: Protocol Next Hop, connecting to remote network.
>So, while the definition of a "link" is left vague in the specification,
>it's clear in context that it's tied to a BGP next hop.
[saumya] How I am seeing this is
* only one instance of “bandwidth extended community “ can be carried in
one BGP update message.
* And BGP update message encapsulation procedures are expected to bucket
as many NRLI’s as possible that share the next hop
* The choice of NLRI’s to be coupled with this extended community
* may not be just plain vanilla pointing to same next-hop
* but also might be driven via other policies as well.
* This will require a mention of these procedures with MAY clause, since
this draft is about this new extended community.
>In terms of deployment use cases, it's not limited in this specification.
>One of the discussions overlapping the feature is that the same community
>can be used in-context for multiple things from underlay, to overlay, to
>load balancing traffic across a provider core for Internet purposes. The
>draft, covering primarily encoding, doesn't try to restrict the use cases.
[saumya] The usage specifically with Overlay Index.
* Should this newly attribute be carried with the UPDATE message publishing
the prefix as NLRI
* Or with the update message carrying the next-hop-resolution.
* For example, for EVPN RT-5’s carrying overlay index pointing to RT-2’s
and RT-1’s.
* Will this attribute be carried with with RT-5 or RT-2/1 which resolve
the route and carries the flattened next-hop
>Some of the BESS discussion covering LBW covers these points along with the
>operational use case for things like accumulation at multipath merge points.
>I'd suggest familiarizing yourself with those drafts.
[saumya] I couldn’t get any reference to its usage with Overlay index in bess
or idr. It will be great to have pointer to the drafts. Else we need to call
out above bullets somewhere.
I think overlay index usage is very important.
>IDR will be coordinating with BESS to figure out the long term disposition
>of those drafts now that the protocol component draft is moving forwarding
>towards publication.
Thanks,
Saumya.
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
