[Idr] Re: [External⚠️] Re: draft-ietf-idr-link-bandwidth#17section-3.3.1 vs draft-ietf-idr-link-bandwidth-07#section-2

[Kaliraj Vairavakkalai <[e-mail]>]

>- 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.
- When a BGP speaker re-advertises a route with Link Bandwidth Extended Community and sets the next hop to itself due to external BGP inherited behaviour, implementation SHOULD NOT remove transitive link-bandwidth extended-community as its implicit behaviour. Implementation MAY provide a local configuration method to alternate its implicit behaviour.
- The transitive/non-transitive property of link-bandwidth extended-community must be honored on advertisement to the eBGP sessions, regardless of implementations implicit behaviour on next-hop change.
- The policy configuration that explicitly alters the Link Bandwidth Extended Community value on route advertisement MUST be honored, regardless of next-hop operation. In this case the link-bandwidth community is freshy originated/re-generated not just re-advertised.
Please also refer to Section 3.4 for use in a BGP multipath environment.

Keon, Kali what about above?


--------------
Rafal Szarecki


On Tue, Sep 16, 2025 at 10:00 PM Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>> wrote:
Keon, Rafal,

The text you two proposed are in conflict. That is what we are trying to resolve here.

If you both are in agreement, please send text that both of you agree on. :-)

Pls find some clarifications to the comments inline KV>

Kaliraj



Juniper Business Use Only
From: Keon Vafai <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 16, 2025 at 5:14 PM
To: Rafal Szarecki <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>, Reshma Das <dreshma=[e-mail]<mailto:[e-mail]>>, Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>>, Jeff Haas <[e-mail]<mailto:[e-mail]>>, Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>, idr@ietf. org <[e-mail]<mailto:[e-mail]>>, Satya Mohanty <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Akshay Gattani <[e-mail]<mailto:[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]



On Tue, Sep 16, 2025 at 3:53 PM Rafal Szarecki <[e-mail]<mailto:[e-mail]>> wrote:
Let me comment Kali's proposal:
“When a BGP speaker re-advertises a route with the Link Bandwidth
Extended Community and changes the next hop, the received Link Bandwidth
Extended Community should be dropped. This may be done implicitly or by
 policy to remove or change the Link Bandwidth Extended Community.

In absence of such implicit or explicit policy to alter the Link Bandwidth
Extended Community, any received Link Bandwidth Extended Community on the
 route will be re-advertised unchanged”

- I do not understand the difference between implicit policy or absence of policy. For me this is the same thing - behaviour which does not require any configuration.
the first paragraph says dropping can be implicit (absence of policy/configuration), and second says implicitly (absence of policy/configuration) link-bandwidth shall remain unchanged. This is not good.

Agreed.

KV> Let me reword “implicit” to “automatic”, means default-behavior.

“When a BGP speaker re-advertises a route with the Link Bandwidth
Extended Community and changes the next hop, the received Link Bandwidth
Extended Community should be dropped. This may be done automatically
or by policy config to remove or change the Link Bandwidth Extended Community.

In absence of such automatic behavior or policy config to alter the Link Bandwidth
Extended Community, any received Link Bandwidth Extended Community on the
route will be re-advertised unchanged”

KV> Hope above rewording clarifies what I meant. Pls suggest text if this doesn’t work.


- If we ask to drop link-bandwidth explicit-community, on any next-hop change, the we make transitive one == non-transitive as we mandate dropping it on eBGP session (except eBGP w/ no-nexthop-change; whcih is corner case).

- If we make implicit default to drop any link-bandwidth when next-hop is changed, then the basic use case envisioned in draft -7 will stop working. Here is scenario:
  - The ISP network is MPLS based (w/ or w/o TE capabilities).
  - The external prefix P is advertised with link-bandwidth of value LBw1 to PE1 and with link-bandwidth of value LBw2 to PE2. All other metric attributes are equal.
  - Each of PE1 PE2 selects the external BGP route as best.
  - The PE3 is in equal IGP distance from PE1 and PE2. It learns both routes over full-mesh iBGP (or add-path, or due to distinct RD if this is L3VPN)
  - PE3 shall distribute traffic destined to P between PE1 and Pe2 is LBw1:LBw2 ratio.

  - The Next-Hop-Self is needed on PE1, PE2 to allow resolution of BGP over MPLS LSP.
  - We do not want link-bandwidth to be dropped/removed.

