Subject: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 13 May 2012 11:01:41 -0700

The working group last call for this draft announced last week continues for another week. Please feel free to comment on it.

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 13 May 2012 14:21:09 -0400

WG,

As a note, an updated version was posted with the NAT64 updates per comments
in Paris.

As of now, we still have not changed the tone of the document from the
"deploy IPv6" and "consider IPv4".  Also, there had been some comments from
one of the contributors that would have put stronger language round
IPv6-only methods of operation (to the CPE) which would have operators
potentially allow IPv4 to suffer in performance to promote IPv6 operation 
this has not yet been included.

My personal opinion is that making IPv4 operate worse on purpose when given
other options is counterintuitive to the job of an operator. Other opinions
welcome.  

So basic points still remain:

* Deploy IPv6 as soon as you can
* Prepare for IPv6 (training, architecture, protocols etc)
* Do it with forward considerations of IPv6-only operation
* Consider the duality of IPv4 and IPv6 when you choose transition
technologies and path forward
* Try and keep IP flows off transition techs to the best extent possible
(cost, scaling, performance benefits)
* Operator can choose to deploy transition techs differently if they choose,
but should be aware of consequences (cost, scale, performance)

Regards,

Victor K

From:  Fred Baker <[email-masked]>
Date:  Sun, 13 May 2012 11:01:41 -0700
To:  <[email-masked]>
Cc:  <[email-masked]>, Ron Bonica <[email-masked]>
Subject:  [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC

The working group last call for this draft announced last week continues for
another week. Please feel free to comment on it.

_______________________________________________ v6ops mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: "George, Wes" <[email-masked]>
Date: Mon, 14 May 2012 13:20:38 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Kuarsingh
Sent: Sunday, May 13, 2012 2:21 PM
To: [email-masked]
Cc: [email-masked]; Ron Bonica
Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC

As of now, we still have not changed the tone of the document from the "deploy IPv6" and "consider IPv4".  Also, there had been some comments from one of the contributors that would have put stronger language round IPv6-only methods of operation (to the CPE) which would have operators potentially allow IPv4 to suffer in performance to promote IPv6 operation - this has not yet been included.

My personal opinion is that making IPv4 operate worse on purpose when given other options is counterintuitive to the job of an operator. Other opinions welcome.

[WEG] Victor - as one of the people who has been advocating a serious discussion of IPv6-only, I think that there are two points to make:
1) IPv6-only has the potential to be simpler than dual-stack because you're not dealing with duplicate network management/scale, etc. Even if the topology is 100% the same between the two, you're still dealing with two separate protocols across your configuration, your route storage/convergence, your management, your troubleshooting. That is probably something to be minimized where possible, and I think it's realistic to start recommending that since IPv6 is the desired end state, if there's a preference for single stack, it makes sense for IPv6 to be the preferred stack over IPv4, even if some parts of the transition happen over a fairly long time.
2) I am certainly not advocating making IPv4 worse, and I think that the draft is pretty good at walking the line here - there's a need to keep IPv4 services working as well as they can for as long as possible to keep legacy customers happy. That doesn't prevent you from also making sure that you're making forward progress towards IPv6 (and eventually reducing the amount of the network that is using IPv4).

I think this draft is ready to progress if you believe that you've covered the comments above.

Wes George

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.

---

From: Chris Donley <[email-masked]>
Date: Fri, 18 May 2012 17:13:27 -0600

I reviewed the document, and think it does a good job outlining the transition path(s). I think it'll be ready to advance once comments are addressed.

One comment wrt Section 3.5.  The document says, "To minimize risk, an operator should use transition technologies for the less dominant address family if possible." I don't think the driver is address family dominance, but availability.  If operators can get  native v6 to the edge, they should do it, even if v6 is not dominant (otherwise we could be stuck in 6RD mode for a while, even when native v6 is available).  On the v4 side, operators won't deploy a transition technology until they run out of addresses. Then the choice is btw NAT444 and DS-Lite (or if we're really lucky, NAT64). Perhaps this is what you mean by dominant? You won’t use any as long as you can get addresses, but once you run out, you might make the choice of base A-F based on dominance/maturity/stability?

I'll send copy-edits to the authors in a separate email.

Chris

From: Fred Baker <[email-masked]<mailto:[email-masked]>>
Date: Sun, 13 May 2012 12:01:41 -0600
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Ronald Bonica <[email-masked]<mailto:[email-masked]>>
Subject: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC

---

From: Victor Kuarsingh <[email-masked]>
Date: Sat, 19 May 2012 10:31:29 -0400

Fred,

I will add the updates from this review to the others noted throughout the
WGLC for next update.

Regards,

Victor K

From:  Chris Donley <[email-masked]>
Date:  Fri, 18 May 2012 17:13:27 -0600
To:  Fred Baker <[email-masked]>, "[email-masked]" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, Ronald
Bonica <[email-masked]>
Subject:  Re: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6
WGLC

I reviewed the document, and think it does a good job outlining the
transition path(s). I think it'll be ready to advance once comments are
addressed.

One comment wrt Section 3.5.  The document says, "To minimize risk, an
operator should use transition technologies for the less dominant address
family if possible." I don't think the driver is address family dominance,
but availability.  If operators can get  native v6 to the edge, they should
do it, even if v6 is not dominant (otherwise we could be stuck in 6RD mode
for a while, even when native v6 is available).  On the v4 side, operators
won't deploy a transition technology until they run out of addresses. Then
the choice is btw NAT444 and DS-Lite (or if we're really lucky, NAT64).
Perhaps this is what you mean by dominant? You won¹t use any as long as you
can get addresses, but once you run out, you might make the choice of base
A-F based on dominance/maturity/stability?

Chris

From:  Fred Baker <[email-masked]>
Date:  Sun, 13 May 2012 12:01:41 -0600
To:  "[email-masked]" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, Ronald
Bonica <[email-masked]>
Subject:  [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC