Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt

Hitoshi Asaeda <asaeda@sfc.wide.ad.jp> Sat, 01 November 2008 05:31 UTC

Return-Path: <multimob-bounces@ietf.org>
X-Original-To: multimob-archive@optimus.ietf.org
Delivered-To: ietfarch-multimob-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2377A3A6A5D; Fri, 31 Oct 2008 22:31:43 -0700 (PDT)
X-Original-To: multimob@core3.amsl.com
Delivered-To: multimob@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 460903A6A5D for <multimob@core3.amsl.com>; Fri, 31 Oct 2008 22:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.619
X-Spam-Level: ***
X-Spam-Status: No, score=3.619 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508]
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 7iNlINoNTqXI for <multimob@core3.amsl.com>; Fri, 31 Oct 2008 22:31:41 -0700 (PDT)
Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 5C02A3A6892 for <multimob@ietf.org>; Fri, 31 Oct 2008 22:31:40 -0700 (PDT)
Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id B3C2313D03D6; Sat, 1 Nov 2008 14:09:09 +0900 (JST)
Date: Sat, 01 Nov 2008 14:31:37 +0900
Message-Id: <20081101.143137.247155156.asaeda@sfc.wide.ad.jp>
To: denghui02@gmail.com
From: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
In-Reply-To: <1d38a3350810312008x377ea91aw2739355335d2a207@mail.gmail.com>
References: <352065.68132.qm@web38808.mail.mud.yahoo.com> <4900E5A0.9050306@informatik.haw-hamburg.de> <1d38a3350810312008x377ea91aw2739355335d2a207@mail.gmail.com>
X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Cc: multimob@ietf.org
Subject: Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/multimob>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: multimob-bounces@ietf.org
Errors-To: multimob-bounces@ietf.org

Hi,

> I agree this scenario works for some deployment, but question here is
> whether we need extend any pmip6 protocol to support this scenario?

The protocol extension should be as simple as possible. And if the
base protocols such as PMIPv6/MLD/PIM do not support the functions we
have been discussing, then we should carefully identify the issues.
The key for identifying the issues is to recognize not only the
effectiveness of the protocol extension but also the generality and
independency of multicast services. I mean, the protocol extension
must be generally applicable and beneficial in a common mobile
multicast communication scenario, not only for some special cases/
services.

So, I'd like to again ask the question especially to operators who
plan to or may prepare PMIPv6 multicast services; Is there a big
impact or problem if all multicast traffic goes through an LMA-MAG
tunnel?

Note that our PMIPv6 multicast extension draft tentatively supports
the local routing, but I personally think it can be removed if
consensus.

Regards,
--
Hitoshi Asaeda

> >> [behcet] The situation you are talking about could become valid if route
> >> optimization is used with PMIPv6. In that case the content server in between
> >> MAG and LMA would send directly to MAG. If route optimization is not used
> >> then all traffic goes through LMA-MAG tunnel. Route optimization for PMIPv6
> >> is some future work, there are drafts but we don't know if the
> >> standardization will go ahead.
> >> Route optimization with multicasting is even more complicated problem. If
> >> you wish to state some requirements for this very complicated case please go
> >> ahead.
> >>
> >
> > [thomas] Hmm, I'm not trying to add complicated requirements. This is the
> > overview about possible scenarios.
> >  We're all just trying to think of a reasonable scope to address and solve
> > the problem (so does the recent pmip6-extension-draft ... see also the last
> > mail from Hitoshi).
> >
> > If multicast on PMIPv6 is supposed to serve as a solution for large-scale
> > content distribution (like in IPTV applications), then we should not just
> > propose to tunnel all traffic from one LMA to the MAGs. That's a bitter pill
> > for those who have to pay for the infrastructure.
_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob