Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

[Eric C Rosen <[e-mail]>]

Eric> 1. It seems that the proposal does not do correct ethernet 
emulation.  Intra-subnet multicast only sometimes preserves MAC SA and 
IP TTL, sometimes not, depending upon the topology.

Ali> EVPN doesn't provide LAN service per IEEE 802.1Q but rather an 
emulation of LAN service. This document defines what that emulation means

The fact that the proposal doesn't do correct ethernet emulation cannot 
be resolved by having the proposal redefine "emulation" to mean 
"whatever the proposal does".

EVPN needs to ensure that whatever works on a real ethernet will work on 
the emulated ethernet as well; the externally visible service 
characteristics on which the higher layers may depend must be properly 
offered by the emulation.  This applies to both unicast and multicast 
equally.

Otherwise anyone attempting to replace a real ethernet with EVPN will 
find that not every application and/or protocol working on the real 
ethernet will continue to work on the EVPN.

Eric> TTL handling for inter-subnet multicast seems inconsistent as 
well, depending upon the topology.

Ali> BTW, TTL handling for inter-subnet IP multicast traffic is done 
consistent!

Consider the following in a pure MVPN environment:

- Source S is on subnet1, which is attached to PE1.

- Receivers R1 and R2 are on subnet2, which is attached to both PE1 and PE2.

- Subnet1 and subnet2 are different subnets.

Now every (S,G) packet will follow the same path: either (a) 
subnet1-->PE1-->subnet2 or (b) subnet1-->PE1-->PE2-->subnet2.

Both paths cannot be used at the same time, because L3 multicast will 
not allow both PE1 and PE2 to transmit the (S,G) flow to subnet2.  So an 
(S,G) packet received by R1 will always have the same TTL as the same 
packet received by R2.  TTL scoping will therefore work consistently; 
depending on the routing, and from the perspective of any given flow, 
the two subnets are either one hop away from each other, or two hops 
away from each other.

In the so-called "seamless-mcast" scheme, on the other hand, if R1 and 
R2 get the same (S,G) packet, each may see a different TTL. Suppose R1 
is on an ES attached to PE1 but not to PE2, S is on an ES attached to 
PE1 but not to PE2, and R2 is on an ES attached to PE2 but not to PE1.  
Then a given (S,G) packet received by R1 will have a smaller TTL than 
the same packet received by R2, even though R1 and R2 are on the same 
subnet.

Note that the seamless-mcast proposal does not provide the behavior that 
would be provided by MVPN, despite the claim that it is "just MVPN".

This user-visible inconsistency may break any use of TTL scoping, and is 
just the sort of thing that tends generate a stream of service calls 
from customers that pay attention to this sort of stuff.

In general, TTL should be decremented by 0 for intra-subnet and by 1 
(within the EVPN domain) for inter-subnet.  Failure to handle the TTL 
decrement properly will break anything that depends upon RFC 3682 ("The 
Generalized TTL Security Mechanism").  Have you concluded that no use of 
multicast together with RFC 3682 will, now or in the future, ever need 
to run over EVPN?  I'd like to know how that conclusion is supported.  
You may also wish to do a google search for "multicast ttl scoping".

A related issue is that the number of PEs through which a packet passes 
should not be inferrable by a tenant.  Any sort of multicast traceroute 
tool used by a tenant will give unexpected results if TTL is not handled 
properly; at the very least this will result in service calls.

The OISM proposal (as described in the irb-mcast draft) will decrement 
TTL by 1 when packets go from one subnet to another, as an IP multicast 
frame is distributed unchanged to the PEs that need it, and its TTL is 
decremented by 1 if an egress PE needs to deliver it to a subnet other 
than its source subnet.


The draft still makes the following peculiar claim:

"Based on past experiences with MVPN over last dozen years for supported 
IP multicast applications, layer-3 forwarding of intra-subnet multicast 
traffic should be fine."

Since MVPN does not do intra-subnet multicast, experience with MVPN has 
no bearing whatsoever on the needs of intra-subnet multicast.

Eric> 2. In order to do inter-subnet multicast in EVPN, the proposal 
requires L3VPN/MVPN configuration on ALL the EVPN PEs.  This is required 
even when there is no need for MVPN/EVPN interworking. This is portrayed 
as a "low provisioning" solution!

Ali> Using MVPN constructs doesn't requires additional configuration on 
EVPN PEs beyond multicast configuration needed for IRB-mcast operation.

I think you'll find that if you don't reconfigure all the BGP sessions 
to carry AFI/SAFIs 1/128, 2/128, 1/5, and 2/5, you'll have quite a bit 
of trouble running any of the native MVPN procedures ;-) This is perhaps 
the simplest example of additional configuration that is needed.

If doing MVPN/EVPN interworking, one needs to go to every EVPN PE and 
set up all the RTs used to control the distribution of routes within the 
L3VPN domain.  One has to consider whether the RDs already used by EVPN 
are distinct from the RDs already used by L3VPN.  One has to enable the 
tunneling mechanisms that are used in the L3VPN domain (hopefully the 
EVPN PEs can support those tunneling techniques).  If the L3VPN 
deployment has been set up with particular routing policies (special 
communities carried, or whatever), these need to be configured on every 
EVPN PE.  One needs to take account of whether the L3VPN deployment uses 
segmented P-tunnels or non-segmented P-tunnels, and whether it depends 
upon the use of (C-*,C-*) S-PMSI A-D routes or not.  One needs to 
configure whether the L3VPN is expecting procedures of RFC6514 Section 
13 ("rpt-spt") or whether it is expecting procedures of RFC6514 Section 
14 ("spt-only").  I think there are quite a few other configuration 
items (various timers, and additional stuff that I probably don't even 
know about) that may need to be coordinated with the L3VPN deployment 
with which one is attempting to interwork.

To do interworking between EVPN and L3VPN/MVPN, the L3VPN/MVPN stuff 
obviously needs to be configured at the interworking points.  The 
REQUIREMENT to do ALL this configuration at EVERY single EVPN PE is what 
seems excessive.

Even if one is not doing MVPN/EVPN interworking, all this stuff still 
has to be configured; one just wouldn't have to worry about in that case 
about coordinating with a pre-existing MVPN deployment. But no one ever 
called L3VPN a "low provisioning solution".   EVPN (unlike MVPN), has a 
fair amount of auto-provisioning built-in, and one loses the advantages 
of that if one has to do MVPN provisioning on every PE.

Eric> 3. The draft claims that the exact same control plane should be 
used for EVPN and MVPN, despite the fact that MVPN's control plane is 
unaware of certain information that is very important in EVPN (e.g., 
EVIs, TagIDs).

Ali> IP multicast described in the draft is done at the tenant's level 
(IP-VRF) and not BD level !! So, BD level info such as tagIDs are not 
relevant.

The failure to carry BD level info is what causes the ethernet emulation 
to be done incorrectly.  Remember that most of EVPN is taken from L3VPN, 
with modifications to add stuff that is needed to correctly emulate the 
ethernet service.

Certainly if you look at the control plane used by EVPN to distribute 
unicast IP addresses, you'll see that it does not "just use L3VPN", but 
instead has lots of EVPN-specific stuff.

It's also worth pointing out that the draft does not really use the 
exact same control plane as MVPN, as it seems to require that each IP 
host address be advertised in two routes (an EVPN-specific route and a 
VPN-IP route), and the EVPN-specific routes (types 2 or 5) are now 
required to carry attributes that are typically carried only by the 
VPN-IP routes.  Also, there are the intra-ES tunnels (discussed below), 
something that doesn't exist in MVPN.  And then there are those 
under-specified EVPN-specific 'gateways' (discussed below) that are used 
to connect tunnels of different types.

Eric> 4. The draft proposes to use the same tunnels for MVPN and EVPN, 
i.e., to have tunnels that traverse both the MVPN and the EVPN domains.  
Various "requirements" are stated that seem to require this solution.  
Somewhere along the line it was realized that this requirement cannot be 
met if MVPN and EVPN do not use the same tunnel types.  So for this very 
common scenario, a completely different solution is proposed, that (a) 
tries to keep the EVPN control plane out of the MVPN domain, and vice 
versa, and (b) uses different tunnels in the two domains.  Perhaps the 
"requirements" that suggest using a single cross-domain tunnel are not 
really requirements!

Ali> There are SPDCs with MPLS underlay and there are SPDCs with VxLAN 
underlay. We need a solution that is optimum for both. Just the same way 
that we need both ASBR and GWs to optimize connectivity for inter-AS 
scenarios.

My point is that the document states "requirements", but applies them 
very selectively and very inconsistently.  There is a "requirement" to 
"use the same tunnels for MVPN and EVPN", but there are many deployment 
scenarios in which this "requirement" simply cannot be met.  If the 
"requirement" were stated as "only use tunnels that provide value",  I'd 
have no problem with it.  It seems that many of the specified 
requirements were reverse engineered from the solution as it was 
originally proposed, and then are silently ignored whenever it is 
discovered that they can't be met.

Eric> 5a. In some cases, the "requirements" for optimality in one or 
another respect (e.g., routing, replication) are really only 
considerations that an operator should be able to trade off against 
other considerations.  The real requirement is to be able to create a 
deployment scenario in which such optimality is achievable.  Other 
deployment scenarios, that optimize for other considerations, should not 
be prohibited.

Ali> What deployment scenarios do you think are prohibited ?

The draft does not appear support scenarios in which the MVPN/EVPN 
interworking procedures are confined to a subset of the EVPN PEs, and 
not even visible to the majority of the EVPN PEs.

Eric> While the authors have realized that one cannot have cross-domain 
tunnels when EVPN uses VxLAN and MVPN uses MPLS, they do not seem to 
have acknowledged the multitude of other scenarios in which cross-domain 
tunnels cannot be used.  For instance, MVPN may be using mLDP, while 
EVPN is using IR.  Or EVPN may be using "Assisted Replication", which 
does not exist in MVPN.  Or MVPN may be using PIM while EVPN is using 
RSVP-TE P2MP. Etc., etc.  I suspect that "different tunnel types" will 
be the common case, especially when trying to interwork existing MVPN 
and EVPN deployments.

I note that the latest rev of the draft still does not take this into 
account.

Eric> The gateway-based proposal for interworking MVPN and EVPN when 
they use different tunnel types is severely underspecified.

Ali> Agreed. This will be covered in the subsequent revisions.

It doesn't seem to be in the latest revision.

Eric> One possible approach to this would be to have a single MVPN 
domain that includes the EVPN PEs, and to use MVPN tunnel segmentation 
at the boundary. While that is a complicated solution, at least it is 
known to work. However, that does not seem to be what is being proposed.

Ali> It is not clear to me exactly what you are suggesting here. At the 
boundary, is there any mcast address lookup or not?

If I were working on a proposal like the one in seamless-multicast, I 
would consider whether the MVPN inter-AS segmented P-tunnels feature 
could be leveraged at the border nodes between domains that use 
different tunnel types.  After all, one of the main purposes of MVPN 
inter-AS segmentation is to connect domains that use different tunnel 
types.  Done properly, that does not require any IP lookups at the 
ASBRs.  The draft seems to be trying to reinvent MVPN P-tunnel 
segmentation from scratch.  This is a very intricate part of the MVPN 
specs and you can't just make it up as you go along.

Here is just a selection of some of the problems with section 10.1 
("Control Plane Interconnect") of the -02 revision:

- Much of the document seems to assume that the RTs used in the MVPN 
domain will be the same as the RTs used in the EVPN domain.  If that is 
the case, all the A-D routes from one domain will propagate into the 
other.  This does not appear to be compatible with the sketchy 
description of "gateway" behavior given in Section 10.

- Section 10.1 states that the RD in a Source Active A-D route needs to 
be changed when a such a route is re-originated by a gateway. 
Unfortunately, MVPN requires that the SA A-D route for (S,G) have the 
same RD as the unicast route for S.  So you would need to block all the 
IPVPN routes at the gateway and reoriginate them with new RDs.  The spec 
fails to mention this.  Note that this is not even possible if the EVPN 
PEs share the RTs of the MVPN domain.

- Interesting effects could arise if an EVPN PE chooses a gateway as the 
UMH, but the gateway chooses an EVPN PE as the UMH.  Can you demonstrate 
that this is impossible?

- Section 10.1 says that the C-multicast routes originated by the 
gateway carry the "exported RT list on the IP-VRF".  In MVPN, 
C-multicast routes do not carry the exported RT list, they carry an RT 
created from the VRF Route Import EC of the Selected UMH route.

- Section 10.1 talks about putting the BGP Encapsulation EC on the 
C-multicast routes sent into the MVPN domain.  However, MVPN does not 
make any use of this EC.

- Section 10.1 states that the S-PMSI A-D routes just propagate from one 
domain to the other, but with some unspecified "modifications".

- Leaf A-D routes are not discussed at all, nor is the setting of the 
LIR flag in the PMSI Tunnel attribute.

- Inter-AS I-PMSI A-D routes are not discussed.

This section is still severely underspecified.  It seems to be inventing 
a new way of interconnecting two L3VPN/MVPN domains, but it's not 
"option A", "option B", or "option C", and it's not "segmented 
P-tunnels".  So what is it exactly, and how do we know it works?

