Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

> On Aug 5, 2016, at 8:01 AM, Dino Farinacci wrote: > >> In addition, while you are trying to optimize for one particular >> implementation and architecture, the long term results of these decisions >> tend to impact many more platforms than the original one. For example,

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

Actually recomposing the VXLAN/LISP splitting was another design goal of VXLAN-GPE. A VXLAN-GPE implementation can share most of its code with a LISP implementation, contributing to the reduction of test and implementation cost. Fabio On 8/5/16 9:21 AM, Jesse Gross wrote: On Aug 5, 2016,

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

> On Aug 4, 2016, at 5:53 PM, Fabio Maino wrote: > Tom, > it's more than just infeasibility that should be considered as part of the > technical evaluation, but also the cost/complexity associated with > implementations. > > Encapsulations are not implemented in a vacuum,

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

> In addition, while you are trying to optimize for one particular > implementation and architecture, the long term results of these decisions > tend to impact many more platforms than the original one. For example, VXLAN > was derived from LISP with the same goals as you are describing here.

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

> Tom, > it's more than just infeasibility that should be considered as part of the > technical evaluation, but also the cost/complexity associated with > implementations. > > Encapsulations are not implemented in a vacuum, but compete with other > features for resources available in a given