Subject: Re: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2011 13:23:18 +1200

Hi,

This is an interesting draft. Could the authors comment on whether
they are suggesting significant differences to the procedures
suggested in RFC 6264 (the Incremental CGN document)? In any case
I think you need to refer to that RFC, in a positive or negative way
at your choice ;-)

Regards
   Brian Carpenter

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Jul 2011 23:35:02 -0400

Brian,

This draft (which requires more work) was to be a narrow scope option
which can be used by operators if they so choose.  The goal was to provide
a "recipe" that could be used.  In talking with some vendors, it appears
that there are still customers (Operators) which are still confused and/or
on the fence as to how they will approach IPv6 transition (sure I know may
have it figured out - and that's great).

This draft would need to point (rightfully so) to RFC6264 which outlines a
good and boarder scope approach to IPv6 transition and use of CGN.  There
is also a link to the transition framework document
(draft-ietf-v6ops-v4v6tran-framework) which this draft was to also follow.

Due to the rawness of the -00 rev, much of the content I wanted to add is
missing and would make it into a -01 rev.  I am missing much content which
I think is valuable for operator consumption and/or consideration

Included in an updated additional content would be:

- Defining logical waypoints which could be used by operators to move
between phases (I.e. Condition of external content, internal services,
tools/readiness, etc)
- Better explanation for the rationale for choosing this specific mix of
technologies and the phase order
- I had specific reasoning as to what the traffic conditions may be like
at each one of the phases as well (which supports the notion of keeping as
little traffic on the CGN/Relay assist path as possible)
- I would also add in options/suggestions as to how operators could grow
their transition environment (supporting this mix of technologies), deal
with routing etc.

Again, this was to be quite operator focused and I was hoping that this
type of information could help some operators who may be still in the
early analysis phases develop an approach to add in IPv6 (with the obvious
understanding that CGN will likely play a part in many networks - like it
or not).

I would be interesting in your (or others) thoughts.  As I had described
to someone else the other day, I think the IETF and folks have done an
excellent job providing all the "ingredients" for IPv6 transition but
wanted to help promote the "recipe" side now - as noted by
draft-ietf-v6ops-v4v6tran-framework.

Regards,

Victor K

On 11-07-20 9:23 PM, "Brian E Carpenter" <[email-masked]>
wrote:

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

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 21 Jul 2011 09:02:31 -0500

Victor,

Do you plan on beefing up 'translation' based options in -01 version?

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Victor Kuarsingh
> Sent: Wednesday, July 20, 2011 11:35 PM
> To: Brian E Carpenter; IPv6 Operations
> Subject: Re: [v6ops] I-D Action:
draft-kuarsingh-wireline-incremental-ipv6-
> 00.txt

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 22 Jul 2011 00:51:11 -0400

Rajiv,

I had considered some additional content around translation.  Most of the
current content surrounds the option of Native Dual Stack using CGN as the
IPv4 path assist when IPv4 runs out.

This particular draft then provides an incremental future option to
optimize the (if necessary) translation for IPv4 with DS-Lite.

I had stuck with technologies (thus far) which are currently deployable,
or are near-deployable.  Did you have a specific additional option in mind
which may be of consideration?  Although I had not specified anything
else, given that phase 3 is a future option, there could be more then one
listed (although I was looking to make it relevant to operators focusing
on existing code and functionality - to the best extent possible).

As an Example:

One additional option that was noted to me offline was NAT64.  I think
NAT64 poses challenges in the near to mid term future (in Wireline
Networks) since there is way too much IPv4-only equipment in customer prem
today. I am hesitant to promote options which are based on eliminating
variables I don't control - consumer controlled and operated equipment.
Therefore assumed Dual Stack home for the foreseeable future (the realist
in me).  On the NAT64 note, I do think it is usable in some environments
(like some Wireless services), but I stuck with common Wireline
environments for now.

Regards,

Victor K

---

From: "George, Wesley" <[email-masked]>
Date: Fri, 22 Jul 2011 14:09:05 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Kuarsingh
Sent: Friday, July 22, 2011 12:51 AM
To: Rajiv Asati (rajiva); Brian E Carpenter; IPv6 Operations
Subject: Re: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt

> (like some Wireless services), but I stuck with common Wireline

Victor - this is a useful consideration around NAT64. You should add some comments to this effect in your draft. I understand the rationale, but it's better to include it and explain like you did here than to simply omit it.

Also, I think that there is an opportunity for a little shameless plug in section 3.3, especially the 3rd paragraph - IETF needs feedback from operators as they discover new issues and problems during their implementation phase :-)

You also may want to discuss the option of moving some things in the operator's infrastructure which can support it to IPv6-only fairly early in the process in order to free up IPv4 resources for use in support of legacy applications and devices which cannot. You mention it in the context of DS-Lite in 5.5, but I think it's more generally applicable. For that matter, there is probably room for some discussion about phasing with regards to infrastructure (such as management of devices, back office, etc) vs customer facing  services and when those all get enabled for IPv6, since "all at once" is rarely practical.

5.1.2 may want to discuss considerations about OSPFv3 vs ISIS as an IGP (or reference an existing document that does, if exist)

5.2 may also want to include discussion of 6PE as a means to bridge gaps where IPv6 cannot be supported in the network infrastructure.

Nits:
4.3 : %s/defiantly/definitely
5.1.1: %s/vial/vital
5.2: %s/Naïve/Native

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: Nikolay Milovanov <[email-masked]>
Date: Wed, 27 Jul 2011 22:00:25 +0300

Hi,

Very interesting draft indeed.
I like that sentence:
   Many supporting systems are also under development and have newly
   developed IPv6 functionality including vendor implementations of
   DHCPv6, Management Tools, Monitoring Systems, Diagnostic systems,
   along with other systems.

As per my perspective more or less OSS/BSS part of operator's infrastructure
is not at all ready for handling IPv6 network transition or Service
transitions/activation. Will be happy to hear more from the author about
that part of the transition.

BR,
Nikolay Milovanov
Network Engineer
NBU

On Fri, Jul 22, 2011 at 9:09 PM, George, Wesley
<[email-masked]>wrote:

> draft-kuarsingh-wireline-incremental-ipv6-00.txt
>
> Victor - this is a useful consideration around NAT64. You should add some
> comments to this effect in your draft. I understand the rationale, but it's
> better to include it and explain like you did here than to simply omit it.
>
> Also, I think that there is an opportunity for a little shameless plug in
> section 3.3, especially the 3rd paragraph - IETF needs feedback from
> operators as they discover new issues and problems during their
> implementation phase :-)
>
> You also may want to discuss the option of moving some things in the
> operator's infrastructure which can support it to IPv6-only fairly early in
> the process in order to free up IPv4 resources for use in support of legacy
> applications and devices which cannot. You mention it in the context of
> DS-Lite in 5.5, but I think it's more generally applicable. For that matter,
> there is probably room for some discussion about phasing with regards to
> infrastructure (such as management of devices, back office, etc) vs customer
> facing  services and when those all get enabled for IPv6, since "all at
> once" is rarely practical.
>
> 5.1.2 may want to discuss considerations about OSPFv3 vs ISIS as an IGP (or
> reference an existing document that does, if exist)
>
> 5.2 may also want to include discussion of 6PE as a means to bridge gaps
> where IPv6 cannot be supported in the network infrastructure.
>
> Nits:
> 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.

-- 
BR,

Nikolay Milovanov
Network Engineer
CCIE SP# 20094
Mob: +359898763322
Email: [email-masked]