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

[seil jeon <[e-mail]>]

Hi Hitoshi,

Please see inline.

2011/12/12 Hitoshi Asaeda <[e-mail]>

> Hi Seil,
>
> >> PIM-SM does not need to use PMIP policy routing at all.
> >> Some MRIB entries are copied from MAG's RIB, other MRIB entries are
> >> separately configured if needed. The MRIB entries may use M-Tunnel
> >> established between MAG and LMA.
> >
> > O.K. If my understainding is correct, your PIM-SM idea is based on not
> > "PMIP tunnel" but "M-Tunnel" between MAG and LMA to choose one LMA using
> > RPF algorithm.
>
> If LMA is not an upstream router in MAG's RIB but if it should be in
> MAG's MRIB, M-Tunnel is used to attach.
>
> > And "M-Tunnel" information is in MAG's RIB.
>
> Precisely, "M-Tunnel information is in MAG's MRIB".
>
> > 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).


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




> Regards,
> --
> Hitoshi Asaeda
>