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

Hi Ashutosh,

Sorry for the late response. Please see zzh> below.

From: Ashutosh Gupta <ashutoshgupta.ietf@gmail.com<mailto:ashutoshgupta.ietf@gmail.com>>
Sent: Wednesday, August 15, 2018 3:57 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: Ali Sajassi <sajassi@cisco.com<mailto:sajassi@cisco.com>>; bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

Hey Jeffrey,

Thanks for your comments & please find my responses inline <AG> .

On Fri, Jul 20, 2018 at 9:53 AM, Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:
Hi Ali,

Here are the comments that I did not get a chance for in the meeting today.

Regarding "ttl decrement" and "src mac change":
------------------------------------------------------------------

Since "bridging/switching in the same BD" is not put down as a requirement in the spec but rather discounted citing "emulation", the listed "requirements" should be changed to "properties" as well - one could also argue that those may not be true requirements and could also discounted.

<AG> seamless-Interop solution supports both intra-subnet and inter-subnet forwarding which are the basic requirement along with Efficient fabric utilization and Operational simplicity. More specifically, having many discussions with customers we didn't come across any use-case where strict intra-subnet bridging was needed along with inter-subnet routing, so we can argue that "strict bridging/switching in the same BD" is just an idealistic requirement.

Zzh> The point is, those “requirements” are really somewhat arbitrary/subjective. We have not heard real requirements about “seamless integration” either, and even when the requirement comes, the OISM can do that seamless integration by having every EVPN as an MEG.

Even if RFC7432 does not prove true ethernet service, "ttl decrement" and "src mac change" for intra-subnet traffic does NOT happen with RFC7432. In other words, this is a step-down from RFC7432.

<AG> It is not a step down since we are not losing any needed functionality.

Zzh> It is a step down from what RFC7432 provides. The argument that TTL/mac change for intra-subnet is not an issue is subjective.

Again, seamless-interop solution utilizes existing and well deployed technology (MVPN) instead of re-defining all the constructs of MVPN into EVPN. evpn-irb-multicast draft takes later approach and achieves in-signification functionality gain at the expense of huge overhead in control-plane (Explained on a separate thread). From our customer interactions, we understand that Multicast is a complex technology to deploy, operate and troubleshoot. So any amount of simplification results in Opex reduction. Additionally, re-use of existing MVPN implementation for additional EVPN use-cases results in quick time-to-market with lower investment.

Zzh> Please see Eric’s comment on a separate thread. Both Eric and I are from MVPN background - trust us that we’d not be against “just use MVPN” if it solves EVPN problems effectively.
Zzh> BTW, with the seamless approach, aren’t you guys abandoning the SMET solution defined in draft-ietf-bess-evpn-igmp-mld-proxy?

About the comment "MVPN also decrements ttl and change src mac address" - that's expected behavior because it is routing between subnets not "intra subnet", and no application that uses MVPN service has assumption on constant TTL and src mac.

More regarding the "requirements" (or "properties")
-----------------------------------------------------------------------

With the other solution (evpn-irb-multicast, aka OISM), if every EVPN PE runs the MEG procedures then the same set of "requirements" is also achieved - it is also "seamless interop" but based on the OISM procedures, but that does not "translate into this method" (as defined in the seamless-interop draft) (I think that's what you mentioned when addressing Jorge's comment). What's more, it does not have the "ttl decrementing" and "src mac change" issue for intra subnet traffic.
<AG> The point was made that once multicast traffic reaches MVPN domain, it doesn't belong to any specific BD and hence intra-subnet and inter-subnet receivers are treated similarly. Even with evpn-irb-multicast solution, it would be the same unless a second copy of traffic is send over BD specific tunnel.

Zzh> But for traffic reaching MVPN domain, we don’t need to worry about TTL and src mac address change, while we do need to worry about that on EVPN side in case of intra-subnet. Indeed separate copies are sent for EVPN and MVPN, but the MVPN copy is only when a remote MVPN PE is not also an EVPN PE. It’s hard to argue that removing that one extra MVPN copy (that is sent towards MVPN-only PEs) is a hard “requirement”.
Zzh> A bit more elaboration on the above “extra copy”. While the traffic is sent on a BD specific tunnel and on an MVPN tunnel, if we’re using ingress replication then there is no extra copy at all – one copy is sent to each EVPN PEs (the EVPN tunnel) and one copy is sent to each MVPN-only PEs (the MVPN tunnel) and there is no overlapping. If we’re using p2mp/BIER, then there is at most one extra copy (for the tunnel to reach all MVPN-only PEs) on the outgoing link, not one extra copy for each MVPN-only PE. That is not bad at all.

Regarding "9.  DCs with only EVPN PEs"
----------------------------------------------------

For comparison, the OISM method does not need any provisioning/procedures related to RP and registering. That is a significant simplification that an EVPN-only operator should be aware of.
<AG>  Same functionality is achieved in seamless-Interop by utilizing SPT-only mode of MVPN in which shared multicast trees are not formed in the core.

Zzh> This is where OISM has a tremendous advantage, besides that it does switching (vs. routing) for intra-subnet traffic. On EVPN-only PEs, only (*,g) state (control plane and data plane) is needed and the concepts of RP, RPT/SPT and switch do NOT exist on EVPN-only PEs.

Zzh> it just is not true that SPT-only mode eliminates provisioning/procedures related to RP and registering.  It does NOT change the following facts:

-         With MVPN spt-only mode, each PE still needs to be aware of RP (or itself must be a RP or have an MSDP session with the RP) so that it can  register with a RP (which could be another PE or outside the EVPN domain). It is that registration that causes the MVPN type-5 routes to be advertised, data driven.

-         There will be (s,g) MVPN type-5 routes installed on ALL PEs, and (s,g) forwarding state installed on all PEs that need to send/receive the traffic. This is a larger scaling concern than having to install MPLS label routes for all BDs on all PEs of a tenant (a concern you raised and Eric commented about in another thread).

Zzh> Additionally, the MVPN instance may very well have to run the rpt-spt mode (shared tree across the core) because some providers (and some of their customers) do not want to change the customer’s RP infrastructure (and bring RP functionality to the PEs). In that case, If some group traffic has sources on both evpn side and mvpn side then rpt-spt mode has to be used even for EVPN sources (even if some other groups only has EVPN sources, since the mode is not on a per-group basis).

Thanks.
Jeffrey

Regards,
Ashutosh

_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=AJQjCmLI3ezSlB5d0_On7W688YzYCCkRPfwSYAirEVc&s=ye7h4lnggye9zWJvSJVNDwpngr2n-ozakKEDYWSK6LM&e=>