Have you thought about cases where multiple domains (i.e., more than 2) 
using different tunnel types are interconnected, perhaps in a cycle?

I think the issue of how to interwork domains that use different tunnel 
types is quite important.  If one wants to interwork an MVPN domain that 
uses mLDP-based P2MP LSPs with an EVPN domain that uses IR, I don't 
think one wants to tell customers that interoperability requires them to 
start using mLDP inside the EVPN domain.  If one is using assisted 
replication (AR) within the EVPN domain, I don't think anyone will want 
to hear "sorry, AR is not supported by MVPN".  I don't think the 
interworking between two domains can be called "seamless" if one has to 
change the tunnel types  of either domain.  But the details for how to 
do the interworking between different tunnel types just don't seem to be 
present.

Furthermore, it is pretty clear that some sort of gateway is going to be 
needed to provide interoperability with RFC 7432 nodes that do not 
implement MVPN; this needs to be addressed as well.

Eric> Another approach would be to set up two independent MVPN domains 
and carefully assign RTs to ensure that routes are not leaked from one 
domain to another.  One would also have to ensure that the boundary 
points send the proper set of routes into the "other" domain.  (This 
includes the unicast routes as well as the multicast routes.)  And one 
would have to include a whole bunch of applicability restrictions, such 
as "don't use the same RR to hold routes of both domains".  I think 
that's what's being proposed, but there isn't enough discussion of RT 
and RD management to be sure, and there isn't much discussion of what 
information the boundary points send into each domain.

Ali> I will expand on that with the RD and RT management aspects. But 
the intention is with a single MVPN domain where both EVPN and MVPN PEs 
participate.

Note that the use of a single RT by both MVPN and EVPN nodes will cause 
routes to be distributed throughout the "single MVPN domain", with no 
opportunity for a gateway to modify the routes.  But section 10.1 does 
seem to require a gateway to modify routes in order to connnect tunnels 
of different types.

Eric> 7. The proposal requires that EVPN export a host route to MVPN for 
each EVPN-attached multicast source.  It's a good thing that there is no 
requirement like "do not burden existing MVPN deployments with a whole 
bunch of additional host routes".  Wait a minute, maybe there is such a 
requirement.

Eric> In fact, whether the host routes are necessary to achieve optimal 
routing depends on the topology.  And this is a case where an operator 
might well want to sacrifice some routing optimality to reduce the 
routing burden on the MVPN nodes.

Ali> If there is mobility, then there is host route advertisement If 
there is no mobility, then prefixes can be advertised.

It seems to me that this is simply not true.  Consider the following 
example:

- BD1 has subnet 192.168.168.0/24.

- BD1 exists on ES1, which is attached to PE1.

- BD2 exists on ES2, which is attached to PE2.  (ES1 and ES2 are not the 
same ES.)

- On BD1/ES1, there are hosts 192.168.168.1, 192.168.168.103, 
192.168.168.204.

- On BD2/ES2 there are hosts 192.168.168.2, 192.168.168.104, 192.168.1.203.

Assume there is no mobility.

In this scenario, I don't see how either PE1 or PE2 can advertise any 
prefix shorter than a /32.  And I don't see how one will prevent all 
these /32 routes from being distributed to all the MVPN nodes.

The fundamental issue here is that while IP addresses can be aggregated 
on a per-BD basis, they cannot be aggregated on a per-ES basis.

I don't think you get "seamless" interworking by requiring all the MVPN 
nodes to receive an unbounded number of host routes.

Eric> 8. The proposal simply does not work when MVPN receivers are 
interested in multicast flows from EVPN sources that are attached to 
all-active multi-homed ethernet segments.

Ali> This issue has been addressed in the new revision.

Yes, this is an improvement.

Suppose PE1 receives an (S,G) IP multicast frame over a local AC from 
BD1/ES1.  And suppose PE2,...,PEn are also attached to ES1. Per the new 
revision, PE1 transmits a copy of the frame on an EVPN-specific tunnel 
to PE2,...,PEn (an "intra-ES1" tunnel), as well as transmitting a copy 
of the contained IP datagram on whatever MVPN tunnel it uses to carry 
(S,G) packets.  Now any EVPN PE attached to the source ES can be 
selected as the UMH by an MVPN node, because all such EVPN PEs get the 
(S,G) frames and can forward forwards them to MVPN receivers.

