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

[Gunter Van de Velde via Datatracker <[e-mail]>]

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://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:
----------------------------------------------------------------------

# The line numbers used are rendered from IETF idnits tool:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-19.txt

# 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"?

# 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)?

[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?


----------------------------------------------------------------------
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?

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 "

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.

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/

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?

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

GV> What is the difference between re-advertising or reflecting?

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?

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.

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.

Many thanks for this well written and useful document,

Kind Regards,
Gunter Van de Velde
RTG Area Director