Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational
Hitoshi Asaeda <Hitoshi.Asaeda@sophia.inria.fr> Tue, 10 June 2003 17:25 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09910 for <ssm-archive@lists.ietf.org>; Tue, 10 Jun 2003 13:25:41 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHOfB10404; Tue, 10 Jun 2003 13:24:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHMaB10322 for <ssm@optimus.ietf.org>; Tue, 10 Jun 2003 13:22:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09834 for <ssm@ietf.org>; Tue, 10 Jun 2003 13:22:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PmnN-0000i9-00 for ssm@ietf.org; Tue, 10 Jun 2003 13:20:29 -0400
Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx with esmtp (Exim 4.12) id 19PmnM-0000i6-00 for ssm@ietf.org; Tue, 10 Jun 2003 13:20:28 -0400
Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (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: <20030610.192141.129511487.Hitoshi.Asaeda@sophia.inria.fr>
To: eckert@cisco.com
Cc: ssm@ietf.org
Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational
From: Hitoshi Asaeda <Hitoshi.Asaeda@sophia.inria.fr>
In-Reply-To: <20030610155923.GR23388@cypher.cisco.com>
References: <20030610144558.GL23388@cypher.cisco.com> <20030610.172332.128597013.Hitoshi.Asaeda@sophia.inria.fr> <20030610155923.GR23388@cypher.cisco.com>
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
Sender: ssm-admin@ietf.org
Errors-To: ssm-admin@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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
- [ssm] Document Action: An Overview of Source-Spec… Bill Fenner
- Re: [ssm] Document Action: An Overview of Source-… Jon Zeeff
- Re: [ssm] Document Action: An Overview of Source-… Toerless Eckert
- Re: [ssm] Document Action: An Overview of Source-… Jon Zeeff
- Re: [ssm] Document Action: An Overview of Source-… Hitoshi Asaeda
- Re: [ssm] Document Action: An Overview of Source-… Toerless Eckert
- Re: [ssm] Document Action: An Overview of Source-… Toerless Eckert
- Re: [ssm] Document Action: An Overview of Source-… Hitoshi Asaeda
- Re: [ssm] Document Action: An Overview of Source-… Toerless Eckert
- Re: [ssm] Document Action: An Overview of Source-… Hitoshi Asaeda
- Re: Re: [ssm] Document Action: An Overview of Sou… Hugh Holbrook
- Re: [ssm] Document Action: An Overview of Source-… Hitoshi Asaeda
- Re: [ssm] Document Action: An Overview of Source-… Jean-Jacques Pansiot