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

Victor,

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

Cheers,
Rajiv

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] 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
> 
> 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" <brian.e.carpenter@gmail.com>
> wrote:
> 
> >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
> >_______________________________________________
> >v6ops mailing list
> >v6ops@ietf.org
> >https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops