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

[Ketan Talaulikar <[e-mail]>]

Hi Eric,

Could you please check the v20 of the draft posted just before the IETF
week and Reshma's responses below to see if they address your concerns?

Thanks
Ketan


On Wed, Oct 29, 2025 at 3:17 PM Reshma Das <dreshma=
[e-mail]> wrote:

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