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

[<[e-mail]>]

Hi Ole, 

I tend to agree with you but with a slightly different proposal:  pick ONE mandatory stateful mechanism (DS-Lite) and ONE mandatory A+P mechanism (MAP-E). 

FWIW, the following tables recap the required functionality to be supported by the CPE for DS-Lite, lw4over6, and MAP-E + required provisioning information for each of them.

   +--------------+----------------+-----------------+-----------------+
   |   Functional |  IPv4-in-IPv6  | Port-restricted | Port-restricted |
   |      Element |     tunnel     |       IPv4      |      NAT44      |
   |              |    endpoint    |                 |                 |
   +--------------+----------------+-----------------+-----------------+
   |           B4 |      Yes       |       No        |       No        |
   |         lwB4 |      Yes       |       Yes       |       Yes       |
   |     MAP-E CE |      Yes       |       Yes       |       Yes       |
   +--------------+----------------+-----------------+-----------------+

                        Table x: Supported Features

         +---------+---------------------------------------------+
         |    Mode | Provisioning Information                    |
         +---------+---------------------------------------------+
         | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint Address |
         |   Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint Address |
         |         | IPv4 Address                                |
         |         | Port Set                                    |
         |   MAP-E | Mapping Rules                               |
         |         | MAP Domain Parameters                       |
         +---------+---------------------------------------------+

                     Table x: Provisioning Information
Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[e-mail]] De la part de
> [e-mail]
> Envoyé : mercredi 12 avril 2017 12:57
> À : [e-mail]
> Cc : [e-mail]
> Objet : Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00
> 
> 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