In your previous mail you wrote:

   >    - there is no reason for using MLD for link local multicast groups
   >      as far IPv6 (layer-3) is concerned.
   >    
   > => there is a very well known reason: snooping by layer-2 switches.
   
   ...and which totally bogus, as such switch cannot utilize the
   information in any significant way.

=> it can use it as for any other multicast group. Don't forget
the layer-2 snooping is a MLD function, NOT a ND one.

   Remember, I'm talking about LINK
   LOCAL MULTICAST groups used in IPv6 NEIGHTBOR DISCOVERY.

=> there is no reason to do a special case for them as the standard
code which handles any multicast works well with them.

   And, as linklocal all-nodes is ALREADY excempted from the MLD,

=> this group is special (for MLD) and more, as all nodes by definition
listen it, it should never be filtered out where there is an IPv6 node.

   what is left is
   *ONLY* the solicited node multicast. I vote that, it too is exempted.
   
=> I vote against.

   When is this joined? ONLY when node configures a NEW id for address,
   so what we are seeing on link, is two back-to-back messages:
   
     1) join solicited node group (MLD), followed by
     2) ND DAD probe
   
   I just can't see any significant use for the (1), even for layer-2
   snooper. The probe alone carries exactly the same information as the
   useless MLD join.

=> the layer-2 snooper has nothing to do with ND, it handles only MLD.
I believe your idea is add a ND snooping in place of the current reuse
of MLD snooping is not good because it will introduce an unneeded exception.

   And whats worse, the switch will increase the
   probability of DAD "failing to do its suff"... (if it decides not to
   forward the DAD to all links based on some stale soft state -- it
   definetly cannot start querying at this point).
   
=> I don't buy this point.

   Additionally, when ND is protected by IPSEC, the switch needs to do
   the IPSEC also.
   
=> so MLD snooping is better?

   >    - illogical definition: you cannot join solicited nodes multicast
   >      group before you have address,
   > 
   > => I don't understand: I can send a join message.
   
   Yes, with "::" source address. Kinky.. :)
   
=> I can't see a problem with the "::" source address in this case
and for the layer-2 snooper the IPv6 source address is not useful.

   >    - if layer-2 snoop is going to make use of MLD, it or some part of it
   >      must actually be node on the network
   > 
   > => no, the layer-2 snooper is a layer-2 snooper by definition.
   
   Then it cannot send queries, and it's knowledge about solicited node
   groups is totally "soft", practically useless (unless it snoops other
   ND traffic, in which case it doesn't need MLD at all for those).
   
=> actual experience (i.e., when a switch is not ultra cheap, it
supports layer-2 snooping for multicast pruning) shows you are wrong.

   > => s/would add/adds/ because MLD is mandatory. But you still can remove
   > the support of multicast on the links (and remove MLD too). Perhaps
   > this is the best solution if your argument is that multicast just sucks.
   
   Where did I say "multicast sucks". I definitely like multicast, I'm
   just talking about these link local groups here, and specifically
   about ND discovery part of it.

=> if you like multicast why you want to do a very special case for ND
when the IGMP/MLD snooping works well? I don't understand...

Regards

[EMAIL PROTECTED]

PS: this discussion should not be in the mobile ip list: the magma list
seems far better.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to