> Agreed. Given that considerable time has past since the initial decision > and as long as we are re-visiting it, why not adopt VXLAN ? It has seen
Well that was my vote but that was isn’t in the list of candidates. And we know that VXLAN can support both L2 and L3 overlays. Just in the L3 overlay case, we waste 14 bytes of packet overhead. But I know merchant silicon can support this already. So you bring up a good point Michael. > considerable deployment and implementation. Its format is compatible with > LISP which serves to provide a common frame format for L2 and L3 overlays. I would argue this ship has already sailed and this is indeed defacto standard. > One issue raised in the meeting was that VXLAN is an independent track > RFC. I may be naïve, but this seems fairly easy to remedy. Worst case, Agree. > call it something else, change the UDP port number (I’m not aware of any > hardware implementations that couldn’t handle changing the port number), Agree. > or revive the pre-VXLAN L2 LISP draft. Agree. Dino > > On 7/26/16, 9:31 AM, "Dino Farinacci" <[email protected]> wrote: > >> The IETF should not encourage more options. Standards are suppose to >> unify interoperability not cause more combinations. >> >> And every decade IETF picks 3 options. Just think if the IETF could >> produce fast? ;-) >> >> Stop the bleeding, >> Dino >> >>> On Jul 26, 2016, at 9:26 AM, Michael Smith (michsmit) >>> <[email protected]> wrote: >>> >>> Users already have to deal with multiple solutions for network overlays >>> in >>> the form of VXLAN and NVGRE. Neither of which is listed as an option >>> here. >>> Picking 1 more solution or 3 more solutions won¹t improve that. >>> >>> On 7/25/16, 6:57 PM, "nvo3 on behalf of Tom Herbert" >>> <[email protected] on behalf of [email protected]> wrote: >>> >>>>> I believe that others are in a similar position but opposite with >>>>> regards to >>>>> technical choices. The net result is that there are almost certain to >>>>> be >>>>> multiple formats in the wild regardless of what is decided here. Yes, >>>>> that >>>>> means letting the market decide rather than the IETF. I honestly don't >>>>> necessarily see that as a negative since it means that it will be >>>>> based >>>>> on >>>>> experience rather than theoretical arguments. I don't even think that >>>>> it >>>>> will cause more confusion or set back the industry given that >>>>> timescales of >>>>> ~5 years are being talked about for a new compromise encap if that >>>>> were >>>>> to >>>>> come to be. >>>>> >>>> I would like to meet the user who thinks having multiple interoperable >>>> solutions that do pretty make the same thing is a good idea. >>>> >>>> _______________________________________________ >>>> 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
