Re: [v6ops] Update IPv6 Wireline Incremental

["George, Wes" <[e-mail]>]

4.5 Probably want to include some discussion that adds on to your existing recommendation about avoiding having transition technologies in the majority-traffic path regarding when the operator should enable existing and new services for IPv6. If the operator is using a transition technology for IPv6, it may not make sense to enable their internal services and those they provide via partnerships (mail, web portal, DNS, content, etc) for IPv6 yet. If they are using native, especially in conjunction with an IPv4-extension transition technology, then it makes sense to rapidly enable their internal services for IPv6 to offload that traffic from IPv4. This is something where providers have a bit more control over when IPv6 content is reachable for their customers (vs simply relying on standard content providers to enable IPv6).

5.1 is missing a discussion about breakage cases (draft-weil, 6to4pmt, etc)
5.3 , 5.4- 6rd & DSLite usually require CPE support (mentioned briefly in 6.2, but should be more prominent here, as that's a significant consideration in the use of these as transition technologies)

6 - I'm not sure I agree with the "low volume during early transition" assertion. We as an industry are working from multiple angles to increase IPv6 adoption, through updates to commercially available CPE, content providers enabling IPv6, etc. For example, the day that IPv6 is enabled on a customer circuit/network, in some cases they may immediately start streaming Youtube content over IPv6. This is not low volume traffic. A few years ago this might have been true, but as updated guidance, I think that this sets providers up for a potential scaling problem, where they assume that IPv6 isn't "real" at first and make tradeoffs that result in a sub-optimal experience. I think you can be more forceful when you discuss having the infrastructure, routing, etc ready before enabling even partial IPv6 support to the end customer. It's far worse to have IPv6 enabled for end customers without having the infrastructure in place and being surprised by the amount of traffic such that the customer experience is bad than it is to wait to enable customers while you ensure that your infrastructure can handle it. Your point earlier about the main goal being to ensure seamless IP service regardless of version is very much applicable here supporting the idea that you need to do IPv6 right to start with.

6.1.1 - it's worth noting that if training is done too early, it will have to be repeated later, because those being trained will forget a lot of the training if they do not have a means to immediately start applying that knowledge on the network that they are supporting.

6.1.4 - also need to specify the capabilities that they expect to use to vendors (eg CPE that they buy now has to support whatever transition technology they will use as they deploy, new gear purchased must support IPv6 fully, etc).

6.2  - reference rfc6343

6.4 - reference to draft-weil


Thanks,

Wes


From: [e-mail] [mailto:[e-mail]] On Behalf Of Victor Kuarsingh
Sent: Monday, October 03, 2011 7:16 PM
To: [e-mail]
Subject: [v6ops] Update IPv6 Wireline Incremental

WG,

Updated version of draft-kuarsingh-wireline-incremental-ipv6-01.

The intent here is to provide a potential path for Wireline Operators who may be looking to support IPv6 in an incremental fashion but may not be fully up to speed on all the various technologies out there, or may not have a full grasp on how to boil it down to a potential plan for their network.

The draft also presents a view on what technologies may be used to solve some of the issues the face many operators over the next few years (introduction of IPv6, infancy IPv6 on access network equipment, exhaustion of IPv4,  future optimizations etc).

This also attempts to build on the v4v6framework draft (draft-ietf-v6ops-v4v6tran-framework)

Future version will also supply further suggestions on some deployment considerations including diagrams.

Comments, suggestions and attacks welcome.

regards,

Victor Kuarsingh

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.