Re: [multimob] Adoption of draft-schmidt-multimob-pmipv6-mcast-deployment as a WG document

["Thomas C. Schmidt" <[e-mail]>]

Hi Behcet,

if I comprehend your point correctly, then you argue that multicast 
locally available at MAGs is tangential to a PMIP multicast solution. On 
that we fully agree.

The outcome of Hiroshima, repeated in my previous mail, was the following:

  * Everyone should address the issues raised in Hiroshima regarding all 
individual approaches, update the drafts, and then find consensus on the 
base document.

  * In the case that draft-schmidt-multimob-pmipv6-mcast-deployment is 
chosen as the base document, we already offered to include the local 
routing as option, as this easily integrates and is technically almost 
for free.

So there is not much novelty - my main point of the previous mail was 
that the adoption call came too early.

Cheers,

Thomas

Behcet Sarikaya wrote:
> Hi Thomas,
>   
>   Please see more comments below, my understanding of the consensus was
> IGMP/MLD Proxy at MAG integrated with LMA.
> 
> Maybe we need to clarify the consensus.
> 
> 
>> On Dec 10, 2009, at 5:01 PM, "Thomas C. Schmidt" 
>> wrote:
>>
>> Hi Behcet, hi all,
>>
>> I don't understand this "call for adoption" at the current moment.
>>
>> We had the consensus at the Hiroshima meeting (affirmed by the recent mailing) 
>> that MLD/IGMP proxy at the MAG should be the favorite approach to a base 
>> solution.
>>
>> We also had a number of questions and issues raised at the Hiroshima meeting 
>> that were to be addressed in updates of the corresponding proposals currently 
>> around.
>>
>> To recall, we had three original solutions:
>>
>> [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.
> 
> Local MR is a specific solution, the implication of it is that PMIPv6 is not in charge of mobility of multicast data. In these cases multicast becomes tangential to mobility. 
> 
> How is it different than locally available multicast that MN can use without bothering with any mobility protocol?
> 
> It is similar to 
> MAG operation as multicast routerdiscussed in Section 6.2 of draft-contreras-multimob-msd-00.txt.
> 
> We have not discussed these types of solutions where multicast is provided separately of mobility in detail yet possibly because it probably requires a separate charter item for us.
> 
> 
>> [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.
> 
> Isn't LMA-M effectively Local MR in draft-sijeon-multimob-mms-pmip6-01?
> 
> 
>> [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].
>>
> 
> What is the point with this, I could not understand?
> 
>> Questions and issues raised at the meeting were concerned with efficiency, the 
>> MLD-related behavior of current router implementations and "the right way to 
>> organize an uplink". Contributers were asked to update the drafts following 
>> further investigations.
>>
>> The latter has not happened, now. Personally, we are working on "our homework" 
>> and furthermore have indicated an elegant path to merge 
>> draft-sijeon-multimob-mms-pmip6-01 into 
>> draft-schmidt-multimob-pmipv6-mcast-deployment. We are about to prepare our 
>> update  and I guess some room for discussion should be left once all updates 
>> have been prepared.
> 
> See above.
> 
> 
>> So I don't see why this call for working group adoption precedes the updates of 
>> the drafts. I would suggest to await updates and perform the call after the 
>> discussion has reached some level of insight.
>>
> 
> ?
> 
> Regards,
> 
> Behcet
> 
> 
> 
>       

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °