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