KV> Keon, can you specify how EOS handles this situation? Does it have policy config to preserve received LBW when readvertising?
KV> This is the point in conflict Rafal and Keon have to resolve with each other.

KV> Rafal, when PE1, PE2 reset NH, in principle, they need to decide what LBW to attach. Because, PE3 sees the LBW given by “PE1 as NH”, not the egress-peer.
KV> I think that is the crux behind the draft-07 text.
KV> And given there are implemntations that follow draft-07 text as confirmed by Keon, my suggested text accomodates both behavior.
KV> As long as an implementation provides a way to achieve the desired functionality, either as default-behavior or by policy config, I am good with it.
KV> It is a tricky situation with this draft, where the revived version attempts to not make existing implementations non-compliant, as much as possible.

- there are 2 cases when nh is changing -  eBGP advertisement (unless is configured explicitly to do not change) and explicit policy/configuration on iBGP session.
For eBGP case, if link-bandwidth is transitional, we expect it to be propagated by default is not? If I must write config/policy, then it become the same as for non-transitional.
For iBGP case, if we do explicit conscious design to set next-hop to self, then we also can do explicit removal of link-bandwidth if this is what we want.

- I'm not aware about any implementation that by implicit default reeves link-bandwidth on a session configured with next-hop-self. IOS-XR requires a nob to enable sending link-bandwidth ext-community on session, but this is not dependent on next-hop-self configuration or lack of it.

EOS by implicit default (behavior which does not require any configuration) will remove LBW on a session configured with NHS. This is aligned with draft version 7 section 2 which said that implementations SHOULD do so. It is also consistent with our general understanding that LBW is inherently tied to a next hop, and that changing a next hop without changing/removing the LBW does not make any sense.

KV> Rafal, this is the default behavior that above proposed text was trying to accommodate. The text you had proposed (sec 3.3.1) makes EOS non-compliant.


- I'm not aware of any BGP attribute that must be removed when next-hop value is overwritten. The closest are AIGP, but it is not removed, just updated (assuming peers negotiated capabilities). The other is MP-REACH NLRI or labeled SAFI, where label is changed/swapped. Again is change not removal.

Perhaps original statemt shall be:
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 either via explicit local policy/configuration or due to external BGP inherited behaviour, it SHOULD follow the same procedures as outlined in Section 3.1.

In the absence of any route policies that explicitly alter the Link Bandwidth Extended Community, any received Link Bandwidth Extended Community on the route will be re-advertised unchanged. The transitiv/non-transitive property of link-bandwidth extended-comunity must be honored on eBGP sessions.
Please also refer to Section 3.4 for use in a BGP multipath environment.

I'm glad you brought this up. Which part(s) of Section 3.1 are being referred to here? I have read these two sections back to back numerous times and I cannot make any sense of what portions of Section 3.1 are being referred to. I would request that the text here can be made explicit instead of referring to an entire section.

    > Which part(s) of Section 3.1 are being referred to here?
KV> All of sec 3.1 applies, rules as ‘Sender of LBW’. I don’t see what the confusion is. Thanks.

Thanks,
Keon


The above mean that tarnsitive ext-communities are trully transitive. And non-transitive trully non-transitive.


--------------
Rafal Szarecki


On Tue, Sep 16, 2025 at 12:46 PM Jeffrey Haas <[e-mail]<mailto:[e-mail]>> wrote:
This will also require the section's name to be updated from "Re-advertisement with Next hop Self".

-- Jeff


On Sep 16, 2025, at 3:26 PM, Reshma Das <dreshma=[e-mail]<mailto:dreshma=[e-mail]>> wrote:

Hi All,

I have added a GitHub issue and recorded the email exchanges. Please review the suggested text.

https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/issues/18<https://urldefense.com/v3/__https:/github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/issues/18__;!!NEt6yMaO-gk!CTqGLhqvjVJSTAYoZPNjLK4fFImII-FQXzA-UNNX-hGEASHS-a4ojOzD-mYWrb_M4ZcrAb6rWg6b$>

Thanks & Regards,
Reshma Das




Juniper Business Use Only
From: Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 16, 2025 at 10:25 AM
To: Keon Vafai <[e-mail]<mailto:[e-mail]>>, Jeff Haas <[e-mail]<mailto:[e-mail]>>, Rafal Szarecki <[e-mail]<mailto:[e-mail]>>, Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>, idr@ietf. org <[e-mail]<mailto:[e-mail]>>
Cc: Reshma Das <[e-mail]<mailto:[e-mail]>>, Satya Mohanty <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Akshay Gattani <[e-mail]<mailto:[e-mail]>>, Natrajan Venkataraman <[e-mail]<mailto:[e-mail]>>
Subject: Re: [External⚠️] Re: draft-ietf-idr-link-bandwidth#17section-3.3.1 vs draft-ietf-idr-link-bandwidth-07#section-2
Jeff> Please notify Ketan that this conversation is taking place.  Also, push this conversation to IDR ASAP

