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

[Hitoshi Asaeda <Hitoshi.Asaeda@sophia.inria.fr>]

Toerless,

> No, i just interpreted your statement incorrectly out of context. Never mind ;-)

Okay. :)

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

No. I mean, whether the multicast address is within the SSM range or
not, and whether the multicast routers compatibility mode is v3 or
not, IGMPv3 capable router SHOULD always send IGMPv3 General query. It
SHOULD NOT send IGMPv1/v2 query in order to avoid that the host
compatibility mode of IGMPv3 capable node is switched to v1/v2 by such
downgraded General query. Due to this rule, the v3 capable node
switches its compat mode only when v1/v2 router, which means
"non-upgraded router", appears on the link (with sending v1/v2 General
query).
It is in fact no problem for non-upgraded *legal* end-nodes since they
can only look 8 bytes from the top of the query message. So, we would
be able to guarantee the interoperability as well.
Further if you want to avoid the mode switch by the v1/v2 router, then
you can configure the compat mode disable by "statically". But as we
agreed, this should not be the default.
These situations are same of MLDv2.
This is my thought.

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

Sounds interesting. I would think it.
Thanks.
--
Hitoshi Asaeda
_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm