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

[Dikshit, Saumya]

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 , bess-cha...@ietf.org 

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:saumya.diks...@hpe.com>> 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...@gmail.com>>
Date: Monday, 25 August 2025 at 12:56 PM
To: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>
Cc: Jeffrey Haas mailto:jh...@pfrc.org>>, BESS 
mailto:bess@ietf.org>>, 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> 
mailto:bess-cha...@ietf.org>>
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 
mailto:40hpe@dmarc.ietf.org>> 
wrote:
Please help me with the below email.


Thanks,

Saumya.

From: Dikshit, Saumya 
mailto:40hpe@dmarc.ietf.org>>
Date: Monday, 18 August 2025 at 5:00 PM
To: Jeffrey Haas mailto:jh...@pfrc.org>>
Cc: BESS mailto:bess@ietf.org>>, 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> 
mailto:bess-cha...@ietf.org>>
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 +, 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 

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

[Ketan Talaulikar]

Yes, MP_REACH ... sorry for that significant slip :-)

Thanks,
Ketan


On Mon, Aug 25, 2025 at 10:01 PM Robert Raszuk  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 
> 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 
>> 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 
>>> *Date: *Monday, 25 August 2025 at 12:56 PM
>>> *To: *Dikshit, Saumya 
>>> *Cc: *Jeffrey Haas , BESS ,
>>> bess-cha...@ietf.org 
>>> *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 >> 40hpe@dmarc.ietf.org> wrote:
>>>
>>> Please help me with the below email.
>>>
>>> Thanks,
>>>
>>> Saumya.
>>> *From: *Dikshit, Saumya 
>>> *Date: *Monday, 18 August 2025 at 5:00 PM
>>> *To: *Jeffrey Haas 
>>> *Cc: *BESS , bess-cha...@ietf.org 
>>> *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 +, 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

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

[Robert Raszuk]

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 
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 
> 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 
>> *Date: *Monday, 25 August 2025 at 12:56 PM
>> *To: *Dikshit, Saumya 
>> *Cc: *Jeffrey Haas , BESS ,
>> bess-cha...@ietf.org 
>> *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 > 40hpe@dmarc.ietf.org> wrote:
>>
>> Please help me with the below email.
>>
>> Thanks,
>>
>> Saumya.
>> *From: *Dikshit, Saumya 
>> *Date: *Monday, 18 August 2025 at 5:00 PM
>> *To: *Jeffrey Haas 
>> *Cc: *BESS , bess-cha...@ietf.org 
>> *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 +, 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 h

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

[Ketan Talaulikar]

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 
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 
> *Date: *Monday, 25 August 2025 at 12:56 PM
> *To: *Dikshit, Saumya 
> *Cc: *Jeffrey Haas , BESS ,
> bess-cha...@ietf.org 
> *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  40hpe@dmarc.ietf.org> wrote:
>
> Please help me with the below email.
>
> Thanks,
>
> Saumya.
> *From: *Dikshit, Saumya 
> *Date: *Monday, 18 August 2025 at 5:00 PM
> *To: *Jeffrey Haas 
> *Cc: *BESS , bess-cha...@ietf.org 
> *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 +, 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.
&g

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

[Dikshit, Saumya]

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 
Date: Monday, 25 August 2025 at 12:56 PM
To: Dikshit, Saumya 
Cc: Jeffrey Haas , BESS , bess-cha...@ietf.org 

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 
mailto:40hpe@dmarc.ietf.org>> 
wrote:
Please help me with the below email.


Thanks,

Saumya.

From: Dikshit, Saumya 
mailto:40hpe@dmarc.ietf.org>>
Date: Monday, 18 August 2025 at 5:00 PM
To: Jeffrey Haas mailto:jh...@pfrc.org>>
Cc: BESS mailto:bess@ietf.org>>, 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> 
mailto:bess-cha...@ietf.org>>
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 +, 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 w

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

[Ketan Talaulikar]

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  wrote:

> Please help me with the below email.
>
> Thanks,
>
> Saumya.
> *From: *Dikshit, Saumya 
> *Date: *Monday, 18 August 2025 at 5:00 PM
> *To: *Jeffrey Haas 
> *Cc: *BESS , bess-cha...@ietf.org 
> *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 +, 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 -- bess@ietf.org
> To unsubscribe send an email to bess-le...@ietf.org
>
___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

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

[Dikshit, Saumya]

Please help me with the below email.


Thanks,

Saumya.

From: Dikshit, Saumya 
Date: Monday, 18 August 2025 at 5:00 PM
To: Jeffrey Haas 
Cc: BESS , bess-cha...@ietf.org 
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 +, 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 -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

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

[Dikshit, Saumya]

Hi Jeff,
Please see inline with tag [saumya]


On Wed, Aug 06, 2025 at 07:07:59PM +, 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 -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

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

[Sridhar Talari]

Hi,

Looks good,
Please let me know if link bandwidth value must always be in "bytes per
second"
I assume the procedure of determining the link bandwidth value that need to
be placed in the community is based on local policy

Regards
Sridhar



On Thu, 14 Aug 2025 at 15:56, Jeffrey Haas  wrote:

> Saumya,
>
> On Wed, Aug 06, 2025 at 07:07:59PM +, 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.
>
> 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.
>
> 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.
>
> 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.
>
> -- Jeff
>
> ___
> BESS mailing list -- bess@ietf.org
> To unsubscribe send an email to bess-le...@ietf.org
>
___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

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

[Jeffrey Haas]

Saumya,

On Wed, Aug 06, 2025 at 07:07:59PM +, 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.

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.

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.

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.

-- Jeff

___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

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

[Dikshit, Saumya]

Any help ?

Thanks,
Saumya.

From: Dikshit, Saumya 
Date: Monday, 11 August 2025 at 10:02 PM
To: Dikshit, Saumya , Jeffrey Haas , 
BESS , bess-cha...@ietf.org 
Subject: Re: [bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 
August, 2025)
Gentle reminder for clarification.

Thanks,
Saumya.

From: Dikshit, Saumya 
Date: Thursday, 7 August 2025 at 12:41 AM
To: Jeffrey Haas , BESS , bess-cha...@ietf.org 

Subject: [bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 
2025)
Any response to below shall surely help.

Thanks,
Saumya.

From: Dikshit, Saumya 
Date: Tuesday, 5 August 2025 at 10:13 PM
To: Jeffrey Haas , BESS , bess-cha...@ietf.org 

Subject: [bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 
2025)
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.

Thanks,
Saumya.

From: Jeffrey Haas 
Date: Friday, 11 July 2025 at 8:37 PM
To: BESS , bess-cha...@ietf.org 
Subject: [bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 
2025)
IDR has started the working group last call covering the link bandwidth 
feature.  Since this draft overlaps with other work done or proposed in BESS, 
please participate in this last call on the IDR mailing list.

-- Jeff (for the IDR Chairs)

On Jul 11, 2025, at 11:01 AM, Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:

https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/__;!!NpxR!n-fJ3oP3xGCaMjLj6rjrGr-ji3l9-rnBE1MsKryXKhxXF1x10R-3eDPulOQiZ7nKKQixpFq4YuQb9Q$>

This begins the working group last call for the link bandwidth extended 
community draft.  Thanks to the authors for working their way through the 
substantive items that have been obstacles to interoperability over the years.

This last call ends a week after IETF 123 to give the working group time to 
review and also take advantage of the focus time that IETF meeting weeks bring 
to our work.

An item in particular we'd like to request particular attention to from the 
working group's review are the procedures covering default behaviors and 
interactions with deployments with mixed transitivities.  The current draft 
text works to try to accommodate maximal backward compatibility with various 
deployment scenarios, but such text is tricky.

For purposes of the shepherd's report and according to IETF BCP 78/79, the 
authors are requested to declare whether they are aware of any undisclosed IPR 
covering this draft. Members of the working group are similarly obligated to 
report any they are aware of as well.

-- Jeff (for the IDR Chairs)

___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

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

[Dikshit, Saumya]

Gentle reminder for clarification.

Thanks,
Saumya.

From: Dikshit, Saumya 
Date: Thursday, 7 August 2025 at 12:41 AM
To: Jeffrey Haas , BESS , bess-cha...@ietf.org 

Subject: [bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 
2025)
Any response to below shall surely help.

Thanks,
Saumya.

From: Dikshit, Saumya 
Date: Tuesday, 5 August 2025 at 10:13 PM
To: Jeffrey Haas , BESS , bess-cha...@ietf.org 

Subject: [bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 
2025)
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.

Thanks,
Saumya.

From: Jeffrey Haas 
Date: Friday, 11 July 2025 at 8:37 PM
To: BESS , bess-cha...@ietf.org 
Subject: [bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 
2025)
IDR has started the working group last call covering the link bandwidth 
feature.  Since this draft overlaps with other work done or proposed in BESS, 
please participate in this last call on the IDR mailing list.

-- Jeff (for the IDR Chairs)

On Jul 11, 2025, at 11:01 AM, Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:

https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/__;!!NpxR!n-fJ3oP3xGCaMjLj6rjrGr-ji3l9-rnBE1MsKryXKhxXF1x10R-3eDPulOQiZ7nKKQixpFq4YuQb9Q$>

This begins the working group last call for the link bandwidth extended 
community draft.  Thanks to the authors for working their way through the 
substantive items that have been obstacles to interoperability over the years.

This last call ends a week after IETF 123 to give the working group time to 
review and also take advantage of the focus time that IETF meeting weeks bring 
to our work.

An item in particular we'd like to request particular attention to from the 
working group's review are the procedures covering default behaviors and 
interactions with deployments with mixed transitivities.  The current draft 
text works to try to accommodate maximal backward compatibility with various 
deployment scenarios, but such text is tricky.

