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

[JORDI PALET MARTINEZ <[e-mail]>]

> On Apr 12, 2017, at 10:44 AM, JORDI PALET MARTINEZ <[e-mail]> wrote:
    > 
    > [Jordi] I disagree here. Adding the actual transition mechanism (all them) in the v-01 of the document (submitted today) means 0,15% of extra flash memory 
    
    no hats
    
    Perhaps true. It also means that the vendor (open source is a vendor, from this perspective) allocates human resources, which cost money, to write and maintain the software. The software has some probability of bugs per volume of code, which means that there is a quantifiable security risk. Now, any business calculates its costs and potential upside benefits, and figures out how to make money (even open source developers do, believe me). Asking them to spend money with little real opportunity to gain saddles them with a cost and a risk with little upside. It's not the volume and price of the flash; it's the support costs.

[Jordi] Not really that much cost:
- Code is available in source, actually there are several implementations.
- Vendor can choose one source, integrate it with his own code (being linux should not be more than a couple of hours).
- Code has been tested already, so yes, still some “integration testing”, again should not be a big issue.
- Yes, more code more bugs, but if it is Linux, it is somehow “self-maintained” from the “source”.

⇒ What I know from several vendors of those CPEs that I’ve talked to, is that they basically take the code of OpenWRT (or others), and personalize the drivers for different chipsets and the GUI. So, adding something that is already done by the community is not the problem at all.

    
    If the vendor is looking at 7084 for guidance and saying there is no market for a given technology, it's because the operators in this working group collectively said there was no market in their networks. In the end it isn't about an RFC, it's about a market. No market, no money, no product. It's that simple.

[Jordi] I think is working in both ways. Vendors look at RFC7084 and integrate their boxes. ISPs talk to vendors and use the RFC7084 to push vendors. But if vendors don’t have a push for a specific technology, because ISPs get an “initial” “isn’t in the RFC7084”, then it never gets done. Also, once a couple of “big” retail (which are the same as ISP CE, but sometime OEM branded) vendors have support for the “new” transition mechs, the others need to do the same, just a matter of competition. Right now, there are 2-3 vendors, but they are expensive and they don’t even consider orders for 10.000 units or are too expensive for many markets. I tried it with several of them … working for customers. Also, I understand that most of the vendors could update the actual products in the market with new firmware, but they don’t do that, because it is better to sell new products to the same ISPs … That’s why I’ve been forced to use in several trials OpenWRT, and also a couple of ISPs actually using it for commercial deployment, reflashing existing “retail” products.
    
    If I'm hearing anything in this discussion, it's that the end game isn't found in having all of the transition technologies in product. It's to be found in native deployment that doesn't need the transition technologies.

[Jordi] Fully agree, but today you can’t tell any ISP that you’re going to deliver IPv6 only CPEs, because customers will not need to access any IPv4 resource in remote Internet or even in their own local networks. Any ISP trying to sell “IPv6-only in the LAN and in the WAN” services, will lose 99% of his customers.
    
    You might find these two links interesting. One is from the IPv4 Market Group, and makes prognostications on the value of an IPv4 address; the other is a public presentation by Swisscom about the traffic measurements in its network. In both cases, they are asking when they expect IPv6 usage, whether in traffic or in users, to exceed IPv4, and as a result when the need for dual stack deployment starts to wind down. Both, by different avenues, pick 2019 as the turning point, and Swisscom suggests that by 2024 it might not have enough IPv4 traffic in its network to justify having IPv4 enabled - even in an overlay.
    
    The issue of transition mechanisms has to do with networks being predominantly IPv4 and having to reach them using IPv6. Both are saying that there is a light at the end of that particular tunnel, and it's not an oncoming train.
    
    http://ipv4marketgroup.com/q42016-update/
    http://www.ipv6conference.ch/wp-content/uploads/2015/06/B10-Swisscom-Status_Roadmap_and_Outlook_IPv6.pdf
    

[Jordi] I already knew the 2nd one, however is a bit older (mid-2015) so I believe the picture changed a lot, and there is much more IPv6 traffic and I’m even more optimistic that it will be predomintanly-IPv6 sooner than any expectation, but still customers will not throw away their local IPv4-only devices (cameras, smartTVs, etc.), and there will be at least 4-5 more years with a considerable amount of IPv4-only sites. Probably 2020-21 it may be possible to start considering disabling IPv4 traffic (in my opinion) but still think that the support of IPv4-only local devices may take a longer time. How you convince folks to buy a new smartTV in 4-5 years, that they have purchased today (at least in Spain they still come w/o IPv6 support), unless the vendor upgrades the firmware? What about all kind of devices (IP cameras, wifi doorbell, cleaning robot, etc.), that today come with IPv4-only ? I think we may see LAN-IPv4 traffic for a longer period, unfortunately, and this is the reason the CPE must support it and some of those “traffic-flows” may require access to IPv4 remote sites (cloud services they are based on).





**********************************************
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 use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.