Hi Ketan, > 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.
You mean in the MP_REACH_NLRI ? Including any extended communities with MP_UNREACH_NLRI would seem pretty pointless. Thx, R. On Mon, Aug 25, 2025 at 3:28 PM Ketan Talaulikar <[email protected]> wrote: > 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] >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
