Re: [multimob] Comments on draft-liu-multimob-pmipv6-multicast-ro-01(JUAN LIU)

[[e-mail]]

Hi Hitoshi,
Thank you for your comments,please see answers inline:

Hitoshi Asaeda <[e-mail]> 写于 2012/07/31 00:35:40:

> Hi,
> 
> >> >> 2/ When you describe the establishment of bidirectional tunnels 
> >> >> between MAGs you refer RFC5213 for further detail, but RFC5213 
does 
> >> >> not include tunnel establishment between MAGs. This is not covered 

> >> >> by standard PMIP (it implies an extension).
> >> > You are right that RFC5213 does not include tunnel establishment 
> > between 
> >> > MAGs.we will correct the description in the next version.
> >> > we can refer to section6.2 of draft-ietf-netext-pmip-lr for 
tunneling 
> >> > between the MAGs.
> >> 
> >> See M-tunnel configuration described in section 4 of above draft.
> > There can be vavious tunnel negotiation mechanisms between MAG,better 
> > based on existing mechanism.
> 
> Does your draft assume MAG acts as MLD proxy for remote subscription
> and also acts as PIM router for local routing?
Our draft does't put any assumption on remote subscription and local 
routing.
MAG acts as PIM router in our solution.
> 
> >> >> 4/ Through the PBU-Q/PBA-Q sequence of messages you are able to 
> >> >> obtain the CoA for the MN source. However, how do you know in 
> >> >> advance that the MN source is attached to the domain? There is no 
> >> >> way of knowing it in advance, and because the MN HoA is not an 
> >> >> address of the PMIPv6 domain, how do you deduce that it is a MN 
> >> >> source? Do you send the PBU-Q for all kind of SSM subscriptions? 
> >> >> Additionally, what happens (what is the message) in case the 
source 
> >> >> is effectively not attached to the PMIPv6 domain
> >> > Yes,we can not know in advance that the MN source is attached 
> to the same 
> >> > domain.So if the MAG in the listener side figures(through the 
> PBU-Q/PBA-Q 
> >> > messages) that the MN source is not attached to a MAG in the 
domain, it 
> >> > will process the multicast message as normal.
> >> > We send the PBU-Q every time when the MAG in the listener side 
> first joins 
> >> > the (S,G) channel.
> >> > We don't solve the case when the source is not attached to the 
PMIPv6 
> >> > domain, the draft assumes that the MN source and MN listener are 
both 
> >> > mobile nodes attached to their own MAG.
> >> 
> >> I don't understand why other query message (except IGMP/MLD query) is
> >> needed.
> > The query message in our solution is used to locate the MN source in 
the 
> > PMIPv6 domain.
> 
> Then I may ask the same question Luis did.
> Does this extension properly work with moving source?
Please see above answer for Luis's question.
This extension can work with source mobility, you can refer to the link 
below to have a rough knowledge on how it works: 
http://www.ietf.org/id/draft-liu-multimob-pmipv6-multicast-ro-02.txt
Details will be included in the next version.
BR,
Juan Liu
> 
> Regards,
> --
> Hitoshi Asaeda
> 



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.