Hi Jorge, Ip aliasing can surely be one placeholder. But as I mentioned if it has applicability to similar case of recursive resolution for others AFI/SAFI, like l3vpn.
Thanks, Saumya. ________________________________ From: Jorge Rabadan (Nokia) <[email protected]> Sent: Saturday, August 30, 2025 6:15:35 pm To: Dikshit, Saumya <[email protected]>; BESS <[email protected]>; [email protected] <[email protected]> Cc: Ketan Talaulikar <[email protected]>; [email protected] <[email protected]> Subject: Re: Bandwidth reservation along with Recursive resolution of NLRIs via Overlay Index or ESI Saumya, Not related to the ebgp-dmz draft, but related to the EVPN link bandwidth extended community, and its usage for RT-5s with an ESI overlay index: https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ip-aliasing#section-7.1<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ip-aliasing*section-7.1__;Iw!!NpxR!luDuzYybzxLsR-ctVgHwcyKogpEpUACJwaPZQpCCmr60FjwNSWJ46bfu2KoSDzF0tI0dxu1QAm_rdrFsDHBMNuywG0vI69z10A$> I don’t think specific EVPN procedures should be specified in draft-ietf-bess-ebgp-dmz. My two cents. Thx Jorge From: Dikshit, Saumya <[email protected]> Date: Friday, August 29, 2025 at 11:25 PM To: Dikshit, Saumya <[email protected]>, BESS <[email protected]>, [email protected] <[email protected]> Cc: Ketan Talaulikar <[email protected]>, [email protected] <[email protected]> Subject: [bess] Re: Bandwidth reservation along with Recursive resolution of NLRIs via Overlay Index or ESI CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hello Bess Chairs, Can you please help answering below questions. Thanks, Saumya. From: Dikshit, Saumya <[email protected]> Date: Friday, 29 August 2025 at 4:47 PM To: BESS <[email protected]>, [email protected] <[email protected]> Cc: Ketan Talaulikar <[email protected]>, [email protected] <[email protected]> Subject: [bess] Bandwidth reservation along with Recursive resolution of NLRIs via Overlay Index or ESI Hello Bess group and Authors of https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/__;!!NpxR!g9bvq4ayTMJWoOl2xsCdqrP4Ido2IPosHbY3aoag1XHkht1GCxaMaicNQckWXU3pWrr5VNWSVVwht40h3MtsOee8ooswNe0fCg$> This is with respect to review I did on the idr draft: draft-ietf-idr-link-bandwidth and was aptly directed by Ketan to bess for the specific observation on usage of the newly introduced extended community for signaling bandwidth reservation in BGP. This observation is w.r.t it’s usage with EVPN aft/safi and in general on its usage for the recursive resolution of routes leveraging Overlay Index or ESI values published in different routes. Right now we don’t have any procedures defined on how the new extended community shall be used along with these kind of scenarios, which may be applicable to more AFI/SAFI’s or I think should be perceive agnostic to MPBGP address families. The usage specifically with Overlay Index. · Should this newly attribute be carried with the UPDATE message publishing the prefix as NLRI o 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. o Will this attribute be carried with with RT-5 or RT-2/1 which resolve the route and carries the flattened next-hop Similar Query is for the resolution via ESI. Thanks, Saumya. From: Dikshit, Saumya <[email protected]> Date: Monday, 25 August 2025 at 11:48 PM To: Ketan Talaulikar <[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) Thanks Ketan. Let me follow up in bess on the use-cases (https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/__;!!NpxR!i5xC0YpUklozHHt_QqiS5mIH-JrK8NN0VrSsaesYVk1u6pIq3iJq0Ee8ftLgaWoPZ06rgA-y5x87XhT9ugCpiA$>) More importantly, the overlay-index (recursive resolution for EVPN NLRIs) along with new extended community needs to discussed if not done so already. Might be applicable to all overlay specific NLRI’s supported by BGP control plane. Thanks, Saumya. From: Ketan Talaulikar <[email protected]> Date: Monday, 25 August 2025 at 6:57 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, 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/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/__;!!NpxR!i5xC0YpUklozHHt_QqiS5mIH-JrK8NN0VrSsaesYVk1u6pIq3iJq0Ee8ftLgaWoPZ06rgA-y5x87XhT9ugCpiA$> Thanks, Ketan On Mon, Aug 25, 2025 at 5:05 PM Dikshit, Saumya <[email protected]<mailto:[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]<mailto:[email protected]>> Date: Monday, 25 August 2025 at 12:56 PM To: Dikshit, Saumya <[email protected]<mailto:[email protected]>> Cc: Jeffrey Haas <[email protected]<mailto:[email protected]>>, BESS <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[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. o 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 o may not be just plain vanilla pointing to same next-hop o 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. o 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]
