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

[Behcet Sarikaya <[e-mail]>]

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