[Idr] Re: [External⚠️] Finishing draft-ietf-idr-link-bandwidth

[Satya Mohanty <[e-mail]>]

Hi Ketan,

Just a pointed note that your comments regarding 3.4, we have incorporated
it.
I could not write back on Friday as I had some issues with replying to IDR
, so I worked with Reshma and we have that in the latest version.

Thanks,
--Satya



On Mon, Sep 22, 2025 at 1:17 AM Ketan Talaulikar <[e-mail]>
wrote:

> < updated the subject >
>
> Hi Reshma/co-authors,
>
> Thanks for posting the updated version. The discussion on this new topic
> has been happening on the WG mailing list for almost a week, and I am not
> seeing any further inputs.
>
> That said, I will wait another day to check if the WG chairs want to add or
> check further and then start the IETF LC on it.
>
> Of course, people can still provide feedback during the IETF LC. I hope the
> WG is truly done with the document this time.
>
> In the meantime, below is a suggestion for the new text for better clarity:
>
> CURRENT:
>
> When a BGP speaker re-advertises a route received with Link Bandwidth
> Extended Community and sets the next hop to itself or to another address,
> implementation MAY remove the Link Bandwidth Extended Community or MAY
> re-advertise it unchanged or regenerate it as its default behavior.
> Implementation SHOULD provide a local configuration method to alter its
> default behavior to one of these options with per-session granularity.
>
> When regenerating Link Bandwidth Extended Community, follow the same
> procedures as outlined in Section 3.1
> <
> https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-18.html#Originator
> >.
> Please also refer to Section 3.4
> <
> https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-18.html#LinkBandwidthArithmetic
> >
> for
> use in a BGP multipath environment.
> SUGGEST:
>
> When a BGP speaker re-advertises a route received with Link Bandwidth
> Extended Community and sets the next hop to itself or to another address,
> *it
> MAY do any one of the following as its default behavior -remove the Link
> Bandwidth Extended Community, **re-advertise it unchanged, or regenerate it
> with an appropriate value.* Implementations SHOULD provide a local
> configuration method to alter *their* default behavior to *the other
> options* with per-session granularity.
>
> When regenerating Link Bandwidth Extended Community, the same procedures as
> outlined in Section 3.1
> <
> https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-18.html#Originator
> >
>  *apply*. Please also refer to Section 3.4
> <
> https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-18.html#LinkBandwidthArithmetic
> >
> for
> use in a BGP multipath environment.
> If authors agree, please feel free to post it anytime (including during the
> IETF LC).
>
> Thanks,
> Ketan
>
> On Mon, Sep 22, 2025 at 8:47 AM Reshma Das <[e-mail]> wrote:
>
> > Hi All,
> >
> >
> >
> > I have published latest version incorporating AD review comments and the
> > NH change issue.
> >
> >
> >
> > Please find the diff:
> >
> >
> >
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-idr-link-bandwidth-17&url2=draft-ietf-idr-link-bandwidth-18&difftype=--html
> >
> >
> >
> > Thanks & Regards,
> >
> > Reshma Das
> >
> >
> >
> > Juniper Business Use Only
> >
> > *From: *Reshma Das <dreshma=[e-mail]>
> > *Date: *Friday, September 19, 2025 at 9:38 AM
> > *To: *Ketan Talaulikar <[e-mail]>
> > *Cc: *Keon Vafai <[e-mail]>, idr@ietf. org <[e-mail]>,
> > [e-mail] <
> > [e-mail]>, Pradosh Mohapatra <
> > [e-mail]>, Satya Mohanty <[e-mail]>, Akshay
> Gattani
> > <[e-mail]>, Rafal Szarecki <[e-mail]>
> > *Subject: *[Idr] Re: [External⚠️] Re:
> > draft-ietf-idr-link-bandwidth#17section-3.3.1 vs
> > draft-ietf-idr-link-bandwidth-07#section-2
> >
> > *[External Email. Be cautious of content]*
> >
> >
> >
> > Hi Ketan/WG group,
> >
> >
> >
> > The authors have reached consensus, and I have incorporated the changes
> > and posted them in GitHub. I am now waiting for the final signoff from
> all
> > authors. This has been published at:
> >
> > https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/pull/19
> > <
> https://urldefense.com/v3/__https:/github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/pull/19__;!!NEt6yMaO-gk!A2m46Pkoi8bmC2Z-qV6Tl-2uH6IClJohlfk0qv9E5LQXWPJ4GiYsxnty6W2AlKlBX6Nuq0J3oJ8auW5C0V56IFtoK_ZrNXA$
> >
> >
> >
> >
> > I sincerely appreciate all the authors and the working group members who
> > have taken the time to review this.
> >
> >
> >
> > Thank you also for your patience while we worked through the AD review.
> >
> > I have posted the latest AD review comments in GitHub as well.
> >
> >
> >
> https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/8de09af22bd7d12b7b8c6a94f19beab0cf48f622#diff-651686fad71caed6b635c7f0743abcd2846e61cb3d455b03001c9eff13356c0b
> > <
> https://urldefense.com/v3/__https:/github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/8de09af22bd7d12b7b8c6a94f19beab0cf48f622*diff-651686fad71caed6b635c7f0743abcd2846e61cb3d455b03001c9eff13356c0b__;Iw!!NEt6yMaO-gk!A2m46Pkoi8bmC2Z-qV6Tl-2uH6IClJohlfk0qv9E5LQXWPJ4GiYsxnty6W2AlKlBX6Nuq0J3oJ8auW5C0V56IFtoiuMwAZQ$
> >
> >
> >
> >
> > Once we close the current issue, I will publish both sets of changes.
> This
> > will allow the AD to review both sets together in one pass.
> >
> >
> >
> > Thanks & Regards
> >
> > Reshma Das
> >
> >
> >
> >
> >
> >
> >
> > Juniper Business Use Only
> >
> > *From: *Ketan Talaulikar <[e-mail]>
> > *Date: *Thursday, September 18, 2025 at 11:32 PM
> > *To: *Reshma Das <dreshma=[e-mail]>
> > *Cc: *Keon Vafai <[e-mail]>, idr@ietf. org <[e-mail]>,
> > [e-mail] <
> > [e-mail]>
> > *Subject: *Re: [Idr] Re: [External⚠️] Re:
> > draft-ietf-idr-link-bandwidth#17section-3.3.1 vs
> > draft-ietf-idr-link-bandwidth-07#section-2
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi Reshma/Satya/co-authors,
> >
> > Following up on this one, can you please post the update based on the
> > offline discussions within the author team for the WG's consideration. If
> > there is a lack of consensus, please let the WG know.
> >
> > Also, it would be great if the pending updates from the AD review are
> > incorporated in the next version as well.
> >
> > I appreciate the efforts from all involved. I hope we can move this
> forward
> > with a greater momentum without sacrificing thoroughness.
> >
> > Thanks,
> > Ketan
> >
> >
> > On Wed, Sep 17, 2025 at 10:26 PM Kaliraj Vairavakkalai <kaliraj=
> > [e-mail]> wrote:
> >
> > > >- transitive link-bandwidth community (I believe only JUNOS has
> > > implementation), by implicit default is readvertised unchanged. This is
> > the
> > > whole point of transitive . Is it not? Kali, Would JUNOS be compliant
> > with
> > > this rule?
> > >
> > >
> > >
> > > Yes this is Junos behavior. But the main point of transitive is
> “nexthop
> > > unchanged” behavior (option-C RR).
> > >
> > >
> > >
> > > And EOS also implements transitive. Keon can confirm.
> > >
> > >
> > >
> > > Since the draft is in critical final step, I’d suggest we can get on a
> > > call and iterate quicker? And send final agreed-upon text to IDR.
> > >
> > >
> > >
> > > Please expect a Teams meeting invite.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Kaliraj
> > >
> > > Juniper Business Use Only
> > >
> > > *From: *Rafal Szarecki <[e-mail]>
> > > *Date: *Wednesday, September 17, 2025 at 1:27 AM
> > > *To: *Kaliraj Vairavakkalai <[e-mail]>
> > > *Cc: *Keon Vafai <[e-mail]>, Jeffrey Haas <[e-mail]>,
> > Reshma
> > > Das <dreshma=[e-mail]>, Jeff Haas <
> [e-mail]
> > >,
> > > Ketan Talaulikar (ketant) <[e-mail]>, idr@ietf. org <
> > [e-mail]>,
> > > Satya Mohanty <[e-mail]>,
> > > [e-mail] <
> > > [e-mail]>, Akshay Gattani <
> > [e-mail]
> > > >
> > > *Subject: *Re: [Idr] [External⚠️] Re:
> > > draft-ietf-idr-link-bandwidth#17section-3.3.1 vs
> > > draft-ietf-idr-link-bandwidth-07#section-2
> > >
> > > *[External Email. Be cautious of content]*
> > >
> > >
> > >
> > > Lets start with plain english.
> > >
> > >
> > >
> > > We want to say that
> > > - there is no prescribed implicit default behaviour when next-hop-set
> is
> > > enabled/configured explicitly. Implementation may drop Link-bandwidth
> or
> > > may re-advertise unchanged. So any implementation is compliant. The
> > > implementation SHOULD (MUST?) provide configuration to change behaviour
> > > from implicit to other.
> > >
> > >   - This applies to iBGP and eBGP. The crucial is that next-hop
> > > change/self/set-to-value is EXPLICITLY configured.
> > >
> > > - For eBGP case (implicit change of NH value):
> > >   - non-transitive link-bandwidth community (the only supported by
> EOS),
> > > by implicit default is dropped. Not because of NH change but because
> the
> > > session is of eBGP type.
> > >     The re-advertisement of non-transitive link-bandwidth on eBGP
> > requires
> > > explicit config anyway, and if it is done, this config should let
> > > link-bandwith to be sent regardless of NH change or not.
> > >
> > >   - transitive link-bandwidth community (I believe only JUNOS has
> > > implementation), by implicit default is readvertised unchanged. This is
> > the
> > > whole point of transitive . Is it not? Kali, Would JUNOS be compliant
> > with
> > > this rule?
> > >
> > >
> > >
> > > 3.3.1. Re-advertisement* when Next hop is changing*.
> > > - When a BGP speaker re-advertises a route with Link Bandwidth Extended
> > > Community and sets the next hop to itself or to an arbitrary address*
> via
> > > explicit local policy/configuration*, implementation may remove
> > > link-bandwidth community or may re-advertise it unchanged as its
> implicit
> > > default behaviour. Implementation SHOULD provide a local configuration
> > > method to alternate its implicit behaviour with per-session granularity

-- 


This communication (including any attachments) is intended for the sole 
use of the intended recipient and may contain confidential, non-public, 
and/or privileged material. Use, distribution, or reproduction of this 
communication by unintended recipients is not authorized. If you received 
this communication in error, please immediately notify the sender and then 
delete all copies of this communication from your system.