On 3/30/17, 12:20 PM, "Int-area on behalf of Khaled Omar"
<int-area-bounces@ietf.org on behalf of eng.khaled.omar@hotmail.com> wrote:

>Ignas,
>
>> Please try to view your proposal from the operational side too.
>
>If they will not accept these changes they will face the division
>problem, they are the customer facing authorities, so if they will not
>make those changes, they will find another problem from the other side.

I don¹t understand your point. We are approaching the division problem
with IPv4 and IPv6. How is a third division helpful?

We have consensus on IPv6, and we have significant deployment. Many of us
are working on deploying single-stack IPv6 networks, with IPv4 translators
at the edges if necessary.

>
>> For any practically sized operator that would be an exercise of years
>>with associated costs of very substantial nature. Please make yourself
>>more familiar with network operational realities.
>
>Upgrading routers' OSs will take a short time if they are organizing
>their work and distributing assignments clearly.

That is not realistic in a large ISP.
I drove the IPv6 deployment at a very large provider. It took us more than
five years to get code from the core to the edge. Vendors are terrible at
delivering code that doesn¹t have fundamental bugs. Minor bugs (e.g.,
IS-IS interoperability between vendors, or prefix lengths other than /64
or /128 on point to point links)  can take a long time to identify and fix.
Vendors are constantly committing patched code, but operators have to
fully test anything they consider putting on their network. Then they find
bugs and wait for updates and test again.
Once the code is approved, tools have to be updated. This includes
standards like IPFIX, and log parsing tools, and alarm generators, and
active monitoring tools.
Core routers are not updated more often than twice a year. Don¹t touch a
working box: every touch increases the odds of an outage.

You¹ve said that this only requires a software update, but you¹re talking
about adding a header to every packet. Routers use custom chips optimized
for processing known headers; anything that doesn¹t fit that pattern is
kicked to a software process, which slows everything down and costs a lot
in CPU cores and memory. Adding a header doesn¹t scale at large numbers of
packets per second.

Your draft even says, "IPv4 and IPv6 routing must be enabled on all
routers² and "All Internet connected hosts must be IPv10 hosts²
If we could update every router and host to support a new protocol, we
would already have IPv6 completely deployed.

I don¹t see any sign that your proposal is gaining consensus.

Lee

>
>-----Original Message-----
>From: Ignas Bagdonas [mailto:ibagdona.ietf@gmail.com]
>Sent: Thursday, March 30, 2017 7:12 PM
>To: Khaled Omar
>Cc: int-area@ietf.org
>Subject: Re: [Int-area] Continuing IPv10 I-D discussion.
>
>
>
>On 30/03/2017 17:29, Khaled Omar wrote:
>>> Same issue with the routers in the path. IPv10 would require *all* of
>> them to be upgraded for the new packet header format.
>>
>> What will happen with one router from a specific company will happen
>> with all routers from the same vendors, inserting updates is not that
>> hard,
>
>Khaled,
>
>Please try to view your proposal from the operational side too.
>Designing a protocol wire representation and implementing that for some
>platform is quite trivial compared to the changes that are needed for the
>network support systems, the effort required for validation of that new
>functionality before the deployment, and the feasibility of doing the
>actual flag day deployment. For any practically sized operator that would
>be an exercise of years with associated costs of very substantial nature.
>Please make yourself more familiar with network operational realities.
>
>
>Ignas
>
>
>_______________________________________________
>Int-area mailing list
>Int-area@ietf.org
>https://www.ietf.org/mailman/listinfo/int-area