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 <[email protected]<mailto:[email protected]>> wrote: Please help me with the below email. Thanks, Saumya. From: Dikshit, Saumya <[email protected]<mailto:[email protected]>> Date: Monday, 18 August 2025 at 5:00 PM To: Jeffrey Haas <[email protected]<mailto:[email protected]>> Cc: BESS <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
