[bess] Re: Bandwidth reservation along with Recursive resolution of NLRIs via Overlay Index or ESI

2025-09-03 Thread Dikshit, Saumya 
Hello Bess chairs,

Is there any work in progress in generic way discussing or adding this 
information via a new dedicate draft, which later can be merged with the right 
placeholder.


Thanks,

Saumya.

From: Dikshit, Saumya 
Date: Sunday, 31 August 2025 at 4:07 PM
To: Jorge Rabadan (Nokia) , BESS 
, [email protected] 
Cc: Ketan Talaulikar , [email protected] 

Subject: [bess] Re: Bandwidth reservation along with Recursive resolution of 
NLRIs via Overlay Index or ESI


Then, do we need a dedicated document which can define the  “applicability and 
procedures EVPN link bandwidth extended community” across MPBGP address 
families.


Thanks,

Saumya.

From: Jorge Rabadan (Nokia) 
Date: Sunday, 31 August 2025 at 1:53 PM
To: Dikshit, Saumya , BESS , 
[email protected] 
Cc: Ketan Talaulikar , [email protected] 

Subject: Re: Bandwidth reservation along with Recursive resolution of NLRIs via 
Overlay Index or ESI

Hi Saumya,

You asked about overlay index recursive resolution, which is specific to EVPN 
and not applicable to other AFI/SAFIs. That’s why I made my comment.

Thanks.
Jorge

From: Dikshit, Saumya 
Date: Saturday, August 30, 2025 at 9:54 AM
To: Jorge Rabadan (Nokia) , BESS , 
[email protected] 
Cc: Ketan Talaulikar , [email protected] 

Subject: 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.


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) 
Sent: Saturday, August 30, 2025 6:15:35 pm
To: Dikshit, Saumya ; BESS ; 
[email protected] 
Cc: Ketan Talaulikar ; [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 
Date: Friday, August 29, 2025 at 11:25 PM
To: Dikshit, Saumya , BESS 
, [email protected] 
Cc: Ketan Talaulikar , [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 
Date: Friday, 29 August 2025 at 4:47 PM
To: BESS , [email protected] 
Cc: Ketan Talaulikar , [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
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 
Date: Monday, 25 August 2025 at 11:48 PM
To: Ketan Ta

[bess] Re: Bandwidth reservation along with Recursive resolution of NLRIs via Overlay Index or ESI

2025-08-31 Thread Dikshit, Saumya 

Then, do we need a dedicated document which can define the  “applicability and 
procedures EVPN link bandwidth extended community” across MPBGP address 
families.


Thanks,

Saumya.

From: Jorge Rabadan (Nokia) 
Date: Sunday, 31 August 2025 at 1:53 PM
To: Dikshit, Saumya , BESS , 
[email protected] 
Cc: Ketan Talaulikar , [email protected] 

Subject: Re: Bandwidth reservation along with Recursive resolution of NLRIs via 
Overlay Index or ESI

Hi Saumya,

You asked about overlay index recursive resolution, which is specific to EVPN 
and not applicable to other AFI/SAFIs. That’s why I made my comment.

Thanks.
Jorge

From: Dikshit, Saumya 
Date: Saturday, August 30, 2025 at 9:54 AM
To: Jorge Rabadan (Nokia) , BESS , 
[email protected] 
Cc: Ketan Talaulikar , [email protected] 

Subject: 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.


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) 
Sent: Saturday, August 30, 2025 6:15:35 pm
To: Dikshit, Saumya ; BESS ; 
[email protected] 
Cc: Ketan Talaulikar ; [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 
Date: Friday, August 29, 2025 at 11:25 PM
To: Dikshit, Saumya , BESS 
, [email protected] 
Cc: Ketan Talaulikar , [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 
Date: Friday, 29 August 2025 at 4:47 PM
To: BESS , [email protected] 
Cc: Ketan Talaulikar , [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
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 
Date: Monday, 25 August 2025 at 11:48 PM
To: Ketan Talaulikar 
Cc: Jeffrey Haas , BESS , [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 (recurs

[bess] Re: Bandwidth reservation along with Recursive resolution of NLRIs via Overlay Index or ESI

2025-08-31 Thread Jorge Rabadan (Nokia) 
Hi Saumya,

You asked about overlay index recursive resolution, which is specific to EVPN 
and not applicable to other AFI/SAFIs. That’s why I made my comment.

Thanks.
Jorge

From: Dikshit, Saumya 
Date: Saturday, August 30, 2025 at 9:54 AM
To: Jorge Rabadan (Nokia) , BESS , 
[email protected] 
Cc: Ketan Talaulikar , [email protected] 

Subject: 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.


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) 
Sent: Saturday, August 30, 2025 6:15:35 pm
To: Dikshit, Saumya ; BESS ; 
[email protected] 
Cc: Ketan Talaulikar ; [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 
Date: Friday, August 29, 2025 at 11:25 PM
To: Dikshit, Saumya , BESS 
, [email protected] 
Cc: Ketan Talaulikar , [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 
Date: Friday, 29 August 2025 at 4:47 PM
To: BESS , [email protected] 
Cc: Ketan Talaulikar , [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
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 
Date: Monday, 25 August 2025 at 11:48 PM
To: Ketan Talaulikar 
Cc: Jeffrey Haas , BESS , [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 
Date: Monday, 25 August 2025 at 6:57 PM
To: Dikshit, Saumya 
Cc: Jeffrey Haas , BESS , [email protected] 

Subject: Re: [bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 
August, 2025)
Hi Saumya,

A BGP UPDATE message

[bess] Re: Bandwidth reservation along with Recursive resolution of NLRIs via Overlay Index or ESI

2025-08-30 Thread Dikshit, Saumya 
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) 
Sent: Saturday, August 30, 2025 6:15:35 pm
To: Dikshit, Saumya ; BESS ; 
[email protected] 
Cc: Ketan Talaulikar ; [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 
Date: Friday, August 29, 2025 at 11:25 PM
To: Dikshit, Saumya , BESS 
, [email protected] 
Cc: Ketan Talaulikar , [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 
Date: Friday, 29 August 2025 at 4:47 PM
To: BESS , [email protected] 
Cc: Ketan Talaulikar , [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
oOr 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.
oWill 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 
Date: Monday, 25 August 2025 at 11:48 PM
To: Ketan Talaulikar 
Cc: Jeffrey Haas , BESS , [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 
Date: Monday, 25 August 2025 at 6:57 PM
To: Dikshit, Saumya 
Cc: Jeffrey Haas , BESS , [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/__;

[bess] Re: Bandwidth reservation along with Recursive resolution of NLRIs via Overlay Index or ESI

2025-08-30 Thread Jorge Rabadan (Nokia) 
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

I don’t think specific EVPN procedures should be specified in 
draft-ietf-bess-ebgp-dmz.

My two cents.

Thx
Jorge

From: Dikshit, Saumya 
Date: Friday, August 29, 2025 at 11:25 PM
To: Dikshit, Saumya , BESS 
, [email protected] 
Cc: Ketan Talaulikar , [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 
Date: Friday, 29 August 2025 at 4:47 PM
To: BESS , [email protected] 
Cc: Ketan Talaulikar , [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
oOr 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.
oWill 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 
Date: Monday, 25 August 2025 at 11:48 PM
To: Ketan Talaulikar 
Cc: Jeffrey Haas , BESS , [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 
Date: Monday, 25 August 2025 at 6:57 PM
To: Dikshit, Saumya 
Cc: Jeffrey Haas , BESS , [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 
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 mailto:ketant.i.

[bess] Re: Bandwidth reservation along with Recursive resolution of NLRIs via Overlay Index or ESI

2025-08-29 Thread Dikshit, Saumya 
Hello Bess Chairs,

Can you please help answering below questions.


Thanks,

Saumya.

From: Dikshit, Saumya 
Date: Friday, 29 August 2025 at 4:47 PM
To: BESS , [email protected] 
Cc: Ketan Talaulikar , [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/

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 
Date: Monday, 25 August 2025 at 11:48 PM
To: Ketan Talaulikar 
Cc: Jeffrey Haas , BESS , [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/)
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 
Date: Monday, 25 August 2025 at 6:57 PM
To: Dikshit, Saumya 
Cc: Jeffrey Haas , BESS , [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/

Thanks,
Ketan


On Mon, Aug 25, 2025 at 5:05 PM Dikshit, Saumya 
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 mailto:[email protected]>>
Date: Monday, 25 August 2025 at 12:56 PM
To: Dikshit, Saumya mailto:[email protected]>>
Cc: Jeffrey Haas mailto:[email protected]>>, BESS 
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 seco