Dear Ali, Thank you for your reply. We have noted your approval of this document on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9785).
We now have all necessary approvals and will move this document forward in the publication process along with RFCs-to-be 9784 and 9786 when they have completed AUTH48. Thank you to all for your time! Best regards, RFC Editor/kc > On Jun 11, 2025, at 2:17 PM, Ali Sajassi (sajassi) > <sajassi=40cisco....@dmarc.ietf.org> wrote: > > Hi Karen, > > I have gone over the changes and they look good to me. I approve the > publication of this document. > > Regards, > Ali > > From: Karen Moore <kmo...@staff.rfc-editor.org> > Date: Tuesday, June 10, 2025 at 6:39 PM > To: Senthil Sathappan (Nokia) <senthil.sathap...@nokia.com>, > je_dr...@yahoo.com<je_dr...@yahoo.com>, Jorge Rabadan (Nokia) > <jorge.raba...@nokia.com>, w...@juniper.net<w...@juniper.net>, Ali Sajassi > (sajassi) <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] AUTH48: RFC-to-be 9785 > <draft-ietf-bess-evpn-pref-df-13> for your review > > 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 athttps://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
