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

[Hugh Holbrook <[e-mail]>]

Without commenting on the MRD-SSM extension, it seems to me that MRD
solves a real problem for an IGMP snooping implementation.  A snooping
implementation today has no clean way to find the multicast routers.
Like it or not, IGMP snooping is here for the foreseeable future and
it seems reasonable to me to make it work better.

MRD doesn't seem particularly complicated to me.  It's hard to imagine
something much simpler that doesn't sacrificing something important.

If one takes it as a goal of MRD to help snooping switches, then I the
224.0.0.x idea has one signification limitation.  I know of a number
of snooping switches deployed today that are layer-2 only devices with
the ability to intercept IGMP.  On such a device, one doesn't have the
ability to intercept packets sent to a specific IP address, so (if you
care about that) then designating some 224.0.0.x as a router
advertisement address wouldn't help these devices, because of the l2
aliasing of IP multicast.

The protocol looks pretty simple to me.  If you eliminate the
solicitation message then you increase the time it takes a switch to
recover state after a reboot.  I suppose one could eliminate the
terminate message if one felt compelled to cut to the bone, but I
don't see that as a big deal.

MRD seems to me like it solves a sort of small problem in a relatively
simple way, and I don't have a problem with advancing it.

Cheers,
-Hugh


> Date: Fri, 5 Sep 2003 10:59:30 +0300 (EEST)
> From: Pekka Savola <[e-mail]>
> Cc: MAGMA Mailing List <[e-mail]>
> 
> 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?
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
> _______________________________________________
> magma mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/magma

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