IETF Logo Mail Archive

Re: [multrans] Draft Multrans BoF request

<mohamed.boucadair@orange-ftgroup.com> Wed, 15 June 2011 06:16 UTC

Return-Path: <mohamed.boucadair@orange-ftgroup.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 82E3C11E80B6 for <multrans@ietfa.amsl.com>; Tue, 14 Jun 2011 23:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level:
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
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 KqN7QV2W8Djf for <multrans@ietfa.amsl.com>; Tue, 14 Jun 2011 23:16:35 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 74DDE11E8076 for <multrans@ietf.org>; Tue, 14 Jun 2011 23:16:35 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 3B49626414A; Wed, 15 Jun 2011 08:16:34 +0200 (CEST)
Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 10EE435C064; Wed, 15 Jun 2011 08:16:34 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 15 Jun 2011 08:16:34 +0200
From: <mohamed.boucadair@orange-ftgroup.com>
To: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>, Jari Arkko <jari.arkko@piuha.net>, Tina Tsou <tena@huawei.com>
Date: Wed, 15 Jun 2011 08:16:33 +0200
Thread-Topic: [multrans] Draft Multrans BoF request
Thread-Index: AQHMKtu7I0ttNqtGZ0a/FRHSSyGv7JS98XaQ
Message-ID: <94C682931C08B048B7A8645303FDC9F33E504F8F61@PUEXCB1B.nanterre.francetelecom.fr>
References: <4DF6441C.4030301@piuha.net> <CA1D4B28.10459%yiu_lee@cable.comcast.com>
In-Reply-To: <CA1D4B28.10459%yiu_lee@cable.comcast.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33E504F8F61PUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.15.50614
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: Wed, 15 Jun 2011 06:16:36 -0000

Hi Jari, all,

We have the same analysis in our side.

Cheers,
Med

________________________________
De : Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]
Envoyé : mardi 14 juin 2011 23:42
À : Jari Arkko; Tina Tsou
Cc : 'Tom Taylor'; BOUCADAIR Mohamed OLNC/NAD/TIP; multrans@ietf.org
Objet : Re: [multrans] Draft Multrans BoF request

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?

v2.8.7 | Report a Bug | By Email