Re: [v4tov6transition] a few quick reviews of the documents for today

On 9/20/10 8:12 PM, Yiu L. Lee wrote:
> Hi Jari,
> 
>> I think that is actually consistent with the advice in our draft (but
>> maybe we need to change something if that was not clear). On any
>> specific part of the network, native and dual stack are preferred if you
>> can do them, but it is indeed natural that most networks employ a
>> combination of tools in different parts. My own network, for instance,
>> has a combination of IPv6-only, dual-stack, and tunneled IPv6 service in
>> different routers/links. I would have avoided the tunneled solution in
>> one part of the network, but it was not possible at the moment.
>>
> You hit the nail in the head. Our network also has multiple technologies.
> Every time we tried to explain this to the management, they scratched their
> heads and asked why we wanted to deploy so many technologies in the network.
> To them, this is confusing and drive up the cost to manage the network. We
> are working hard to balance technologies to provide service continuity and
> meanwhile to speedup the IPv6 deployment. My wish is that all operators
> could converse to a single technology for transitioning :-) but I have
> learned that this will only stay as a wish :-( My worry is that the more the
> confusion in the community, the higher the cost for the transition.

Right but the transition technology is mostly another bandaid associated
with lack of v6 deployment or ipv4 address pressure forcing shim
technologies. your/our deployed ipv4 service is going to get crapier
when you have no more public ip4 addresses to hand to costomers, the
pain can be minimized to some extent but it cannot be entirely aleviated.

Ipv6 deployment is unabiguous, my first one was in 2001 and it still is now.

> Anyway, our intention for this use case draft is to address the use cases at
> least in cable industry so that MSOs could agree with similar technologies.
> We hope if we could agree with the use cases and technologies, this could
> help to train the engineers and drive down the overall cost (both CapEx and
> OpEx).

Minimzing opex is about being constructively lazy, the minimum amount of
necessary work done in order to support the use case is the low bar to
get over.

> -- Yiu
> 
> _______________________________________________
> v4tov6transition mailing list
> v4tov6transition@ietf.org
> https://www.ietf.org/mailman/listinfo/v4tov6transition
> 