Having VXLAN as an Independent Stream RFC gives a document to be used to innovate from. I believe that was the intent of VXLAN-GPE - to provide the ability for needed extensions.
>From an IETF perspective, it is critical to have an encapsulation that can provide reasonable OAM and at least the potential for security when the industry is ready. Regards, Alia On Tue, Jul 26, 2016 at 2:59 PM, Michael Smith (michsmit) < [email protected]> wrote: > 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 > considerable deployment and implementation. Its format is compatible with > LISP which serves to provide a common frame format for L2 and L3 overlays. > 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, > 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), > or revive the pre-VXLAN L2 LISP draft. > > 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
