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

[Isidor Kouvelas <[e-mail]>]

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: [e-mail], 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
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/magma
>

_______________________________________________
magma mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/magma