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 _______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
