And you kill multicast applications as well. The point of multicast is to save replication bandwidth at the source and bandwidth in the network by sending a single encapsulated packet using an outer multicast destination address. But now you have to undo all of that because some NVEs do VXLAN, another NVGRE, etc.
Dino > On Jul 26, 2016, at 3:05 PM, Anton Ivanov <[email protected]> > wrote: > > On 26/07/16 22:52, Lucy yong wrote: >> All three can’t interwork with VXLAN nor NVGRE. To interwork with them, an >> end point has to support multiple encaps and sync with peer what to use by >> configuration or control plane. > > I would not call that interworking. > > For me (and I have written more than one paravirtual vNIC driver) means that > a driver for encaps A can parse and produce frames in encaps B solely by > means of configuration. > > The interworking between these three from a technical point of view is > EXACTLY ZERO. > > A. > >> >> Lucy >> >> From: nvo3 [mailto:[email protected]] On Behalf Of Reith, Lothar >> Sent: Tuesday, July 26, 2016 4:45 PM >> To: Alia Atlas; Joe Touch >> Cc: Tom Herbert; Michael Smith (michsmit); [email protected]; Matthew Bocci; >> Paul Quinn; Dino Farinacci; Jesse Gross; Larry Kreeger >> Subject: Re: [nvo3] Consensus call on encap proposals >> >> Hi Alia, >> >> I fully support your approach. I am strongly in favor of moving forward >> with one standards track encap. >> >> May be it would be an approach to try and agree on a handful of criteria, >> such as extensibility, backwards compatibility with VXLAN and/or NVGRE, >> number of running code, ease of hardware implementation (evidenced by number >> of running hardware code), interoperability with VXLAN/NVGRE, Security, Cost >> in terms of protocol overhead, Cost in terms of scarce numbering resources, >> interoperability with legacy deployments in the field, support by deployed >> control planes, and yes: Simplicity (the opposite of complexity). >> >> Did I miss any important category? >> >> One could agree on the categories, agree on a process to rank the 3 >> candidate protocols – e.g. identify the best and the worst by the number and >> severity of objections in that category, the third is in the middle. >> >> The final rank would be average of the ranks per category. That one should >> be promoted to standards track. >> >> One could consider flipping a coin to decide the rank in a category – but >> only in a contentious situation between 2 of the 3 candidates. >> >> Lothar >> >> >> >> Von: nvo3 [mailto:[email protected]] Im Auftrag von Alia Atlas >> Gesendet: Dienstag, 26. Juli 2016 22:05 >> An: Joe Touch <[email protected]> >> Cc: Tom Herbert <[email protected]>; Michael Smith (michsmit) >> <[email protected]>; [email protected]; Matthew Bocci >> <[email protected]>; Paul Quinn <[email protected]>; Dino Farinacci >> <[email protected]>; Jesse Gross <[email protected]>; Larry Kreeger >> <[email protected]> >> Betreff: Re: [nvo3] Consensus call on encap proposals >> >> On Tue, Jul 26, 2016 at 3:50 PM, Joe Touch <[email protected]> wrote: >> >> >> On 7/26/2016 12:42 PM, Alia Atlas wrote: >> ... >> >> The question is: >> >> (1) Should the WG move forward with one standards track encap? >> >> I've heard a lot of concern that we just can't do it, that it's too late, >> etc. >> >> I don't think it's ever "too late", but I also don't see consensus forming >> either. >> >> It may be that many folks are recovering from IETF and not responding yet. >> >> ... >> We can always flip a coin - if the solutions are technically equivalent and >> so is the >> support. >> >> That defines "random", not "consensus". >> >> It's not a preferred way - but it's a way of breaking a deadlock. >> Of course, the WG would have to have consensus on that being the decision >> process. >> Take a read through RFC 7282. I keep praising it because it gives really >> good perspectives. >> >> >> >> Joe >> >> >> >> >> _______________________________________________ >> nvo3 mailing list >> >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
