> 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.
Not sure why I would want to do that. I would like all designs to play together nicely and not look like they were done in silos. > 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. Yes, if they can be added at the same time. But typically has happened and we have seen this with LISP since 2007 that features get added over time in subsequent generation products. And I have been put on record many times for not changing the data plane. IMO, the P-bit is a change that doesn't really add anything new but does something for another data-plane. That probably does not have a good cost/benefit tradeoff. Howver, service chaining is a completely different matter. Dino > > 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
