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

[Éric Vyncke via Datatracker <[e-mail]>]

É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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/



----------------------------------------------------------------------
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://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
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)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


## COMMENTS (non-blocking)

### BCP 14

I second Mohamed Boucadair's DISCUSS about the use of the wrong BCP14 template
at the common location.

### 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.

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.

### 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.

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 ?

### 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://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

### 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://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#trans-two-octet-as

### Section 7

As this section contains only another section without any lead text, consider
removing the section 7.1 title.

This section mentions "previous implementations", was there a RFC for it ?