Re: [magma] Multicast Router Discovery - Is it a valid solution?

[Brian Haberman <[e-mail]>]

Pekka Savola wrote:

>On Thu, 4 Sep 2003, Brian Haberman wrote:
>  
>
>>     The initial point that should probably be discussed is
>>whether people feel that the general approach defined in MRD is
>>useful for the task of finding multicast routers.
>>
>>     When MRD was first defined, no other work had started on
>>IGMP/MLD snooping.  The goal was to define a mechanism that
>>would provide switches the capability of quickly discovering
>>the location of multicast routers without having to update code
>>everytime a new routing or group management protocol came along.
>>
>>     At this point, there is also the issue that the snooping
>>draft recommends using MRD as a part of an overall switch/snooping
>>implementation.
>>    
>>
>
>You said "The initial point"; are followup questions to be expected on 
>other points?
>
Yes.  If we determine that MRD accomplishes the function needed, I will
outline the open issues with it that need to be addressed.

>
>My brief take is that MRD seems to suffer from a case of lack of clear 
>applicability.  This can be seen e.g. by looking at an extension proposed 
>for it, draft-ietf-magma-mrdssm-03.txt.  That extends the use of MRD from 
>snooping switches to practically every host.
>
>I think we have to be very, very careful here.  Approach like MRDSSM 
>doesn't look good.
>
The MRD-SSM extension is not the issue.  At this point, we need to 
determine whether
the base MRD spec is the correct approach.

>
>On the other hand, it may be useful to be able to automate the mechanism
>the snooping switches (or IGMP proxies, maybe) could use to to find the
>multicast routers.  I haven't looked closely enough in that problem space
>to see whether this kind of mechanism is really needed though.
>
That was the original goal of MRD.  A simple means for a switch to find 
the multicast
routers.

>
>However, my concern is that if we're only interested in router<->snooping 
>switch interaction, is this the right solution?  In particular, is the 
>solution unnecessarily complex for the task to be done?
>
How is it complex?

>
>Perhaps we could just get around the problem by having the router send a
>magic multicast heartbeat packets (e.g. a probe to a designated
>224.0.0.x/24 address), using which the switches could figure out what is
>the path towards the router(s), as simple as that.
>
As Hugh pointed out in another follow-up, there is a need for a 
capability that
allows the switch to elicit a quick response from a router rather than 
waiting for
the next heartbeat.

>
>The hosts in the subnet could mess this up, of course, by also sending 
>such packets, but that's already the case with MRD, and similar 
>countermeasures would apply.
>
Agreed.

>
>So, to conclude, I'm very concerned with the direction MRD has taken, in
>particular whether it's the right way to solve this particular problem.  
>But if we end up going for it anyway, I'd sugggest publishing it as
>Experimental, not PS.
>
Do you also think that ICMP Router Discovery should have been 
Experimental?  This is
essentially the same functionality.

Or is your concern more with the proposed extensions to MRD?

Regards,
Brian


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