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. 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? Original: EVPN Virtual Ethernet Segment Current: EVPN Virtual Ethernet Segments Perhaps: EVPN and Provider Backbone Bridge EVPN Solutions for Virtual Ethernet Segments --> 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. --> 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"? If your answer is "R2a", then the subsequent requirements will be updated as well (i.e. R4a, R4b, etc., will become R3a, R3b, etc.) 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). --> 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. --> 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>? 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. --> 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. --> 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. --> 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. --> 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>. --> 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? 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".] 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 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). --> 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) 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) c) Please let us know how we may expand the following term: - SH (in the title of Figure 1) 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 --> 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. --> 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