For purposes of the shepherd's report and according to IETF BCP 78/79, the 
authors are requested to declare whether they are aware of any undisclosed IPR 
covering this draft. Members of the working group are similarly obligated to 
report any they are aware of as well.

-- Jeff (for the IDR Chairs)

___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

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

[Dikshit, Saumya]

Any response to below shall surely help.

Thanks,
Saumya.

From: Dikshit, Saumya 
Date: Tuesday, 5 August 2025 at 10:13 PM
To: Jeffrey Haas , BESS , bess-cha...@ietf.org 

Subject: [bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 
2025)
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.

Thanks,
Saumya.

From: Jeffrey Haas 
Date: Friday, 11 July 2025 at 8:37 PM
To: BESS , bess-cha...@ietf.org 
Subject: [bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 
2025)
IDR has started the working group last call covering the link bandwidth 
feature.  Since this draft overlaps with other work done or proposed in BESS, 
please participate in this last call on the IDR mailing list.

-- Jeff (for the IDR Chairs)

On Jul 11, 2025, at 11:01 AM, Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:

https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/__;!!NpxR!n-fJ3oP3xGCaMjLj6rjrGr-ji3l9-rnBE1MsKryXKhxXF1x10R-3eDPulOQiZ7nKKQixpFq4YuQb9Q$>

This begins the working group last call for the link bandwidth extended 
community draft.  Thanks to the authors for working their way through the 
substantive items that have been obstacles to interoperability over the years.

This last call ends a week after IETF 123 to give the working group time to 
review and also take advantage of the focus time that IETF meeting weeks bring 
to our work.

An item in particular we'd like to request particular attention to from the 
working group's review are the procedures covering default behaviors and 
interactions with deployments with mixed transitivities.  The current draft 
text works to try to accommodate maximal backward compatibility with various 
deployment scenarios, but such text is tricky.

For purposes of the shepherd's report and according to IETF BCP 78/79, the 
authors are requested to declare whether they are aware of any undisclosed IPR 
covering this draft. Members of the working group are similarly obligated to 
report any they are aware of as well.

-- Jeff (for the IDR Chairs)

___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

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

[Dikshit, Saumya]

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.

Thanks,
Saumya.

From: Jeffrey Haas 
Date: Friday, 11 July 2025 at 8:37 PM
To: BESS , bess-cha...@ietf.org 
Subject: [bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 
2025)
IDR has started the working group last call covering the link bandwidth 
feature.  Since this draft overlaps with other work done or proposed in BESS, 
please participate in this last call on the IDR mailing list.

-- Jeff (for the IDR Chairs)


On Jul 11, 2025, at 11:01 AM, Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:

https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/__;!!NpxR!n-fJ3oP3xGCaMjLj6rjrGr-ji3l9-rnBE1MsKryXKhxXF1x10R-3eDPulOQiZ7nKKQixpFq4YuQb9Q$>

This begins the working group last call for the link bandwidth extended 
community draft.  Thanks to the authors for working their way through the 
substantive items that have been obstacles to interoperability over the years.

This last call ends a week after IETF 123 to give the working group time to 
review and also take advantage of the focus time that IETF meeting weeks bring 
to our work.

An item in particular we'd like to request particular attention to from the 
working group's review are the procedures covering default behaviors and 
interactions with deployments with mixed transitivities.  The current draft 
text works to try to accommodate maximal backward compatibility with various 
deployment scenarios, but such text is tricky.

For purposes of the shepherd's report and according to IETF BCP 78/79, the 
authors are requested to declare whether they are aware of any undisclosed IPR 
covering this draft. Members of the working group are similarly obligated to 
report any they are aware of as well.

-- Jeff (for the IDR Chairs)

___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

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

[Jeffrey Haas]

IDR has started the working group last call covering the link bandwidth 
feature.  Since this draft overlaps with other work done or proposed in BESS, 
please participate in this last call on the IDR mailing list.

-- Jeff (for the IDR Chairs)

> On Jul 11, 2025, at 11:01 AM, Jeffrey Haas  wrote:
> 
> https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/ 
> 
> 
> This begins the working group last call for the link bandwidth extended 
> community draft.  Thanks to the authors for working their way through the 
> substantive items that have been obstacles to interoperability over the years.
> 
> This last call ends a week after IETF 123 to give the working group time to 
> review and also take advantage of the focus time that IETF meeting weeks 
> bring to our work.
> 
> An item in particular we'd like to request particular attention to from the 
> working group's review are the procedures covering default behaviors and 
> interactions with deployments with mixed transitivities.  The current draft 
> text works to try to accommodate maximal backward compatibility with various 
> deployment scenarios, but such text is tricky.
> 
> For purposes of the shepherd's report and according to IETF BCP 78/79, the 
> authors are requested to declare whether they are aware of any undisclosed 
> IPR covering this draft. Members of the working group are similarly obligated 
> to report any they are aware of as well.
> 
> -- Jeff (for the IDR Chairs)

___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org