Re: [v6ops] slides for draft-tsou-v6ops-multicast-transition-v6only

Tina Tsou <tena@huawei.com> Sun, 27 March 2011 16:00 UTC

Return-Path: <tena@huawei.com>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D9C3A6882 for <v6ops@core3.amsl.com>; Sun, 27 Mar 2011 09:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.299
X-Spam-Level:
X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JiYKjZl7oSR for <v6ops@core3.amsl.com>; Sun, 27 Mar 2011 09:00:30 -0700 (PDT)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 5BFF83A6878 for <v6ops@ietf.org>; Sun, 27 Mar 2011 09:00:30 -0700 (PDT)
Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIQ00KL04JIIZ@usaga01-in.huawei.com> for v6ops@ietf.org; Sun, 27 Mar 2011 11:02:06 -0500 (CDT)
Received: from TingZousc1 (dhcp-4264.meeting.ietf.org [130.129.66.100]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIQ00DP44JF62@usaga01-in.huawei.com> for v6ops@ietf.org; Sun, 27 Mar 2011 11:02:06 -0500 (CDT)
Date: Sun, 27 Mar 2011 18:02:02 +0200
From: Tina Tsou <tena@huawei.com>
In-reply-to: <000501cbeb8b$5df61160$19e23420$@com>
To: fred@cisco.com
Message-id: <000001cbec98$50f6d950$f2e48bf0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_DHPObqjrW8cxNAyuQdAAew)"
Content-language: en-us
Thread-index: AcvrFz6wU5wUawEQTM602H010bJztgAcIbzAAEOrAfA=
References: <000501cbeb8b$5df61160$19e23420$@com>
Cc: 'IPv6 Ops WG' <v6ops@ietf.org>
Subject: Re: [v6ops] slides for draft-tsou-v6ops-multicast-transition-v6only
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Mar 2011 16:00:40 -0000

Hi Fred,
Thank and respect your deep comments. Comments are in line.


We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html



-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com] 
Sent: Friday, March 25, 2011 12:23 AM
To: Joel Jaeggli
Cc: Tina Tsou; 'IPv6 Ops WG'; 'V6ops Chairs';
draft-tsou-v6ops-multicast-transition-v6only@tools.ietf.org
Subject: Re: [v6ops] slides for draft-tsou-v6ops-multicast-transition-v6only

The -00 was before 3/7; the -01 update came in on 3/15. Both were just under
the wire.
[Tina: The key message of the document is under the assumptions stated on
the slides; there is no rush for the operator to change the end points of
the multicast sub-system. The document shows a transition path where
existing investments are fully amortized, and the network never has to carry
duplicate IPv4 and IPv6 streams of multicast content.]

My question is whether there is significant operational value here. 
[Tina] Compared to other multicast transition solutions in bebave WG, NAT
could be avoided, and then the performance could be better. Compared to some
multicast transition solution in softwire WG, softwire tunnel could be
avoided, and the cost of update is lowest, then the IPv4 investment could be
protected better.   

The document seems to think that dual stack servers will come into existence
at some point in the future; I think they exist now, and have for some time.

[Tina] One of the points made in the draft is that the operator may be in no
hurry to invest in new servers because it wants to amortize its existing
investment.

The document seems to think that new equipment will be only IPv6-capable. I
imagine that IPv4 capabilities will be removed from or not designed into new
equipment at some point when IPv4 is irrelevant to the market, but will be
used only when appropriate. From my perspective, the thing that will be dual
stack, IPv4-only, or IPv6-only will be the network, not the systems that use
it.

Frankly, this looks like something to fill a check-box in the framework Tina
proposed, not a useful bit of operational advice, as it doesn't reflect what
I understand to be operational reality.

To my mind, operational reality is this. There is a set of residential
IPv4-only systems in the field. There are two reasons for them to be
IPv4-only: they are older Windows systems and set-top boxes, or there is a
CPE in the residence that is IPv4-only. There is a set of dual stack systems
in the field; at this point relatively few CPEs, although that will change,
and any personal computer purchased within the past three years. Service
providers therefore have two markets for video content: an IPv4-only one,
and a dual stack one.
[Tina] If video content is transferred both in IPv4 and IPv6 in the same
time, two times of bandwidth will be consumed.  

If a service provider wishes to move his service to IPv6, he therefore needs
to work with CPE and set-top vendors to deploy IPv6-capable code in personal
computers, telephones, set-top boxes, and CPE routers. The vendors will want
to sell product; the residential customer will want a simple procedure to
follow that will download and install a new software image. However that is
resolved, the network now wants to measure IPv6 capability, and deliver IPv6
service to those that can use it. The network now has two trend lines: a
growing population of IPv6-capable residences, regardless of their IPv4
capability, and a diminishing population of IPv4-only residences that the
network must cater to. At some point, the latter loses business value and is
phased out. The former is the future.

On Mar 25, 2011, at 7:46 AM, Joel Jaeggli wrote:

> Unless I mistaken we haven't quite synched up on the final agenda yet.
> 
> I don't see this document as being posted before 03/07 is this related
> to what you're presenting in behave?
> 
> On 3/24/11 5:57 PM, Tina Tsou wrote:
>> Hi Fred, Joel, and Kurt,
>> I applied a time slot for v4v6tran community work earlier, as a place
>> holder.
>> This is a bit of it. Would it be shown on the agenda?
>> 
>> 
>> We keep our promises with one another - no matter what!
>> 
>> Best Regards,
>> Tina TSOU
>> http://tinatsou.weebly.com/contact.html
>> 
>> 
>> -----Original Message-----
>> From: Tina Tsou [mailto:tena@huawei.com] 
>> Sent: Thursday, March 24, 2011 3:57 PM
>> To: 'V6ops Chairs'
>> Cc: 'IPv6 Ops WG';
>> 'draft-tsou-v6ops-multicast-transition-v6only@tools.ietf.org'
>> Subject: slides for draft-tsou-v6ops-multicast-transition-v6only
>> 
>> Hi Fred, Joel, Kurt et al,
>> Attached please find slides for
>>
https://datatracker.ietf.org/doc/draft-tsou-v6ops-multicast-transition-v6onl
>> y/
>> 
>> 
>> We keep our promises with one another - no matter what!
>> 
>> Best Regards,
>> Tina TSOU
>> http://tinatsou.weebly.com/contact.html
>> 
>> 
>> 
>>
----------------------------------------------------------------------------
>> ----
>> [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread
Index]
>> Re: [v6ops] V4tov6transition Applicability Statement I-Ds and Transition
>> Guide I-Ds
>> 
>>
----------------------------------------------------------------------------
>> ----
>> 
>> From: Satoru Matsushima <satoru.matsushima at gmail.com>
>> To: Tina Tsou <tena at huawei.com>, IPv6 Ops WG <v6ops at ietf.org>
>> Date: Tue, 8 Mar 2011 17:49:11 +0900
>> In-reply-to: <001f01cbdd12$543413c0$fc9c3b40$ at com>
>> References: <001f01cbdd12$543413c0$fc9c3b40$ at com> 
>> 
>>
----------------------------------------------------------------------------
>> ----
>> Hello,
>> 
>> We've submitted two documents, in which v4tov6transition related topics.
>> 
>> 1).
>>
http://tools.ietf.org/id/draft-matsushima-v6ops-transition-experience-00.txt
>> 2). http://tools.ietf.org/id/draft-sun-intarea-4rd-applicability-00.txt
>> 
>> 1) is a transition experience and considerations for the transition from
>> another aspect.
>> 2) is posted to intarea-wg, but it would be interested in this area.
>> 
>> 
>> Best regards,
>> 
>> --satoru
>> 
>> 
>> 
>> On 2011/03/08, at 6:55, Tina Tsou wrote:
>> 
>>> Dear interested party on V4tov6transition, To get the best effect, may 
>>> I suggest submitting the Internet Draft final submission by 17:00 PT, 
>>> to reference each other for the following drafts?
>>> .2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 
>>> PT (01:00 Tuesday, March 15 UTC), upload using IETF ID Submission Tool.
>>> 
>>> Your contribution is invited.
>>> 
>>> Problem Statement and Framework:
>>> draft-lee-v4v6tran-problem-02
>>> draft-ietf-v6ops-v4v6tran-framework-01 (formerly
>>> draft-carpenter-v4v6tran-framework-00)
>>> 
>>> Broadband:
>>> draft-huang-v6ops-v4v6tran-bb-usecase-01 (formerly
>>> draft-tian-v4v6tran-broadband-sp-usecase-00)
>>> draft-yang-v6ops-v4v6tran-bb-transition-guide-01 (formerly
>>> draft-yang-v4v6tran-ipv6-transition-guide-00)
>>> 
>>> Cable:
>>> draft-lee-v6ops-tran-cable-usecase-00 (formerly
>>> draft-lee-v4v6tran-usecase-cable-00)
>>> 
>>> Mobile:
>>> draft-tsou-v6ops-mobile-transition-guide (formerly
>>> draft-tsou-v4v6tran-mobile-transition-guide-00)
>>> draft-zhou-v6ops-mobile-use-case (formerly 
>>> draft-zhou-v4v6tran-mobile-use-case-00 )
>>> 
>>> Applicability Statements:
>>> http://tools.ietf.org/html/draft-tan-v6ops-nat64-experiences-00
>>> https://datatracker.ietf.org/doc/draft-tsou-v6ops-multicast-transition
>>> -v6onl
>>> y/
>>> 
>>> 
>>> 
>>> We keep our promises with one another - no matter what!
>>> 
>>> Best Regards,
>>> Tina TSOU
>>> http://tinatsou.weebly.com/contact.html
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops at ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> 
>> 
>>
----------------------------------------------------------------------------
>> ----
>> 
>> References: 
>> [v6ops] V4tov6transition Applicability Statement I-Ds and Transition
Guide
>> I-Ds
>> From: Tina Tsou
>> Prev by Date: Re: [v6ops] Happy Eyeballs and SIP Next by Date: Re:
[v6ops]
>> Happy Eyeballs and SIP Previous by thread: [v6ops] V4tov6transition
>> Applicability Statement I-Ds and Transition Guide I-Ds Next by thread:
>> [v6ops] FW: V4tov6transition Applicability Statement I-Ds and Transition
>> Guide I-Ds
>> Index(es): 
>> Date
>> Thread
>> Note Well: Messages sent to this mailing list are the opinions of the
>> senders and do not imply endorsement by the IETF.
>> 
>> _______________________________________________
>> 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