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

["Karstens, Nate" <[e-mail]>]

Sorry for the delay, it took me a bit to track this down.

Toerless -- In our case, not supporting SSM is closest to the second interpretation that you list. The Address Translation Unit in the switch is only capable of mapping 48-bit destination Ethernet addresses to one or more ports (a bit-field port vector). We support IGMPv3/MLDv2 messages, but we aren't able to do anything with messages that use SSM and our ecosystem does not utilize this functionality anyway. I haven't done an exhaustive study of the market but I think this is a common limitation of consumer-grade switch parts. I agree that it would be good to explicitly define this in the problem statement.

In any case, this limitation is why we arrived at the solution to use ASM but only transmit from a single source -- it has the same outcome as SSM, but can be accomplished with consumer-grade parts.

Lenny -- I see what you mean by SSM being a subset of ASM in that SSM lets you select a subset of all hosts that are transmitting to a given ASM group. However, from an implementation standpoint, SSM requires more functionality than ASM and so ASM is a subset of the functionality needed for SSM.

While we're on the subject, it's worth considering the additional functionality that would be needed to implement SSM in the ATU. If we are just worried about L2, then we could add a source Ethernet address field to each ATU entry. However, if we start bringing in multicast traffic from other subnets, then two hosts transmitting to the same L3 destination address will have their L2 source address replaced with the router's source address, making them indistinguishable to L2 switches. To address this, we either need to have the ATU consider L3 addresses, or the multicast router would need to map a different L2 source address for each incoming stream.

Thanks,

Nate

-----Original Message-----
From: pim <[e-mail]> On Behalf Of Leonard Giuliano
Sent: Friday, November 10, 2023 16:07
To: Toerless Eckert <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [pim] [MBONED] mboned/pim: "SSM (in)capable" IGMP snooping switches - and PIM-WG zeroconf work...

CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.


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/mbon
| ed__;!!NEt6yMaO-gk!F6JI10CTeVp4GRbFhxior8YUX7KHFJ1WQ0dafDz8V1kBdsebBL5
| HprM0p3W5xAx-n9zfeQ-lJ_o$
|

_______________________________________________
pim mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!EJc4YC3iFmQ!WMrM1PRE5WiZ0p2dDoX-UEAWnGiBesDUzrD6HgldkUyDJ5XNlnLi3go22_UBwxLWTxMAzfTWxB-WjcSyuu7-hvmN0-z2wdLikg$