+Ketan, IDR.

I think we need not madate the implicit drop behavior as a ‘must’, because there
are implementations that follow base BGP behavior. even in draft-07, it is a ‘should’.

How about:

“When a BGP speaker re-advertises a route with the Link Bandwidth
Extended Community and changes the next hop, the received Link Bandwidth
Extended Community should be dropped. This may be done implicitly or by
 policy to remove or change the Link Bandwidth Extended Community.

In absence of such implicit or explicit policy to alter the Link Bandwidth
Extended Community, any received Link Bandwidth Extended Community on the
 route will be re-advertised unchanged”

@Rafal, pls pay attention to this discussion. Since the text being discussed was proposed by you.
https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-17.html#section-3.3.1<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-17.html*section-3.3.1__;Iw!!NEt6yMaO-gk!CTqGLhqvjVJSTAYoZPNjLK4fFImII-FQXzA-UNNX-hGEASHS-a4ojOzD-mYWrb_M4ZcrAdW1e9D3$>

I think your intent was to specify behavior of a BGP speaker following regular BGP
procedures readvertising routes with extended-communities including LBW.

Keon and Satya are noting some implementations have the behavior of removing the LWB
implicitly as described in
https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07#section-2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07*section-2__;Iw!!NEt6yMaO-gk!CTqGLhqvjVJSTAYoZPNjLK4fFImII-FQXzA-UNNX-hGEASHS-a4ojOzD-mYWrb_M4ZcrAZ4TOTFN$>

So, above proposed text accomodates both draft-07 behavior as well as base BGP behavior.

Thanks
Kaliraj




Juniper Business Use Only
From: Keon Vafai <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 16, 2025 at 10:01 AM
To: Jeff Haas <[e-mail]<mailto:[e-mail]>>
Cc: Reshma Das <[e-mail]<mailto:[e-mail]>>, Satya Mohanty <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Akshay Gattani <[e-mail]<mailto:[e-mail]>>, Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>>, Natrajan Venkataraman <[e-mail]<mailto:[e-mail]>>
Subject: 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 all,

Thanks for considering my feedback.

Reshma, Jeff - My apologies for the timing. This is my first go around with any IETF RFC discussion so I am not familiar with the usual process. I was only alerted to these new draft versions a few weeks ago. That being said, it seems that there is a decent consensus that this section with respect to the next hop changing needs rewording. Hopefully it is better to get the document out late and correct rather than have to issue a correction soon after publishing.

I agree with Jeff that any change to the next hop should bring the validity of the link bandwidth received with the route into question. Next hop self is just a special case of changing the next hop. The reason I called out next hop self in my initial feedback is because draft version #7 (the "de facto" standard out there for many years) had specific language for setting the next hop to self, so backwards compatibility is a question. But I would be happy with generalizing this behavior to any change of the next hop.

My suggested text for section 3.3.1 is based on section 3.3.2 which I think does a nice job of concisely conveying the opposite behavior when the next hop is unchanged. I am not sure what the current reference to section 3.1 in section 3.3.1 is achieving, as there is no information in Section 3.1 regarding when an LBW should be removed or otherwise not advertised.

Taking Satya and Jeff's feedback into consideration and applying the sentence structure from section 3.3.2, I suggest the following for Section 3.3.1:

A BGP speaker that receives a route with a Link Bandwidth Extended Community and re-advertises or reflects the same while changing its next hop, without specifying any policy to set, change, or propagate the LBW, MUST drop the received LBW extcomm.

Best,
Keon



On Tue, Sep 16, 2025 at 4:36 AM Jeff Haas <[e-mail]<mailto:[e-mail]>> wrote:
A few brief comments:

Firstly, we’d gone through last call and a further review period for what were intended to be a very minor change in the draft.  If it weren’t for a bit of author/AD sluggishness, this would already be an RFC.  With an Arista author on the draft, this conversation should have happened much earlier.  That said, the Google author was the reason for our previous last-second hold up.  Sigh.

Please notify Ketan that this conversation is taking place.  Also, push this conversation to IDR ASAP.  Any change to normative text will require another review period.

