Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!--[rfced] Please note that the title has been updated as follows.
The abbreviation has been expanded per Section 3.6 of RFC 7322
("RFC Style Guide"). Please review.
Original:
Preference-based EVPN DF Election
Current:
Preference-Based EVPN Designated Forwarder (DF) Election
-->
2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
3) <!-- [rfced] We note that the term "Default Designated Forwarder
Algorithm" does not appear in RFC 7432 (it does use "Designated
Forwarder"). Is an update needed to the term, reference, or
placement of the citation?
Original:
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 user-controlled method is required.
-->
4) <!--[rfced] DP vs. D
a) In Section 2, we note that the description for "DP" includes "(me)";
however, "(me)" is not used elsewhere in the document or in the
"DF Election Capabilities" registry
<https://www.iana.org/assignments/bgp-extended-communities>.
Should it be removed?
Current:
DP: Refers to the "Don't Preempt" (me) capability in the
Designated Forwarder Election extended community.
Perhaps:
DP: Refers to the "Don't Preempt" capability in the
DF Election Extended Community.
b) Section 2 says "DP" refers to the "Don't Preempt" capability, but
Section 3 says "DP" refers to the "D bit" or "'Don't Preempt' bit".
There are also 11 instances of "DP bit" and "DP capability". Are the
'Don't Preempt' bit and "Don't Preempt" capability the same or
different? Please let us know if/how we can make these consistent
within the text and IANA registry.
Current (in the running text):
"Don't Preempt" capability vs.
'Don't Preempt' bit vs.
DP capability vs.
DP bit vs.
D bit
In the DF Election Capabilities Registry:
Bit Name Reference
- - - - - - - - - - - - - - - - - - - - - - -
0 D (Don't Preempt) Capability RFC XXXX
-->
5) <!--[rfced] Should "route type 1" be "Route Type (1 octet)"
per RFC 7432 or as "Route Type 1" per the description of
"Ethernet A-D per EVI route" in RFC 8584 (which updates RFC 7432)?
Also, may we move the citation to the end of the sentence as we note that
it refers to both "Route Type 1" and "Auto-Discovery".
Original:
Ethernet A-D per EVI route - refers to [RFC7432] route type 1 or
Auto-Discovery per EVPN Instance route.
Perhaps:
Ethernet A-D per EVI route: Refers to Route Type 1 or
Auto-Discovery per the EVPN Instance route [RFC7432].
-->
6) <!--[rfced] Is it correct that the default DF algorithm is the same
as the "modulus-based algorithm as per [RFC7432]"? If so,
even though this text currently matches RFC 8584, would it be
more clear to use "i.e.," or another phrase to indicate that
these are equivalent (rather than alternatives)?
Original:
Alg 0 - Default Designated Forwarder Election algorithm, or
modulus-based algorithm as per [RFC7432].
Perhaps:
Alg 0 - Default Designated Forwarder Election algorithm, i.e.,
the modulus-based algorithm as per [RFC7432].
For comparison, from RFC 8584:
- Type 0: Default DF election algorithm, or modulus-based
algorithm as defined in [RFC7432].
-->
7) <!--[rfced] Should Figure 2 be updated to show the T bit as
defined in RFC-to-be 9722 (draft-ietf-bess-evpn-fast-df-recovery-12),
which also update RFC 8584 and is currently in AUTH48 state? If so,
should any text be added to mention that document?
Current:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Perhaps:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A| |T| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-->
8) <!--[rfced] FYI: We removed "described by this document" in the
following entry (in Section 3) to avoid redundancy as the
description points to Section 4.1 of this document. Please
let us know of any objections.
Original:
* Designated Forwarder (DF) Preference (described in this document):
defines a 2-octet value that indicates the PE preference to become
the Designated Forwarder in the Ethernet Segment, as described in
Section 4.1.
Current:
* Designated Forwarder (DF) Preference: Defines a 2-octet value that
indicates the PE preference to become the Designated Forwarder in
the Ethernet Segment, as described in Section 4.1.
-->
9) <!--[rfced] Is "DF Algorithms" intended to be singular possessive
(option A) or plural (option B)? Please let us know how we may
update this text for clarity.
Original:
The Designated Forwarder Preference field is specific
to DF Algorithms Highest-Preference and Lowest-Preference,
and this document does not define any meaning for other
algorithms.
Perhaps A:
The Designated Forwarder Preference field is specific
to a DF Algorithm's Highest-Preference and Lowest-Preference,
and this document does not define any meaning for other
algorithms.
Perhaps B:
The Designated Forwarder Preference field is specific
to Highest-Preference and Lowest-Preference DF Algorithms,
and this document does not define any meaning for other
algorithms.
-->
10) <!--[rfced] Section 4.1: For readability, may spaces be added after
commas in the parameter lists (as shown in Option A)? If so, other
instances will be updated accordingly; one sample is below.
In addition, would you like to format the examples as lists (Option B)?
Original:
a. vES1 and vES2 are now configurable with three optional parameters
that are signaled in the Designated Forwarder Election extended
community. These parameters are the Preference, Preemption
option (or "Don't Preempt" option) and DF Algorithm. We will
represent these parameters as (Pref,DP,Alg). For instance, vES1
(Pref,DP,Alg) is configured as (500,0,Highest-Preference) in PE1,
and (255,0,Highest-Preference) in PE2. vES2 is configured as
(100,0,Highest-Preference), (200,0,Highest-Preference) and
(300,0,Highest-Preference) in PE1, PE2 and PE3 respectively.
Option A:
a. vES1 and vES2 are now configurable with three optional parameters
that are signaled in the DF Election Extended Community. These
parameters are the Preference, Preemption (or "Don't Preempt")
option, and DF Algorithm. We will represent these parameters as
(Pref, DP, Alg). For instance, vES1 (Pref, DP, Alg) is
configured as (500, 0, Highest-Preference) in PE1, and (255, 0,
Highest-Preference) in PE2. vES2 is configured as (100, 0,
Highest-Preference), (200, 0, Highest-Preference) and (300, 0,
Highest-Preference) in PE1, PE2, and PE3, respectively.
Option B:
a. vES1 and vES2 are now configurable with three optional parameters
that are signaled in the DF Election Extended Community. These
parameters are the Preference, Preemption (or "Don't Preempt")
option, and DF Algorithm. We will represent these parameters as
(Pref, DP, Alg). For instance, vES1 (Pref, DP, Alg) is
configured as:
(500, 0, Highest-Preference) in PE1,
(255, 0, Highest-Preference) in PE2.
vES2 is configured as
(100, 0, Highest-Preference) in PE1,
(200, 0, Highest-Preference) in PE2, and
(300, 0, Highest-Preference) in PE3.
Sample from Section 4.3 if the space is added:
PE3 will select PE2 as the
Highest-PE over PE1, because when comparing (Pref, DP,
PE-IP), (200, 1, PE2-IP) wins over (100, 1, PE1-IP). PE3 will
select PE1 as the Lowest-PE over PE2, because
(100, 1, PE1-IP) wins over (200, 1, PE2-IP).
-->
11) <!--[rfced] FYI: We removed the citation from the title of Section 4.2
as RFC 7432 is cited within the first sentence.
Original:
4.2. Use of the Highest-Preference or Lowest-Preference algorithm
in [RFC7432] Ethernet Segments
Current:
4.2. Use of the Highest-Preference or Lowest-Preference Algorithm
in Ethernet Segments
-->
12) <!--[rfced] FYI, we added a space after the comma
after "Ethernet Tag-range" for consistency with the example
in this sentence. Please let us know if you prefer otherwise.
Original:
* In addition, assuming VLAN-based service interfaces and that the
PEs are attached to all Ethernet Tags in the range 1-4000, both
PE1 and PE2 may be configured with (Ethernet Tag-range,Lowest-
Preference), e.g., (2001-4000, Lowest-Preference).
Current:
* In addition, assuming VLAN-based service interfaces and that the
PEs are attached to all Ethernet Tags in the range 1-4000, both
PE1 and PE2 may be configured with (Ethernet Tag-range, Lowest-
Preference), e.g., (2001-4000, Lowest-Preference).
-->
13) <!--[rfced] In Section 4.3, item (5) lists the steps PE3 will
take. The first two bullet points work off of the introductory
sentence; however, the 3rd and 4th bullet points do not. To
make the list parallel, may we rephrase the 3rd and 4th
bullet points as shown below?
Original:
PE3 will then:
[...]
* Note that, a PE will always send its DP capability set to zero
as long as the advertised Pref is the 'in-use' operational
Pref (as opposed to the 'administrative' Pref).
* This Ethernet Segment route update sent by PE3, with
(200,0,PE3-IP), will not cause any Designated Forwarder
switchover for any Ethernet Tag. PE2 will continue being
Designated Forwarder for Ethernet Tag-1. This is because
the DP bit will be used as a tiebreaker in the Designated
Forwarder election. That is, if a PE has two candidate PEs
with the same Pref, it will pick the one with DP=1. There are
no Designated Forwarder changes for Ethernet Tag-2 either.
Perhaps:
PE3 will then:
[...]
* Send its DP capability set to zero, as long as the advertised
Pref is the 'in-use' operational Pref (as opposed to the
'administrative' Pref).
* Continue to be the Designated Forwarder for Ethernet Tag-1.
The Ethernet Segment route update sent by PE3, with
(200,0,PE3-IP), will not cause any Designated Forwarder
switchover for any Ethernet Tag. This is because the
DP bit will be used as a tiebreaker in the Designated
Forwarder election. That is, if a PE has two candidate PEs
with the same Pref, it will pick the one with DP=1. There
are no Designated Forwarder changes for Ethernet Tag-2 either.
-->
14) <!--[rfced] FYI, this sentence was updated for readability (rephrased
the opening clause; changed "and impact" to "to impact"). Please
review whether it conveys the intended meaning.
Original:
With Highest-Preference or Lowest-Preference as DF Algorithm,
an attacker may change the configuration of the Preference
value on a PE and Ethernet Segment, and impact the traffic
going through that PE and Ethernet Segment.
Current:
When the DF Algorithm is Highest-Preference or Lowest-Preference,
an attacker may change the configuration of the Preference
value on a PE and Ethernet Segment to impact the traffic
going through that PE and Ethernet Segment.
-->
15) <!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->
16) <!-- [rfced] Terminology
a) May we update the following terms to the form on the right for
consistency within the document and Cluster 492 (C492)?
Designated Forwarder Election vs.
Designated Forwarder election -> DF election
Designated Forwarder Election Algorithm vs.
Designated Forwarder Election algorithm vs.
Designated Forwarder election algorithm -> DF election algorithm
Default Designated Forwarder Election Algorithm vs.
Default Designated Forwarder Election algorithm vs.
default Designated Forwarder election algorithm
-> default DF election algorithm (per RFC 8584)
b) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.
Default DF Algorithm vs. Default Algorithm vs. Default algorithm
[Note: Should "Default" perhaps be lowercase? Should "DF" be
removed or added for consistency (also see (c) below)?
Perhaps: "default DF algorithm" (per RFC 8584)
Preference value vs. preference value
c) We note "Highest-Preference and/or Lowest-Preference DF Algorithm(s)" (with
"DF")
vs. "Highest-Preference and/or Lowest-Preference Algorithm(s)" (without "DF").
Per the "DF Alg" registry
<https://www.iana.org/assignments/bgp-extended-communities>,
these terms appear without "DF". Should "DF" be removed from these
terms in the document or should "DF" be added to the terms in this
document and in the registry for consistency?
Per the "DF Alg" registry:
2 Highest-Preference Algorithm
3 Lowest-Preference Algorithm
A few examples that vary in the text (see the document for more examples):
The DP capability is supported by the Highest-Preference or
Lowest-Preference DF Algorithms.
The procedures of the "Don't Preempt" capability for the
Highest-Preference and Lowest-Preference DF Algorithms are
described in Section 4.1.
The Highest-Preference and Lowest-Preference Algorithms MAY be used
along with the AC-DF capability.
The document also describes how a local policy can override the
Highest-Preference or Lowest-Preference Algorithms for a range of
Ethernet Tags in the Ethernet Segment.
d) We made the following changes for consistency (the document now uses the
form on the right). Please let us know if any further changes are needed.
Acknowledgments -> Acknowledgements (for consistency with C492)
all-active -> All-Active (for consistency with C492)
Broadcast Domain -> broadcast domain (for consistency with C492)
Designated Forwarder Election Extended Community and
Designated Forwarder Election extended community ->
DF Election Extended Community (per IANA, RFC 8584, and C492)
Ethernet segment -> Ethernet Segment
Highest-Preference algorithm -> Highest-Preference Algorithm (per IANA)
Lowest-Preference algorithm -> Lowest-Preference Algorithm (per IANA)
single-active -> Single-Active (for consistency with C492)
-->
17) <!-- [rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
- Operations, Administration, and Maintenance (OAM)
- VLAN ID (VID)
b) For consistency (within the RFC series and C492), we
updated the document to use the forms on the right.
Please let us know if you prefer otherwise.
AC-Influenced Designated Forwarder Election (AC-DF) ->
AC-Influenced DF (AC-DF) election (per RFC 8584)
ENNI: Ethernet Network to Network Interface ->
ENNI: External Network-Network Interface
(to match usage in RFC-to-be 9784)
-->
18) <!--[rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
Thank you.
RFC Editor/kc/ar
On May 15, 2025, rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2025/05/15
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9785.xml
https://www.rfc-editor.org/authors/rfc9785.html
https://www.rfc-editor.org/authors/rfc9785.pdf
https://www.rfc-editor.org/authors/rfc9785.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9785-diff.html
https://www.rfc-editor.org/authors/rfc9785-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9785-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9785
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9785 (draft-ietf-bess-evpn-pref-df-13)
Title : Preference-Based EVPN Designated Forwarder (DF) Election
Author(s) : J. Rabadan, Ed., S. Sathappan, W. Lin, J. Drake, A. Sajassi
WG Chair(s) : Matthew Bocci, Stephane Litkowski, Zhaohui (Jeffrey) Zhang
Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
