<no hats on> > On 25 Aug 2015, at 18:27, Dino Farinacci <[email protected]> wrote: > > I agree with everything Fabio stated. To me this means, in totality, we > support the following data-planes and corresponding well-known port numbers: > > (1) L3 LISP ala RFC 6830, port 4341 > (2) L2 LISP ala Smith Internet Draft, port 8472 > (3) VXLAN already in the field, port 4789 > (4) LISP-GPE, port 4341
I do not think this would work. How can you make the difference between a LISP-GPE and a LISP header when both use the same UDP port? You would need side information about whether or not an xTR supports or not the LISP-GPE header. Feasible, but I fear that we will end up with so many corner cases that will make the solution complex. Further, LISP-GPE and VXLAN-GPE are so similar that makes me wonder why should we have both? L. > (5) VXLAN-GPE, port 4790 > > And nothting else. > > Supporting (4) and (5) will allow (2) and (3) to eventually go away. Which > means we end up with port 4341 for L2 and L3 overlay support using a LISP > header, and L2 and L3 overlay support using a VXLAN header. > > And the LISP header and the VXLAN header look so much alike that we can > conclude that VXLAN is just a less-feature data-plane than LISP. > > We go this route, we head in a direction of *less* encapsulations that do > *more* functionality than we have today. > > Dino > >> On Aug 25, 2015, at 7:08 AM, Fabio Maino <[email protected]> wrote: >> >> 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 > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
