Hey Jeffrey, Thanks for your comments & please find my responses inline *<AG>* .
On Fri, Jul 20, 2018 at 9:53 AM, Jeffrey (Zhaohui) Zhang <[email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
