Re: [multimob] draft-asaeda-multimob-pmip6-extension-05

[Hitoshi Asaeda <[e-mail]>]

Hi Behcet,

>   I read your draft and have some comments.
> In section 3.3, you say MN sends MLD Report upon multicast data
> reception. Why? 
> I think there is something wrong in that sentence.

I cannot understand what's wrong here?

> Your draft is long and detailed and on top of that it mentions [9] 
> draft-asaeda-multimob-igmp-mld-mobility-extensions-03.txt as normative 
> reference. 

Right, that draft should be informative reference. I'll move it in the
next revision.

> What I am more curious about is how your draft solves the tunnel convergence 
> problem. I don't think it is the M-Tunnel because as you mentioned
> M-Tunnel is MAG-LMA tunnel as in [2], i.e. RFC 5213. 

Single M-Tunnel is established between LMA-MAG and dedicated to
MLD messages and multicast data transmission. It is shared by all MNs
attached to a MAG. It's not established per MN, unlike rfc5213.

> I don't think it is MAG as PIM-SM router as you mention that
> operators would not 
> like it. Sorry but I could not find a specific solution proposal in
> your draft. 
> Maybe I missed something.

It is one of the possible ways for multicast services in PMIPv6
domain. I cannot find the reason to prohibit PIM-SM capable MAG.
In fact, since an incoming interface can be set up by the PIM-SM
capable MAG, it gives the chance of localized routing and source
mobility without any protocol modification.
Giving the possibility of a PIM-SM capable MAG would be rather
positive in my feeling.

> How relevant your Section 7 is to the tunnel convergence solution? I
> have a feeling that it is more relevant for handover optimizations
> work item we have.

I think sharing single M-Tunnel by all MNs address the tunnel
convergence problem. If you don't think so, could you tell me what the
problem is?
Regarding handover, I believe our proposed extension is not only
simple and in line with the standard functions, but effectively 
provides seamless handover.
I don't deny someone will propose other mechanisms or extensions with
a different view for the optimization in the later phase, such as
proactive handover. But their mechanisms might require more extension
or additional functions to give more optimization. Our proposal could
be defined as the base extension for them, I guess.

Regards,
--
Hitoshi Asaeda