draft-ietf-magma-snoop-11.txt

Folks --
	An update to the snoop draft has just been sent to the repository.  The
changes are editorial in nature:
      * the section related to not rejecting packets with an all-zeros
        source address has been simplified in order to avoid perceived
        conflicts between this and the proxy draft
      * references to other drafts have been updated to their current
        revisions
      * correction to one of the "Author's Addresses"

I-D ACTION:draft-ietf-magma-snoop-11.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multicast & Anycast Group Membership Working Group of the IETF.

	Title		: Considerations for IGMP and MLD Snooping Switches
	Author(s)	: M. Christensen, et al. 
	Filename	: draft-ietf-magma-snoop-11.txt
	Pages		: 23
	Date		: 2004-5-5
	
This memo describes the recommendations for IGMP- and MLD-snooping
switches. These are based on best current practices for IGMPv2,
with further considerations for IGMPv3- and MLDv2-snooping.
Additional areas of relevance, such as link layer topology changes
and Ethernet-specific encapsulation issues, are also considered.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-magma-snoop-11.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-magma-snoop-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 

IGMP snooping L3 forwarding

I-D ACTION:draft-ietf-magma-snoop-11.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multicast & Anycast Group Membership Working Group of the IETF.

	Title		: Considerations for IGMP and MLD Snooping Switches
	Author(s)	: M. Christensen, et al.
	Filename	: draft-ietf-magma-snoop-11.txt
	Pages		: 23
	Date		: 2004-5-5
	
This memo describes the recommendations for IGMP- and MLD-snooping
switches. These are based on best current practices for IGMPv2,
with further considerations for IGMPv3- and MLDv2-snooping.
Additional areas of relevance, such as link layer topology changes
and Ethernet-specific encapsulation issues, are also considered.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-magma-snoop-11.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-magma-snoop-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-magma-snoop-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Re: Comments draft-ietf-magma-snoop-11.txt (SSM)

Excuse me but were you hybernating during the last call etc for this
draft? This is currently in the RFC editor queue!

Isidor

Toerless Eckert writes:
>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 <at> 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
>
>_______________________________________________
>magma mailing list
>magma <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/magma
>

Re: Comments draft-ietf-magma-snoop-11.txt (SSM)

I am very sorry for the last public message. It was meant to be a
private message to Toerless.

Isidor

Isidor Kouvelas writes:
>
>Excuse me but were you hybernating during the last call etc for this
>draft? This is currently in the RFC editor queue!
>
>Isidor
>
>Toerless Eckert writes:
>>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 <at> 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
>>
>>_______________________________________________
>>magma mailing list
>>magma <at> ietf.org
>>https://www1.ietf.org/mailman/listinfo/magma
>>
>
>_______________________________________________
>magma mailing list
>magma <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/magma
>

Re: Comments draft-ietf-magma-snoop-11.txt (SSM)

On Mon, 17 May 2004, Isidor Kouvelas wrote:
> Excuse me but were you hybernating during the last call etc for this
> draft? This is currently in the RFC editor queue!

Further, I think there was considerable pushback for configured SSM 
ranges in IETF59 when we had this debate.

If folks think that's important, it should be easily to specify as a 
separate draft to the new mrdisc.  Then we'd see who would bother 
implementing it :)

> Toerless Eckert writes:
> >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 <at> 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
> >
> >_______________________________________________
> >magma mailing list
> >magma <at> ietf.org
> >https://www1.ietf.org/mailman/listinfo/magma
> >
> 
> _______________________________________________
> magma mailing list
> magma <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/magma
> 

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: Comments draft-ietf-magma-snoop-11.txt (SSM)

On Tue, May 18, 2004 at 12:27:03AM +0300, Pekka Savola wrote:
> On Mon, 17 May 2004, Isidor Kouvelas wrote:
> > Excuse me but were you hybernating during the last call etc for this
> > draft? This is currently in the RFC editor queue!
> 
> Further, I think there was considerable pushback for configured SSM 
> ranges in IETF59 when we had this debate.

I don't remember that. I also know that our customers explicitly asked
us to have the SSM range configurable. But be that as it may. I don't think
we have arrived at the conclusion that there MUST only be SSM on the
default range, and providing automatic support for SSM on any range with
IGMP snooping is easy enough to do, so i don't thnk we need to gate a
decision on what to recommend for IGMP snooping by whatever discussion
we have over further down the road recommendations for scoped SSM 
address range support.

> If folks think that's important, it should be easily to specify as a 
> separate draft to the new mrdisc.  Then we'd see who would bother 
> implementing it :)

I wonder how many folks here have actively been involved in deployment
discussions for larger SSM solutions. I don't think that the active magma
working group participation should be so bold to exclude well working
approaches for scoping SSM purely based on their own perceptions. IGMP snooping
is currently the one most needed functionality in support of SSM and excluding
an already deployed and working solution to support this pending on the
adoption of a not yet deployed scoping approach doesn't sound like a logical
approach. And pushing the solution back to other protocols to be defined
and implemented first is likewise bogus.

Cheers
	Toerless

RE: Comments draft-ietf-magma-snoop-11.txt (SSM)

> -----Original Message-----
> From: Toerless Eckert [mailto:eckert <at> cisco.com]

> I don't remember that. I also know that our customers explicitly asked
> us to have the SSM range configurable. But be that as it may. 
> I don't think
> we have arrived at the conclusion that there MUST only be SSM on the
> default range, and providing automatic support for SSM on any 
> range with
> IGMP snooping is easy enough to do, so i don't thnk we need to gate a
> decision on what to recommend for IGMP snooping by whatever discussion
> we have over further down the road recommendations for scoped SSM 
> address range support.

I have to agree that SSM should be implementable over any multicast address range. I'm not clear why anyone
would object to this. One argument is that since IP multicast is a receiver-controlled protocol, the
receivers should be able to filter based on whatever criteria they think make sense. No matter what the
group address.

In addition, it would seem to me that any IP multicast content could be advertized to require or not require
SSM. "Group X is best joined with SSM," or "Group X requires SSM." Anything wrong with that? However these
multicast groups are announced can also announce what's required to receive them properly, much like web
sites advertize the best screen resolutions to use.

Bert