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

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 20 Jul 2018 16:53:04 +0000

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.

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.

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.

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.

Thanks.
Jeffrey