Hi Saumya, A BGP UPDATE message can include those "only few prefixes" in the MP_UNREACH attribute and then include the LBW ExtCom (with the desired value) as well. That is the way to advertise what you seek. How this is achieved is implementation specific.
I hope I am getting your question/point correctly. If not, and if it is specific to BESS use-case that leverages LBW, then perhaps discuss in the BESS WG if it can be included in https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/ Thanks, Ketan On Mon, Aug 25, 2025 at 5:05 PM Dikshit, Saumya <[email protected]> wrote: > Hi Ketan, > > Thanks for your response. > > *>>> **but this is (or should be) something that every BGP developer is > aware of.* > [saumya] I understand that. But what I was looking for is, that there > could be selective tying of bandwidth with only few prefixes for a specific > next-hop. This is specific to the bandwidth extended community and > applicable to one or more use-cases. Hence, I think needs a placeholder. > > I shall trigger the discussions in bess regarding recursive resolution. > > Thanks, > > Saumya. > *From: *Ketan Talaulikar <[email protected]> > *Date: *Monday, 25 August 2025 at 12:56 PM > *To: *Dikshit, Saumya <[email protected]> > *Cc: *Jeffrey Haas <[email protected]>, BESS <[email protected]>, > [email protected] <[email protected]> > *Subject: *Re: [bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending > 1 August, 2025) > > Hi Saumya, > > Pitching in here as I do the AD evaluation for the link-bandwidth draft. > In my opinion, neither of these are directly related to the link bandwidth > draft. > > The first point seems to be about general BGP UPDATE message packing that > is applicable to any attribute and not specific to the LBW ExtCom. I can't > remember off the top of my head if the topic of BGP update packing is > covered by any RFC/draft but you can fork a new thread on IDR for > discussion around it. > > The second point is use of the LBW ExtCom for EVPN and as such it is > better covered in a BESS document. I am not sure > if draft-ietf-bess-ebgp-dmz is that document or if there is another more > appropriate one. I'll request you to start a separate thread on it and the > BESS chairs to guide. > > I hope this helps. > > Thanks, > Ketan > > > On Wed, Aug 20, 2025 at 4:42 PM Dikshit, Saumya <saumya.dikshit= > [email protected]> wrote: > > Please help me with the below email. > > Thanks, > > Saumya. > *From: *Dikshit, Saumya <[email protected]> > *Date: *Monday, 18 August 2025 at 5:00 PM > *To: *Jeffrey Haas <[email protected]> > *Cc: *BESS <[email protected]>, [email protected] <[email protected]> > *Subject: *[bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 > August, 2025) > > 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] > >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
