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

Hitoshi Asaeda <> Tue, 10 June 2003 17:25 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id NAA09910 for <>; Tue, 10 Jun 2003 13:25:41 -0400 (EDT)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h5AHOfB10404; Tue, 10 Jun 2003 13:24:41 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h5AHMaB10322 for <>; Tue, 10 Jun 2003 13:22:36 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA09834 for <>; Tue, 10 Jun 2003 13:22:30 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19PmnN-0000i9-00 for; Tue, 10 Jun 2003 13:20:29 -0400
Received: from ([]) by ietf-mx with esmtp (Exim 4.12) id 19PmnM-0000i6-00 for; Tue, 10 Jun 2003 13:20:28 -0400
Received: from localhost ( []) by (8.12.8/8.12.5) with ESMTP id h5AHLgvK017781; Tue, 10 Jun 2003 19:21:42 +0200
Date: Tue, 10 Jun 2003 19:21:41 +0200
Message-Id: <>
Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational
From: Hitoshi Asaeda <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Mew version 2.2rc1 on Emacs 21.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Source-Specific Multicast <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit


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

> 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.
Hitoshi Asaeda
ssm mailing list