And, for my own input to this chaos… any next hop *CHANGE* likely is the circumstance we’re talking about.  “self” just happens to be a form of such a change.  self means that you know what you’re going to attach, but a third party next hop increases the likelihood that dropping LBW is more likely procedure.

A comment on Satya’s text:
I am suggesting the following text  for consideration in 3.3.1 : " When a BGP speaker re-advertises a route with the Link Bandwidth Extended Community and sets the next hop to itself without specifying any policy to set or change the LBW, the LBW extcom must be dropped".

I suggest “changes the next hop” and “set, change, or propagate”.  The non-transitive ebgp case can be viewed as an intentional propagation operation, e.g.

Depending on the author opinions on the change vs. self conversation, the section may need renaming.

-- Jeff


From: Reshma Das <[e-mail]<mailto:[e-mail]>>
Date: Monday, September 15, 2025 at 23:59
To: Satya Mohanty <[e-mail]<mailto:[e-mail]>>, Keon Vafai <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Akshay Gattani <[e-mail]<mailto:[e-mail]>>, Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>>, Natrajan Venkataraman <[e-mail]<mailto:[e-mail]>>, Jeff Haas <[e-mail]<mailto:[e-mail]>>
Subject: Re: [External⚠️] Re: draft-ietf-idr-link-bandwidth#17section-3.3.1 vs draft-ietf-idr-link-bandwidth-07#section-2

Hi Satya,

The primary goal of this effort is to ensure backward compatibility with existing implementations while extending the draft.
Therefore, if there are implementations that implicitly remove the LBWC when setting next-hop self, we should preserve that behavior.
On the other hand, for implementations that follow standard BGP procedures with extended communities, enforcing the removal of LBWC when setting next-hop self would not be appropriate.

@Keon Vafai<mailto:[e-mail]>: Please do share your suggested texts so we can all go through it.

Thanks & Regards,
Reshma Das



Juniper Business Use Only
From: Satya Mohanty <[e-mail]<mailto:[e-mail]>>
Date: Monday, September 15, 2025 at 5:05 PM
To: Reshma Das <[e-mail]<mailto:[e-mail]>>
Cc: Keon Vafai <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Akshay Gattani <[e-mail]<mailto:[e-mail]>>, Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>>, Natrajan Venkataraman <[e-mail]<mailto:[e-mail]>>, Jeff Haas <[e-mail]<mailto:[e-mail]>>
Subject: 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 and Keon,

I think it is better to make this explicit to remove ambiguity. Also, I remember we specifically discussed this point in zoom meetings last year. As Keon mentioned, LBW and Nexthop are intrinsically related regardless of transitivity  and explicitly setting the nexthop to self under the neighbor (peer) configuration implicitly removes the link bandwidth extcom in many implementations. This is how it is in XR and I gather it's the same in Arista as well.

I am suggesting the following text  for consideration in 3.3.1 : " When a BGP speaker re-advertises a route with the Link Bandwidth Extended Community and sets the next hop to itself without specifying any policy to set or change the LBW, the LBW extcom must be dropped".

The mention of "policy" in the above text leaves open the case of "creating the lbw new" and attaching it to the re-advertised route. Otherwise it is dropped.

In the cases that you have mentioned, inter-as Option B (typical case) and RR (with NHS) will cause the change in NH. Option C typically will not. In all these cases, we need to make sure that the LBW is really pertaining to the resulting nexthop in the route in each scenario as is the case. Otherwise, I am afraid it is not an accurate representation.

Regarding section 3.4, we are working to update the ebgp dmz draft. I think it is best we don't discuss it much here at all.

Thanks,
--Satya



On Mon, Sep 15, 2025 at 3:32 PM Reshma Das <[e-mail]<mailto:[e-mail]>> wrote:
++ LBW authors, chairs

HI Keon,

Thanks for reviewing the document. Going through the old and new texts:

"Additionally, if a route is received with link bandwidth extended community and the BGP
speaker sets itself as next-hop while announcing that route to other
peers, the link bandwidth extended community should be removed.”


- The "should" in the above text is not NORMATIVE and they don't have any text on how to handle it if someone does not
  follow this. How the extended community is removed is also not clear. It looks to be removing a received community
  in the background with NH self.

- The above text only covers non-transitive case and hence this text does not apply to any
  transitive usecases eg: EBGP NH self. When a route crosses an AS boundry non-transitive LBWC is dropped.
