Markku Savela wrote:
From: Brian Haberman <[EMAIL PROTECTED]> Markku Savela wrote:
From: Brian Haberman <[EMAIL PROTECTED]>
- desire to avoid packet storms upon booting many nodes simultaneously
2710 accomplishes this by using message suppression. If a node hears a Report for the same group, it cancels the transmission of any pending Reports it has for the group.
Above will totally fail with ND multicast groups. Their design goal is that each host is only on one group. It is highly unlikely that listening would hear a duplicate join for the solicited node multicast address.
It is not a failure, it is just not useful for solicited-node multicast addresses. But, you also snipped a part of the note that pointed out that ND and MLD were designed with differing techniques to deal with reliability.
Perhaps MLD has evolved since I last looked at the WG group. However, I believe using MLD snooping switches makes your network unreliable.
Let me iterate my reasoning (maybe MLDv2 has been fixed since, but..). All of the following relates only to solicited node multicast groups:
- if MLD join on DAD is lost, it does not only break DAD, it also makes that node invisible to all other nodes behind the snooping swith (because no ND traffic related to that group is passed through).
Correct, to a degree. The node sends N Reports in a particular window in order to deal with random packet loss. The node is invisible until the switch processes the Report and adds forwarding state for the requested multicast address.
- to recover, someone is supposed to request MLD report from all nodes on the link.
- who sends this request? As far as I understand, only multicast routers are requesting those reports? Is running a multicast router now obligatory MUST on every link?
Not at all. Snooping switches take on the role of Querier in all IGMP snooping devices that I know of. They send out Queries on all ports setup for snooping.
Much of the detail is outlined in draft-ietf-magma-snoop-10.txt. In addition, draft-ietf-magma-igmp-proxy-04.txt may be useful in some cases as well.
- ok, you can say the snooping switch sends the report request occasionally. But, then the switch must have IPv6 link local address, it must implement at least part of the IPv6 ND. It might as well note the ND DAD messages.
If it sends MLD messages, it will need to conform to the MLD spec. And for IPv6, it gets a little more complicated than it did for v4. That is due to the inclusion of MLD and ND messages inside of ICMPv6. Now the switch has to be able to parse ICMPv6 messages in order to find the messages of interest.
- when report request is sent, EVERY node on the link going to reply, and without a delay. Isn't this going to raise the probability that some of the replies are lost? If so, then again we have some nodes, whose ND is not working over the switch. How do recover from this cycle?
Message suppression helps in 2710 if the group address is the same. Otherwise the randomized delay in sending the remaining N-1 messages will offer recovery from packet loss.
- if your switch boots, it has to request reports from all links, and it can enable the filtering only after it is sure that it has a complete picture of joined groups. Again, a storm of replies, possibility of lost answers?
Possibly. That is why MLD sends N Reports.
Are such switches used to bridge WLAN's?
I have no idea.
Are existing MLD snooping switches currently really trying to work on link local groups (and especieally solicited node)? Or, are they just passing all and ingoring link local groups? Have they really though over the issues above? Is this a "snake oil" product, as far as solicited node groups are considered? :-)
The purpose of the above referenced snooping draft is supposed to help switch vendors "do the right thing". Most switches deployed today do not recognize IPv6 multicast addresses at all. In fact, IGMP snooping switches adversely affect IPv6 multicast in odd ways. So, I have heard all sorts of instances where IGMP snooping had to be disabled in order to allow IPv6 to work.
Regards, Brian
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
