Karen, I approve the publication. Thank you very much for your work on this. Senthil.
-----Original Message----- From: Karen Moore <kmo...@staff.rfc-editor.org> Sent: Monday, June 2, 2025 12:12 PM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>; Senthil Sathappan (Nokia) <senthil.sathap...@nokia.com>; je_dr...@yahoo.com; saja...@cisco.com; w...@juniper.net Cc: rfc-edi...@rfc-editor.org; bess-...@ietf.org; bess-cha...@ietf.org; slitkows.i...@gmail.com; andrew-i...@liquid.tech; auth48archive@rfc-editor.org Subject: Re: [auth48] AUTH48: RFC-to-be 9785 <draft-ietf-bess-evpn-pref-df-13> for your review [You don't often get email from kmo...@staff.rfc-editor.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] 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. Dear Jorge and John, Thank you for your replies. We have noted your approvals on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9785). We now await approvals from Ali, Senthil, and Wen prior to moving forward with the publication process. Best regards, RFC Editor/kc > On Jun 2, 2025, at 7:35 AM, John Drake <je_drake=40yahoo....@dmarc.ietf.org> > wrote: > > > Karen, > > I approve publication. Very nice work. > > Thanks, > > John > On Jun 2, 2025, at 5:02 AM, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > wrote: > > Hi Karen, > > I’m good with your points 1) and 2) below. > > It looks good to me now. I approve the document for publication. > > Thank you very much for your work on this. > Jorge > > > From: Karen Moore <kmo...@staff.rfc-editor.org> > Date: Friday, May 30, 2025 at 4:12 PM > To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, > je_dr...@yahoo.com<je_dr...@yahoo.com>, Senthil Sathappan (Nokia) > <senthil.sathap...@nokia.com>, saja...@cisco.com <saja...@cisco.com>, > w...@juniper.net <w...@juniper.net> > 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] 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. > > > > 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://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. > > > > [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://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. > > > > [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
