Yes, MP_REACH ... sorry for that significant slip :-) Thanks, Ketan
On Mon, Aug 25, 2025 at 10:01 PM Robert Raszuk <[email protected]> wrote: > 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]
