Post by George, WesHi -
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.
Post by George, WesFirst, 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.
Post by George, WesRegarding 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.
Post by George, WesI 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.
Post by George, WesI 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.
Post by George, WesBasically 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.
Post by George, WesI 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?
Post by George, WesI 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
Post by George, WesThanks,
Wes George
-----Original Message-----
Behalf Of GangChen
Sent: Monday, October 15, 2012 11:59 AM
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 ----------
Date: Mon, 15 Oct 2012 07:48:32 -0700
Subject: I-D Action: draft-chen-sunset4-traffic-migration-00.txt
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
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.
https://datatracker.ietf.org/doc/draft-chen-sunset4-traffic-migration
http://tools.ietf.org/html/draft-chen-sunset4-traffic-migration-00
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
I-D-Announce mailing list
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
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.