As an author, I certainly support inclusion of VXLAN-GPE (and its
counterpart LISP-GPE) and I'll continue to contribute to that work.
Given the wide availability of VXLAN in many HW and SW platforms, it may
make sense to include VXLAN as well, especially for the NVO3 use cases.
Note that with VXLAN-GPE, support for VXLAN will come almost implicitly.
Fabio
On 8/25/15 2:02 AM, Luigi Iannone wrote:
Hi All,
Thanks from the reply so far.
What I gather is that there is interest in extending the LISP overlay model to
support other data-planes.
What remain unclear is what those data-planes should be.
Note that it is impossible to cover all existing data-planes.
Would be helpful if the group gives a clearer direction by suggesting a set
encaps to add support for.
(this include as well the willingness to directly contribute to the work)
ciao
L.
On 10 Aug 2015, at 00:05, Luigi Iannone <[email protected]> wrote:
Hi,
LISP provides a rather complete and powerful control-plane, where
by means of LCAF, possibly any existing namespace can be mapped
on each other.
However, the data-plane is not as flexible. The current specifications
allow only IPv4 over IPv6 and vice versa.
In order to create what Sharon Barakai defined “map assisted overlays”
more work is needed.
In this context the WG should also decide whether just an extended/enhanced
data-plane is sufficient/needed. Or should the scope be slightly larger and
allow as well to support multiple headers type?
Such header are not necessarily defined by the LISP WG
(e.g. VXLAN-GPE, GENEVE, GUE, etc.)
Would the WG be interested in working in extending the LISP overlay model
in order to provide data-plane support for what the control plane already
allows?
And what should be the scope?
Joel & Luigi
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
