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

[GangChen <[e-mail]>]

2012/10/23, 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.

Thanks for the review and guidance. More replies are inline.

> 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.

ACKed. Will update it in the next version.

> 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.

Good suggestion. The intention of texts is exactly what you described.
Mentioning dual-stack intends to state the fact dual-stack may be the
phase some operators adopted. It's required that sunset technologies
positively enable the migration to IPv6-only mode. I would modify the
texts by combining statements in paragraph 2 and 3.


> 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.

The draft cited RFC6264, because it explicitly provides an evolving
path to IPv6-only stack. It may be useful hints to graceful IPv4
sunsets. In particular, the incremental IPv6 transition could be
facilitated by a sunset technology.

> 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.

Good to hear it. The point here is IPv4 sunset may be a soft-landing
process. We managed to seek a way, which is safe, stable and
acceptable for operators. Traffic steering may fit the goal, since it
increases IPv6 usages with no risks to degration of customer's
experiences. With the growth of IPv6 traffic, it serves a strong IPv6
sign to the industry. Application developer, ICP, OS provider, network
provider, etc could be inspired to enable native IPv6 features. Single
IPv6 deployment could be achieved with usages of transition mechanism
going down.

> 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?"

That is a hard question. I also put a note in the draft and expect
discussions from the group. I suppose selection of particular
technology may not the goal of sunset4, neither in the draft.

> 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 also agree a way to business rules is important. As you indicated,
several drafts intend to provide these analysis about the
gap/solutions between the bussines expectation and technical status.
This draft basically want to initiate a discussion what's sunset4
process should be. Should it make a smooth enabler or prompt changes?

> 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...

I think that is a good process from problem poking to solution
designing. Only one point is to be clarified. If one goal could be
fulfilled by several approaches and wg agree each of them has
necessity, I guess document them in one draft may benefit to the
legibility.  Making a container requesting protocol changes is better
than separated requests.

Best Regards


Gang



BRs

Gang

> 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.
>