Hello Bess group and Authors of
https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/
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
*
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
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.
* 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]