It's good to see the draft recognizing that IP multicast frames do need 
to be transmitted as frames on EVPN-specific tunnels, in addition to 
being transmitted as packets on MVPN tunnels.  (Of course this solution 
violates the stated "requirement" that a given IP multicast packet not 
be transmitted on two different tunnels. Sigh, another example of 
"requirements" being applied inconsistently.)

However, there are still several problems with this solution.

No control plane is described to support this intra-ES tunneling. Is 
that "for the next revision"? ;-)

There's a suggestion that this solution is trivial, because no one would 
ever home an ES to more than two PEs, and therefore you just have to 
unicast a copy to the other PE.

But the PE receiving a frame has to figure out whether the frame was 
sent to it on an intra-ES tunnel or not, and if so, which ES the tunnel 
is associated with.  It is not clear how the receving PE is supposed to 
make this determination.  One needs to say something more than "just use 
ingress replicaton".

The draft also suggests that "multi-homed" always means "dual-homed", 
which I don't think is acceptable.

Note also that a scheme like this causes EVERY (S,G) frame to get sent 
to EVERY PE that is attached to S's source ES.  This happens even if 
there are NO receivers anywhere interested in (S,G) at all. In effect, 
the LAG hashing algorithm is defeated.  If a switch is multi-homed to n 
PEs, it uses a LAG hashing algorithm to ensure that any given packet is 
sent to just one of those PEs.  Then one EVPN PE gets the packet and 
sends it to the other n-1 PEs, who have to treat the packet as if it had 
just arrived on the AC from the multi-homed switch.  Iit would be better 
to have a "pull model" where PEx gets the (S,G) packet from PE1 only if 
some MVPN PE has sent a C-multicast (S,G) or (*,G) route to PEx.

In addition, the latest rev of the draft is still confused about the way 
UMH selection is done.  It seems to assume all the PEs will select the 
same "Upstream PE" for a given (S,G).  While this is one possible option 
(generally referred to as Single Forwarder Selection), it is not 
required, and I believe the most common deployment scenario is to use 
the "Installed UMH Route" as the "Selected UMH Route".  (See section 
5.1.3 of RFC 6513.)  This means that it is always possible for a PE to 
receive more than one copy of an (S,G) packet, and the PE must therefore 
always be able to apply the "discard from the wrong PE" procedures of 
RFC 6513 Section 9.1.1.

Suppose for example that EVPN-PE1 transmits its IP multicast frames on 
an I-PMSI that is instantiated by a P2MP LSP.  EVPN-PE2 will have to 
join that I-PMSI.  If PE1 and PE2 are both attached to BD1/ES1, then 
when PE1 gets an (S,G) IP multicast frame from BD1/ES1, PE2 will get two 
copies: one on the intra-ES1 tunnel from PE1 and one on the I-PMSI 
tunnel from PE1.  PE2 will probably choose itself as the "Upstream PE" 
for (S,G), in which case it needs to discard the copy that arrives on 
the I-PMSI tunnel from PE1, while accepting the copy that arrives on the 
intra-ES1 tunnel from PE1.  (If PE2 for some reason chose PE1 as the 
Upstream PE for (S,G), it would have to discard the copy arriving on the 
intra-ES1 tunnel and accept the copy arriving on the I-PMSI tunnel.)  
The draft seems to imply, incorrectly, that the "discard from the wrong 
PE" procedure is not necessary.

The "discard from the wrong PE" procedures are also needed to handle the 
case where the source is at a site homed to two or more MVPN PEs, and 
there are MVPN receivers that do not do single forwarder selection.  
This may cause some packets to appear on multiple I-PMSIs, and each 
EVPN-PE will have to join all the I-PMSIs, of course.

(The use of S-PMSIs rather than I-PMSIs does not eliminate this 
problem.  A given S-PMSI from PE1 might carry a flow that PE2 needs from 
PE1, and it might also carry a flow that PE2 is getting on an S-PMSI 
from PE3.)

Please note that if MPLS ingress replication is being used, the "discard 
from the wrong PE" functionality requires that the egress PE be able to 
tell from a packet's encapsulation when a packet is from the wrong 
ingress PE.

If the MVPN nodes are using the "extranet" feature (RFC 7900), "discard 
from the wrong PE" is not actually sufficient, one needs to "discard 
from the wrong ingress VRF".

Since there is no clean layering between MVPN and EVPN protocols in this 
proposal, every little nit and corner case of MVPN has to be examined to 
make sure it will also work in the EVPN domain.

