Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

[[e-mail]]

Jordi,

> I’m NOT in favor of including an unlimited number of mechanisms, and I think we must focus in those that have a real traction. I’m NOT in favor of including LISP.
> 
> However, the document is a WG document, so is not just my decision, but the WG, so I must ask the WG opinions before “rejecting” LISP. That was my question.
> 
> I think we need to have a balance:
> 1) Main goal, support of IPv6-only access but allow IPv4 to keep working in the customer’s LANs.
> 2) Allow the support of “older” IPv6-in-IPv4 (basically 6rd) as it was in the previous version of the document, but moved to MAY. Deployments that today have IPv4-only access, can start deploying IPv6 (in IPv4 if they need it), but use the same CE for when they can move to IPv6-only access.

Which is a bit ironic with regards to 6RD which is one of the few mechanisms with real deployment, as in millions and millions of users.

>3) Support a subset of IPv4-in-IPv6 (from all those that IETF designed), based on market relevance and understanding that most of them don’t take additional code in the CPE, because most of this code is basically the same.

That statement is not quite true. The various mechanisms while largely being built out of the same parts, require quite a bit of glue, testing and additional support for configuration. If you think the conflict around hosts/network DNS recursive resolver configuration is hard, then this is a n-square problem.

For implementation complexity just compare MAP-T and MAP-E/LW46 in:
https://git.fd.io/vpp/tree/src/vnet/map

> So, to make it short, unless there is a “magic” mechanism that I’m not aware of, and the WG decides to include it, my intend is no longer include anything new in the document. And if that “magic” mechanism exists, then we could delete all the others.

The magic is in us having the balls to make a choice. And pick one mandatory to implement mechanism. And only one.

Cheers,
Ole