Re: [sunset4] Fwd: I-D Action: draft-chen-sunset4-traffic-migration-00.txt

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

Hi -

I've reviewed your draft, apologies that I didn't get to this in time for you to push a revision before Atlanta, I've been out for medical reasons and indeed will be attending the next IETF remotely as a result.

First, I'd note that I-Ds don't normally reference specific WGs in the text, because WGs and their charters tend to be ephemeral when compared with their RFC output, so it's more effective to discuss specifically the problem being solved without reference to the WG that may or may not exist to solve it.

Regarding the second paragraph of your introduction- I'm unclear why you referenced dual-stack here. It'd be helpful to be more explicit about the fact that dual-stack is a transition point itself, and the goal is single-stack IPv6 (as you state in the beginning of section 3) and lead the reader to the conclusion you're drawing by including the discussion about dual-stack, or possibly remove it.

I think section 3 is a little out of place in this document - there are many documents covering transition mechanisms to manage carrying IPv4 over an IPv6 network, we don't need to revisit them in sunset4.

I like the idea of presenting different ways to push traffic towards IPv6 in hosts where there is an option, in fact, that is one of the things we added to the charter in the last revision. Basically the question is, "how do you signal a preference between IPv4 or IPv6 to dual-stack hosts?" and a follow-on question might be "how granular does that signaling need to be?"
I think draft-perreault-sunset4-noipv4 talks about one way, draft-kaliwoda-sunset4-dual-ipv6-coexist talks about some other aspects of it, and other bits may be in the gap analysis draft, and there have been previous discussions on other WG lists about whether happy eyeballs is enough by itself, or whether one should induce delay to affect happy eyeballs' choice of protocol. Ultimately, it's going to be important to have a way to communicate business rules assuming that networks will have varying methods of carrying IPv4 traffic (including NAT that may make it a secondary choice) and providing IPv6 access to IPv4-only content or devices (ex NAT64, etc) such that without some additional guidance, the end hosts may make the wrong choice about which address family to use and the customer will get adverse service due to capacity limitations, translation issues, etc.

I think the WG needs to decide how to structure drafts discussing and solving this exact problem - my initial thought would be to document the protocols where it would make sense to be able to communicate this preference within the gap analysis, and then once we have consensus on where, then we write drafts to propose the features and option codes necessary to make that work in the different protocols. This is especially true where we're recommending changes to protocols that are under the purview of another WG - we want to be able to send them a draft that covers the changes we propose and why we propose them in a relatively self-contained manner for ease of review (vs one draft that proposes changes to several protocols simultaneously).
But I'm open to alternate suggestions by other members of the WG - I'd like to get some discussion going...

Thanks,

Wes George

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of GangChen
> Sent: Monday, October 15, 2012 11:59 AM
> To: [e-mail]
> Subject: [sunset4] Fwd: I-D Action: draft-chen-sunset4-traffic-
> migration-00.txt
>
> Hello all,
>
> New draft has been just submitted in order to achieve a graceful IPv4
> sunset depending on the methods of traffic steering.
>
> The link and more information are shown as below.
>
> Your comments and review are appreciated.
>
> Many thanks
>
> Gang
>
> ---------- Forwarded message ----------
> From: [e-mail]
> Date: Mon, 15 Oct 2012 07:48:32 -0700
> Subject: I-D Action: draft-chen-sunset4-traffic-migration-00.txt
> To: [e-mail]
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>       Title           : Graceful IPv4 Sunset with Traffic Migration
>       Author(s)       : Gang Chen
>       Filename        : draft-chen-sunset4-traffic-migration-00.txt
>       Pages           : 8
>       Date            : 2012-10-15
>
> Abstract:
>    In order to make a graceful IPv4 sunset, this memo described a method
>    helping traffic migration to IPv6.  With the growth of IPv6 traffic,
>    operators could safely turn off IPv4 and evolve to IPv6-only network.
>    In order to achieve the goal, new traffic-migration options have been
>    proposed in DHCPv6 and PCP.  IPv6 traffic steering could be performed
>    using those configurations.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-chen-sunset4-traffic-migration
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-chen-sunset4-traffic-migration-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> sunset4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sunset4

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.