Re: [v6ops] I-D Action:draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-00.txt

[Ed Jankiewicz <[e-mail]>]

  Is it impossible to agree with both opinions?

Fred/Randy:  Operators should devote scarce resources to deploying 
native IPv6 and managing it well, rather than spinning more complicated 
webs of IPv4 accommodation.

Victor:  The ISP cannot dictate all updates to CPE, must provide access 
to all legacy customers, not just eager IPv6 adopters, so an interim 
mechanism that minimizes their inconvenience is needed.

There are around 100 RFCs and drafts about aspects of coexistence and 
transition flying around*, I sure hope they are not all going to be 
"standardized" because 100 standards for the same thing is about as good 
as none (IMHO).   Some of these are being generated by folks in the 
operator community, not just ivory tower solutions, so they should be 
motivated by real problems that need to be solved.  One size will never 
fit all, so some solutions may be a good fit for one ISP, and not for 
others.  Our job here is to provide engineering opinions on all these 
alternatives, to permit things that will help, and prevent things that 
will harm.

There should be something like "The laws of robotics" for 
transition/coexistence mechanisms:

1.  First, do no harm (to your legacy IPv4 customers, to your eager IPv6 
customers, to the larger community)
2.  Keep it simple (solve particular problems with targeted mechanisms) 
but no simpler than necessary to avoid harm
3.  Design and deploy your interim solution(s) with a clear path to 
eventually render them redundant:  enable, promote and encourage 
transition to native IPv6 (do not install any new equipment that does 
not support IPv6; sunset IPv4 access - without harming legacy customers)

I think these allow an operator complete freedom to manage their own 
network and to chose and operate any coexistence mechanism as long as 
they need to for supporting their customers, except where those choices 
cause harm to someone else.  Of course, there is no universal definition 
of "harm" so reasonable people can disagree, e.g. if a mechanism in use 
on the access side causes additional delay, content providers may see 
that as "harming" their users' experience.  That's why mailing lists and 
WG meetings are just so much fun.

On reflection, these are just corollary to the Robustness Principle or 
Postel's Law [RFC 793] .  "Be conservative in what you do, be liberal in 
what you accept from others."

Ed J


*shameless self-promotion:  take a look at 
http://tools.ietf.org/html/draft-jankiewicz-v6ops-v4v6biblio-02 
something I started to organize my own reading, but posted in case it 
helps anyone.  It tries to take a snapshot of the current work, so if I 
missed or mischaracterized anything, happy to take comments off-list to 
correct before Oct 25 update deadline.

On 10/20/2010 2:52 AM, Victor Kuarsingh wrote:
> Fred,
>
> I do agree with your position, but that is predicated on the ISP "managing"
> the CPE.  In many cases, the ISP just provides "access" to IP which means
> the customer equipment and it's capabilities are what determines what is
> feasible at that site.
>
> All the IPv6 enablement I do cannot change that (again, short of changing an
> entire business model for a company, this is running state for many ISPs).
> IPv4 service worked well since the equipment acquired by customers had a
> baseline of functionality which for the most part worked with the provider
> upstream systems.  IPv6 poses new challenges since the existing and deployed
> gear in many cases dose not support IPv6. ISPs will try to get this
> corrected but cannot control the entire deployment base.
>
> But I do find that many see this transition challenge as an "either/or"
> where we (many ISPs) see it as a combination of strategies.  I can work to
> provide IPv6 native connectivity, while providing a better service for
> endpoints that cannot support IPv6 day 1.  This was targeted as a part of
> the "mix" to keep things going while the real work of IPv6 deployment is
> carried out (again, not either/or, but parallel streams where this is not
> compromising the IPv6 deployment).
>
> This option is very easy to put in place (like 6to4 relays) and is low
> touch.  I would not consume many resources and engineering effort.
>
> I do see the argument if this was the sole strategy for a provider (which
> makes little sense), but do not fully see everyone's position if it's part
> of a bigger mix of technologies (of which IPv6 native is one) that supply
> services to the large cross-section of customers with varying degrees of
> functionality.  I can push for IPv6 and have this running on the side.
>
> Regards,
>
> Victor
>
>
>
> On 19/10/10 10:41 PM, "Randy Bush"<[e-mail]>  wrote:
>
>>> My humble perspective, speaking strictly for myself here, is that any
>>> ISP (not just your employer, but any ISP) that is really concerned
>>> about consumer experience of IPv6 would do better to deploy IPv6 and
>>> manage it the same way it manages IPv4 traffic than to try to manage
>>> the way its customers work around the lack of native support.
>> yesssssssssss!
>>
>> bleeping brilliantly said.  thank you.
>>
>> randy
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops