Hi Senthil, Thank you for your reply. We have noted your approval on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9785).
We now await approvals from Ali and Wen prior to moving forward with publication. Best regards, RFC Editor/kc > On Jun 2, 2025, at 12:20 PM, Senthil Sathappan (Nokia) > <senthil.sathap...@nokia.com> wrote: > > 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
