Re: [bess] Lars Eggert's No Objection on draft-ietf-bess-evpn-pref-df-11: (with COMMENT)

["Jorge Rabadan (Nokia)" <[e-mail]>]

Hi Lars,

Thank you very much for your review.
All your comments have been addressed in version 12.
Let us know if you have further questions.

Please see in-line with [Jorge].

Thanks!
Jorge


From: Lars Eggert via Datatracker <[e-mail]>
Date: Friday, August 4, 2023 at 4:53 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Stephane Litkowski <[e-mail]>, [e-mail] <[e-mail]>
Subject: Lars Eggert's No Objection on draft-ietf-bess-evpn-pref-df-11: (with COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Lars Eggert has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-11: 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-pref-df/



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

# GEN AD review of draft-ietf-bess-evpn-pref-df-11

CC @larseggert

Thanks to Vijay Gurbani for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/yyKue3u0e4F2LuAMSzjlxaEKHrQ).

## Comments

### Section 1.1, paragraph 2
```
     While the Default Designated Forwarder Algorithm [RFC7432] or the
     Highest Random Weight algorithm (HRW) [RFC8584] provide an efficient
     and automated way of selecting the Designated Forwarder across
     different Ethernet Tags in the Ethernet Segment, there are some use-
     cases where a more 'deterministic' and user-controlled method is
     required.  At the same time, Service Providers require an easy way to
```
Why is "deterministic" in quotes here? Is this algorithm not
(always) in fact deterministic? Could a more accurate term be
chosen?
[Jorge] I removed “deterministic”. I think “user-controlled method” conveys the meaning that we want in this text.


### Section 4.1, paragraph 1
```
     Assuming the operator wants to control - in a flexible way - what PE
     becomes the Designated Forwarder for a given virtual Ethernet Segment
     and the order in which the PEs become Designated Forwarder in case of
     multiple failures, the following procedure may be used:
```
It's not clear what kind of procedure the list items a-f describe. The
individual list items read more like standalone considerations than
any kind of procedure.
[Jorge] we changed the first paragraph, hopefully it reads better now. Let us know please.


## 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.
[Jorge] ok, thanks.


### Typos

#### Section 4.1, paragraph 2
```
-        (100,0,Highest-Preferance), (200,0,Highest-Preference) and
-                             ^
+        (100,0,Highest-Preference), (200,0,Highest-Preference) and
+                             ^
```

#### Section 4.1, paragraph 11
```
-           if PE2's IP addres is lower than PE1's.  Same example applies
+           if PE2's IP address is lower than PE1's.  Same example applies
+                            +
```

#### Section 4.2, paragraph 1
```
-    Segment.  A potential way to achive a more granular load balancing is
-    decribed below.
+    Segment.  A potential way to achieve a more granular load balancing is
+                                     +
+    described below.
+      +
```

### Outdated references

Document references `draft-ietf-bess-evpn-virtual-eth-segment-11`, but `-12` is
the latest available revision.
[Jorge] updated, thanks.

### Grammar/style

#### Section 4.1, paragraph 3
```
nce is more preferred than PE2's). Hence PE1 becomes the Designated Forwarde
                                   ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".
[Jorge] added


#### Section 4.1, paragraph 4
```
dered list for vES1 is <PE2, PE1>. Hence PE2 becomes the Designated Forwarde
                                   ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".
[Jorge] added



#### Section 4.1, paragraph 6
```
s are used as tie-breakers. If more that one PE is advertising itself as the
                                    ^^^^
```
Did you mean "than"?
[Jorge] fixed


#### Section 4.3, paragraph 11
```
with DP=1, that is, PE2 (Pref=200). Hence PE3 will inherit PE2's preference a
                                    ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".
[Jorge] fixed



#### Section 4.3, paragraph 19
```
warder Election Algorithm different than the one configured in the rest of t
                                    ^^^^
```
Did you mean "different from"? "Different than" is often considered colloquial
style.
[Jorge] fixed



## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool