I found the document well written and no serious issues.
There are however a few minor issues that I think should be resolved before it is submitted to the IESG.

I see revision 06 was reviewed previously, please check that all those comments are addressed.
review-ietf-bess-evpn-mvpn-seamless-interop-06-rtgdir-early-boucadair-2023-11-29-00

There are a few sentences that are hard to parse.

In section 5.2:
   sending these messages over MPLS/IP core.  A tenant virtual/physical
   router (e.g., CE) attached to an EVPN PE becomes a multicast routing
   the adjacency of that PE.  Furthermore, the PE uses MVPN BGP protocol

I don't understand the sentence ending with "the adjacency of that PE". Should simply "the" be removed?

In section 5.3:
   attached behind EVPN PEs.  All VPN-IP routes SHOULD be summarized
   while adverting to MVPN PEs.

Replace "adverting" with "advertising"?

In 6.1:
   In case of a TS, receiver sits behind an All-Active Multihoming ES
   and a TS source sits behind an inter-subnet tunnel (with respect to
   the multihomed PE), it is possible that more than one multihomed PEs
   sends MVPN join toward remote PE based on incoming join on their

Replace "more than one" with "more than one of the"?

In 6.4:
   Here, IGMP/MLD states are terminated at IRB interfaces, and local
   interest are expressed in the context of IP-VRF to remote PEs.

s/are/is?

In 7.2:
   Rcvr2 in Figure 1 is connected to PE1 in MAC-VRF2 and hence PE1 will
   record its membership in MAC-VRF2.  Since MAC-VRF2 is enabled with
   IRB, gets added as another OIF to the routing entry formed for (C-S,
   C-G).

What is it that gets added as another OIF?

In 7.2:
   another OIF 'MAC-VRF2' to its existing routing entry.  But there is
   no change in control plane states since it is already sent MVPN route
   and no further signaling is required.  Traffic received by the tenant

Replace "it is already" with "it has already"?

In 8.1:
   It must be emphasized that this solution poses no restriction on the
   setup of the tenant BDs and that neither the source PE, nor the
   receiver PEs do not need to know/learn about the BD configuration on
   other PEs in the tenant IP-VRF ( Since EVPN PE is modeled as MVPN PE,
   source and receivers are announced to remote PE in the context of
   tenant IP-VRF(MVPN) as opposed to BD context).  The Reverse Path

This is hard to read with the double negative. Can "do not" be removed?

In 8.1:
   EVPN PE MUST have Route Target Extended Community to import/export
   MVPN routes.  In a data center environment, it is desirable to have
   this RT is configured using an auto-generated method rather than a
   static configuration.

Replace "RT is" with "RT"?

In 8.1:
   be appended as an export route-target extended community.  The PE
   which has advertised the unicast route with VRI, will import the
   incoming MCAST-VPN NLRI in the IP-VRF with the same import route-
   target extended-community and other PEs SHOULD ignore it.  Following

Why is this a SHOULD and not a MUST? What are the conditions where it makes sense not to ignore it?

In 8.1:
   If the multicast source is unknown (overlay ASM mode), the MCAST-VPN
   route type 6 (C-*,C-G) join SHOULD be targeted towards the designated
   overlay Rendezvous Point (RP) by appending the received RP VRI as an
   export route-target extended community.  Every PE which detects a a

Also here, why is it a SHOULD and not a MUST. When does it make sense not to do it?

In 8.2.2:
   When the encapsulation mode is configured as the VXLAN, the

Should it say "as VXLAN"?

In 8.2.2:
   A gateway is needed for inter-operation between the EVPN MVPN-capable
   PEs and non-EVPN MVPN PEs.  The gateway should re-originate the
   control plane signaling with the relevant tunnel encapsulation on
   either side.  In the data plane, the gateway terminates the tunnels

Upper case SHOULD?

Heading 12: TS RP options

What is TS?

Section 13 IANA Considerations:

Maybe point out that references need to be updated when published?

Section 14 Security Considerations

Are there no new considerations due to how the existing technologies are combined?

In A.3:
   Recent ASIC supports single lookup forwarding for bridging and
   routing (L2+L3).  The procedure mentioned here leverages this ASIC
   capability.

"Recent" may not age well. This document may be read years after publication. It might also become multiple ASICs.
I also find it a bit odd to mention ASIC support. Maybe it makes more sense with ASIC support, but couldn't it be done anyway?

That's all my issues.