Re: [v6ops] Trajectory for "transition" mechanisms in our working group

Jordi,

> I stated clearly CLAT not the complete 464XLAT.

Packet path for the CE. Including in the case of CLAT the two stateful NATs. SIIT etc.
Another metric is to measure the number of cycles used to process the packet. Compare CLAT processing and non-translation solutions.
CLAT comes worse off both in matter of cycles and lines of code, and likely provisioning.
Enough to care… who knows. My point was, just stop spreading incorrect information. You can not claim that CLAT is simpler/cheaper/faster to implement than the others.

Ole

> -----Mensaje original-----
> De: Ole Troan <otroan@employees.org>
> Fecha: jueves, 18 de octubre de 2018, 10:37
> Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
> CC: Mikael Abrahamsson <swmike@swm.pp.se>, Lee Howard <lee@asgard.org>, <v6ops@ietf.org>
> Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working group
> 
>    Jordi,
> 
>    So the metric you use to justify your claim is code size?
> 
>> I've posted some time ago a comparison in terms of code size in OpenWRT comparing all the IPv4aaS, not going to repeat that, just for short, CLAT code size in OpenWRT is 4 Kbytes: https://openwrt.org/packages/pkgdata/464xlat
>> 
>> I can see the code simplicity at:
>> 
>> https://github.com/openwrt-routing/packages/blob/master/nat46/files/464xlat.sh
>> 
>> If you remove the comment lines, is less than 100 very simple code lines.
>> 
>> Of course, there are other implementations, all can be googled for, such as Jool, Android, VPP and the one from Tore Anderson.
> 
>    But if your claim had been correct, then the other mechanisms would have had more code lines right?
>    And you do need to include the whole packet path. And provisioning.
> 
>    Either you substantiate your claim, or you stop making it. I would suggest the latter would save both you, me and the list some time.
> 
>    Ole
> 
> 
>> -----Mensaje original-----
>> De: Ole Troan <otroan@employees.org>
>> Fecha: jueves, 18 de octubre de 2018, 10:10
>> Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
>> CC: Mikael Abrahamsson <swmike@swm.pp.se>, Lee Howard <lee@asgard.org>, <v6ops@ietf.org>
>> Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working group
>> 
>>  Jordi,
>> 
>> 
>>> I guess you're forgetting the CLAT, which is the simpler one to implement as part of the packet accelerator.
>> 
>>  Can you substantiate that? By what metric.
>>  If you look at number of lines of code, amount of state, or even provisioning complexity you are wrong.
>> 
>>  Ole
>> 
>> 
>>> 
>>> All what you mention is the reason I started the work on draft-palet-v6ops-transition-ipv4aas, which unfortunately take much longer than expected.
>>> 
>>> We need to point the SoC vendors, not just the CE vendors, to this document.
>>> 
>>> Regards,
>>> Jordi
>>> 
>>> 
>>> 
>>> -----Mensaje original-----
>>> De: v6ops <v6ops-bounces@ietf.org> en nombre de Mikael Abrahamsson <swmike@swm.pp.se>
>>> Organización: People's Front Against WWW
>>> Fecha: jueves, 18 de octubre de 2018, 9:34
>>> Para: Lee Howard <lee@asgard.org>
>>> CC: <v6ops@ietf.org>
>>> Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working group
>>> 
>>> On Thu, 18 Oct 2018, Lee Howard wrote:
>>> 
>>>> Yannis, I'm interested in hearing more about what isn't working well, 
>>>> either on-line or directly.
>>> 
>>>> From my experience, the biggest problem is the same as Yannis is 
>>> presenting, it's all about HGW support for these things. The major vendors 
>>> support 6to4, 6RD and ds.lite (plus regular dual stack). Then it's 
>>> problematic.
>>> 
>>> One of the major SoC vendors had a packet accelerator problem with LW4o6 
>>> in that the accelerator "forgot" to NAT44 the packets when it took over 
>>> the flow. I spent 9 months getting nowhere until finally I managed the use 
>>> threats to get through to some engineering people and explain my case. 
>>> They fixed the problem 2 weeks later. They said they didn't first 
>>> understand what I wanted, and basically had asked the wrong question 
>>> internally and then probably got a "err, no, not justified by the business 
>>> case".
>>> 
>>> But now I have a fully working, fully accelerated LW4o6-supporting gigabit 
>>> ethernet (can actually do that) HGW for LW4o6 use-case on active-ethernet.
>>> 
>>> Someone else might want to do this over PPPoE, so then you might be in 
>>> trouble again because the accelelator might not support the 
>>> LW4o6-over-IPv6-over-PPPoE case. I don't know, I haven't tested it because 
>>> in my deployment we don't do PPPoE.
>>> 
>>> So the problems aren't really technical, they're all business related. The 
>>> vendors are doing pushback on all these different versions of doing pretty 
>>> much the same thing, that all require development resources.
>>> 
>>> So let me list some of the common use-cases the IETF/ISPs basically is 
>>> asking them to support.
>>> 
>>> 6to4
>>> ds.lite
>>> LW4o6
>>> MAP(-e and -t)
>>> 6RD
>>> 
>>> all of the above over:
>>> 
>>> PPPoE over DSL, PON and ethernet
>>> PPPoA over DSL
>>> Native Ethernet
>>> 
>>> ..... plus probably something else I forgot. That's tens of different 
>>> combinations for doing what looks to be almost the same thing. Some others 
>>> also expect them to have multiple VLANs on WAN, because that's how the 
>>> operator likes to deply their IPTV and VoIP service.
>>> 
>>> The linux kernel does all of the above, but the packet accelerators 
>>> typically in these kinds of devices do not support all of it. There are 
>>> lots of different platforms, and all customers have whole departments that 
>>> are penny-pinching price on each device when doing procurement.
>>> 
>>> Things are improving as the business ecosystem is moving to more common 
>>> operating systems and fewer platforms, but it's still an issue, and it's 
>>> going to be an issue for a long time.
>>> 
>>> The vendors don't typically jump on whatever new stuff the IETF came up 
>>> with last month, I've heard some who say "we typically wait 2-3 years 
>>> until we consider implementing an RFC to see if it actually gets some 
>>> support".
>>> 
>>> -- 
>>> Mikael Abrahamsson    email: swmike@swm.pp.se
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>>> 
>>> 
>>> 
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.consulintel.es
>>> The IPv6 Company
>>> 
>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> 
>> 
>> 
>> 
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.consulintel.es
>> The IPv6 Company
>> 
>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>> 
>> 
>> 
> 
> 
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> 
> 
> 