RFC Editors, Alanna, I approve this RFC for publication.
Thanks, Aparna From: Alanna Paloma <apal...@staff.rfc-editor.org> Date: Monday, April 28, 2025 at 1:34 PM To: Neeraj Malhotra (nmalhotr) <nmalhotr=40cisco....@dmarc.ietf.org> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Ali Sajassi (sajassi) <saja...@cisco.com>, Aparna Pattekar (apjoshi) <apjo...@cisco.com>, jorge.raba...@nokia.com <jorge.raba...@nokia.com>, ar977m <ar9...@att.com>, jdr...@juniper.net <jdr...@juniper.net>, bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, slitkows.i...@gmail.com <slitkows.i...@gmail.com>, gunter.van_de_ve...@nokia.com <gunter.van_de_ve...@nokia.com>, auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> Subject: Re: AUTH48: RFC-to-be 9721 <draft-ietf-bess-evpn-irb-extended-mobility-21> for your review Hi Neeraj, Thank you for the updated XML file. We have updated the other files accordingly. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9721.xml https://www.rfc-editor.org/authors/rfc9721.txt https://www.rfc-editor.org/authors/rfc9721.html https://www.rfc-editor.org/authors/rfc9721.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9721-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9721-auth48diff.html (AUTH48 changes) Your approval has been noted on the AUTH48 status page. We assume assent to any changes from your coauthors unless we hear otherwise. Once we receive approvals from Ali, Aparna, Jorge, Avinash, and John, we will move this document forward in the publication process. For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9721 Thank you, RFC Editor/ap > On Apr 25, 2025, at 1:42 PM, Neeraj Malhotra (nmalhotr) > <nmalhotr=40cisco....@dmarc.ietf.org> wrote: > > RFC Editors, > Many thanks for all the edits. > On behalf of all the co-authors, I have carefully reviewed all the edits and > incorporated all of the proposed edits in the attached XML file. They were > all good comments and there was no objection to any made or proposed changes. > All comments and questions in the XML file are also updated inline under [NM] > to reflect this. > I approve this RFC for publication. > Thanks, > Neeraj > From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > Date: Thursday, April 24, 2025 at 1:58 PM > To: Neeraj Malhotra (nmalhotr) <nmalh...@cisco.com>, Ali Sajassi (sajassi) > <saja...@cisco.com>, Aparna Pattekar (apjoshi) <apjo...@cisco.com>, > jorge.raba...@nokia.com <jorge.raba...@nokia.com>, ar977m <ar9...@att.com>, > jdr...@juniper.net <jdr...@juniper.net> > Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, bess-...@ietf.org > <bess-...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, > slitkows.i...@gmail.com <slitkows.i...@gmail.com>, > gunter.van_de_ve...@nokia.com <gunter.van_de_ve...@nokia.com>, > auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> > Subject: Re: AUTH48: RFC-to-be 9721 > <draft-ietf-bess-evpn-irb-extended-mobility-21> 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] Please note that the title of the document has been updated as > follows: > > Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC > Style Guide"). Please review. > > Original: > > Extended Mobility Procedures for EVPN-IRB > > Current: > > Extended Mobility Procedures for Ethernet VPN Integrated Routing and > Bridging (EVPN-IRB) > --> > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> > > > 3) <!-- [rfced] May we number the text below for ease of the reader? Please > review: > > Original: > > This document updates the sequence number assignment procedures > defined in [RFC7432] to adequately address mobility support across > EVPN-IRB overlay use cases that permit MAC-IP address bindings to > change across host moves and support mobility for both MAC and IP > route components carried in an EVPN RT-2 for these use cases. > > Perhaps: > > This document updates the sequence number assignment procedures > defined in [RFC7432] to 1) adequately address mobility support across > EVPN-IRB overlay use cases that permit MAC-IP address bindings to change > across host moves and 2) support mobility for both MAC and IP > route components carried in an EVPN RT-2 for these use cases. > > --> > > > 4) <!-- [rfced] Section 2: Please review the following questions and changes > regarding the terminology list in this section. > > > a.) FYI - We have made several updates to reflect a 1:1 relationship between > abbreviation and expansion. Please carefully review these updates and let us > know any objections. > > > b.) As this list contains both abbreviations and definitions, would you like > to separate these items into two separate lists for readability? > > > c.) Would you like to order these terms alphabetically? > > > d.) We have adjusted the list items below for clarity. Please review to ensure > these updates do not change your intended meaning. > > Original: > > * EVPN-IRB: A BGP-EVPN distributed control plane based integrated > routing and bridging fabric overlay discussed in [RFC9135]. > > * Overlay: L3 and L2 Virtual Private Network (VPN) enabled via NVO3, > VXLAN, SRv6, or MPLS service layer encapsulation. > > * Host: Host in this document generically refers to any user/CE > endpoint attached to an EVPN-IRB network which may be a VM, > containerized workload or a physical end-point or CE device. > > * Ethernet-Segment: Physical ethernet or LAG (Link Aggregation > Group) port that connects an access device to an EVPN PE, as > defined in [RFC7432]. > > Current: > > EVPN-IRB: Ethernet VPN Integrated Routing and Bridging. A > BGP-EVPN distributed control plane that is based on the integrated > routing and bridging fabric overlay discussed in [RFC9135]. > > Overlay: L2 and L3 VPNs that are enabled via NVO3, VXLAN, > SRv6, or MPLS service-layer encapsulation. > > Host: In this document, generically refers to any user or CE > endpoint attached to an EVPN-IRB network, which may be a VM, > containerized workload, physical endpoint, or CE device. > > ES: Ethernet Segment. A physical ethernet or LAG port that connects > an access device to an EVPN PE, as defined in [RFC7432]. > > e.) Route Type 5 does not appear to be mentioned in RFC 7432; however, it is > defined in RFC 9136. May we update the citation in this list entry to RFC 9136 > and add an Informative Reference entry for it? > > Original: > > * RT-5: EVPN route type 5 carrying IP prefix reachability as > specified in [RFC7432]. > > Perhaps: > > RT-5: Route Type 5. Refers to the EVPN RT-5 carrying IP prefix > reachability as specified in [RFC9136]. > > > f.) For consistency with RFC 8926 and to reflect a 1:1 relationship between > abbreviation and expansion, we have separated this list item into two separate > items: > > Original: > > * NVO3: Network Virtualization Overlays as specified in [RFC8926]. > > Current: > > NVO: Network Virtualization Overlay. > > NVO3: Network Virtualization over Layer 3 (as specified in > [RFC8926]). > > > g.) FYI - We plan to add the following abbreviations in the terminology > section, as they appear within other definitions in this list. Please let > us know of any objections. > > CE: Customer Edge. > PE: Provider Edge. > LAG: Link Aggregation Group. > L2: Layer 2. > L3: Layer 3. > ToR: Top-of-Rack. > --> > > > 5) <!-- [rfced] Section 3.2: May we add the following lead-in text to the list > below? The proposed text is from the same list in the Introduction. > > Original: > > 3.2. Mobility Use Cases > > This section outlines the IRB mobility use cases addressed in this > document. Detailed procedures to handle these scenarios are provided > in Sections 6 and 7. > > * A host move results in both the host's IP and MAC addresses moving > together. > > * A host move results in the host's IP address moving to a new MAC > address association. > > * A host move results in the host's MAC address moving to a new IP > address association. > > > Perhaps: > > 3.2. Mobility Use Cases > > This section outlines the IRB mobility use cases addressed in this > document. Detailed procedures to handle these scenarios are provided in > Sections 6 and 7. The following IRB mobility scenarios are considered: > > ... > > --> > > > 6) <!-- [rfced] We have clarified "higher than N and the previous Mz sequence > number M" as follows. Please review and let us know if this update has > altered the intended meaning. > > Original: > > If IPx moves to a new physical server behind PE2 and is associated with MAC > Mz, the new local Mz-IPx route must be advertised with a sequence number > higher than N and the previous Mz sequence number M. > > Current: > > If IPx moves to a new physical server behind PE2 and is associated with MAC > Mz, the new local Mz-IPx route must be advertised with a sequence number > higher than N and higher than the previous Mz sequence number M. > > --> > > > 7) <!-- [rfced] May we clarify "local and Peer-Sync-Local MAC and MAC-IP > route" as follows? > > Original: > > The following sections specify the sequence number assignment > procedures required for local and Peer-Sync-Local MAC and MAC-IP > route learning events to achieve the objectives outlined. > > Perhaps: > > The following sections specify the sequence number assignment > procedures required for local MAC, local MAC-IP, Peer-Sync-Local MAC, > and Peer-Sync-Local MAC-IP route learning events to achieve the > outlined objectives. > > --> > > > 8) <!-- [rfced] To improve readability, may we split the sentence below > into two sentences? Please review and let us know if this changes the > intended meaning. > > Original: > > A local Mx-IPx learning via ARP or NDP should result in the > computation or re-computation of the parent MAC route Mx's sequence > number, following which the MAC-IP route Mx-IPx inherits the parent > MAC route's sequence number. > > Perhaps: > > A local Mx-IPx learning via ARP or NDP should result in the > computation or re-computation of the parent MAC route Mx's sequence > number. After this, the MAC-IP route Mx-IPx inherits the parent > MAC route's sequence number. > > --> > > > 9) <!--[rfced] The following list reads awkwardly. May we rephrase the list > items so that they each describe the way a sequence number from the remote > MAC route should be handled? > > Original: > > To handle this case, if different sequence numbers are received for > remote MAC+IP routes and corresponding remote MAC routes from a > remote PE, the sequence number associated with the remote MAC route > MUST be computed and interpreted as: > > * The highest of all received sequence numbers with remote MAC+IP > and MAC routes with the same MAC address. > > * The MAC route sequence number would be re-computed on a MAC or > MAC+IP route withdraw as per the above. > > Perhaps: > > To handle this case, if different sequence numbers are received for > remote MAC+IP routes and corresponding remote MAC routes from a > remote PE, the sequence number associated with the remote MAC route > MUST be: > > * computed and interpreted as the highest of all received sequence > numbers with remote MAC+IP and MAC routes with the same MAC address > and > > * re-computed on a MAC or MAC+IP route withdraw as per the above. > --> > > > 10) <!-- [rfced] Please review the following questions and changes regarding > the > abbreviations used in this document. Per Section 3.6 of RFC 7322 ("RFC Style > Guide"), abbreviations should be expanded upon first use. > > a.) How may we expand "CLI" in the sentence below? As "command-line > interface", > "Call Level Interface", "Calling Line Identification", or something else? > > Original: > > Unfreezing the duplicate or frozen MAC or IP route via a CLI can be > used to recover from the duplicate and frozen state following > corrective un-provisioning of the duplicate MAC or IP address. > > > b.) FYI - We have already expanded the following abbreviations upon first use. > Please review each expansion in the document carefully to ensure correctness. > > Media Access Control (MAC) > MAC Virtual Routing and Forwarding (MAC-VRF) > IP Virtual Routing and Forwarding (IP-VRF) > Ethernet Segment Identifier (ESI) > Ethernet Segment (ES) > Provider Edge (PE) > Neighbor Advertisement (NA) > VXLAN Tunnel End Point (VTEP) > > --> > > > 11) <!-- [rfced] Please review the "Inclusive Language" portion of the online > Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature typically > result in more precise language, which is helpful for readers. > > For example, please consider whether "natively" should be updated in the > instances below: > > ...for a host that is attached to a local ES may be learned natively via... > ...routes learnt natively via data plane and ARP/NDP are respectively... > > --> > > > Thank you. > > RFC Editor/kf/ap > > > On Apr 24, 2025, at 1:57 PM, rfc-edi...@rfc-editor.org wrote: > > *****IMPORTANT***** > > Updated 2025/04/24 > > 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/rfc9721.xml > https://www.rfc-editor.org/authors/rfc9721.html > https://www.rfc-editor.org/authors/rfc9721.pdf > https://www.rfc-editor.org/authors/rfc9721.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9721-diff.html > https://www.rfc-editor.org/authors/rfc9721-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9721-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9721 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9721 (draft-ietf-bess-evpn-irb-extended-mobility-21) > > Title : Extended Mobility Procedures for EVPN-IRB > Author(s) : N. Malhotra, A. Sajassi, A. Pattekar, J. Rabadan, A. > Lingala, J. Drake > WG Chair(s) : Matthew Bocci, Stephane Litkowski, Zhaohui (Jeffrey) Zhang > > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > <rfc9721.xml>
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
