Linux Ethernet Bridging - Sep 2020 - [Bridge] [PATCH net-next v2 00/15] net: bridge: mcast: initial IGMPv3 support (part 1)

On 9/2/20 10:58 PM, David Miller wrote:
> From: Nikolay Aleksandrov <nikolay at cumulusnetworks.com>
> Date: Wed,  2 Sep 2020 14:25:14 +0300
> 
>> Here're the sets that will come next (in order):
>>   - Fast path patch-set which adds support for (S, G) mdb entries
needed
>>     for IGMPv3 forwarding, entry add source (kernel, user-space etc)
>>     needed for IGMPv3 entry management, entry block mode needed for
>>     IGMPv3 exclude mode. This set will also add iproute2 support for
>>     manipulating and showing all the new state.
>>   - Selftests patch-set which will verify all IGMPv3 state transitions
>>     and forwarding
>>   - Explicit host tracking patch-set, needed for proper fast leave and
>>     with it fast leave will be enabled for IGMPv3
>>
>> Not implemented yet:
>>   - Host IGMPv3 support (currently we handle only join/leave as before)
>>   - Proper other querier source timer and value updates
>>   - IGMPv3/v2 compat (I have a few rough patches for this one)
> 
> What about ipv6 support?  The first thing I notice when reading these
> patches is the source filter code only supports ipv4.
> 
Indeed, these are IGMPv3/IPv4 targeted. But MLDv2 should be relatively easy to
add once we have all the set/state transitions as it uses the same.
Adding both at once would be a much bigger change.

Once all the infra (with fast-path) for IGMPv3 is in, MLDv2 should be a much
easier change, but I must admit given the amount of work this required I
haven't
yet looked into MLDv2 in details. The majority of the changes would be just
switch
protocol statements that take care of the IPv6 part.

I have also explicitly added the IPv4 checks right now to limit the dump code,
otherwise
we'd get for example group mode export for IPv6 entries which yet don't
support it.

If you'd prefer I can remove the explicit IPv4 checks and leave the switch
protocol check
with ETH_P_IP only currently, but it wouldn't affect the end result much.

On 9/2/20 11:08 PM, Nikolay Aleksandrov wrote:
> On 9/2/20 10:58 PM, David Miller wrote:
>> From: Nikolay Aleksandrov <nikolay at cumulusnetworks.com>
>> Date: Wed,? 2 Sep 2020 14:25:14 +0300
>>
>>> Here're the sets that will come next (in order):
>>> ? - Fast path patch-set which adds support for (S, G) mdb entries
needed
>>> ??? for IGMPv3 forwarding, entry add source (kernel, user-space
etc)
>>> ??? needed for IGMPv3 entry management, entry block mode needed for
>>> ??? IGMPv3 exclude mode. This set will also add iproute2 support
for
>>> ??? manipulating and showing all the new state.
>>> ? - Selftests patch-set which will verify all IGMPv3 state
transitions
>>> ??? and forwarding
>>> ? - Explicit host tracking patch-set, needed for proper fast leave
and
>>> ??? with it fast leave will be enabled for IGMPv3
>>>
>>> Not implemented yet:
>>> ? - Host IGMPv3 support (currently we handle only join/leave as
before)
>>> ? - Proper other querier source timer and value updates
>>> ? - IGMPv3/v2 compat (I have a few rough patches for this one)
>>
>> What about ipv6 support?? The first thing I notice when reading these
>> patches is the source filter code only supports ipv4.
>>
> 
> Indeed, these are IGMPv3/IPv4 targeted. But MLDv2 should be relatively easy
to
> add once we have all the set/state transitions as it uses the same.
> Adding both at once would be a much bigger change.
> 
> Once all the infra (with fast-path) for IGMPv3 is in, MLDv2 should be a
much
> easier change, but I must admit given the amount of work this required I
haven't
> yet looked into MLDv2 in details. The majority of the changes would be just
switch
> protocol statements that take care of the IPv6 part.
> 
> I have also explicitly added the IPv4 checks right now to limit the dump
code, otherwise
> we'd get for example group mode export for IPv6 entries which yet
don't support it.
> 
> If you'd prefer I can remove the explicit IPv4 checks and leave the
switch protocol check
> with ETH_P_IP only currently, but it wouldn't affect the end result
much.
i. e. this doesn't exclude IPv6 or makes it worse for it, on the contrary
the ops needed to
implement MLDv2 state transitions are in this set, they just need to be extended
for v6.
The new br_ip src group field contains also a field for an IPv6 address.

From: Nikolay Aleksandrov <nikolay at cumulusnetworks.com>
Date: Wed, 2 Sep 2020 23:08:40 +0300
> Once all the infra (with fast-path) for IGMPv3 is in, MLDv2 should
> be a much easier change, but I must admit given the amount of work
> this required I haven't yet looked into MLDv2 in details. The
> majority of the changes would be just switch protocol statements
> that take care of the IPv6 part.
As difficult as this is for me to do, I really have to be consistent
in my policy and push back on this.  We are far past the point of
accepting new features without ipv6 support as well, sorry.