So the only case is IBGP doing NH self, which means that IBGP RR in forwarding path that does UECMP.

- This was initially discussed indepth with all authors. These are some grey areas in the old draft that IDR wanted to
  correct and make it complaint with exisiting extended community RFC.

- How Juniper implements it today is we use policy to always remove any community as NH self is also
policied. We can check  how other vendors have implemented this.


"When a BGP speaker re-advertises a route with Link Bandwidth Extended Community and sets the next hop to itself,
it SHOULD follow the same procedures as outlined in Section 3.1.

In the absence of any route policies that alter the Link Bandwidth Extended Community, any received Link Bandwidth Extended
Community on the route will be re-advertised unchanged. Please also refer to Section 3.4 for use in a BGP multipath environment."


- When we considered transitivity in the equation, In cases like MPLS VPN option A,B, C networks
  the egress PE intends the ingress PE to always see the LBWC, which can span across multiple
  AS domains.

- In such scenarios, the RR can be a non-fwd node where NH remains unchanged when readvertising the
  received route or the RR is a fwd node. In both these cases all transitive extended communities
  should be carried upstream as per RFC-4360.

- The old draft deviating from RFC-4360 for LBWC alone. If someone follows the old draft the scenario it covers
  is limited to single AS domain running IBGP.

- May be we can add a recommendation in deployment consideration, if NH self is added that value advertised without
  removing the LBWC is what is received and may not be what user wants.

Whether current text is not complaint with the old draft I am not sure as the old text itself has insufficient detail in the
draft and not NORMATIVE.

Document history details accounts for interop:
https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-17.html#appendix-A<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-17.html*appendix-A__;Iw!!NEt6yMaO-gk!HFKaT6z9lz35a1-P9m3jMrLPDBuK4uZeZxPl-4iBLRnuDpRt6kf4MQUNJZDKTBNvH-lvRVESuD1a4_XdMw$>

Also we recommend to go through IDR interim recordings where LBW usecases were discussed.

I would like to review your suggested text and provide my opinion on it.


Thanks & Regards,
Reshma Das






Juniper Business Use Only
From: Keon Vafai <[e-mail]<mailto:[e-mail]>>
Date: Friday, September 12, 2025 at 12:48 PM
To: Reshma Das <[e-mail]<mailto:[e-mail]>>
Cc: Akshay Gattani <[e-mail]<mailto:[e-mail]>>
Subject: 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,

Thanks for all of your efforts in pushing towards getting this draft standardized. It's great to see so much progress on this matter.

Our concern is specifically with the behavior with respect to propagating a received Link Bandwidth (regardless of transitivity) when the BGP speaker is setting itself as the next hop (NHS).

Because draft #7 was the latest draft available for over 6 years, it can be considered a "de facto standard". Vendors and network operators can be assumed to have been relying on this behavior, and therefore special consideration needs to be given to any changes in the latest draft which may be backwards incompatible with draft #7.

In draft #7 section 2, this behavior is specifically called out:

Additionally, if a
   route is received with link bandwidth extended community and the BGP
   speaker sets itself as next-hop while announcing that route to other
   peers, the link bandwidth extended community should be removed.

This is quite clear. If a BGP speaker performs NHS, it should strip out the LBW before advertising the route. This makes sense because LBW and next hop are inherently tied together. An LBW is not just an advertisement of the capacity towards a prefix. More specifically, it is an advertisement of the capacity that a particular router (identified by the BGP next hop) has towards a prefix. Thus when the next hop is changed, the LBW that was received with that next hop is meaningless at best and a false advertisement of capacity at the worst. Some interpretations of this language may extend the intent to remove the LBW when the next hop is changed in any way (not just NHS) however the draft was specific to NHS and thus our concern is as well.

In draft #17 section 3.3.1, the behavior with respect to NHS now says:

When a BGP speaker re-advertises a route with Link Bandwidth Extended Community and sets the next hop to itself, it SHOULD follow the same procedures as outlined in Section 3.1.

In the absence of any route policies that alter the Link Bandwidth Extended Community, any received Link Bandwidth Extended Community on the route will be re-advertised unchanged. Please also refer to Section 3.4 for use in a BGP multipath environment.
Responding to the first paragraph, Section 3.1 discusses sender behavior. There are specific details on the flexibility to send a transitive or non transitive LBW, as well as some commentary on how an LBW can be attached or updated during inbound and outbound processing. However, there is no information in Section 3.1 regarding when an LBW should be removed or otherwise not advertised.

