From mailman-admin@ietf.org Sat May 1 11:36:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26483 for ; Sat, 1 May 2004 11:36:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJuVI-0002qI-AV for ssm-archive@lists.ietf.org; Sat, 01 May 2004 09:26:04 -0400 Date: Sat, 01 May 2004 09:26:04 -0400 Message-ID: <20040501132604.27207.27376.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ssm-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ssm-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ssm-archive@lists.ietf.org: List Password // URL ---- -------- ssm@ietf.org mifemu https://www1.ietf.org/mailman/options/ssm/ssm-archive%40lists.ietf.org From exim@www1.ietf.org Sat May 1 12:55:02 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01681 for ; Sat, 1 May 2004 12:55:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxIV-0008LG-WB for ssm-archive@odin.ietf.org; Sat, 01 May 2004 12:25:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41GP3kG032060 for ssm-archive@odin.ietf.org; Sat, 1 May 2004 12:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJvBt-0007Pw-QU for ssm-web-archive@optimus.ietf.org; Sat, 01 May 2004 10:10:05 -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 KAA17781 for ; Sat, 1 May 2004 10:10:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJvBr-0003Ph-OS for ssm-web-archive@ietf.org; Sat, 01 May 2004 10:10:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJvB1-0003E9-00 for ssm-web-archive@ietf.org; Sat, 01 May 2004 10:09:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJvAC-00032a-00 for ssm-web-archive@ietf.org; Sat, 01 May 2004 10:08:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJuE0-0005QN-Gx for ssm-web-archive@ietf.org; Sat, 01 May 2004 09:08:12 -0400 Date: Sat, 01 May 2004 09:08:12 -0400 Message-ID: <20040501130812.27207.51141.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ssm-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ssm-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ssm-web-archive@ietf.org: List Password // URL ---- -------- ssm@ietf.org daemut https://www1.ietf.org/mailman/options/ssm/ssm-web-archive%40ietf.org From ssm-admin@ietf.org Mon May 17 13:50:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08266 for ; Mon, 17 May 2004 13:50:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] 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 ([132.151.1.176] 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 [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07336 for ; Mon, 17 May 2004 13:34:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] 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 ([171.68.10.87]) 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 (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 17 May 2004 10:30:35 -0700 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) 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 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-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 232.0.0.0/8 ) 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. Problem: 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. Solution: 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) reports. 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 draft-holbrook-idmr-igmpv3-ssm-06.txt. Thanks Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From exim@www1.ietf.org Mon May 17 14:13:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10016 for ; Mon, 17 May 2004 14:13:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmZC-0005oS-20 for ssm-archive@odin.ietf.org; Mon, 17 May 2004 14:10:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HIAMDU022344 for ssm-archive@odin.ietf.org; Mon, 17 May 2004 14:10:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmHo-0002YT-62 for ssm-web-archive@optimus.ietf.org; Mon, 17 May 2004 13:52:24 -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 NAA08378 for ; Mon, 17 May 2004 13:52:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPmHl-0004Fo-Pa for ssm-web-archive@ietf.org; Mon, 17 May 2004 13:52:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPmGZ-0003pZ-00 for ssm-web-archive@ietf.org; Mon, 17 May 2004 13:51:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPmFX-0003Ld-00 for ssm-web-archive@ietf.org; Mon, 17 May 2004 13:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] 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 ([132.151.1.176] 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 [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07336 for ; Mon, 17 May 2004 13:34:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] 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 ([171.68.10.87]) 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 (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 17 May 2004 10:30:35 -0700 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) 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 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 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , 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 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 232.0.0.0/8 ) 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. Problem: 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. Solution: 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) reports. 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 draft-holbrook-idmr-igmpv3-ssm-06.txt. Thanks Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm