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

[Toerless Eckert <eckert@cisco.com>]

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