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

[[e-mail]]

Hi Hitoshi,
Please see answers inline:

Hitoshi Asaeda <[e-mail]> 写于 2012/07/30 11:19:54:

> Hi,
> 
> >> 1/ You propose the MAGs to be multicast enabled routers. However, to
> >> enabling the solution you propose to set-up a tunnel among the MAGs 
> >> where the source and the listener are attached to. Why do you need 
> >> such tunnel? Why the communication cannot be directly routed without
> >> any additional tunnel (assuming the domain is multicast enabled)? In
> >> fact the tunnel probably will follow the same path as the PIM 
> >> messages would follow.
> > I think that depends on how the MRIB is generated. In our draft,the 
> > MAG-MAG tunnel needs to be included into the MRIB.
> > Otherwise,source-specific Join message will follow the LMA-MAG tunnel 
to 
> > the source.
> 
> At first, all scenarios related to PIM-capable MAG are described in;
> http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-10
> 
> I'd say people who are interested in the optimized solution done by
> PIM-callable MAG had better read above draft.
Yes,the scenarios in our draft are related to PIM-capable MAG.But the 
optimized solution is different from yours.
> 
> >> 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.
> 
> >> 3/ For the mobile node operation you are restricting the 
> >> optimization proposal to the case where the listener is an SSM-aware
> >> host. In my opinion this restricts the solution, not being generic 
> >> (ASM case is not covered)
> > You are right that our solution should cover the ASM scenario,we have 
> > planned to add it in the next version.
> > In the phase three of PIM-SM(ASM Scenario),when the MAG on the 
receiver's 
> > side initiates a transfer from the shared tree to a source-specific 
> > shortest-path tree,the solution can be used in this phase to 
reestablish 
> > the optimized SPT.
> 
> If the standard PIM-SM is supported by the proposed solution, RPT-SPT
> switch must be dependent on PIM-SM itself. In other words, it is not
> necessary to change the standard PIM-SM behavior for RPT-SPT switch.
By doing this,we can establish a optimized SPT instead of a LMA-MAG 
tunnel(towards the MN source) based SPT.
> 
> >> 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.
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.