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
