Hi Jorge,
Thank you for your review and reply. We have updated our files accordingly.
Please review the updates and let us know if any further changes are needed.
Note that we have a few clarifications below.
1) Please review the term updates carefully throughout the document and let us
know if any further changes are needed. To summarize, the document now reflects
the following forms:
DF algorithm*
DF election
DF election algorithm
default DF algorithm
default DF election algorithm
"Don't Preempt” Capability
preference value
Highest-Preference and/or Lowest-Preference Algorithm(s)
* We thought that instances of “DF Algorithm” should be “DF algorithm” for
consistency; however, if that is not correct, please let us know and we will
revert the changes.
2) In Section 4.3, we updated the following sentence so that it will parse with
the introductory sentence:
Suggested:
PE3 will then:
* Does not trigger any Designated Forwarder changes for Ethernet Tag-1.
Current:
PE3 will then:
* Not trigger any Designated Forwarder changes for Ethernet Tag-1.
— FILES —
The updated XML file is here:
https://www.rfc-editor.org/authors/rfc9785.xml
The updated output files are here:
https://www.rfc-editor.org/authors/rfc9785.txt
https://www.rfc-editor.org/authors/rfc9785.pdf
https://www.rfc-editor.org/authors/rfc9785.html
These diff files show all changes made during AUTH48:
https://www.rfc-editor.org/authors/rfc9785-auth48diff.html
https://www.rfc-editor.org/authors/rfc9785-auth48rfcdiff.html (side by side)
These diff files show all changes made to date:
https://www.rfc-editor.org/authors/rfc9785-diff.html
https://www.rfc-editor.org/authors/rfc9785-rfcdiff.html (side by side)
Note that it may be necessary for you to refresh your browser to view the most
recent version. Please review the document carefully to ensure satisfaction as
we do not make changes once it has been published as an RFC.
Please contact us with any further updates or with your approval of the
document in its current form. We will await approvals from each author prior
to moving forward in the publication process.
For the AUTH48 status of this document, please see:
https://www.rfc-editor.org/auth48/rfc9785
Best regards,
RFC Editor/kc
> On May 30, 2025, at 5:12 AM, Jorge Rabadan (Nokia) via auth48archive
> <auth48archive@rfc-editor.org> wrote:
>
> Dear editor,
>
> Please find my comments in-line below with [jorge].
>
> Thank you!
> Jorge
>
> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>
> Date: Thursday, May 15, 2025 at 1:29 PM
> To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, Senthil Sathappan
> (Nokia) <senthil.sathap...@nokia.com>, w...@juniper.net <w...@juniper.net>,
> je_dr...@yahoo.com<je_dr...@yahoo.com>, saja...@cisco.com <saja...@cisco.com>
> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, bess-...@ietf.org
> <bess-...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>,
> slitkows.i...@gmail.com <slitkows.i...@gmail.com>, andrew-i...@liquid.tech
> <andrew-i...@liquid.tech>,
> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org>
> Subject: Re: AUTH48: RFC-to-be 9785 <draft-ietf-bess-evpn-pref-df-13> for
> your review
>
>
> 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.
>
>
>
> 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
> -->
>
> [jorge] the change is good, thanks.
>
>
>
>
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the title) for use on https://www.rfc-editor.org/search. -->
>
> [jorge] Highest-Preference, Lowest-Preference, Non-Revertive, Don’t Preempt,
> Preemption
>
>
>
>
> 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.
> -->
>
> [jorge] The term “default designated forwarder algorithm" is introduced in
> RFC8584 as the algorithm used in RFC7432, hence the reference. But it is
> probably more correct to use RFC8584 for both. That is:
>
> OLD:
> 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.
>
> NEW:
> While the Default Designated Forwarder Algorithm 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-extended-communities&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cf873d1f8c8b244f57fb208dd93ef323e%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638829377775963302%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7Pl96EnxeOYry9WcOFmEj1pj5NIjbPJNs6XOLEGFEiE%3D&reserved=0>.
> 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.
>
> [jorge] I agree with the suggestion.
>
>
>
> 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
> -->
>
> [jorge] We can use “Don’t Preempt Capability” everywhere, except in section
> 3. Section 3 describes what “bit” of the extended community indicates the
> Don’t Preempt Capability when set. We can make this change in section 3 to
> clarify:
>
> OLD:
>
> Bit 0 (corresponds to Bit 24 of the DF Election Extended Community, and it is
> defined by this document): The D bit, or 'Don't Preempt' bit ("DP"
> hereafter), determines if the PE advertising the Ethernet Segment route
> requests the remote PEs in the Ethernet Segment to not preempt it as the
> Designated Forwarder.
>
> NEW:
>
> Bit 0 (corresponds to Bit 24 of the DF Election Extended Community, and it is
> defined by this document): The D bit, or 'Don't Preempt' Capability,
> determines if the PE advertising the Ethernet Segment route requests the
> remote PEs in the Ethernet Segment to not preempt it as the Designated
> Forwarder.
>
>
>
>
> 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].
> -->
>
> [jorge] counter proposal (remove “the”):
>
> OLD:
> Ethernet A-D per EVI route - refers to [RFC7432] route type 1 or
> Auto-Discovery per EVPN Instance route.
>
> NEW:
> Ethernet A-D per EVI route: Refers to Route Type 1 or
> Auto-Discovery per 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].
> -->
>
> [jorge] I agree with the suggestion.
>
>
>
>
> 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| |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> -->
>
> [jorge] I prefer not to add “T”. Bit A is added here because the capability
> that represents is used later in the text. It is not necessary to show here
> other capabilities that exist in other specs.
>
>
>
>
> 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.
> -->
>
> [jorge] I agree with the suggestion.
>
>
>
>
> 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.
> -->
>
> [jorge] use “Perhaps B”, please
>
>
>
>
> 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.
>
> [jorge] I like Option B, please use it.
>
>
>
> 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).
> -->
>
> [jorge] I agree with the suggestion
>
>
>
>
> 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
> -->
>
> [jorge] I agree with the suggestion
>
>
>
>
> 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).
> -->
>
> [jorge] I agree with the suggestion
>
>
>
>
> 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.
> -->
>
> [jorge] the last bullet in the proposal is not correct. Suggestion:
>
> OLD:
> 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.
>
> NEW:
> 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).
>
> * Does not trigger any Designated Forwarder changes 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.
> -->
>
> [jorge] I agree with the suggestion
>
>
>
>
> 15) <!-- [rfced] Would you like the references to be alphabetized
> or left in their current order?
> -->
>
> [jorge] alphabetized, please
>
>
>
>
> 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)
>
> [jorge] I’m ok with the suggestion
>
>
>
> 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)
>
> [jorge] I’m ok with “default DF algorithm”
>
>
>
> Preference value vs. preference value
>
> [jorge] “preference value” is ok
>
>
>
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-extended-communities&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cf873d1f8c8b244f57fb208dd93ef323e%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638829377775995078%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pvrP5ew%2FSf%2FPA4PGI4l0ngMiOGaXiPd2oo7w%2F1AMgTs%3D&reserved=0>,
> 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.
>
> [jorge] I agree with the suggestion of removing “DF” from those terms and be
> consistent with the DF Alg registry
>
>
>
>
>
> 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)
> -->
>
> [jorge] I agree with the suggestions
>
>
>
>
> 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)
>
> [jorge] I agree with the suggestion
>
>
>
> 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)
> -->
>
> [jorge] I agree with the suggestions
>
>
>
>
> 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.
> -->
>
> [jorge] I checked and I didn’t see any term that we should replace
>
> Thank you!
>
> Jorge
>
>
>
>
> 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
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