Responding to the second paragraph, NHS is not a route policy that alters the LBW. It is a route policy that alters the next hop. Therefore, the unchanged re-advertisement should apply with NHS.

Our interpretation of this section is that the received LBW should be re-advertised unchanged (subject to transitivity) even if the BGP speaker is setting itself as the next hop. Therefore, any BGP speaker who has been in compliance with draft #7 section 2 will be in violation of draft #17 section 3.3.1.

Section 3.3.1 is titled "Re-advertisement with Next hop Self", however there is nothing in this section that refers to NHS configuration or behavior. Therefore, I am assuming this backwards incompatible change is not intentional because otherwise, what is the intent of this specific section? I am happy to suggest some clarifications that could be added to this section pending your response.

Thanks,
Keon

On Fri, Sep 12, 2025 at 12:19 PM Reshma Das <[e-mail]<mailto:[e-mail]>> wrote:
Of course, it’s better to make the document better before we go for publication.
I would appreciate if these were closed ahead of time specially from authors 😊 but better late than never.

Please let me know the concerns and we can check.

Thanks & Regards,
Reshma Das


Get Outlook for Mac<https://urldefense.com/v3/__https:/aka.ms/GetOutlookForMac__;!!NEt6yMaO-gk!Fl2PCXX61Vw66E4FfyA2ad-ibz2NAa7oyHjOJ9ZhRNCRiXRIHnNgNlq_X9aoOLlYyR3G8kNZ-oY$>



Juniper Business Use Only
From: Akshay Gattani <[e-mail]<mailto:[e-mail]>>
Date: Friday, September 12, 2025 at 12:00 PM
To: Reshma Das <[e-mail]<mailto:[e-mail]>>
Cc: Keon Vafai <[e-mail]<mailto:[e-mail]>>
Subject: 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

Keon on our side has done a lot of detailed analysis on this, so I will let him respond. Once we finalize our recommendations here, can we take this up as part of the "AD evaluation" thread?

Thanks

On Fri, Sep 12, 2025 at 11:44 AM Reshma Das <[e-mail]<mailto:[e-mail]>> wrote:
Hi Akshay,

Yes, the old version is based on the non-transitive version. In our current version, we point towards the BGP procedures. May be we can add reference to the extended community RFC [rfc4360]?
which itself is being updated currently in the list.

Would that help?

Thanks & Regards,
Reshma Das

Get Outlook for Mac<https://urldefense.com/v3/__https:/aka.ms/GetOutlookForMac__;!!NEt6yMaO-gk!DfX7raENo-aO2AkEiLlyPfxy-RLFfTzbUwR3MsetdMDh8uzcyYBhcUttWu3UQQjdhB0tgq3vS2BxbQ$>



Juniper Business Use Only
From: Akshay Gattani <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 11, 2025 at 7:58 PM
To: Reshma Das <[e-mail]<mailto:[e-mail]>>
Cc: Keon Vafai <[e-mail]<mailto:[e-mail]>>
Subject: 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

As we were doing a more detailed review of the latest “last call” draft, we noticed that the current phrasing of section 3.3.1 (below)



 In the absence of any import or export policies that alter the Link

   Bandwidth Extended Community, any received Link Bandwidth Extended

   Community on the route will be re-advertised unchanged, in accordance

   with standard BGP procedures.

can result in interpretations which run counter to the recommendations in https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07#section-2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07*section-2__;Iw!!NEt6yMaO-gk!CkYizpxVje4eWEPBRMlfbkvzOMBsaS0yhFznFXmFgIpMudi1Ug1-R4PajToxvWGacSeU57N9TwpGfg$> (below)



Additionally, if a

   route is received with link bandwidth extended community and the BGP

   speaker sets itself as next-hop while announcing that route to other

   peers, the link bandwidth extended community should be removed.

So some implementations following recommendations from draft#07 would now see a change in behavior which would be backward incompatible. You had clarified<https://urldefense.com/v3/__https:/github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/issues/15__;!!NEt6yMaO-gk!CkYizpxVje4eWEPBRMlfbkvzOMBsaS0yhFznFXmFgIpMudi1Ug1-R4PajToxvWGacSeU57O1JeKOEA$> that the new 3.3.1 contents are to be mostly interpreted in the context of transitive re-advertisement of the LBW attribute.

Can we bring this up as part of the current “AD evaluation review” discussion or any other recommendation? I think section 3.3.1 could use clarity.

Thanks


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.
_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>