Re: [multrans] Draft Multrans BoF request

"Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> Tue, 14 June 2011 21:41 UTC

Return-Path: <yiu_lee@cable.comcast.com>
X-Original-To: multrans@ietfa.amsl.com
Delivered-To: multrans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1487F11E811E for <multrans@ietfa.amsl.com>; Tue, 14 Jun 2011 14:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.22
X-Spam-Level:
X-Spam-Status: No, score=-106.22 tagged_above=-999 required=5 tests=[AWL=2.242, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-QOWys+dr0A for <multrans@ietfa.amsl.com>; Tue, 14 Jun 2011 14:41:47 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id CBE4811E80E8 for <multrans@ietf.org>; Tue, 14 Jun 2011 14:41:46 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.131175326; Tue, 14 Jun 2011 17:41:38 -0400
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Tue, 14 Jun 2011 17:41:38 -0400
From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
To: Jari Arkko <jari.arkko@piuha.net>, Tina Tsou <tena@huawei.com>
Thread-Topic: [multrans] Draft Multrans BoF request
Thread-Index: AQHMKtu7I0ttNqtGZ0a/FRHSSyGv7A==
Date: Tue, 14 Jun 2011 21:41:37 +0000
Message-ID: <CA1D4B28.10459%yiu_lee@cable.comcast.com>
In-Reply-To: <4DF6441C.4030301@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.0.101115
x-originating-ip: [24.40.55.71]
Content-Type: multipart/alternative; boundary="_000_CA1D4B2810459yiuleecablecomcastcom_"
MIME-Version: 1.0
Cc: "multrans@ietf.org" <multrans@ietf.org>
Subject: Re: [multrans] Draft Multrans BoF request
X-BeenThere: multrans@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss the work of IPv4-IPv6 multicast." <multrans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multrans>, <mailto:multrans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multrans>
List-Post: <mailto:multrans@ietf.org>
List-Help: <mailto:multrans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multrans>, <mailto:multrans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2011 21:41:48 -0000

Hi Jari,

Yes, dual-stack multicast seems natural and easy for transitioning. Since there is no IPv4 address depletion for IPv6 multicast addresses and most multicast deployments are private, why not multicast content in both IPv4 and IPv6? I see at least two drawbacks:

(1) Bandwidth utilization. Content is agnostic, it doesn't care it was delivered over IPv4 or IPv6. However, when we multicast content in both IP versions, it would double the multicast traffic for nothing. Consider more and more TV channels moving to HD, the bandwidth consumption could be substantial. This problem is particularly problematic when comes to the access network. Cable is a shared media, as long as one receiver subscribes a channel, the media would flow through in the access network.

(2) Managing both IPv4 and IPv6 multicast distribution trees would increase opex. This may not sound big but troubling multicast is cosidered harder than unicast, so this could be some saving.

B.R.,
Yiu


From: Jari Arkko <jari.arkko@piuha.net<mailto:jari.arkko@piuha.net>>
Date: Mon, 13 Jun 2011 20:08:44 +0300
To: Tina Tsou <tena@huawei.com<mailto:tena@huawei.com>>
Cc: "Yiu L. LEE" <yiu_lee@cable.comcast.com<mailto:yiu_lee@cable.comcast.com>>, 'Tom Taylor' <tom111.taylor@bell.net<mailto:tom111.taylor@bell.net>>, "mohamed.boucadair@orange-ftgroup.com<mailto:mohamed.boucadair@orange-ftgroup.com>" <mohamed.boucadair@orange-ftgroup.com<mailto:mohamed.boucadair@orange-ftgroup.com>>, "multrans@ietf.org<mailto:multrans@ietf.org>" <multrans@ietf.org<mailto:multrans@ietf.org>>
Subject: Re: [multrans] Draft Multrans BoF request

Also, for my background: are there providers who are asking for multicast transition solutions? I.e., not just deploying multicast separately for the two IP versions?