Dear Ali and Wen, A friendly reminder that we await your approvals for this document.
Note that we updated “multi-homed” and “multi-homing” to “multihomed” and “multihoming” for consistency with RFC-to-be 9784 and the RFC Series. — 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) Best regards, RFC Editor/kc > On Jun 2, 2025, at 5:01 PM, Karen Moore <kmo...@staff.rfc-editor.org> wrote: > > 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
