Ali and *Rick, Thank you for providing alternate email address for Rick. We have updated Rick’s affliction and email in the document accordingly.
*Rick, if you have missed any AUTH48 correspondence for this document, please visit https://mailarchive.ietf.org/arch/search/?q=rfc9784. Note that we currently await approvals from Rick and John and replies to 3 outstanding questions. --FILES-- The updated XML file is here: https://www.rfc-editor.org/authors/rfc9784.xml The updated output files are here: https://www.rfc-editor.org/authors/rfc9784.txt https://www.rfc-editor.org/authors/rfc9784.pdf https://www.rfc-editor.org/authors/rfc9784.html These diff files show all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9784-auth48diff.html https://www.rfc-editor.org/authors/rfc9784-auth48rfcdiff.html (side by side) These diff files show all changes made to date: https://www.rfc-editor.org/authors/rfc9784-diff.html https://www.rfc-editor.org/authors/rfc9784-rfcdiff.html (side by side) Best regards, RFC Editor/kc > On Jun 16, 2025, at 12:59 PM, Ali Sajassi (sajassi) <saja...@cisco.com> wrote: > > Hi karen, > > Rick’s email is: rick_sch...@outlook.com > Please change his designation to “Independent” from “Verizon” > > Thanks, > Ali > > From: Karen Moore <kmo...@staff.rfc-editor.org> > Date: Monday, June 16, 2025 at 12:38 PM > To: Ali Sajassi (sajassi) <saja...@cisco.com>, jdr...@juniper.net > <jdr...@juniper.net>, jorge.raba...@nokia.com <jorge.raba...@nokia.com>, > Patrice Brissette (pbrisset) <pbris...@cisco.com>, richard.sch...@verizon.com > <richard.sch...@verizon.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>, > laburdet.i...@gmail.com <laburdet.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 9784 > <draft-ietf-bess-evpn-virtual-eth-segment-19> for your review > > Authors, > > We have received a failed delivery message for Richard > (richard.sch...@verizon.com). Does anyone happen to have an alternate email > address for Richard? > > Thanks, > RFC Editor/kc > > > > On Jun 16, 2025, at 11:51 AM, Karen Moore <kmo...@staff.rfc-editor.org> > > wrote: > > > > Hi Ali, > > > > Thank you for the clarifications (we have left “PBB-EVPN” singular) . We > > now await responses to the three questions below as well as approvals from > > John and Richard. > > > > 1) Please let us know how we may update the title of Figure 1 with “SH” > > expanded (perhaps A or B?): > > > >>> Ali> single-homed > > > > > > Original: > > Figure 1: A Dual-Homed Device/Network (Both SA/AA) and SH on the Same ENNI > > > > Current: > > Figure 1: A Dual-Homed Device/Network (Both SA/AA) and Single-Homed on > > the Same ENNI > > > > Perhaps A: > > Figure 1: A Dual-Homed Device/Network (Both SA/AA) That is Single-Homed > > on the Same ENNI > > > > Perhaps B: > > Figure 1: A Dual-Homed and Single-Homed Device/Network (Both SA/AA) on the > > Same ENNI > > > > … > > 2) In Section 4.1, is “ES-Import extended community" the same as "ES-Import > > Route Target extended community"? > > If so, should it be updated, or is this short form of the name sufficiently > > clear? (It seems to be "ES-Import Route Target" in > > <https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn> > > and in RFC-to-be 9786). > > > > Current: > > When a PE discovers the vESI or is configured with the vESI > > associated with its attached vES, it advertises an ES route > > with the associated ES-Import extended community attribute. > > > > Perhaps: > > When a PE discovers the vESI or is configured with the vESI > > associated with its attached vES, it advertises an ES route > > with the associated ES-Import Route Target extended community > > attribute. > > > > 3) Please confirm if any key words are desired. > > > >> <!-- [rfced] Please insert any keywords (beyond those that appear in > >> the title) for use on https://www.rfc-editor.org/search. > >> --> > > > > > > > > Best regards, > > RFC Editor/kc > > > > > >> On Jun 15, 2025, at 10:09 PM, Ali Sajassi (sajassi) <saja...@cisco.com> > >> wrote: > >> > >> Hi Karen, > >> > >> Please refer to my comments inline marked with Ali>> > >> > >> From: Karen Moore <kmo...@staff.rfc-editor.org> > >> Date: Tuesday, June 10, 2025 at 6:21 PM > >> To: Ali Sajassi (sajassi) <saja...@cisco.com>, > >> jorge.raba...@nokia.com<jorge.raba...@nokia.com>, > >> richard.sch...@verizon.com<richard.sch...@verizon.com>, Ali Sajassi > >> (sajassi) <saja...@cisco.com>, Patrice Brissette (pbrisset) > >> <pbris...@cisco.com> > >> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, > >> jdr...@juniper.net <jdr...@juniper.net>, bess-...@ietf.org > >> <bess-...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, > >> laburdet.i...@gmail.com <laburdet.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 9784 > >> <draft-ietf-bess-evpn-virtual-eth-segment-19> for your review > >> > >> Dear Ali, Jorge, and Patrice, > >> > >> Thank you for your replies. We have updated our files accordingly (see > >> the files below). We have marked approvals for Ali and Jorge; however, > >> please note that we have some follow-up questions. > >> > >> 1) We updated the title with “PBB-EVPN” expanded because “PBB” is not > >> marked as a well-known term (see > >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list). Please let > >> us know if the following update is correct or if you prefer otherwise > >> (should “Provider Backbone Bridge” be singular or plural here?). > >> > >>> Ali> I would prefer “Virtual Ethernet Segments for EVPN and PBB-EVPN” for > >>> the title > >> > >> > >> Current: > >> Virtual Ethernet Segments for EVPN and Provider Backbone Bridge EVPN > >> > >> Ali>> That’s fine > >> > >> > >> > >> ... > >> 2) Please clarify the following request. Is it correct that “Provider > >> Backbone Bridge” as well as “PBB-EVPN” should be updated to the plural > >> forms everywhere in the document (e.g., “Provider Backbone Bridges” and > >> “PBBs-EVPN”)? Should “PBB” and “PBB-EVPN” remain singular in the > >> Terminology list (Section 2) for consistency with the other terms, or do > >> you prefer both to be plural in that section? Note that only “PBB-EVPN” > >> (not "PBBs-EVPN") has been used in the RFC Series. > >> > >> Ali>> I am sorry for the confusion that I created. Your original text of > >> singular is correct and PPB stands for Provider Backbone Bridge. I just > >> went back to IEEE 802.1Q 2014 and verified there. > >> > >> Ali>> Please change everything back to singular. The reason for my > >> confusion was because some IEEE documents refer to PBB as singular and > >> some as plural and yet some as “Provider Backbone Bridged”. However, in > >> the context of this document, the most correct one is “Provider Backbone > >> Bridge”. > >> > >> > >> > >> Regards, > >> > >> Ali > >> > >> > >> > >>> Ali> Please change “Provider Backbone Bridge” to “Provider Backbone > >>> Bridges” throughout this document. > >> > >> > >> Some examples > >> > >> Current: > >> Ethernet VPN (EVPN) and Provider Backbone Bridge EVPN (PBB-EVPN) > >> introduce a comprehensive suite of solutions for delivering Ethernet > >> services over MPLS/IP networks. > >> > >> Perhaps: > >> Ethernet VPN (EVPN) and Provider Backbone Bridges EVPN (PBBs-EVPN) > >> introduce a comprehensive suite of solutions for delivering Ethernet > >> services over MPLS/IP networks. > >> > >> Current: > >> PBB: Provider Backbone Bridge > >> PBB-EVPN: Provider Backbone Bridge EVPN > >> > >> Perhaps: > >> PBBs: Provider Backbone Bridges > >> PBBs-EVPN: Provider Backbone Bridges EVPN > >> > >> Current: > >> This section describes the requirements specific to vES for EVPN and > >> PBB-EVPN solutions. > >> > >> Perhaps: > >> This section describes the requirements specific to vES for EVPN and > >> PBBs-EVPN solutions. > >> > >> ... > >> 3) Please let us know how we may update the title of Figure 1 with “SH” > >> expanded. > >> > >>> Ali> single-homed > >> > >> > >> Original: > >> Figure 1: A Dual-Homed Device/Network (Both SA/AA) and SH on the Same > >> ENNI > >> > >> Current: > >> Figure 1: A Dual-Homed Device/Network (Both SA/AA) and Single-Homed on > >> the Same ENNI > >> > >> Perhaps A: > >> Figure 1: A Dual-Homed Device/Network (Both SA/AA) That is Single-Homed > >> on the Same ENNI > >> > >> Perhaps B: > >> Figure 1: A Dual-Homed and Single-Homed Device/Network (Both SA/AA) on > >> the Same ENNI > >> > >> ... > >> 4) In Section 4.1, is "ES-Import extended community" the same as > >> "ES-Import Route Target extended community"? > >> If so, should it be updated, or is this short form of the name > >> sufficiently clear? (It seems to be "ES-Import Route Target" in > >> <https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn> > >> and in RFC-to-be 9786). > >> > >> Current: > >> When a PE discovers the vESI or is configured with the vESI > >> associated with its attached vES, it advertises an ES route > >> with the associated ES-Import extended community attribute. > >> > >> Perhaps: > >> When a PE discovers the vESI or is configured with the vESI > >> associated with its attached vES, it advertises an ES route > >> with the associated ES-Import Route Target extended community > >> attribute. > >> > >> 5) Please confirm if any key words are desired. > >> > >>> <!-- [rfced] Please insert any keywords (beyond those that appear in > >>> the title) for use on https://www.rfc-editor.org/search. > >>> --> > >> > >> > >> > >> --FILES-- > >> The updated XML file is here: > >> https://www.rfc-editor.org/authors/rfc9784.xml > >> > >> The updated output files are here: > >> https://www.rfc-editor.org/authors/rfc9784.txt > >> https://www.rfc-editor.org/authors/rfc9784.pdf > >> https://www.rfc-editor.org/authors/rfc9784.html > >> > >> These diff files show all changes made during AUTH48: > >> https://www.rfc-editor.org/authors/rfc9784-auth48diff.html > >> https://www.rfc-editor.org/authors/rfc9784-auth48rfcdiff.html (side by > >> side) > >> > >> These diff files show all changes made to date: > >> https://www.rfc-editor.org/authors/rfc9784-diff.html > >> https://www.rfc-editor.org/authors/rfc9784-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 John and Rick > >> prior to moving forward in the publication process. > >> > >> For the AUTH48 status of this document, please see: > >> https://www.rfc-editor.org/auth48/rfc9784 > >> > >> Best regards, > >> RFC Editor/kc > >> > >> > >>> On Jun 10, 2025, at 12:26 PM, Ali Sajassi (sajassi) > >>> <sajassi=40cisco....@dmarc.ietf.org> wrote: > >>> > >>> Hi Karen, > >>> > >>> Please refer to my comments inline starting with “Ali>”. After > >>> incorporating my comments, you can reflect my approval for this document. > >>> Thank you! > >>> > >>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > >>> Date: Thursday, May 15, 2025 at 1:28 PM > >>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Patrice Brissette > >>> (pbrisset) <pbris...@cisco.com>, richard.sch...@verizon.com > >>> <richard.sch...@verizon.com>, jdr...@juniper.net <jdr...@juniper.net>, > >>> 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>, laburdet.i...@gmail.com > >>> <laburdet.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 9784 > >>> <draft-ietf-bess-evpn-virtual-eth-segment-19> 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] To align with the Abstract/Introduction, we made > >>> "Virtual Ethernet Segment" plural in the document title and the > >>> short title (which appears in the running header of the PDF). > >>> Please let us know of any changes. > >>> > >>> Ali> That’s fine. > >>> > >>> Additionally, please consider if "Provider Backbone Bridge EVPN" > >>> should be included in the document title per the scope. And for > >>> clarity, would it be correct for "Solutions", "Requirements", or > >>> other to be included? > >>> > >>> Ali> Please change “Provider Backbone Bridge” to “Provider Backbone > >>> Bridges” throughout this document. > >>> > >>> > >>> Original: > >>> EVPN Virtual Ethernet Segment > >>> > >>> Current: > >>> EVPN Virtual Ethernet Segments > >>> > >>> Perhaps: > >>> EVPN and Provider Backbone Bridge EVPN Solutions for > >>> Virtual Ethernet Segments > >>> --> > >>> > >>> Ali> I would prefer “Virtual Ethernet Segments for EVPN and PBB-EVPN” for > >>> the title > >>> > >>> > >>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > >>> the title) for use on https://www.rfc-editor.org/search. > >>> --> > >>> > >>> > >>> 3) <!--[rfced] For clarity, may "on a per individual PW" be rephrased > >>> as "on each PW"? Alternatively, if "individual" is necessary, then > >>> perhaps "for each individual PW". > >>> > >>> Original: > >>> For instance, if PW3 were terminated into a > >>> third PE, e.g. PE3, instead of PE1, the vES would need to be defined > >>> on a per individual PW on each PE. > >>> > >>> Perhaps: > >>> For instance, if PW3 were terminated into a > >>> third PE, e.g., PE3, instead of PE1, the vES would need to be defined > >>> on each PW on each PE. > >>> --> > >>> > >>> Ali> That’s fine. > >>> > >>> > >>> 4) <!--[rfced] Section 3.2: Why is this item numbered "R3a" instead of > >>> "R2a"? > >>> In other words, The preceding section is R1a, R1b, etc., so > >>> should this be "R2a" instead of "R3a"? > >>> > >>> Ali> Yes, it should be “R2a” because we removed one subsection. > >>> > >>> > >>> If your answer is "R2a", then the subsequent requirements will be > >>> updated as well (i.e. R4a, R4b, etc., will become R3a, R3b, etc.) > >>> > >>> Ali> Yes. > >>> > >>> > >>> Original: > >>> (R3a) A PE device that supports the vES function MUST support local > >>> switching among different vESes associated with the same service > >>> instance on a single physical port. > >>> --> > >>> > >>> > >>> 5) <!--[rfced] Section 3.4: FYI, we changed "Rbc" to"R5b". > >>> Rationale: The preceding item is R5a, and the numbering in the > >>> preceding section is R4a, R4b, R4c, etc. Please let us know if > >>> you intended otherwise. > >>> > >>> Original: > >>> (Rbc) Each vES MUST be identified by its own virtual ESI (vESI). > >>> > >>> Current: > >>> (R5b) Each vES MUST be identified by its own virtual ESI (vESI). > >>> --> > >>> > >>> Ali> Updated text is fine. > >>> > >>> > >>> 6) <!--[rfced] We had trouble parsing this sentence and updated it for > >>> clarity as shown below. Please let us know if it changes the > >>> intended meaning. > >>> > >>> Original: > >>> Since many EVCs (and their associated vESes) are aggregated via a > >>> single physical port (e.g., ENNI), then the failure of that physical > >>> port impacts many vESes and triggers equally many ES route > >>> withdrawals. > >>> > >>> Perhaps: > >>> Since many EVCs (and their associated vESes) are aggregated via a > >>> single physical port (e.g., ENNI), when there is a failure of that > >>> physical port, it impacts many vESes and equally triggers many ES route > >>> withdrawals. > >>> --> > >>> > >>> Ali> Updated text is fine. > >>> > >>> > >>> 7) <!-- [rfced] We note that RFC 7623 does not contain Section > >>> 7.2.1.1. Was Section 6.2.1.1 ("PE B-MAC Address Assignment") > >>> perhaps intended > >>> <https://www.rfc-editor.org/rfc/rfc7623#section-6.2.1.1>? > >>> > >>> Ali> Correct. It should be changed to 6.2.1.1. > >>> > >>> > >>> Original: > >>> For PBB-EVPN solution, the main change is with respect to the B-MAC > >>> address assignment which is performed similar to what is described in > >>> section 7.2.1.1 of [RFC7623] with the following refinements: > >>> --> > >>> > >>> > >>> 8) <!--[rfced] Is a word missing after "Single-Active" in the following > >>> sentence? Perhaps "scenario"? > >>> > >>> Original: > >>> In case of a Single-Active, when a service moves from one PE in the > >>> Redundancy Group to another PE because of DF re-election, the PE, > >>> which ends up being the elected DF for the service, MUST trigger a > >>> MAC address flush notification towards the associated vES if the > >>> multi-homing device is a bridge or the multi-homing network is an > >>> Ethernet bridged network. > >>> --> > >>> > >>> Ali> That’s correct – “Single-Active scenario” > >>> > >>> 9) <!--[rfced] Please clarify "instead of NULL value". Is the intended > >>> meaning that an I-SID is carried in the Ethernet Tag ID field > >>> instead of in the NULL value (Perhaps A) or that the route is > >>> modified to carry an I-SID instead of a NULL value (Perhaps B)? > >>> > >>> Original: > >>> [RFC9541] introduces B-MAC/I-SID route where existing PBB-EVPN B-MAC > >>> route is modified to carry an I-SID in the "Ethernet Tag ID" field > >>> instead of NULL value. > >>> > >>> Perhaps A: > >>> [RFC9541] introduces a B-MAC/I-SID route where the existing PBB-EVPN > >>> B-MAC > >>> route is modified to carry an I-SID in the "Ethernet Tag ID" field > >>> instead > >>> of in the NULL value. > >>> or > >>> > >>> Perhaps B: > >>> [RFC9541] introduces a B-MAC/I-SID route where the existing PBB-EVPN > >>> B-MAC > >>> route is modified to carry an I-SID, instead of a NULL value, in the > >>> "Ethernet Tag ID" field. > >>> --> > >>> > >>> Ali> (B) is correct! > >>> > >>> 10) <!--[rfced] Please clarify if "one for each VLAN" is the same as "one > >>> for each I-SID"? And does "one" mean "one route"? > >>> > >>> Original: > >>> However, if the failed EVC carries multiple VLANs each with its own > >>> broadcast domain, then the affected PE needs to advertise multiple > >>> B-MAC/I-SID routes - one for each VLAN (broadcast domain) - i.e., > >>> one for each I-SID. > >>> > >>> Perhaps: > >>> However, if the failed EVC carries multiple VLANs each with its own > >>> broadcast domain, then the affected PE needs to advertise multiple > >>> B-MAC/I-SID routes, i.e., one route for each VLAN (broadcast domain), > >>> meaning one route for each I-SID. > >>> --> > >>> > >>> Ali> Updated text is correct! > >>> > >>> 11) <!--[rfced] Please clarify what "(1)" is referring to in the > >>> text below. Is "(1)" within the same section (Section 5.3) or a > >>> different section? Or, perhaps "one (1)" was intended? > >>> > >>> Original: > >>> 4. When this message is received, the remote PE MAY detect the > >>> special vES mass-withdraw message by identifying the Grouping > >>> Ethernet A-D per ES route. The remote PEs MAY then access the > >>> list created in (1) of the vESes for the specified color, and > >>> initiate locally MAC address invalidating procedures for each of > >>> the vESes in the list. > >>> --> > >>> > >>> Ali> Yes, (1) refers to the same section. Perhaps “1.” should be used? > >>> > >>> > >>> 12) <!-- [rfced] We found the following URL for [MEF63]: > >>> https://www.mef.net/resources/mef-6-3-subscriber-ethernet-service-definitions/. > >>> May we add this URL to the reference entry for easy access? > >>> > >>> Original: > >>> [MEF63] Metro Ethernet Forum, "Subscriber Ethernet Services > >>> Definitions", MEF Standard, MEF 6.3, November 2019. > >>> > >>> Perhaps: > >>> [MEF63] Metro Ethernet Forum, "Subscriber Ethernet Services > >>> Definitions", MEF Standard, MEF 6.3, November 2019, > >>> <https://www.mef.net/resources/mef-6-3-subscriber- > >>> ethernet-service-definitions>. > >>> --> > >>> > >>> Ali> Yes, thanks! > >>> > >>> 13) <!-- [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. > >>> > >>> Ethernet A-D per ES route (16) vs. > >>> Ethernet A-D per ES (5) > >>> [Note: should "route" be added to the 5 instances that > >>> do not include it? > >>> > >>> Ali> Yes! > >>> > >>> MAC Mobility Extended Community vs. > >>> MAC Mobility Extended community vs. > >>> MAC mobility Extended community > >>> [Note that the case used in RFCs 7432 and 7623 is > >>> "MAC Mobility extended community".] > >>> > >>> Ali> should be made consistent with RFC 7432 & 7623 > >>> > >>> b) For consistency, we updated the document to use the form on the > >>> right. Please let us know of any objections. > >>> > >>> Core Network -> core network > >>> DF Election -> DF election > >>> Ethernet segment -> Ethernet Segment > >>> Multi-Homed and Multi-homed -> multi-homed > >>> Redundancy Group -> redundancy group > >>> Service Provider -> service provider > >>> Single-homed -> single-homed > >>> > >>> Ali> Yes, that’s fine. > >>> > >>> c) May "multi-homed" and "multi-homing" > >>> be changed to "multihomed" and "multihoming" per common > >>> use in the RFC series (and in particular, in RFCs 7432, > >>> 7623, and 8584)? Your reply to this will be applied to the > >>> other documents in this cluster (9785 and 9786). > >>> --> > >>> > >>> Ali> Yes, that’s fine. > >>> > >>> 14) <!-- [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. > >>> > >>> - Label Distribution Protocol (LDP) > >>> - Media Access Control (MAC) > >>> > >>> Ali> Yes, that’s fine. > >>> > >>> b) For consistency (within the RFC series and cluster 492), we updated > >>> this document to use the forms on the right. Please let us know of > >>> any objections. > >>> > >>> All-Active Redundancy Mode (AA) -> All-Active (AA) Redundancy Mode > >>> > >>> Broadcast, Unknown-unicast, Multicast (BUM) -> > >>> Broadcast, Unknown Unicast, and Multicast (BUM) (per RFC 7432) > >>> > >>> External Network-to-Network Interface (ENNI) (Section 1.2) vs. > >>> External Network-Network Interface (Section 2) > >>> -> updated to the latter for consistency. > >>> > >>> Provider Backbone (PBB) -> Provider Backbone Bridge (PBB) (per RFC 7623) > >>> > >>> Single-Active Redundancy Mode (SA) -> Single-Active (SA) Redundancy Mode > >>> > >>> Virtual Pseudowire Service (VPWS) -> > >>> Virtual Private Wire Service (VPWS) (per RFC 8214) > >>> > >>> Ali> Yes, all the above are fine. > >>> > >>> c) Please let us know how we may expand the following term: > >>> > >>> - SH (in the title of Figure 1) > >>> > >>> Ali> single-homed > >>> > >>> d) As recommended in the Web Portion of the Style Guide > >>> <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>, > >>> once an abbreviation is introduced, the abbreviated form > >>> should be used thereafter. Please consider if you would > >>> like to apply this style for the following term: > >>> > >>> - Ethernet Segment (ES) -> use "ES" thereafter > >>> --> > >>> > >>> Ali> Yes! > >>> > >>> 15) <!-- [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. > >>> --> > >>> > >>> Ali> we are good! > >>> > >>> 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/rfc9784.xml > >>> https://www.rfc-editor.org/authors/rfc9784.html > >>> https://www.rfc-editor.org/authors/rfc9784.pdf > >>> https://www.rfc-editor.org/authors/rfc9784.txt > >>> > >>> Diff file of the text: > >>> https://www.rfc-editor.org/authors/rfc9784-diff.html > >>> https://www.rfc-editor.org/authors/rfc9784-rfcdiff.html (side by side) > >>> > >>> Diff of the XML: > >>> https://www.rfc-editor.org/authors/rfc9784-xmldiff1.html > >>> > >>> > >>> Tracking progress > >>> ----------------- > >>> > >>> The details of the AUTH48 status of your document are here: > >>> https://www.rfc-editor.org/auth48/rfc9784 > >>> > >>> Please let us know if you have any questions. > >>> > >>> Thank you for your cooperation, > >>> > >>> RFC Editor > >>> > >>> -------------------------------------- > >>> RFC9784 (draft-ietf-bess-evpn-virtual-eth-segment-19) > >>> > >>> Title : EVPN Virtual Ethernet Segments > >>> Author(s) : A. Sajassi, P. Brissette, R. Schell, J. Drake, J. > >>> Rabadan > >>> 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
