[ssm] Comments draft-ietf-magma-snoop-11.txt (SSM)

Toerless Eckert <eckert@cisco.com> Mon, 17 May 2004 17:50 UTC

Received: from optimus.ietf.org (iesg.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08266 for <ssm-archive@lists.ietf.org>; Mon, 17 May 2004 13:50:33 -0400 (EDT)
Received: from localhost.localdomain ([] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPm7l-0000xh-VH; Mon, 17 May 2004 13:42:01 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPm0P-0008E2-6D for ssm@optimus.ietf.org; Mon, 17 May 2004 13:34:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07336 for <ssm@ietf.org>; Mon, 17 May 2004 13:34:23 -0400 (EDT)
Received: from ietf-mx.ietf.org ([] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPm0N-0005hi-3I for ssm@ietf.org; Mon, 17 May 2004 13:34:23 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlzb-0005M7-00 for ssm@ietf.org; Mon, 17 May 2004 13:33:35 -0400
Received: from sj-iport-5.cisco.com ([]) by ietf-mx with esmtp (Exim 4.12) id 1BPlyh-0004x7-00; Mon, 17 May 2004 13:32:39 -0400
Received: from sj-core-3.cisco.com ( by sj-iport-5.cisco.com with ESMTP; 17 May 2004 10:30:35 -0700
Received: from cypher.cisco.com (cypher.cisco.com []) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i4HHW60Q010589; Mon, 17 May 2004 10:32:06 -0700 (PDT)
Received: (from eckert@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA04268; Mon, 17 May 2004 10:32:05 -0700 (PDT)
Date: Mon, 17 May 2004 10:32:05 -0700
From: Toerless Eckert <eckert@cisco.com>
To: magma@ietf.org, ssm@ietf.org, mboned@ietf.org
Cc: mjc@tt.dk, karen.kimball@hp.com, fsolensky@WestRidgeNetworks.com
Message-ID: <20040517173205.GQ305@cisco.com>
Reply-To: magma@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [ssm] Comments draft-ietf-magma-snoop-11.txt (SSM)
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>

I would hereby like to express my opinion that subject draft MUST
mentioned SSM explicitly (and provide appropriate detail) before
progressing any further. Without mentioning ASM and SSM service model support
explicitly, we will solely get yet another document that will not
support SSM sufficiently anmore and given that SSM is recognized by
mboned to be the one service model the IETF should focus further
work on, it is unacceptable to over and over get the excuse of
"oh well, the SSM support side can be done later in a different document".

[ Cc'ed ssm and mboned working groups to alert them about this lack
  of right focus of that draft. Please keep replies to the 
  Reply-To: magma@ietf.org, to avoid flooding three mailing lists with this. ]

Specifically this is what i think is needed:

  SSM can be used in varying IPv4 address ranges, a decision as to limit
  it to specific address ranges (like only the default ) has
  not been made (i would also oppose that). IGMP snooping switches on
  the other hand should be zero-config simply deployable devices that
  do not necessarily need to be configured to know L3 specifics like
  an SSM range.

  For this reason i would recommend that a default mode of operations
  of IGMPv3 switches is mandated which provides for SM-safe-reporting, 
  meaning that receiver systems expecting to use SSM will not be impacted by
  (erroneous) receiver systems using ASM style membership reports on
  any addresses.

    Reporter 1 on port 1 sending an INCLUDE({S},G) IGMPv3 report, reporter
    2 on port 2 sending an EXCLUDE({},G) IGMPv3 report. IGMP snooping
    switch builds aggregate state for G to report to upstream router(s).
    This aggregate state is (according to IGMPv3 specs) EXCLUDE({},G).
    If only this is reported, reporter 1 SSM application will fail because
    the router never receives any INCLUDE({S},G) reports.
    Define SSM-safe-reporting to be a condition for an IGMP snooping switch
    in which it ensures that all include({S},G) membership state will
    be reported correctly to router ports irrespective of exclude({..},G)

    There are lots of alternatives on how a switch can do this, the
    most simple one is to pass on _all_ membership reports from
    hosts without suppressing any of them on ports connected to routers.
    That way in above example both the INCLUDE and EXCLUDE mode report
    would be seen by the router and if G is SSM, the router can correctly
    ignore the EXCLUDE mode report. 

    There are alternatives on how to do SSM-safe-reporting which are
    more complex but provide more membership report suppression/aggregation
    towards router ports, but i think details of those should be left
    up for individual implementations.
    I would simply mandate that the default operations of an IGMP snooping
    switch must provide for SSM-safe-reporting without explicit manual
    configuration of the SSM range and without expecting SSM to be only
    operated on a well known SSM-range (IPv4).

  Obviously, this is only a problem for IPv4, as in IPv6 the SSM-range
  is well defined, MLD-snooping routers can thus rely on that
  range definition.

  And yes, i understand that this is only an informational document, but
  that's all we have. Hugh also does not mentiones snooping in


ssm mailing list