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

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you, Jorge, for taking the time to reply.

I can only regret the use of “DP” rather than “DNP”, but you have a point if there are existing implementations.

Regards

-éric

From: Jorge Rabadan (Nokia) <[e-mail]>
Date: Friday, 6 October 2023 at 21:51
To: Eric Vyncke (evyncke) <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Stephane Litkowski <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-bess-evpn-pref-df-11: (with COMMENT)
Hi Éric,

Thanks very much for the review. Your comments are addressed in version 12.

Please see in line with [Jorge] for more details.

Thanks.
Jorge

From: Éric Vyncke via Datatracker <[e-mail]>
Date: Tuesday, August 1, 2023 at 2:35 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: Éric Vyncke'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.



Éric Vyncke 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:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-pref-df-11

Thank you for the work put into this document. Please note that I was close to
ballot a DISCUSS based on my non-blocking COMMENT points, but as I am not an
expert in EPVN, I am trusting the responsible AD.

Please find below osome non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and several nits (please run
your I-D through a spell-checker).
[Jorge] all the nits are fixed now, thanks


Special thanks to Stéphane Litkowski for the shepherd's detailed write-up
including the WG consensus and the justification of the intended status even if
using the old template.

I hope that this review helps to improve the document,
[Jorge] it does, thank you very much.


Regards,

-éric

# COMMENTS

## Abstract

Please fix the expansion of BUM as it is not `Broadcast, Unknown unicast and
Broadcast traffic (BUM)` ;-)
[Jorge] fixed, thanks


## Section 1.1

Please fix the expansion of BUM as it is not `Broadcast, Multicast and Unknown
unicast traffic (BUM)` ;-) I was amused to read two different wrong expansions
for BUM ;-)
[Jorge] yeah, we should have caught it way earlier ☹ - It’s fixed now, thanks


I am sure that non SP will also use this technique, i.e., I wonder whether
s/Service Providers/Network Operators/ would be beneficial.
[Jorge] good point, changed now.


## Section 2

Rather than using "DP" in `DP - refers to the "Don't Preempt me"` should "DNP"
be more logical ?
[Jorge] maybe, but at this point with so many implementations (and debug commands showing DP), I prefer to keep it as DP. Hopefully it is ok.


## Section 3

Should RFC 8584 be formally updated as its reserved field is carved out ?

`The DP capability is supported by DF Algorithms Highest-Preference or
Lowest-Preference, and MAY be used with the default DF Algorithm or HRW
[RFC8584]` Is there any migration concern with the use of MAY ? I.e., part of
the participating routers will use the DP and the other part not => leading to
an inconsistent election result.
[Jorge] the reason why we added this was to leave the door open to use the DP capability with other DF Algorithms, but you are right that the above text is confusing, especially because the intent was not to specify how to use it for the default and HRW algorithms, but to say that the use of DP for any other algorithm is out of scope. So we changed the text to:
         The DP capability is supported
         by the Highest-Preference or Lowest-Preference DF Algorithms.
         The procedures of the "Don't Preempt" capability for other DF
         Algorithms are out of the scope of this document.



# NITS

s/tie-breakers/tiebreakers/
s/The existence of both provide/The existence of both provides/
s/achive/achieve/ ?
s/decribed/described/

'e.g.' is usually surrounded by ','
[Jorge] all fixed now