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

[Isidor Kouvelas <[e-mail]>]

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: [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
>

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