Another problem: according to the draft, if an EVPN PE, say PE1, learns 
of a source via a locally attached all-active multi-homed ES, it will 
originate an IP route for that source.  Consider another PE, say PE2, 
attached to the same multi-homed ES.  When PE2 receives that IP route 
from PE1, PE2 will then originate its own IP route for that source.  
Since PE1 receives PE2's route, it is not clear how the route ever gets 
withdrawn.  If PE1 stops seeing the local traffic, it will still see 
PE2's route, and hence will still originate its own route.  One might 
think this is easily fixed by attaching to PE1's route an EC that 
declares that route to be "authoritative"; PE2's route would not have 
that EC.  Note though that the adding or removal of this "authoritative" 
EC will cause some churn that will be visible to the MVPN-only nodes, 
even though it does not provide them with any useful information.

I would also like to take note of the following issue.  From the draft:

"The EVPN PEs terminate ...  PIM messages from tenant routers on their 
IRB interfaces, thus avoid sending these messages over MPLS/IP core."

A PIM control message from a given PIM router needs to reach whichever 
other PIM router is a possible unicast next hop for any multicast source 
or RP.  The scheme of having each EVPN PE terminate the PIM messages 
presupposes that each tenant router will have the nearest EVPN PE as its 
unicast next hop towards the multicast source or RP.

This is likely to be a common scenario, but it certainly is not the only 
scenario.  A tenant might have several PIM routers on a given BD, where 
each PIM router is attached to a different PE.  The PIM routers could be 
IGP neighbors in the tenant's IGP, and may be exchanging IGP updates 
with each other.  In this case, PIM control messages from one tenant PIM 
router on the BD need to reach the other tenant routers on the BD.

For example, suppose Tenant Router R1 on BD1 attaches to PE1, and Tenant 
Router R2 on a different ES of BD1 attaches to PE2.  If R1 and R2 are 
IGP neighbors, R2 may see R1 as the next hop to a given source S.  In 
that case, R2 may choose to target a PIM Join(S,G) to R1.

In this scenario, the PIM control messages between R1 and R2 have to be 
sent between PE1 and PE2.  Since PIM control messages have a TTL of 1, 
they would have to be sent on BD1's BUM tunnels rather than on the IP 
multicast tunnels.

Now the question is, if R2 sends PIM Join(S,G) to R1, how does R2 get 
the (S,G) traffic from R1?  Either PE1 has to send it on BD1's BUM 
tunnel, or else PE2 has to figure out that it needs to pull (S,G) 
traffic from PE1 on an IP multicast tunnel.  The spec needs to explain 
how this situation is handled.  If the (S,G) traffic travels on BD1's 
BUM tunnel, the spec also has to make it clear how that traffic gets to 
other BDs.

BTW, section 6.5 of the draft says that any frame containing an IP 
packet whose destination address is in the range 224/8 is sent as a BUM 
frame.  I suspect that 224.0.0/24 is what is meant, as that seems to be 
the IPv4 multicast link-local address space.

One more thing.  The draft says that SPT-ONLY (RFC 6514 section 14) mode 
should be the default configuration.  This has several problems:

- SPT-ONLY mode requires each PE to function as an RP, which creates a 
considerable amount of additional work for the PE (handling the register 
messages and maintaining a large number of (S,G) states). It also 
requires the PE to originate a Source Active A-D route for each (S,G), a 
route that would not otherwise be needed.

- If the tenant or MVPN customer already has a multicast infrastructure 
with Rendezvous Points (RPs), it may be impossible to use SPT-ONLY mode, 
as this mode may not be compatible with the customer/tenant's 
infrastructure.  However, it may still be desirable to have RP-free 
operation for multicast groups whose sources and receivers are all in 
the EVPN domain.

- SPT-ONLY mode can sometimes be made compatible with an existing 
tenant/customer multicast infrastructure by having the PEs participate 
in the BSR or Auto-RP protocols, and/or by having the PEs participate in 
MSDP.  This would not generally be regarded as a simplification.

- If one is interworking with an MVPN whose PEs are configured to use 
RPT-SPT mode (RFC 6514 section 13), one must configure the EVPN-PEs to 
use RPT-SPT mode as well, because the two modes are not interoperable.  
I believe most MVPN deployments use RPT-SPT mode.

So I don't see the grounds for recommending the SPT-ONLY mode as the 
default.  The choice between SPT-ONLY mode and RPT-SPT mode depends on 
many factors and requires knowledge of (a) a particular tenant's 
deployment scenario, and (b) if MVPN interworking is being done, the 
mode that is being used by the MVPN nodes.