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
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
