Early Review of draft-ietf-bess-rfc7432bis-07
review-ietf-bess-rfc7432bis-07-rtgdir-early-mcbride-2023-07-20-00

The following simply makes the document more readable/understandable
to me. I had to scratch my head on a couple sentences and re-worded
to make it clear. Feel free to incorporate my suggestions. And I know
you didn't make bis changes to the Intro and Section 4 but I'm making
suggestions anyway because they sound better to me. 

Well done, good bis document.

1. Introduction

Existing:
This document describes procedures for a BGP MPLS-based solution
called Ethernet VPN (EVPN) to address the requirements specified in
[RFC7209].

Better:
This document describes procedures for Ethernet VPN (EVPN), a BGP MPLS-based 
solution which addresses the requirements specified in [RFC7209].

4. BGP MPLS-Based EVPN Overview

Existing:
A CE attaches to a BD on a PE, on an Ethernet interface that may be
configured for one or more Ethernet tags.

Better:
A CE attaches to a BD, on a PE, using an Ethernet interface that may be
configured for one or more Ethernet tags.

6.4. EVPN PE Model

Existing:
Since a single tenant subnet is typically (and in this document)
represented by a VLAN (and thus supported by a single BT), for a
given tenant there are as many BTs as there are subnets as shown in
the PE model above.

Better:
A single tenant subnet is typically represented by a VLAN 
and thus supported by a single BT. For a given tenant there are as 
many BTs as there are subnets as shown in the PE model above.

7.11.1. EVPN Layer 2 Attributes Partitioning

Existing:
In order to minimize the processing overhead of configuration-time items 
such as MTU not expected to change at runtime based on failures, the L2-Attr
Extended Community from [RFC8214] is partitioned, with a subset of
information carried over each Ethernet A-D per EVI and Inclusive
Multicast routes.

Better:
In order to minimize the processing overhead of configuration-time items, 
such as MTU not expected to change at runtime based on failures, the L2-Attr
Extended Community [RFC8214] is partitioned and a subset of
information is carried over each Ethernet A-D per EVI and Inclusive
Multicast routes.

7.12. Route Prioritization

Existing:
Ethernet A-D per ES (Mass-Withdraw Route Type 1) and Ethernet
Segment (Route Type 4) are lower scale and highly convergence
affecting, and SHOULD be handled in first order of priority

Better:
Ethernet A-D per ES (Mass-Withdraw Route Type 1) and Ethernet
Segment (Route Type 4) are lower scale, highly convergence
affecting and SHOULD be handled in first order of priority.

Existing:
Ethernet A-D per EVI, Inclusive Multicast Ethernet Tag route,
and IP Prefix route defined in [RFC9136] are sent for each
Bridge or AC at medium scale and may be convergence affecting,
and SHOULD be handled in second order of priority

Better:
Ethernet A-D per EVI, Inclusive Multicast Ethernet Tag route,
and IP Prefix route, as defined in [RFC9136], are sent for each
Bridge or AC at medium scale, may be convergence affecting
and SHOULD be handled in second order of priority.

Existing:
MAC advertisement route (zero and non-zero IP portion),
Multicast Join Sync and Multicast Leave Sync routes defined in
[RFC9251] are considered 'individual routes' and very-high
scale or of relatively low importance for fast convergence and
SHOULD be handled in the last order of priority

Better:
MAC advertisement routes (zero and non-zero IP portion),
Multicast Join Sync and Multicast Leave Sync routes, as defined in
[RFC9251], are considered 'individual routes' and SHOULD be handled 
in the last order of priority.

I struggled with understanding what was trying to be said
in this last point 3 paragraph so made it as simple as possible to 
still make sense. See if it makes sense to you, and if not, perhaps
re-word your original better.

Add a period after both points 1 and 2 like you do with 3.

15.3. Loop Protection

Existing:
While this helps the control plane settle, in case there is backdoor 
link (loop) between two or more PEs attached to the same BD, BUM 
frames being sent by a CE are still endlessly looped within the BD 
through the backdoor link and among the PEs.

Better:
This helps the control plane settle, however, when there is a backdoor 
link (loop) between two or more PEs attached to the same BD, BUM frames
from a CE are still endlessly looped within the BD through the 
backdoor link and among the PEs.

18.1. Flow Label

Existing:
Receiving the F bit from a remote PE which does not match the
local Flow label support is notified to the operator and the
receiving PE excludes the remote PE as the EVPN destination for
any of the corresponding service instances.

Better:
When receiving the F bit from a remote PE, which does not match the
local Flow label, the receiving PE excludes the remote PE as the EVPN 
destination for any of the corresponding service instances.

Existing:
Therefore, from the VPN label, the receiving PE knows
whether the next label is a ESI label or a Flow label - i.e., if
the VPN label is for known unicast, then the next label MUST be a
flow label and if the VPN label is for BUM traffic, then the next
label MUST be an ESI label because BUM packets are not sent with
Flow labels.

Better:
The receiving PE knows from the VPN label whether the next label 
is a ESI label or a Flow label - i.e., if the VPN label is for known 
unicast, then the next label MUST be a flow label and if the VPN 
label is for BUM traffic, then the next label MUST be an ESI label 
because BUM packets are not sent with Flow labels.