Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational

On Tue, Jun 10, 2003 at 05:23:32PM +0200, Hitoshi Asaeda wrote:
> Maybe I don't understand your question.. but, there is no change about
> querier selection. (What is the relation to my last comment?)

No, i just interpreted your statement incorrectly out of context. Never mind ;-)
But: I am not sure how much more the stronger statement in MLDv2
buys. After all, it's the IGMPv3 for SSM spec that states you to ignore
any non IGMPv3 (include type) reports within the SSM range, so i am
not too much concerned about group mode behavior on the router, the
only critical elements is host behaviour and illegal lower version queriers.

> > Sure, such configuration options will be all over us and make deployment
> > even more complex. You can pretty much figure that only the default
> > behaviour will be what 90% of people will have installed. 
> 
> I prefer to have an option to fix the problem rather than close my
> eyes, even though it may make some additional complexity. (But it's
> really complex?)

And i prefer to have what's needed be enabled by default so that the
90% population that doesn't want to waste understanding this mess still
gets a save and working feature.

> Anyway, in a README file of IGMPv3 imple., I specify as follws:
> 	....
> 	After this static configuration is done, any old IGMP Query
> 	message doesn't affect to change the compatibility mode.
> 	Remember this is useful only when correct upstream router(s)
> 	must be IGMPv3 capable and you want to filter out or ignore
> 	some bogus or unneeded old version's Report and Query messages
> 	transfered by irregular nodes. This configuration affects all
> 	interfaces of the box.
> 	Note that this configuration is not mentioned in a spec and
> 	turned off as the kernel's default value.

Very nice. Now how many pizzas does it take for you to enable this by
default ? ;-)) (yeah, yeah, i know you can't do this today, see - that's
the problem with config options, they are never enabled when you need them).

Here's what i would recommend for this protection: Define another
kernel flag (maybe force_v3_4_ssm) which you can enable by default.
If it is enabled, then you will force yourself into that IGMPv3 mode
(like with the flag you already have) only whenever there is at least
one active INCLUDE mode membership application running (eg: a socket
with an include source list). There's a higher than 90% chance that
an application using INCLUDE mode memberships is written for SSM, so
there you have your 90% correct by default situation. Sure, this wouldn't
work all too well for servers running a lot of different multicast
application simultaneously, but those are way below the 90% mark too.
And this default could be changed wether or not this is supposed to be
desktop or server installation.

Even if you don't have this flag enabled by default, you can still have
warnings by default: If you're not using IGMPv3 membership reports
(eg: querier is older) but you start an application using INCLUDE mode
reports, this might be worthy of a syslog to console or the like.

There's a lot of things you can do to improve the perception of SSM
application users i think. 

Cheers
	Toerless

> I've never said host compat is *always* wrong. But we may need to
> bypass this automatic mode change *for some cases*. And at this
> moment, I don't have other good idea to bypass it.
> Or, do you have another solution to bypass the DoS Jon Zeeff mentioned?
> Or, ignoring the problem is good for the deployment?
> 
> > > FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway.
> > 
> > Is it on by default ? 
> 
> No.
> 
> Thanks.
> --
> Hitoshi Asaeda
_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm