Dino,
I thought that lisp-crypto was overlapping with the use of P bit
already. My mistake: I see that the picture in the lisp-crypto draft
mentions indeed the P bit.
I think what GPE is trying to propose, is an extension to the LISP
protocol that together with crypto would allow LISP to handle a set of
"features": multiprotocol, services, metadata... IMO, if we have to
change the data path, we should rather look at a change that enables a
set of "features" rather than a single one.
Fabio
On 7/8/14, 1:39 PM, Dino Farinacci wrote:
2) the layout does not fit well with draft-farinacci-lisp-crypto-00. Are
there any plans to solve this? Should this at least be mentioned somewhere?
Both this draft and lisp-crypto are proposals to extend the LISP encap with new
features. I don't think they need to refer each other at this point.
I just note that by adding multiprotocol support, one could add a shim header
that provides encryption services to the LISP payload.
When I selected the location of the K bits, I knew the P-bit was predefined in
the gpe draft, so I didn't use that location. There are no flag bits left if
GPE and lisp-crypto are accepted as working group items.
Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
