Subject: Re: [v6ops] Updated Feedback on Wireline Incremental IPv6

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 04 Mar 2012 21:31:57 -0500

V6ops team, (Second Post of this message)

A new version of "draft-ietf-v6ops-wireline-incremental-ipv6-01" has been
posted including feedback from the group.  This version has some textual
improvements and has made the following changes.

1. We have removed some language which focused on the IPv4 connectivity
phenomenon (we did not remove all, but some).  The focus of this document is
about IPv6 introduction and evolution.  This is also based on other
discussions such as the Intarea meeting in Taipei (ref -
http://www.ietf.org/proceedings/82/intarea.html)
2. The third phase is no longer called tunnelled IPv4, but IPv6-only.  This
phase would include tunnelled mode IPv4 if required (I.e. DS-LITE)
I would like WG feedback if the refined focus (which is based on comments
on/off list) is in line with how the WG thinks this document should proceed.
As well, I would also like feedback on the inclusion/exclusion of the
following technologies in phase 3.

1. NAT64.  Although this mode of operation will be difficult in the
foreseeable future (on it's own) in a Wireline network due to the massive
amounts of iPv4 equipment in the environment, it may be of consideration to
some wireline providers.
2. Also, should we include discussion on 464 xlate
(draft-ietf-v6ops-464xlat-00) framework/architecture.  Although the document
is focused on "commercially available" technology, it appears that the
technology for the 464 xlate is available (CLAT via some beta code and NAT64
is out there)
I would like to build in comments in the next rev 02.  In that rev, there
will also be additional considerations discussion/information based on some
additional input which is coming now.

Regards,

Victor K

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 4 Mar 2012 19:19:37 -0800

On Mar 4, 2012 6:32 PM, "Victor Kuarsingh"
<victor.kuarsingh<[email-masked]>
>
> We have removed some language which focused on the IPv4 connectivity
phenomenon (we did not remove all, but some).  The focus of this document
is about IPv6 introduction and evolution.  This is also based on other
discussions such as the Intarea meeting in Taipei (ref -
http://<http://www.ietf.org/proceedings/82/intarea.html>
www.ietf.org <http://www.ietf.org/proceedings/82/intarea.html>
/proceedings/82/ <http://www.ietf.org/proceedings/82/intarea.html>
intarea.html <http://www.ietf.org/proceedings/82/intarea.html>)
> The third phase is no longer called tunnelled IPv4, but IPv6-only.  This
> I would like WG feedback if the refined focus (which is based on comments
on/off list) is in line with how the WG thinks this document should
proceed.  As well, I would also like feedback on the inclusion/exclusion of
the following technologies in phase 3.
>
> NAT64.  Although this mode of operation will be difficult in the

Understood, but there are places in wireline that can work ipv6-only in
time (ftth)

> Also, should we include discussion on 464 xlate
(draft-ietf-v6ops-464xlat-00) framework/architecture.  Although the
document is focused on "commercially available" technology, it appears that
the technology for the 464 xlate is available (CLAT via some beta code and
NAT64 is out there)

Yes, there is the Android code.  NEC also has a commercial home gateway
product with CLAT feature.  I am also in the process of documenting proof
of concept testing using the Cisco asr 1000 and Linux Tayga both
functioning as CLAT.

As co-author of the 464xlat draft, I think it would be a relevant scenario
for your draft to reference

Cb
> I would like to build in comments in the next rev –02.  In that rev,
there will also be additional considerations discussion/information based
on some additional input which is coming now.
>
> Regards,
>
> Victor K
>
> _______________________________________________
> v6ops mailing list
> v6ops <[email-masked]>@ <[email-masked]>ietf.org <[email-masked]>
> https:// <https://www.ietf.org/mailman/listinfo/v6ops>www.ietf.org<https://www.ietf.org/mailman/listinfo/v6ops>
/mailman/ <https://www.ietf.org/mailman/listinfo/v6ops>listinfo<https://www.ietf.org/mailman/listinfo/v6ops>
/ <https://www.ietf.org/mailman/listinfo/v6ops>v6ops<https://www.ietf.org/mailman/listinfo/v6ops>

---

From: Washam Fan <[email-masked]>
Date: Wed, 7 Mar 2012 13:38:33 +0800

Hi Victor,

I am aware of this draft
http://tools.ietf.org/html/draft-ietf-softwire-dslite-deployment-02,
and think that it should be referenced in section 5.5.1.

The paragraph just before section 5.5.1 is talking about the scenario
where NAT444 CGN co-located with AFTR. Could you elaborate on this
scenario? I could not come up with any cases for this scenario.

Thanks,
washam

2012/2/26 Victor Kuarsingh <[email-masked]>:
> V6ops team,
> discussions such as the Intarea meeting in Taipei (ref
> - http://www.ietf.org/proceedings/82/intarea.html)
> NAT64.  Although this mode of operation will be difficult in the foreseeable
> future (on it's own) in a Wireline network due to the massive amounts of
> iPv4 equipment in the environment, it may be of consideration to some
> wireline providers.
> I would like to build in comments in the next rev –02.  In that rev, there
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 7 Mar 2012 09:06:19 -0500

Washam,

> and think that it should be referenced in section 5.5.1.

Yes, I have already spoken to those authors and am planning to include the
reference in the next revision.

> scenario? I could not come up with any cases for this scenario.

I can expand on this point if you like. The use case is for operators which
may start with NAT444 and then begin to support DS-LIte as a follow-up.  In
this case, not all devices will support/ or be moved to DS-Lite (AFTR
supported) services.  In this case, the operator *may* want to co-locate
such services.

Since these devices will be managed by the operator in a special way (vs.
standard network routers) and will have logging and other requirements,
keeping theses functions in a common place it advantageous (but not
necessarily required).

regards,

Victor K

---

From: Washam Fan <[email-masked]>
Date: Wed, 7 Mar 2012 22:39:53 +0800

Hi Victor,

> keeping theses functions in a common place it advantageous (but not

I got what you said. But what does "co-located" mean here? Are you
meaning combination of CGN part of NAT444 and CGN part of AFTR into a
generic CGN? These two parts are a slight different since CGN of AFTR
depends on IPv6 addresses in addition to IPv4 addresses for
translation. If these two parts are still separate instead of combined
into one, I think "co-located" is only meaning CGN and AFTR are
connected within a chassis instead of via cable or fibre.

Thanks,
washam

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 7 Mar 2012 09:46:15 -0500

Washam,

Ok, I see what your question was.  My intent was to describe that the two
functions would be geographically co-located and/or could be in a common
chassis.  I was not intending to describe an integration of the two
technologies.  I am not saying a vendor may not be crafty and do this, but
that is out of my control or interest.

I could clean up the text to be more specific.  If I addressed this (with
sufficient text), would you be ok with that?

regards,

Victor K

---

From: Washam Fan <[email-masked]>
Date: Thu, 8 Mar 2012 10:10:47 +0800

Hi Victor,

> sufficient text), would you be ok with that?

Yes, please. That would address my concern.
Thanks,
washam