Hi Jorge, Thank you for your reply. We have noted your approval on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9786).
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> > 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> > Date: Thursday, May 29, 2025 at 12:04 PM > 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>, bin_...@comcast.com <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: [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. 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> > > 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://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) > > > > 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/rfc9786 > > > > Best regards, > > RFC Editor/kc > > > > > >> On May 20, 2025, at 9:17 AM, Luc Andre Burdet (lburdet) via auth48archive > >> <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://www.rfc-editor.org/info/rfc9722> > >> > >> > >> All other changes made directly in XML. I have also reviewed the changes > >> in diff (https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html) which > >> look good, thank you! > >> > >> > >> Regards, > >> Luc André > >> > >> Luc André Burdet | lbur...@cisco.com | Tel: +1 613 254 4814 > >> > >> > >> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > >> Date: Thursday, May 15, 2025 at 16:30 > >> To: Patrice Brissette (pbrisset) <pbris...@cisco.com>, Luc Andre Burdet > >> (lburdet) <lbur...@cisco.com>, bin_...@comcast.com <bin_...@comcast.com>, > >> edward.leyton <edward.ley...@verizonwireless.com>, > >> jorge.raba...@nokia.com<jorge.raba...@nokia.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_ve...@nokia.com > >> <gunter.van_de_ve...@nokia.com>,auth48archive@rfc-editor.org<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://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. > >> > >> 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 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/rfc9786.xml > >> https://www.rfc-editor.org/authors/rfc9786.html > >> https://www.rfc-editor.org/authors/rfc9786.pdf > >> https://www.rfc-editor.org/authors/rfc9786.txt > >> > >> Diff file of the text: > >> https://www.rfc-editor.org/authors/rfc9786-diff.html > >> https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html (side by side) > >> > >> Diff of the XML: > >> https://www.rfc-editor.org/authors/rfc9786-xmldiff1.html > >> > >> > >> Tracking progress > >> ----------------- > >> > >> The details of the AUTH48 status of your document are here: > >> https://www.rfc-editor.org/auth48/rfc9786 > >> > >> 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 > >> 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
