[MBONED] mboned/pim: "SSM (in)capable" IGMP snooping switches - and PIM-WG zeroconf work...

[Toerless Eckert <[e-mail]>]

Expanding to mboned, because there may be more operational experience.

draft-ietf-pim-zeroconf-mcast-addr-alloc-ps refers to L2 switches
that do not support SSM - without defining what this means. And
i do not think we have such a definition. 

One possible interpretation is that such L2 switches do not support
IGMPv3/MLDv2 at all, but just IGMPv2/MLDv1, but of course this would
equally impact ASM, so i hope this is not what is being thought of.

The second possible interpretation is that the switch will do
something wrong, such as ignoring IGMPv3/MLDv2 INCLUDE({S},G)
membership reports while not ignoring IGMPv3/MLDv2 EXCLUDE({},G) membership
reports.

I am not aware of such low-end L2 switches limitations, primarily because
several IPTV providers have been running IGMPv3 with SSM for
several years (intohomes withlow-end switches) and that has lead for
such possible gaps in IGMPv3/MLDv2 snooping support to be fixed quite
broadly in the industry. So if you are aware of switches that do have
this problem, i would love to hear about the models. But i would not call
them non-SSM capable, but non-IGMPv3/MLDv2 capable, because
failure to support IGMPv3/MLD2 INCLUDE memberships is not specific
to SSM.

The third possible interpretation is that the switch will
establish per-port MAC(G) filtering for INCLUDE({S},G) membership
reports in the same way as establishing MAC(G) filtering for
EXCLUDE({},G) membership reports. I would hope this is what is
being meant with "non-SSM capable" (but disagree on the term).

This is what i know from all but very high-end
L2 switches. It is also what is recommended in RFC4541
("It is encouraged that snooping switches at least recognize and
  process IGMPv3 Join Reports, even if this processing is limited to
  the behavior for IGMPv2 Joins...")

So, i would recommend to not use non-defined terms such as
"non SSM capable", but clearly specify what the switches are
expected to do that are addressed by the work.

I am having this concern, because the PIM WG drafts written to
address the problems described in this mcast-addr-alloc-ps
do ignore (draft-ietf-pim-ipv6-zeroconf-assignment) or
explicitly reject to consider SSM (draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-01)
because of this "non SSM capable L2 switch" denomination.

FOr example, i explicitly asked for draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-01
to support ASM and SSM address ranges and was rejected with that argument.
I think it would be very sad if PIM-WG would go forward explicitly
ignoring SSM in new work without good cause - which i think/hope does
not exist here.

In other words: zeroconf G address allocation free of MAC(G)
collisions in support of low-end L2 switches is as applicable to
SSM address range as it is applicable to ASM address range, and
IMHO really needs to be explicitly supported by these two zeroconf
address allocation documents.

Thanks!
    Toerless