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

[Leonard Giuliano <[e-mail]>]

Hmm, this does sound curious, since, generally speaking, SSM is basically 
a subset of ASM functionality.  So I'd also be curious about what 
specifically is meant by switches that do not support SSM.

-Lenny

On Thu, 9 Nov 2023, Toerless Eckert wrote:

| 
| 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
| 
| _______________________________________________
| MBONED mailing list
| [e-mail]
| https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!F6JI10CTeVp4GRbFhxior8YUX7KHFJ1WQ0dafDz8V1kBdsebBL5HprM0p3W5xAx-n9zfeQ-lJ_o$
|