Subject: [bess] Mike Bishop's No Objection on draft-ietf-bess-evpn-unequal-lb-33: (with COMMENT)
From: Mike Bishop via Datatracker <[email-masked]>
To: "The IESG" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Tue, 03 Mar 2026 11:45:23 -0800
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>

Mike Bishop has entered the following ballot position for
draft-ietf-bess-evpn-unequal-lb-33: No Objection

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-bess-evpn-unequal-lb/

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

# IESG review of draft-ietf-bess-evpn-unequal-lb-33

CC @MikeBishop

This is outside my area of technology expertise, so it's entirely possible some
of my comments can be dismissed on that basis.

## Comments

### Section 4.1, paragraph 9

How do endpoints negotiate their awareness of this OPTIONAL value, or
advertise support for new values defined in the future?

### Section 4.1.1, paragraph 3

Given that these messages will not arrive and be processed
simultaneously on all routes, it might be worth mentioning that "inconsistency"
might be a normal and transient state -- if it's been received on one but not
all yet, or if it's in the process of switching from one unit to another.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### "BESS", paragraph 0
```
- Updates: RFC8584 (if approved)                             Cisco Systems
-          ---
```

You don't need the "RFC" before the number in the header.

### URLs

These URLs point to tools.ietf.org, which has been taken out of service:

 * https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-19.txt

These URLs in the document did not return content:

 *
 http://www.ietf.org/internet-drafts/draft-ietf-bess-evpn-per-mcast-flow-df-election-13.txt

### Grammar/style

#### Section 5.1, paragraph 1
```
-    generalized weight.  New EVPN link bandwidth extended community
-                         ^
+    generalized weight.  The new EVPN link bandwidth extended community
+                         ^^^^^
```

#### Section 5.1, paragraph 2
```
-    EVPN link bandwidth extended community MUST NOT be attached to per-
+    The EVPN link bandwidth extended community MUST NOT be attached to per-
+   ++++
```

#### Section 6.2, paragraph 3
```
ability of being DF in proportion to it's relative bandwidth within an ES. As
                                     ^^^^
```
Did you mean "its" (possessive pronoun) instead of "it's" (short for "it is")?

#### Section 6.3.2, paragraph 6
```
-    This essentially results in number of candidate HRW hash computations
+    This essentially results in a number of candidate HRW hash computations
+                               ++
```

#### Section 7.2, paragraph 1
```
hts are assigned to each PE in a consistent manner. * When a generalized wei
                            ^^^^^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "consistently" to avoid
wordiness.