Hi Rick and Ali, The document reflects Rick’s new information, and we have noted Rick’s approval on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9784). We now have all necessary approvals and will move this document forward in the publication process along with RFCs-to-be 9785 and 9786.
Thank you to all for your time and working closely with us on C492! Best regards, RFC Editor/kc > On Jun 18, 2025, at 8:12 AM, Ali Sajassi (sajassi) <saja...@cisco.com> wrote: > > Thank you Rick! > > Karen, > I believe we are all set for publication. > > Thank you for all your work, > Ali > > From: Rick Schell <rick_sch...@outlook.com> > Date: Wednesday, June 18, 2025 at 6:23 AM > To: Karen Moore <kmo...@staff.rfc-editor.org>, Ali Sajassi (sajassi) > <saja...@cisco.com> > Subject: Fw: AUTH48: RFC-to-be 9784 > <draft-ietf-bess-evpn-virtual-eth-segment-19> for your review > > Hi Karen, > Approved. > > I have retired from Verizon, I am now Independent. > > My new email is rick_sch...@outlook.com > > Thanks for the great work. > > > > Thanks > Rick > 214-202-3464 > rick_sch...@outlook.com > ________________________________________ > > On Jun 17, 2025, at 3:20 PM, Karen Moore <kmo...@staff.rfc-editor.org> wrote: > > Hi Ali and John, > > We have updated our files with John’s requested changes. > > As an FYI, if we are unable to reach Rick this week, you may choose one of > the following options: > > 1) The author can be removed as an author and moved to the Acknowledgements > section. > 2) The author can be removed as an author and moved to the Contributors > section. > 3) A stream manager can approve the document in place of the unavailable > author (this option is typically used in instances where the missing author > made significant contributions to the document and the other authors are not > comfortable removing the individual from the author list). > > --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 17, 2025, at 11:35 AM, Ali Sajassi (sajassi) <saja...@cisco.com> >> wrote: >> >> Hi Karen, >> >> I just pinged Rick via another email. Let’s wait till end of the week >> (Friday). If we don’t hear back from him, please remove him from the author >> list and proceed with publication. >> >> Thanks, >> Ali >> > >> On Jun 17, 2025, at 1:11 PM, John Drake <je_dr...@yahoo.com> wrote: >> >> Karen, >> >> My affiliation is 'independent' and my email address is >> 'je_dr...@yahoo.com'. >> >> Thanks, >> >> John >> >> On Tuesday, June 17, 2025 at 11:38:19 AM PDT, Ali Sajassi (sajassi) >> <saja...@cisco.com> wrote: >> >> >> Hi John, >> >> >> Are you OK with your affiliation as “Juniper”. Or do you prefer >> “Independent”. If latter, then we need to let Karen now. If former, we don’t >> need to do anything. It seems like your Juniper email account is still >> active ☺ >> >> >> Cheers, >> >> Ali >> >> >> From: John Drake <je_dr...@yahoo.com> >> Date: Tuesday, June 17, 2025 at 6:40 AM >> To: Karen Moore <kmo...@staff.rfc-editor.org>, jdr...@juniper.net >> <jdr...@juniper.net>, jorge.raba...@nokia.com <jorge.raba...@nokia.com>, >> Patrice Brissette (pbrisset) <pbris...@cisco.com>, Ali Sajassi (sajassi) >> <saja...@cisco.com>, Rick Schell <rick_sch...@outlook.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 >> >> I approve the draft for publication >> >> >> On Monday, June 16, 2025 at 09:54:35 PM PDT, Ali Sajassi (sajassi) >> <saja...@cisco.com> wrote: >> >> >> >> Hi Karen, >> >> >> Thanks again for your review and corresponding suggestions. Please refer to >> my reply inline. >> >> >> John, Rick: >> >> If you are OK with the document, please approve. >> >> >> Regards, >> >> Ali >> >> >> From: Karen Moore <kmo...@staff.rfc-editor.org> >> Date: Monday, June 16, 2025 at 11:52 AM >> To: Ali Sajassi (sajassi) <saja...@cisco.com>, jdr...@juniper.net >> <jdr...@juniper.net>, richard.sch...@verizon.com >> <richard.sch...@verizon.com>, jorge.raba...@nokia.com >> <jorge.raba...@nokia.com>, Patrice Brissette (pbrisset) <pbris...@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>, >> 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 >> >> 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 >> >> Ali> It should be: >> >> “Figure 1: Single-Homed Devices and a Dual-Homed Device/Network 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. >> >> Ali> Perfect! >> >> 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. >>> --> >> >> Ali> Keywords: vES, Virtual ES >> >> >> >> 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
