Re: [multimob] Proposals and charter discussion

"Luis M. Contreras" <luisc@it.uc3m.es> Sun, 01 November 2009 12:59 UTC

Return-Path: <luisc@it.uc3m.es>
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 C7B393A6852 for <multimob@core3.amsl.com>; Sun, 1 Nov 2009 04:59:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 peccVCrwovAI for <multimob@core3.amsl.com>; Sun, 1 Nov 2009 04:59:33 -0800 (PST)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 79A203A6358 for <multimob@ietf.org>; Sun, 1 Nov 2009 04:59:33 -0800 (PST)
Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 31AE6BA83AD; Sun, 1 Nov 2009 13:59:50 +0100 (CET)
Received: from 106.pool85-49-206.dynamic.orange.es (106.pool85-49-206.dynamic.orange.es [85.49.206.106]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Sun, 01 Nov 2009 13:59:48 +0100
Message-ID: <20091101135948.qmgnb7zw80k0wwg8@webcartero01.uc3m.es>
Date: Sun, 01 Nov 2009 13:59:48 +0100
From: "Luis M. Contreras" <luisc@it.uc3m.es>
To: "Thomas C. Schmidt" <schmidt@fhtw-berlin.de>
References: <4AEB5B09.3060907@venaas.com> <4AEB62D6.4030105@fhtw-berlin.de>
In-Reply-To: <4AEB62D6.4030105@fhtw-berlin.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.0.4)
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16982.007
Cc: isoto@it.uc3m.es, multimob@ietf.org
Subject: Re: [multimob] Proposals and charter discussion
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/mail-archive/web/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>
X-List-Received-Date: Sun, 01 Nov 2009 12:59:34 -0000

Hi all,

I think that draft-contreras-multimob-msd-00 can fit also into the 
category of "dedicated multicast LMA" when the MAG operates as MLD 
proxy and the upstream interface is defined over the tunnel between the 
MAG and the LMA, as mentioned in section 6.1. The draft considers just 
one MLD proxy instance per MAG, that is the case of "dedicated 
multicast LMA" category.

Additionally, draft-contreras-multimob-msd-00 presents a handover 
support method which is applicable for all cases. I think it could be 
considered as input for both proposal categories under evaluation.

Best regards,
Luis


"Thomas C. Schmidt" <schmidt@fhtw-berlin.de> dijo:

> Hi Stig,
>
> if I overlook proposals correctly, there are three contributions that 
> comply to the charter:
>
> [Direct Routing Option:]
> If native multicast routing reaches all MAGs in a PMIP domain, then 
> straight-forward MLD proxying can be applied at MAGs with neither 
> participation of the LMAs, nor tunneling.
> This is proposed in parts of [draft-sijeon-multimob-mms-pmip6-01], if 
> you strip context transfer and predictive operations off the document.
>
> [Dedicated Multicast LMA:]
> If all multicast traffic of an entire PMIP domain is managed by a 
> single LMA, then all MAGs may choose a tunnel with this particular 
> LMA for multicast uplink. There is no need for proxy binding caches 
> and MN-specific states at the LMA.
> This is proposed in section 3. of [draft-zuniga-multimob-smspmip-00], 
> if you strip handover-specifics off the document.
>
> [Proxy instance per LMA:]
> If multicast traffic in PMIP should follow unicast paths, then it 
> arrives at the MN via MN-specific LMAs and MAGs on the basis of proxy 
> binding caches. This approach is a direct extension of unicast, 
> facilitated by placing a proxy instance per MAG-LMA uplink on MAGs 
> and proposed in [draft-schmidt-multimob-pmipv6-mcast-deployment].
>
> From my understanding of the available documents, no further 
> contributions exist that comply to the charter (i.e., do not change 
> PMIP or multicast protocols, or the processing/semantics at 
> corresponding routers).
>
> Hope that clarifies the field ;)
>
> Cheers,
>
> Thomas
>
>
> Stig Venaas wrote:
>> The main goal of our meeting in Hiroshima is to see if we can adopt
>> documents for our charter work items. In addition to the technical
>> evaluation, we also need to consider whether documents are within our
>> charter. Either whether the document is currently within the charter,
>> or if it can easily be updated to be within the charter.
>>
>> For PMIP, we have the following milestone:
>>
>> Nov 2009 Initial version of a document explaining the use of multicast
>> in PMIPv6
>>
>> It might be good to get some discussion on the list prior to the meeting
>> to see which proposals may be within the charter and a candidate for
>> this. We will certainly be discussing this in the meeting, but by having
>> some discussion and analysis on the mailing list before the meeting, we
>> may be able to have a better discussion at the meeting itself.
>>
>> You should all read the charter at
>> http://www.ietf.org/dyn/wg/charter/multimob-charter.html
>>
>> Some of the important points related to PMIP (this may not be a full
>> list, so read the charter itself) are:
>>
>> 1. Work requiring modifications to mobility protocols and IGMPv3/MLDv2
>>    is out of scope in this first stage of this working group.
>>    Modifications to multicast routing protocols are out of scope.
>>
>> 2. This work will not require any additions or changes to message types
>>    and parameters specified in RFC 5213,
>>
>> 3. and must assume an unmodified mobile host.
>>
>> 4. The work will employ the remote subscription model. This is a
>>    mechanism by which a mobile node joins a multicast group and
>>    receives multicast data forwarded via the local mobility anchor.
>>
>> I hope I've given managed to point out the main points in the charter in
>> a fair way. It's the charter text itself that is important, not what I
>> write here though.
>>
>> I now hope we can get some discussion on whether the different proposals
>> match the points above, or if you like, the charter text.
>>
>> Stig, co-chair hat on
>> _______________________________________________
>> multimob mailing list
>> multimob@ietf.org
>> https://www.ietf.org/mailman/listinfo/multimob
> _______________________________________________
> multimob mailing list
> multimob@ietf.org
> https://www.ietf.org/mailman/listinfo/multimob
>



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Luis M. Contreras
Profesor Asociado
Dpto. de Ingeniería Telemática
Universidad Carlos III de Madrid
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~