Re: [multimob] 答复: multimob Digest, Vol 62, Issue 21

[Hitoshi Asaeda <[e-mail]>]

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.

>> 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.

>> 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.

>> 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.

Regards,
--
Hitoshi Asaeda