GrumpyOldTroll
commented
2 years ago Yes, if the client switches to a new network path it'll need to attempt rejoining its joined sessions on the new path.
That's a good point about a false idle time issue, but that's also applicable to the initial join--there maybe should be a different initial join max idle vs. the max idle after the first data is received. If we had that, on a connection change maybe client could use the initial join max idle. (And also maybe server should assume that unicast data is required until there start being MP_SESSION_ACKs, and this should also start immediately upon a unicast connection id change?)
It is also possible the client limits change in this scenario, such as the "permit IPv4" or the "permit IPv6" flags or the max rate. These might require server to change the sessions the client joins.
Anyway, +1, there should be a discussion of the issues that can happen on a client network change, and perhaps some guidance on how to handle it. That's probably a whole section, with perhaps several subsections.
What happens if the unikalster path is being migrated due to a change in NAT/ mobility? It would probably mean that all sessions should issue new IGMP/MLD reports since it’s quite possible that the device is connected to a new router does not yet have forwarding state and waiting for a query might cause unnecessary delays.
It might also mean that the idle timeout for the session is (falsely) triggered as it could take some time for the join to propagate far enough upstream to receive Multicast packets once again.