Hi Linda, (also noting some overlap with Julien's response) The MLDv1 (RFC2710) or v2 (RFC3810) Querier sends out a general query R times (where R is the reliability factor for the link), which requests that all devices respond. This goes to all-nodes multicast ff02::1, and the desitnation of the query doesn't have to match recipients (all of which listen to that multicast group).
This scales with responses on order N x R where N is the number of nodes. If a router needs to manage a particular stream, it can send a specific query to one of the multicast addresses, particularly to verify that participants. The router doesn't actually need to track the solicited nodes multicast addresses, as these are link-local scoped and not multicast routed off-link. Actually in conformance with RFC 6398/BCP 168 (IP Router Alert Considerations and Usage)/RFC 6192 (Protecting the Router Control Plane) it is feasible to construct filters which ignore MLD report messages which only contain Link-local scoped multicast groups on the router. With the correct hardware support, this can be done at the line interface, without CPU processing. The default is to pass all MLD reports up to the Router though. Arguably, the only reason to send MLD Join messages for Solicited Nodes' multicast addresses _is_ to support MLD snooping switches. Please note that MLD snooping is an LRU caching scheme, where the cache is refreshed for all active users through the background polling of the MLD querier. The switches do not need to know anything ahead of time. Devices which do not respond to the query will be dropped from the cache, and only the number of active hosts will be retained. If you changed the IP addresses of every host on the link within a single query interval, the maximum number of Solicited nodes addresses cached by an MLD snooping network would be: ^A x N x 2 Where: The original the number of addresses is ^A x N and ^A is the mean number of addresses per host, and N is the number of hosts on the link. Sincerely Greg Daley > > > From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf > Of Linda Dunbar > Sent: Thursday, 22 November 2012 2:17 AM > To: Suresh Krishnan > Cc: julien.i...@gmail.com; int-area@ietf.org > Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 > > Suresh, > > "solicited node multicast address" is formed by taking the low-order 24 bits > of target address (unicast or anycast) and appending those bits to the prefix > > FF02:0:0:0:0:1:FF00::/104 > > Routers don't know ahead of time what hosts are present in their Layer 2 > domain. In DC with virtual machines added/deleted consistently, there could > > be millions of possibilities. > > What multicast addresses should router send out MLD Query? > > What you are proposing is like using MLD snooping to achieve ND function, > which doesn't scale. > > Linda > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krish...@ericsson.com] > Sent: Tuesday, November 20, 2012 5:58 PM > To: Linda Dunbar > Cc: int-area@ietf.org; julien.i...@gmail.com; Tal Mizrahi > Subject: Re: IPv6 ND applicability in draft-nachum-sarp-03 > > Hi Linda, > > On 11/20/2012 01:05 PM, Linda Dunbar wrote: > > Suresh, > > > > Are you saying that router has to send out MLD Query for all > potential ND multicast addresses and keep up state for listeners for > all those multicast addresses? > > Nope. Only for those solicited node multicast groups that have at least > one host on the subnet join. > > > > > There could be millions of "Solicited-Node multicast addresses". That > is a lot of processing on routers. > > Not sure that I follow. Do you have millions of hosts on the subnet? If > not, I do not see why you have to keep track of "millions of solicited > node multicast addresses". > > Thanks > Suresh > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
