Re: [multimob] IGMP/MLD Proxy at the MAG

[<[e-mail]>]

Dear all,
Thanks to all for this discussion!
Especially concerning the proposed optimizations I would appreciate if we could document such open issues in an I-D like the very draft one I had prepared for Hiroshima (http://tools.ietf.org/id/draft-von-hugo-multimob-future-work-00.txt) - e.g. with your contributions for an updated version - or with a completely new one, if this is more appropriate.
What do you think?

Best regards
Dirk 

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im Auftrag von Stig Venaas
Gesendet: Montag, 7. Dezember 2009 09:14
An: Hitoshi Asaeda
Cc: [e-mail]
Betreff: Re: [multimob] IGMP/MLD Proxy at the MAG

Hitoshi Asaeda wrote:
> Stig,
> 
> I agree that discussing many technical issues in this ML is beneficial
> to decide the current and future direction of this group.
> On the other hand, I thought the primary point raised by Jari was
> regarding the necessity of protocol modification for "optimized"
> mobile multicast.
> Although I don't restart the discussion about the "optimization", what
> we should know now is what functions should be taken into account for
> mobile multicast and which functions may not properly work without
> protocol modification or how such functions can be revived by
> effective protocol modification.
 >
> I think a seamless handover (bullet 1) requires protocol modification.
> It is impossible to provide a seamless handover without protocol
> modification. This is the main concern.

I agree with you. And we have already seen several drafts that discuss
various optimizations. Although we should not work on optimizations now,
it might be worthwhile documenting the shortcomings of whatever basic
solution we come up with.

> I also raised other scenarios (bullet 2 to 4). In the current charter,
> although some of them could be implemented by some methods without
> protocol modification. However, for them, as well as bullet 1,
> protocol performance may be improved or operational cost may be
> reduced if protocol modification is allowed. This is still my guess,
> though.
> 
> Again, I don't deny the current MLD proxy approach.
> My point is that it is beneficial for this group to move forward by
> rechartering after the current basic proposal (i.e. implementation
> with no protocol modification) is clarified and completed.

We are in agreement then :)
> 
> 
> Ok, then I reply Stig's comments below.
> 
>> Right. With respect to the MLD-proxy at the MAG, it can really be policy
>> and/or configuration which upstream interface is used for the various
>> MNs. Which means, which MLD-proxy instance handles the particular MAG-MN
>> interface. Depending on policy/config it can be the usual LMA for the
>> MN, but can possibly be any interface, like an interface to a local
>> router (if you want to subscribe in the local network instead of home
>> subscription), or it could be through say a tunnel interface to another
>> remote router handling multicast, this could also maybe be a "multicast
>> LMA", although I'm not sure yet whether that is a good term.
>>
>> What I'm trying to say is that having an MLD-proxy at the MAG allows for
>> other approaches than just using the LMA-MAG, and it can maybe be done
>> on a per MN basis.
> 
> How do you do it? By configuration? Per MN? Per channel?
> It is called "static route", isn't it? :)

OK, I didn't want to go into details, but for instance today you may
have that your MNs are using different LMAs. In the same way I can
imagine for instance that an operator could configure that MNs that
use one LMA for unicast should get multicast locally, while MNs that
use another LMA should get multicast from that LMA. There could be
other ways of determining which proxy instance/upstream interface to
use for a given MN. My point is just that I think there is a lot of
flexibility in this approach.

>>> This is the way to escape from protocol modification, by configuring
>>> "multicast enable (MLD proxy enable) MAG" and "unicast only MAG".
>>> However, it does not enable to establish the shortest multicast path
>>> for every channel and will use triangle routes. And also it may
>>> require special operational or resource costs, I guess.
>>> Is it an optimal way this group's charter aims anyway?
>> I feel we need a solution that does not require multicast support in
>> the local network and which does subscription through the MAG-LMA
>> tunnel. Which also the charter says. But as I wrote above, the proxy
>> approach could allow local subscription too. Describing that should
>> maybe be left for later, but I believe it is a simple extension. I think
>> it's good if we describe a base model, but which is easily extensible.
> 
> I cannot imagine such mechanism by a simple extension, but I agree
> it'd be good if possible.
> 
>>>>> 3. No local routing supported only with MLD proxy. If local routing
>>>>>   should be supported, dual-mode implementation (MLD proxy and PIM on
>>>>>   MAG or LMA) should be also discussed.
>> I'm not so sure about mixing MLD proxy and PIM router either. You
>> could certainly do PIM instead of MLD proxy, it's almost identical,
>> but as you say, a bit more flexible. My only worry about doing PIM
>> on the MAG is that it's more heavy duty. It also requires LMAs to
>> support PIM I think, at least if you think of doing the equivalent
>> of base MLD-proxy approach with PIM instead. While with MLD-proxy
>> you have a choice whether the LMA should be another MLD-proxy or a
>> PIM router. In a way this can be a deployment choice, but you have
>> a problem if your MAG only supports PIM and LMA only MLD.
> 
> Right. Hence I said the requirement of "dual-mode implementation".
> 
>> I think this point is certainly worth discussing. Maybe we can keep
>> discussing it now and see what people think. I'm leaning towards
>> MLD-proxy as a more simple basic solution (with PIM a possible later
>> improvement), but depending on the resources available at MAGs, PIM
>> could certainly be an option. One consideration here is the complexity
>> of a single PIM instance with multiple upstream interfaces, compared to
>> multiple MLD-proxy instances serving those same upstream interfaces. PIM
>> is significantly more complex (and it comes in addition to doing MLD on
>> the downstream interfaces), but with many upstream interfaces, PIM might
>> be easier.
> 
> Yes, that is the point.
> 
>> I also want to say though that if we later describe new solutions
>> involving protocol changes, I think one could also imagine a proxy
>> implementation that handles multiple upstream interfaces. Or it is
>> in a way an implementation detail how you implement multiple proxy
>> instances in the most efficient way.
> 
> Well, according to its concept, proxy modification is more difficult,
> because it behaves as a host (from a view of its upstream router) and
> does not select an incoming interface. If it selects an incoming
> interface intelligently and dynamically, it's called a router. :)

I see your point, but I had a more static binding in mind. That
according to some policy the upstream interface could be determined in
a more static way. I'm not talking about say RPF here. Anyway, I think
this is something we can discuss later if you like.

> For PMIP modification, adding the state transition mechanism with
> defining new messages and CT mechanism would address most issues and
> work with any multicast instance (e.g. proxy or router).

I think you're right, but need to think more about it.

Stig

> Regards,
> --
> Hitoshi Asaeda

_______________________________________________
multimob mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/multimob