Hi Patrice, Thank you for your review and reply. We have noted your approval on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9786).
We now await approval from Edward prior to moving forward with publication. Best regards, RFC Editor/kc > On Jun 10, 2025, at 8:33 AM, Patrice Brissette (pbrisset) > <pbris...@cisco.com> wrote: > > Hi Karen, > > Sorry for being late on this one. I’m very pleased with the document. > Thank you. > > Regards, > Patrice Brissette > Distinguished Engineer > Cisco Systems > > > > From: Karen Moore <kmo...@staff.rfc-editor.org> > Date: Friday, June 6, 2025 at 13:04 > To: Luc Andre Burdet (lburdet) <lbur...@cisco.com>, Patrice Brissette > (pbrisset) <pbris...@cisco.com>, edward.leyton > <edward.ley...@verizonwireless.com>, Jorge Rabadan (Nokia) > <jorge.raba...@nokia.com>, Wen, Bin <bin_...@comcast.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>, Gunter van de Velde > (Nokia) <gunter.van_de_ve...@nokia.com>, > auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> > Subject: Re: [EXTERNAL] [auth48] AUTH48: RFC-to-be 9786 > <draft-ietf-bess-evpn-mh-pa-13> for your review > > Dear Luc, Patrice, and Edward, > > This is a friendly reminder that we await your approvals for this document. > Please review the files and let us know if there are any further changes or > if you approve the document in its current form. > > --FILES-- > The updated XML file is here: > https://www.rfc-editor.org/authors/rfc9786.xml > > The updated output files are here: > https://www.rfc-editor.org/authors/rfc9786.txt > https://www.rfc-editor.org/authors/rfc9786.pdf > https://www.rfc-editor.org/authors/rfc9786.html > > These diff files show all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9786-auth48diff.html > https://www.rfc-editor.org/authors/rfc9786-auth48rfcdiff.html (side by side) > > These diff files show all changes made to date: > https://www.rfc-editor.org/authors/rfc9786-diff.html > https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html (side by side) > > Best regards, > RFC Editor/kc > > > > On May 30, 2025, at 4:13 PM, Karen Moore <kmo...@staff.rfc-editor.org> > > wrote: > > > > Hi Bin, > > > > Thank you for your reply. We have noted your approval on the AUTH48 status > > page (https://www.rfc-editor.org/auth48/rfc9786). > > > > We now await approvals from Luc, Patrice, and Edward. > > > > Have a great weekend! > > > > Best regards, > > RFC Editor/kc > > > >> On May 30, 2025, at 12:21 PM, Wen, Bin <bin_...@comcast.com> wrote: > >> > >> Hi Karen, > >> > >> I have reviewed the document, and it looks good to me. > >> > >> Very glad to see this going thru. Thank you all! > >> > >> Bin > >> > >> > >> On 5/30/25, 3:19 PM, "Karen Moore" <kmo...@staff.rfc-editor.org > >> <mailto:kmo...@staff.rfc-editor.org>> wrote: > >> > >> > >> Hi Jorge, > >> > >> > >> Thank you for your reply. We have noted your approval on the AUTH48 status > >> page for this document > >> (https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9786__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8ki27DPY$ > >> > >> <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9786__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8ki27DPY$> > >> ). > >> > >> > >> We now await approvals from Luc, Patrice, Bin, and Edward. > >> > >> > >> Best regards, > >> RFC Editor/kc > >> > >> > >>> On May 30, 2025, at 5:01 AM, Jorge Rabadan (Nokia) > >>> <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> wrote: > >>> > >>> Hi Karen, > >>> > >>> I checked the changes and they look good to me. > >>> I approve the document for publication. > >>> > >>> Thank you for all the work, and thanks to Luc André for driving this > >>> during the last stages. > >>> > >>> Jorge > >>> > >>> From: Karen Moore <kmo...@staff.rfc-editor.org > >>> <mailto:kmo...@staff.rfc-editor.org>> > >>> Date: Thursday, May 29, 2025 at 12:04 PM > >>> To: Luc Andre Burdet (lburdet) <lbur...@cisco.com > >>> <mailto:lbur...@cisco.com>>, Patrice Brissette (pbrisset) > >>> <pbris...@cisco.com <mailto:pbris...@cisco.com>>, edward.leyton > >>> <edward.ley...@verizonwireless.com > >>> <mailto:edward.ley...@verizonwireless.com>>, Jorge Rabadan (Nokia) > >>> <jorge.raba...@nokia.com <mailto:jorge.raba...@nokia.com>>, > >>> bin_...@comcast.com<mailto:bin_...@comcast.com> <bin_...@comcast.com > >>> <mailto:bin_...@comcast.com>> > >>> Cc: rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> > >>> <rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>>, > >>> bess-...@ietf.org <mailto:bess-...@ietf.org> <bess-...@ietf.org > >>> <mailto:bess-...@ietf.org>>, bess-cha...@ietf.org > >>> <mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org > >>> <mailto:bess-cha...@ietf.org>>, slitkows.i...@gmail.com > >>> <mailto:slitkows.i...@gmail.com> > >>> <slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>>, Gunter van de > >>> Velde (Nokia) > >>> <gunter.van_de_ve...@nokia.com<mailto:gunter.van_de_ve...@nokia.com>>, > >>> auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org> > >>> <auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org>> > >>> Subject: Re: [auth48] AUTH48: RFC-to-be 9786 > >>> <draft-ietf-bess-evpn-mh-pa-13> for your review > >>> > >>> [You don't often get email from kmo...@staff.rfc-editor.org > >>> <mailto: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. > >>> > >>> > >>> > >>> Authors, > >>> > >>> Please let us know if any further updates are needed for this document or > >>> if you approve this document in its current form. We will await approvals > >>> from each author prior to publication. > >>> > >>> Best regards, > >>> RFC Editor/kc > >>> > >>>> On May 21, 2025, at 6:16 PM, Karen Moore <kmo...@staff.rfc-editor.org > >>>> <mailto:kmo...@staff.rfc-editor.org>> wrote: > >>>> > >>>> Hi Luc, > >>>> > >>>> Thank you for your reply and for the updated XML file. We have updated > >>>> our files accordingly. > >>>> > >>>> Note that we updated one instance of "ESI label extended community" to > >>>> "ESI Label Extended Community" (which will be consistent with "ESI > >>>> Label" (0x01) per RFC 7432 as well as "DF Election Extended Community"). > >>>> > >>>> --FILES-- > >>>> The updated XML file is here: > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.xml__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8xgVz6JE$ > >>>> > >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.xml__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8xgVz6JE$> > >>>> > >>>> > >>>> The updated output files are here: > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.txt__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8JQGE-Eg$ > >>>> > >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.txt__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8JQGE-Eg$> > >>>> > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.pdf__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Vk5qkis$ > >>>> > >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.pdf__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Vk5qkis$> > >>>> > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8bk0N2V0$ > >>>> > >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8bk0N2V0$> > >>>> > >>>> > >>>> These diff files show all changes made during AUTH48: > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-auth48diff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr88iV-yH0$ > >>>> > >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-auth48diff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr88iV-yH0$> > >>>> > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-auth48rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8W9ciCLE$ > >>>> > >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-auth48rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8W9ciCLE$> > >>>> (side by side) > >>>> > >>>> These diff files show all changes made to date: > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-diff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8104iKxU$ > >>>> > >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-diff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8104iKxU$> > >>>> > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8zTZGlpU$ > >>>> > >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8zTZGlpU$> > >>>> (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://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9786__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8ki27DPY$ > >>>> > >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9786__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8ki27DPY$> > >>>> > >>>> > >>>> Best regards, > >>>> RFC Editor/kc > >>>> > >>>> > >>>>> On May 20, 2025, at 9:17 AM, Luc Andre Burdet (lburdet) via > >>>>> auth48archive <auth48archive@rfc-editor.org > >>>>> <mailto:auth48archive@rfc-editor.org>> wrote: > >>>>> > >>>>> Hi Alice, > >>>>> > >>>>> I have addressed most in XML directly, with only a few comments here: > >>>>> > >>>>> DF Election extended community -> DF Election Extended Community (per > >>>>> RFC 8584) > >>>>> ESI Label Extended Community -> ESI label extended community (per RFC > >>>>> 7432) > >>>>> Wouldn’t this just swap from one inconsistent capitalisation to > >>>>> another? I will leave the final call in your hands. > >>>>> > >>>>> > >>>>> I added the T flag to the bitmap, and a reference at the end: > >>>>> <!-- [RFC9722] draft-ietf-bess-evpn-fast-df-recovery-12 companion doc > >>>>> RFC9722; in RFC Editor Queue as of 04/24/25. Updated the title to match > >>>>> the doc --> > >>>>> <reference anchor="RFC9722" > >>>>> target=https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc9722__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Ut6pKA8$ > >>>>> > >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc9722__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Ut6pKA8$> > >>>>> > > >>>>> > >>>>> > >>>>> All other changes made directly in XML. I have also reviewed the > >>>>> changes in diff > >>>>> (https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8zTZGlpU$ > >>>>> > >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8zTZGlpU$> > >>>>> ) which look good, thank you! > >>>>> > >>>>> > >>>>> Regards, > >>>>> Luc André > >>>>> > >>>>> Luc André Burdet | lbur...@cisco.com <mailto:lbur...@cisco.com> | Tel: > >>>>> +1 613 254 4814 > >>>>> > >>>>> > >>>>> From: rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> > >>>>> <rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>> > >>>>> Date: Thursday, May 15, 2025 at 16:30 > >>>>> To: Patrice Brissette (pbrisset) <pbris...@cisco.com > >>>>> <mailto:pbris...@cisco.com>>, Luc Andre Burdet (lburdet) > >>>>> <lbur...@cisco.com <mailto:lbur...@cisco.com>>, > >>>>> bin_...@comcast.com<mailto:bin_...@comcast.com> <bin_...@comcast.com > >>>>> <mailto:bin_...@comcast.com>>, edward.leyton > >>>>> <edward.ley...@verizonwireless.com > >>>>> <mailto:edward.ley...@verizonwireless.com>>,jorge.raba...@nokia.com > >>>>> <mailto:jorge.raba...@nokia.com><jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> > >>>>> Cc: rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> > >>>>> <rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>>, > >>>>> bess-...@ietf.org <mailto:bess-...@ietf.org><bess-...@ietf.org > >>>>> <mailto:bess-...@ietf.org>>, bess-cha...@ietf.org > >>>>> <mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org > >>>>> <mailto:bess-cha...@ietf.org>>, slitkows.i...@gmail.com > >>>>> <mailto:slitkows.i...@gmail.com> > >>>>> <slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>>, > >>>>> gunter.van_de_ve...@nokia.com<mailto:gunter.van_de_ve...@nokia.com> > >>>>> <gunter.van_de_ve...@nokia.com<mailto:gunter.van_de_ve...@nokia.com>>,auth48archive@rfc-editor.org > >>>>> <mailto:auth48archive@rfc-editor.org><auth48archive@rfc-editor.org > >>>>> <mailto:auth48archive@rfc-editor.org>> > >>>>> Subject: Re: AUTH48: RFC-to-be 9786 <draft-ietf-bess-evpn-mh-pa-13> for > >>>>> your review > >>>>> > >>>>> Authors, > >>>>> > >>>>> While reviewing this document during AUTH48, please resolve (as > >>>>> necessary) the following questions, which are also in the XML file. > >>>>> > >>>>> 1) <!--[rfced] Luc André, FYI, we updated your name to match > >>>>> how you updated it in RFC 9722 during AUTH48 recently. > >>>>> Please let us know if you prefer otherwise. > >>>>> --> > >>>>> > >>>>> > >>>>> 2) <!-- [rfced] FYI, we note that RFC 5306 does not mention "LDP". > >>>>> Apparently the digits were transposed, so we updated the reference > >>>>> from [RFC5306] to [RFC5036], titled "LDP Specification". > >>>>> Please let us know if this is not accurate. > >>>>> > >>>>> Original: > >>>>> b. Port-Active redundancy eliminates the need for ICCP and LDP > >>>>> [RFC5306] (e.g., VXLAN [RFC7348] or SRv6 [RFC8402] may be used in > >>>>> the network). > >>>>> > >>>>> Current: > >>>>> b. It eliminates the need for ICCP and LDP [RFC5036] (e.g., Virtual > >>>>> eXtensible Local Area Network (VXLAN) [RFC7348] or Segment > >>>>> Routing over IPv6 (SRv6) [RFC8402] may be used in the network). > >>>>> --> > >>>>> > >>>>> > >>>>> 3) <!--[rfced] The text states that one or more PEs keep the port in > >>>>> standby mode. Do one or more PEs keep the port in active mode > >>>>> as shown below? > >>>>> > >>>>> Original: > >>>>> PEs in the redundancy group leverage the DF election defined in > >>>>> [RFC8584] to determine which PE keeps the port in active mode and > >>>>> which one(s) keep it in standby mode. > >>>>> > >>>>> Perhaps: > >>>>> PEs in the redundancy group leverage the DF election defined in > >>>>> [RFC8584] to determine which PE(s) keeps the port in active mode > >>>>> and which PE(s) keeps it in standby mode. > >>>>> --> > >>>>> > >>>>> > >>>>> 4) <!-- [rfced] [RFC7432] does not mention a "Single-Active blocking > >>>>> scheme", but it does mention "Single-Active redundancy mode". Is > >>>>> an update perhaps needed to the text below? > >>>>> > >>>>> Original: > >>>>> Non-DF routers SHOULD implement a bidirectional blocking scheme > >>>>> for all traffic comparable to the Single-Active blocking scheme > >>>>> described in [RFC7432], albeit across all VLANs. > >>>>> --> > >>>>> > >>>>> > >>>>> 5) <!--[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 is currently in AUTH48 state? If so, should any text > >>>>> be added to mention that document? > >>>>> (This question also appears in RFC-to-be 9785.) > >>>>> > >>>>> Original: > >>>>> 1 1 1 1 1 1 > >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>> |D|A| |P| | > >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>> > >>>>> 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| |P| | > >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>> --> > >>>>> > >>>>> > >>>>> 6) <!--[rfced] How may we rephrase this sentence for clarity? We note > >>>>> that "DF Elected" is not used elsewhere in the document or in the > >>>>> normative references; should "Elected" perhaps be removed (option A), > >>>>> or should "election" perhaps be used instead (option B)? > >>>>> > >>>>> Also note that RFC 8584 expands "BDF" as "Backup Designated Forwarder" > >>>>> (rather than "Back-up DF Elected"); may we update this expansion > >>>>> accordingly? > >>>>> > >>>>> Original: > >>>>> The algorithm to detemine the DF Elected and Backup-DF > >>>>> Elected (BDF) at Section 3.2 of [RFC8584] is repeated > >>>>> and summarized below using only (Es) in the computation: > >>>>> > >>>>> Perhaps A: > >>>>> The algorithm used to determine the DF and Backup Designated > >>>>> Forwarder (BDF) per Section 3.2 of [RFC8584] is repeated and > >>>>> summarized below using only (Es) in the computation: > >>>>> or > >>>>> > >>>>> Perhaps B: > >>>>> The algorithm used to determine the DF and Backup Designated > >>>>> Forwarder (BDF) elections per Section 3.2 of [RFC8584] is > >>>>> repeated and summarized below using only (Es) in the computation: > >>>>> --> > >>>>> > >>>>> > >>>>> 7) <!--[rfced] In the title of Section 4.1, we added "Bits" as the "P > >>>>> and > >>>>> B bits" are described in this section. Please let us know if this > >>>>> update is not correct. > >>>>> > >>>>> Original: > >>>>> 4.1. Primary / Backup per Ethernet-Segment > >>>>> > >>>>> Current: > >>>>> 4.1. Primary/Backup Bits per Ethernet Segment > >>>>> --> > >>>>> > >>>>> > >>>>> 8) <!--[rfced] Does the remote ESI label extended community signal a > >>>>> Single-Active "procedure" or perhaps "redundancy mode"? Please > >>>>> clarify. > >>>>> > >>>>> Original: > >>>>> * The remote ESI Label Extended Community ([RFC7432]) signals > >>>>> Single-Active (Section 3) > >>>>> > >>>>> Perhaps: > >>>>> * The remote ESI label extended community [RFC7432] signals the > >>>>> Single-Active redundancy mode (Section 3). > >>>>> --> > >>>>> > >>>>> > >>>>> 9) <!-- [rfced] Terminology > >>>>> > >>>>> a) 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. > >>>>> > >>>>> Bitmap field vs. bitmap field > >>>>> [Are these different? For example, "a Bitmap (2 octets) field" vs. > >>>>> "DF Election Capabilities bitmap field"] > >>>>> > >>>>> b) We updated the text to use the form on the right for consistency > >>>>> within this document and Cluster 492 (C492). Please let us know of any > >>>>> objections. > >>>>> > >>>>> active-standby -> active/standby > >>>>> All-active -> All-Active > >>>>> DF Election -> DF election (for general use, per RFC 8584) > >>>>> DF Election extended community -> DF Election Extended Community (per > >>>>> RFC 8584) > >>>>> 'Don't Pre-empt' -> 'Don't Preempt' (per companion doc and IANA > >>>>> registry) > >>>>> ESI Label Extended Community -> ESI label extended community (per RFC > >>>>> 7432) > >>>>> Ethernet-AD per-ES -> Ethernet A-D per ES (per RFC 8584) > >>>>> Port Mode DF Election -> Port Mode Designated Forwarder Election (per > >>>>> IANA) > >>>>> Single-active -> Single-Active > >>>>> --> > >>>>> > >>>>> > >>>>> 10) <!-- [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. > >>>>> > >>>>> Customer Equipment (CE) > >>>>> Cyclic Redundancy Check (CRC) > >>>>> Media Access Control (MAC) > >>>>> Neighbor Discovery (ND) > >>>>> Segment Routing over IPv6 (SRv6) > >>>>> Virtual Routing and Forwarding (VRF) > >>>>> Virtual Private Wire Service (VPWS) > >>>>> Virtual eXtensible Local Area Network (VXLAN) > >>>>> > >>>>> b) For consistency within the RFC series and C492, we updated > >>>>> the document to use the form on the right. Please review. > >>>>> > >>>>> AC-Influenced Designated Forwarder Election (AC-DF) -> > >>>>> AC-Influenced DF (AC-DF) election (per RFC 8584) > >>>>> > >>>>> Interchassis Communication Protocol (ICCP) -> > >>>>> Inter-Chassis Communication Protocol (ICCP) > >>>>> > >>>>> Multi-Chassis Link Aggregation Group (MC-LAG) -> > >>>>> Multi-Chassis Link Aggregation (MC-LAG) group > >>>>> --> > >>>>> > >>>>> > >>>>> 11) <!-- [rfced] Please review the "Inclusive Language" portion of the > >>>>> online > >>>>> Style Guide > >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/<https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/>*inclusive_language__;Iw!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8AxX4rCs$ > >>>>> > > >>>>> and let us know if any changes are needed. Updates of this nature > >>>>> typically > >>>>> result in more precise language, which is helpful for readers. > >>>>> > >>>>> For example, please consider whether the following should be updated: > >>>>> > >>>>> - black-holing > >>>>> --> > >>>>> > >>>>> > >>>>> Thank you. > >>>>> > >>>>> RFC Editor/kc/ar > >>>>> > >>>>> > >>>>> On May 15, 2025, rfc-edi...@rfc-editor.org > >>>>> <mailto: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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Mv-KgyA$ > >>>>> > >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Mv-KgyA$> > >>>>> ). > >>>>> > >>>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8CxPiKUk$ > >>>>> > >>>>> <https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8CxPiKUk$> > >>>>> ). > >>>>> > >>>>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8rlg1KH0$ > >>>>> > >>>>> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8rlg1KH0$> > >>>>> >. > >>>>> > >>>>> * 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 <mailto: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 <mailto: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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8hTA4ur0$<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8hTA4ur0$> > >>>>> > >>>>> > >>>>> * The archive itself: > >>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8oCO2e9Q$<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8oCO2e9Q$> > >>>>> > >>>>> > >>>>> * 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 <mailto: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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.xml__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8xgVz6JE$ > >>>>> > >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.xml__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8xgVz6JE$> > >>>>> > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8bk0N2V0$ > >>>>> > >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8bk0N2V0$> > >>>>> > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.pdf__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Vk5qkis$ > >>>>> > >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.pdf__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Vk5qkis$> > >>>>> > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.txt__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8JQGE-Eg$ > >>>>> > >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.txt__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8JQGE-Eg$> > >>>>> > >>>>> > >>>>> Diff file of the text: > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-diff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8104iKxU$ > >>>>> > >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-diff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8104iKxU$> > >>>>> > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8zTZGlpU$ > >>>>> > >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8zTZGlpU$> > >>>>> (side by side) > >>>>> > >>>>> Diff of the XML: > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-xmldiff1.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8MXnFziY$ > >>>>> > >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-xmldiff1.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8MXnFziY$> > >>>>> > >>>>> > >>>>> > >>>>> Tracking progress > >>>>> ----------------- > >>>>> > >>>>> The details of the AUTH48 status of your document are here: > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9786__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8ki27DPY$ > >>>>> > >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9786__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8ki27DPY$> > >>>>> > >>>>> > >>>>> Please let us know if you have any questions. > >>>>> > >>>>> Thank you for your cooperation, > >>>>> > >>>>> RFC Editor > >>>>> > >>>>> -------------------------------------- > >>>>> RFC9786 (draft-ietf-bess-evpn-mh-pa-13) > >>>>> > >>>>> Title : EVPN Port-Active Redundancy Mode > >>>>> Author(s) : P. Brissette, LA. Burdet, Ed., B. Wen, E. Leyton, J. Rabadan > >>>>> WG Chair(s) : Matthew Bocci, Stephane Litkowski, Zhaohui (Jeffrey) Zhang > >>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > >>>>> <rfc9786-01-from-0.diff.html><rfc9786-01.txt><rfc9786-01.xml>-- > >>>>> auth48archive mailing list -- auth48archive@rfc-editor.org > >>>>> <mailto:auth48archive@rfc-editor.org> > >>>>> To unsubscribe send an email to auth48archive-le...@rfc-editor.org > >>>>> <mailto:auth48archive-le...@rfc-editor.org> > >>>> > >>> > >> > >> > >> > >> > >> > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
