[Idr] Re: Éric Vyncke's Discuss on draft-ietf-idr-link-bandwidth-19: (with DISCUSS and COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Eric,

I am following up on this document and I note your ABSTAIN and other
comments that were not responded to.

You have provided two reasons for your ABSTAIN:

1) the use of "SHOULD" in section 3 should have been a "MUST" (AFAIK all
implementations support it)

While a lot of implementations support the LBW EC specified in this
document, there are two variants of it (transitive and non-transitive) and
both of them are not supported by all implementations. The document allows
implementations to support in a way/form as/when required by their
respective customer deployments. For some years (while this draft was in
hibernation), there have been interop challenges due to these two variants
and the authors that picked up this WG have worked out a solution to
interoperate in deployments with these two types. All the SHOULDs in
section 3 are about dealing with these two variants. They are SHOULDs so as
not to make many implementations non-compliant and give time for the
transition mechanisms to work out. These SHOULDs have come from long
deliberations in the WG between authors from multiple vendors and I believe
their usage is appropriate. I hope you are able to reconsider your ballot
given this context.

2) there are also a lot of "out of scope" statements

I'll walk through them all.

a) New text in section 2 clarifies the 4-byte ASN aspects. Further, to
address comments from Paul, I've suggested the following change:

CURRENT: The encoding of the full four-octet ASNs is out of scope for this
document.
SUGGEST: The encoding of the full four-octet ASNs is not supported by the
Link Bandwidth Extended Community. Such a capability, should the
operational need for it arise, may be provided by a new BGP extension.

b) Section 3.2 about weighted load-balancing. The WG has decided to keep
only the LBW EC encoding and signaling aspects in this document. There is a
companion https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/ that
builds on top of this spec. It goes into use-cases and a lot of behaviors
that are local to the node but are important for interoperability and
working of the network wide solutions. All of the remaining "out of scope"
point towards the work being done in that document.

CURRENT: Details of weighted load-balancing are outside the scope of this
document.
SUGGEST: Details of weighted load-balancing are outside the scope of this
document. Refer to [draft-ietf-bess-ebgp-dmz
<https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-21.html#draft-ietf-bess-ebgp-dmz>
] which describes some of the weighted load-balancing aspects.

c) Section 3.4 about the arithmetic with multipath - the pointer is already
provided.

CURRENT: This topic is beyond the scope of this document. Refer to [
draft-ietf-bess-ebgp-dmz
<https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-21.html#draft-ietf-bess-ebgp-dmz>
] which describes how this could be done in specific scenarios.

d) Section 7.2 about determination of the bandwidth values

CURRENT: How the bandwidth value is computed or determined is out of scope
of this document. It is recommended that implementations provide mechanisms
to limit the churn caused by frequently changing bandwidth values because
rapid fluctuations could impact protocol stability and network operations.
However, the specific methods for achieving this are out of scope of this
document.
SUGGEST: How the bandwidth value is computed or determined is out of scope
of this document. Refer to [draft-ietf-bess-ebgp-dmz
<https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-21.html#draft-ietf-bess-ebgp-dmz>
] which describes how this could be done in specific scenarios. It is
recommended that implementations provide mechanisms to limit the churn
caused by frequently changing bandwidth values because rapid fluctuations
could impact protocol stability and network operations.

I hope this clarifies your 2nd concern.

Please check inline below for KT for clarifications on your comments.


On Wed, Nov 12, 2025 at 7:51 PM Eric Vyncke (evyncke) <evyncke=
[e-mail]> wrote:

> Thanks, Reshma, for your message, it was sent when I was travelling to the
> busy IETF week, hence thanks also for your patience.
>
>
>
> You may have seen my ballot change to a non-blocking ABSTAIN, other
> comments below as indicated by EV>
>
>
>
> Regards,
>
>
>
> -éric
>
>
>
> Cisco Confidential
>
> *From: *Reshma Das <[e-mail]>
> *Date: *Wednesday, 29 October 2025 at 23:16
> *To: *Eric Vyncke (evyncke) <[e-mail]>, The IESG <[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-idr-link-bandwidth-19:
> (with DISCUSS and COMMENT)
>
>
>
> Hi Éric Vyncke ,
>
>
>
> Thanks for reviewing the document. Please find my reply inline as RD>
>
>
>
> Thanks & Regards,
> Reshma Das
>
>
>
>
>
> Juniper Business Use Only
>
> *From: *Éric Vyncke via Datatracker <[e-mail]>
> *Date: *Friday, October 10, 2025 at 2:09 AM
> *To: *The IESG <[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Éric Vyncke's Discuss on draft-ietf-idr-link-bandwidth-19:
> (with DISCUSS and COMMENT)
>
> [External Email. Be cautious of content]
>
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-idr-link-bandwidth-19: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!F6g9-SE4iwzK_9_Nl403nfwaTxkQrHiXCtLOQuqFDoZxy548EM2e6WHD71BOUxBpO7KSLmS5TUN8E14$
> <https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!F6g9-SE4iwzK_9_Nl403nfwaTxkQrHiXCtLOQuqFDoZxy548EM2e6WHD71BOUxBpO7KSLmS5TUN8E14$>
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/__;!!NEt6yMaO-gk!F6g9-SE4iwzK_9_Nl403nfwaTxkQrHiXCtLOQuqFDoZxy548EM2e6WHD71BOUxBpO7KSLmS5p4AoToc$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/__;!!NEt6yMaO-gk!F6g9-SE4iwzK_9_Nl403nfwaTxkQrHiXCtLOQuqFDoZxy548EM2e6WHD71BOUxBpO7KSLmS5p4AoToc$>
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-idr-link-bandwidth-19
> CC @evyncke
>
> Thank you for the work put into this document.
>
> Please find below one blocking DISCUSS points (easy to address I think),
> some
> non-blocking COMMENT points/nits (replies would be appreciated even if
> only for
> my own education).
>
> Special thanks to Jeffrey Haas for the shepherd's detailed write-up
> including
> the WG consensus and the justification of the intended status and about
> having
> 6 authors rather than the recommended max of 5 authors.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> ## DISCUSS (blocking)
>
> As noted in
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/__;!!NEt6yMaO-gk!F6g9-SE4iwzK_9_Nl403nfwaTxkQrHiXCtLOQuqFDoZxy548EM2e6WHD71BOUxBpO7KSLmS5QJnDX1Q$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/__;!!NEt6yMaO-gk!F6g9-SE4iwzK_9_Nl403nfwaTxkQrHiXCtLOQuqFDoZxy548EM2e6WHD71BOUxBpO7KSLmS5QJnDX1Q$>
> ,
> a DISCUSS ballot is a request to have a discussion on the points below; I
> really think that the document would be improved with a change here, but
> can be
> convinced otherwise.
>
> ### Section 2
>
> (see also non-blocking comments about this section)
>
> As the section text is about *router* bandwidth, what is a *router*
> bandwidth
> as opposed to a *link* bandwidth ? Is it the max forwarding rate ? or the
> sum
> of all link bandwidth ?
>
> This must be specified (or a reference be added to its definition)
>
> RD> The draft has been updated, and the following has been added to the
> Introduction. Please let me know this addresses your concern.
>
> “The Link Bandwidth Extended Community carries the bandwidth information
> of a directly connected link or multi-hop/multipath nexthop as advertised
> by a router.”
>
>
>
>
> EV> unsure what is the bandwidth of ` or multi-hop/multipath` is it the
> sum of the bandwidth of all links ?
>

KT> Yes - in a manner of speaking. This is being dealt with in
https://www.ietf.org/archive/id/draft-ietf-bess-ebgp-dmz-08.html#section-4.2
and is a work in progress.


>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> ## COMMENTS (non-blocking)
>
> ### BCP 14
>
> I second Mohamed Boucadair's DISCUSS about the use of the wrong BCP14
> template
> at the common location.
>
> RD>  ACK, this has been updated.
>
>
> ### Abstract
>
> Abstract gains to be short and concise but this one is really short as it
> does
> not even mention 'bandwidth'... Please consider giving a more descriptive
> abstract.
>
> The abstract should also mention that only 16-bit ASN are fully supported
> per
> section 2.
>
> RD> Please find suggested text for new Abstract:
>
> “This document defines a BGP Extended Community, the Link Bandwidth
> Extended Community, which carries link bandwidth information to enable
> weighted load-balancing in multipath scenarios. It specifies the format and
> processing rules for this community type””
>
>
>
> EV> better thanks
>
>
>
>
> Per section 4, this I-D also specifies forwarding behaviour in addition to
> defining a BGP community, let's mention this in the abstract *and*
> introduction.
>
> ### Section 1
>
> Should there be some text about *how* this metric can be used ? Obviously
> not
> for ECMP as the costs are no more equal.
>
> RD> This has been mentioned in receiver section.
>
>
> https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-19.html#name-receiver-receiving-link-ban
>
>
>
> EV> sure, but some words in the introduction would have made the text
> easier to read and understand
>

KT> I agree but I've left it to the authors' consideration.


>
>
> ### Section 2
>
> The section title is about *link* bandwidth while the text is about
> *router*
> bandwidth? Which one is the correct one ? Please ensure that section title
> and
> section content are aligned.
>
> RD>  The document defines:
>
> “The Link Bandwidth Extended Community provides a mechanism for routers to
> advertise the bandwidth of their downstream path that may either be a
> directly connected link or multi-hop/multipath nexthop. “
>
> Hence rewording this section as below, please review:
>
> “The Link Bandwidth Extended Community is defined as a BGP extended
> community that carries the bandwidth information, represented by BGP Next
> Hop, connecting to a remote network”
>
>
> I am not a BGP expert but processing only 16-bit ASN in 2025 seems quite
> limitative per `The encoding of 4-octet ASN is out of scope of this
> document.`
> Did the IDR WG try to explore other techniques to support 32-bit ASN ?
>
> RD> I would like to point you to Jeffs reply
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/inJK_mowTUP-JlY7gDwyPmPVkmk/__;!!NEt6yMaO-gk!E3eFCzM3qCIf9qoqIcqWNtDgCVTRRL38kvsM9BZ2qBzn1chSnIcGR5rM-bTWrlqpgAO4--I5rEY2e_al3ualFYq0KO-GB6M$> to
> a similar comment that details the format of extended community.
>
> Based on various review comments we have reworded this section, please
> check the new text GitHub-ASNUM
> <https://urldefense.com/v3/__https:/github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/pull/21/commits/4461d3def20e589987be61e38e7b88ac2f08ffbd*diff-483d4c38615bf145bb86c3b6a77bdae817e0b0f15c616c5df65039377016e59a__;Iw!!NEt6yMaO-gk!E3eFCzM3qCIf9qoqIcqWNtDgCVTRRL38kvsM9BZ2qBzn1chSnIcGR5rM-bTWrlqpgAO4--I5rEY2e_al3ualFYq0CJp-aKo$>
> .
>
>
>
> EV> alas Jeff replied only to Paul, i.e., I did not read his reply until
> reading your email 😊
>

KT> That text was updated and there is one further update that I've
suggested - (2)(a) above related to "out-of-scope".


>
>
> ### Section 3.1
>
> This section contains several "SHOULD" but nothing is specified about when
> these "SHOULD" can be bypassed or what are the consequences of bypassing
> them.
> See the IESG statement
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/__;!!NEt6yMaO-gk!F6g9-SE4iwzK_9_Nl403nfwaTxkQrHiXCtLOQuqFDoZxy548EM2e6WHD71BOUxBpO7KSLmS5fCIUpxI$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/__;!!NEt6yMaO-gk!F6g9-SE4iwzK_9_Nl403nfwaTxkQrHiXCtLOQuqFDoZxy548EM2e6WHD71BOUxBpO7KSLmS5fCIUpxI$>
>
> RD>  As noted in Appendix-A
> <https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-19.html#appendix-A>,
> The previous versions of the draft supported only non-transitive, while
> current version supports both transitive and non-transitive LBWC. Any
> implementation that supports this current draft should be able to process
> both these versions. Please note that the main goal of this effort is to
> record all implementation behaviors observed in the field today, allowing
> them to be used as the default behavior. The intent is that no existing
> implementation should be considered non-compliant following publication of
> this specification as an RFC. Also making sure all implementations
> interoperate. Hence SHOULD has been used
>
>
>
> EV> while basing a I-D on existing implementations is perfectly fine
> (“running code” 😊 ), then I wonder why it is not a MUST
>

KT> I think I've provided the context on this at the top of this email.


>
>
> ### Section 4
>
> The section title is about "Error" but except for paragraph 4 and 5, the
> content is not about error handling. Consider splitting this section in 2.
>
> EV> No changes there in the diff, this is fine as this was non-blocking
> anyway
>

KT> You have a valid point here - there is text here that is not related to
error or non-conformant behavior handling. I have the following suggestions
for the authors:

Between transitive and non-transitive types of Link Bandwidth Extended
Communities that have the same 'Bandwidth Value', the transitivity does not
matter for purpose of computing weighted load balancing or programming to
FIB (Forwarding Information Base).
KT> Authors, should this be moved into section 3.2 ?

Note that these procedures mean that a BGP speaker reflecting a route with
next hop unchanged (e.g. RR) will re-advertise the Link Bandwidth Extended
Communities received on the route as-is without any modification, while
following the extended community transitivity rules.
KT> Authors, should this be moved into section 3.3.2 ?


>
> ### Section 5
>
> Suggest adding a reference to the registry URI, e.g.,
>
> https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml*trans-two-octet-as__;Iw!!NEt6yMaO-gk!F6g9-SE4iwzK_9_Nl403nfwaTxkQrHiXCtLOQuqFDoZxy548EM2e6WHD71BOUxBpO7KSLmS5NJ2duuo$
> <https://urldefense.com/v3/__https:/www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml*trans-two-octet-as__;Iw!!NEt6yMaO-gk!F6g9-SE4iwzK_9_Nl403nfwaTxkQrHiXCtLOQuqFDoZxy548EM2e6WHD71BOUxBpO7KSLmS5NJ2duuo$>
>
> ### Section 7
>
> As this section contains only another section without any lead text,
> consider
> removing the section 7.1 title.
>
> RD> This section has been expanded to add another section.
>
>
> https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/blob/main/draft-ietf-idr-link-bandwidth.txt
>
>
>
> This section mentions "previous implementations", was there a RFC for it ?
>
> RD> This is covered in the Appendix. This document has a long history as
> it was introduced in 2009.
>
>
> https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-19.html#appendix-A
>
>
>
> EV> I do not see a list of implementations in the appendix A ;-)
>

KT> I believe Reshma was referring to the document's history. Normally IDR
implementation reports are documented here:
https://wiki.ietf.org/group/idr/implementations ... However, I find this
document missing there. I think the WG got so involved in fixing this
document that the need to document implementations was missed. I will jot
it down to the fact that most engineers from major vendors involved in
picking up this document from hibernation were aware of each other's
implementations :-) ... and there are definitely more than 2.

Thanks,
Ketan