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

[Ashutosh Gupta <[e-mail]>]

Hey Jeffrey,

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

On Fri, Jul 20, 2018 at 9:53 AM, Jeffrey (Zhaohui) Zhang <[e-mail]
> 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>* s*eamless-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.

>
>
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. 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.

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.

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 *s**eamless-Interop* by
utilizing SPT-only mode of MVPN in which shared multicast trees are not
formed in the core.

Thanks.
> Jeffrey
>
>
> Regards,
Ashutosh


> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess