Re: [multimob] Comment on draft-asaeda-multimob-pmip6-extension-07

[Hitoshi Asaeda <[e-mail]>]

>> And if then, the upstream router of MAG has nothing to be an LMA, it can be
>> another dedicated server for multicast support because it does not use PMIP
>> tunnel. So, your idea appear to me as one of specific PIM-SM application
>> method over dedicated multicast architecture.
>
> I don't understand what "dedicated server" and "dedicated multicast
> architecture" mean.
 
=> The multicast replicator, as it is, to deliver the multicast
   packets to all attached MAGs (e.g. MTMA named in
   draft-zuniga-multimob-pmipv6-ropt).

We don't need to assume to have such special entity.

> Let's see the case of direct routing.
> If operator thinks streams for some group (or source) prefixes do not
> need to go through LMA (as they are direct routing), MAG enabling
> PIM-SM simply forwards PIM join messages to its adjacent multicast
> router without M-Tunnel and can get the streams natively.

=> The issue is not the use of PIM-SM based direct routing. In my
   sense, the issue was raised because you has been calling the
   entity, establishing "M-Tunnel" with an MAG, an LMA. As I told you
   before, the entity cannot be an LMA but may be closely to a sort of
   multicast replicator server deliverying multicast packets to
   attached MAGs.

There is no issue as you said.
MAG enabling PIM-SM communicates with neighbor PIM-SM routers. The
neighbor PIM-SM router may be the LMA enabling PIM-SM, may be an
adjacent PIM-SM router, etc. No difference from the ordinal PIM-SM
routing behavior.

M-Tunnel is used to configure an upstream (neighbor) router when a
multicast route for some group/source prefixes should be distinguished
from the corresponding route in RIB. This is also same as of the
regular situation (while dedicate M-Tunnel is a new definition of
specific GRE tunnel).

Regards,
--
Hitoshi Asaeda