[Idr] Re: Gunter Van de Velde's Discuss on draft-ietf-idr-link-bandwidth-19: (with DISCUSS and COMMENT)

[Reshma Das <[e-mail]>]

Hi Gunter Van de Velde,

Thank you for the detailed review. Please find my replies inline as:
RD>

Thanks & Regards,
Reshma Das



Juniper Business Use Only
From: Gunter Van de Velde via Datatracker <[e-mail]>
Date: Wednesday, October 22, 2025 at 6:41 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Gunter Van de Velde's Discuss on draft-ietf-idr-link-bandwidth-19: (with DISCUSS and COMMENT)
[External Email. Be cautious of content]


Gunter Van de Velde 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!GNd0peVC0qMyS_0IY0cZassVjNZX-MProodMuBphNXfG9OkHehMgmp6tWUqp0mc4JwvduYxwKlFI38M$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!GNd0peVC0qMyS_0IY0cZassVjNZX-MProodMuBphNXfG9OkHehMgmp6tWUqp0mc4JwvduYxwKlFI38M$>
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!GNd0peVC0qMyS_0IY0cZassVjNZX-MProodMuBphNXfG9OkHehMgmp6tWUqp0mc4JwvduYxwQfYLX4A$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/__;!!NEt6yMaO-gk!GNd0peVC0qMyS_0IY0cZassVjNZX-MProodMuBphNXfG9OkHehMgmp6tWUqp0mc4JwvduYxwQfYLX4A$>



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# The line numbers used are rendered from IETF idnits tool:
https://urldefense.com/v3/__https://author-tools.ietf.org/api/idnits?url=https:**Awww.ietf.org*archive*id*draft-ietf-idr-link-bandwidth-19.txt__;Ly8vLy8!!NEt6yMaO-gk!GNd0peVC0qMyS_0IY0cZassVjNZX-MProodMuBphNXfG9OkHehMgmp6tWUqp0mc4JwvduYxwoKl0iDM$<https://urldefense.com/v3/__https:/author-tools.ietf.org/api/idnits?url=https:**Awww.ietf.org*archive*id*draft-ietf-idr-link-bandwidth-19.txt__;Ly8vLy8!!NEt6yMaO-gk!GNd0peVC0qMyS_0IY0cZassVjNZX-MProodMuBphNXfG9OkHehMgmp6tWUqp0mc4JwvduYxwoKl0iDM$>

# Many thanks for the RTGDIR review from Russ White and the shepherd writeup
from Jeff Haas.

# I found the draft well written, easy to ready and understand the procedures
and have only few observations and a simple to resolve DISCUSS.

# One general observation was that the document uses terminology as ECMP and
load-balancing and weighted load-balancing. Would it be more consistent to use
everywhere "equal load-balancing" and "weighted load-balancing" or "ECMP" and
"weighted ECMP"?

RD>  Updated to use “equal load-balancing” and “weighted load-balancing” everywhere. Addressed this and updated in (Git-Issue-Tracker<https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/compare/main...22-review-comment-edits>)

# DISCUSS
# =======

[DISCUSS#1]
169        route.  However during transition (refer Section 7 for details), a
170        BGP speaker MAY attach one Link Bandwidth Extended Community per
171        transitivity (transitive/non-transitive) both having the same
172        'Bandwidth Value' field.

GV> From the text above i assert that the "Bandwidth Value" MUST be identical
if this happens. Is there a reason this asserting is not baked in stone by
formal language, with a MUST or SHOULD (with implication explained)?
RD>  Please review the suggested text:
“However, during the transition (refer to Section 7 for details), a BGP speaker MAY attach one Link Bandwidth Extended Community per transitivity (transitive and non-transitive); the 'Bandwidth Value' field in both communities SHOULD be the same.”

[DISCUSS#2]
202        zero values, the behavior is determined by local policy.  For
203        example, implementations MAY exclude the paths with zero value from
204        weighted load balancing formation as long as at least one path with
205        non-zero value exists or they MAY fallback to ECMP.

GV> What is the expected behavior when some NLRI have the extended metric (zero
or a value) and some do not have the community?

RD>  The handling of the zero value is covered in (Receiver<https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-19.html#name-receiver-receiving-link-ban>) Please note that this section documents 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. When a path lacks a Link Bandwidth Extended Community, the behavior falls back to ECMP, as mentioned in (Error Handling<https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-19.html#name-error-handling>)
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# comments
# ========

123         0                   1                   2                   3
124         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
125        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
126        |Type=0x00/0x40 | SubType= 0x04 |       AS Number               |
127        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
128        |                     Bandwidth Value                           |
129        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

GV> on the section after this figure, you explain the fields saying they are
"Global Administrator sub-field" and "Local Administrator sub-field". What is
written is not wrong, it just reads a bit awkward to see "AS Number" and
"Bandwidth Value" in the picture and then have different field names mentioned
below. Maybe this can be made more consistent to avoid getting confused on the
formal definitions?
RD > ACK, I have updated the same, (Git-Issue-Tracker<https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/compare/main...22-review-comment-edits>)


150        handle both variants in a way that supports existing deployments.

GV> what does 'existing' exactly mean? does that exclude future deployments? i
suspect that the author wants to say:

"
handle both variants, ensuring that implementations can interoperate correctly
across all deployments "
RD> ACK. Updated this in GitHub link (Git-Issue-Tracker<https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/9c3901a0ff0d2998c0356ce54fbfae153ffc18e4>)


161        Different implementations MAY use different default values for the
162        transitivity type of the Link Bandwidth Extended Community.  The

GV> Nothing wrong with each implementation having its own default value.
Nevertheless, maybe a suggestion of a reasonable default value may be helpful
for implementors, when he doesn't know, or has absolutely no value preference,
then an example value can be useful to fil in the blanks.
RD>  We have updated the document as follows to ensure operators are aware of default values. Since this document was first introduced in 2009, various implementations have adopted different default transitivity types. One of the primary goals in updating this document is to record all current behaviors in the field so that no implementation will be deemed non-compliant once this specification becomes an RFC. Both transitivity types should be processed by all implementations supporting the latest draft, so there is no need to prefer one over the other; they differ only by the transitivity bit.
New text as suggested in other AD review:
“Different implementations MAY use different default values for the transitivity type of the Link Bandwidth Extended Community. The provided configuration SHOULD allow operators to override the default transitivity value as needed. Likewise, implementations SHOULD expose their default values. An implementation MAY advertise a bandwidth value of zero.”


167        Generally, a single Link Bandwidth Extended Community of the
168        transitivity type that is desired in a deployment is attached to a

GV> not sure we need "that is" in this phrase
GV> s/type that is desired in/type desired in/
RD>  Ack. (Git-Issue-Tracker<https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/compare/main...22-review-comment-edits>)


174        A Link Bandwidth Extended Community MAY be attached or updated for a
175        BGP route upon receipt during Adj-RIB-In processing.  The Link

GV> is it a BGP route or a BGP NLRI it is attached to? Would using BGP NLRI not
be more accurate?
RD>  I prefer route as used through RFC-4360. Please let me know your thoughts.


231        Community and re-advertises or reflects the same without changing its

GV> What is the difference between re-advertising or reflecting?
RD> Reflecting in BGP refers to a route reflector forwarding routes between iBGP peers, breaking the iBGP full mesh requirement while preventing loops using attributes like Cluster-ID and Originator-ID.​
Re-advertising describes any BGP speaker passing on received routes to its peers, potentially modifying route attributes (like next hop or communities) as appropriate.


264        Link Bandwidth Extended Communities with a negative value SHALL be
265        ignored and MUST NOT be advertised.

GV> does this mean that a route-reflector, when it receives such a community,
it will strip the community from the route without any operator input? is
logging expected?
RD> This text is misleading, the intention of the text is to say when attaching LBWC a negative value should not be attached. If a negative value is received it should be ignored (treat as if LBWC does not exist). The community by itself should not be stripped by any receiver. I have reworded this as below:
“A negative value in a Link Bandwidth Extended Community SHOULD NOT be attached or originated by any BGP speaker. If a BGP receiver encounters a Link Bandwidth Extended Community that contains a negative link-bandwidth value, the Link Bandwidth Extended Community SHOULD be ignored.”
Please review the suggested text.


271        ECMP (Equal-Cost Multi-Path) MUST be used instead.

GV> late in the document to expand on ECMP abbreviation. Maybe expand at first
usage.
RD> Updated this part of first review comment.


313        would treat the use of the other transitivity type in a "ships in the
314        night" fashion.  The procedures in this document govern how multiple

GV> i observe that other ADs have issues with the construct "ships in the
night". I do not share that complaint and want to note that this phrase is very
well known in routing world. No nautical experience necessary :-) Using
something else would possibly make it less clear.
RD>  😊


Many thanks for this well written and useful document,

Kind Regards,
Gunter Van de Velde
RTG Area Director