Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization

From: Markku Savela <[email-masked]>
Date: Tue, 3 Sep 2002 17:55:24 +0300

> From: Francis Dupont <[email-masked]>
> 
>  In your previous mail you wrote:
> 
>    > >I'm going to ingore RFC 2710 on this point. I do not send MLD for link
>    > >local multicast groups.
>    > 
>    > 	then your device will have trouble operating on coming switches
>    > 	that support MLD snooping, and it will be very difficult to
>    > 	track the issue down (extraordinary support load to your colleagues).
>    > 	i suggest you to follow RFC2710.
>    
> => I strongly support Itojun! Please don't ignore standards just because
> NIBY.

It's not yet a standard, right? It's still RFC, and I'm just giving my
comments on it. I'm only trying to work as a "fire fighter" to prevent
dubious requirements to get into standards (and hurting everyone
there).

NIBY??? (if this is supposed to mean "Not Invented By You", I'm
somewhat offended). My complaint about sending MLD reports on link
local groups has nothing to do with anything I invented or didn't
invent. It purely technical issue, based on

- there is no reason for using MLD for link local multicast groups
  as far IPv6 (layer-3) is concerned.

- the only presented reason for them is some layer-2 snooping. This is
  layer violation, a hack, which should not be codified in standards.

- at least it should be optional for link local multicast groups used
  in Neighbor discovery

- illogical definition: you cannot join solicited nodes multicast
  group before you have address, you cannot do DAD without listening
  to solicited nodes multicast group

- layer-2 snooper can get the same information from the ND traffic
  directly,

- sending MLD's on big monolithic stacks, can be minor issue (code is
  already there), but for small devices, like cell phones, modularity
  is desired. One should be able to run IPv6 without MLD.

- if layer-2 snoop is going to make use of MLD, it or some part of it
  must actually be node on the network and work as a multicast router
  to make queries (a switch can be powered off when host is attached
  or just powered off and loses the state)

- in practice, there will never be "leave group" MLD's from hosts on
  the link (hosts leave the link usually by user just unplugging it).

--
ps. There has been some discussion about having DAD optional on 3GPP
links. Requiring MLD would add more packets to that link: MLD join +
DAD.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Sep 2002 18:54:45 +0200

It's not yet a standard, right?

=> it is a proposed standard.

   It's still RFC,

=> ????

   and I'm just giving my
   
=> there is a time for this : last call(s) for the next version
which is proposed for the IGMPv3/MLDv2 upgrade and draft standard status.

=> there is a very well known reason: snooping by layer-2 switches.

=> so you should flame the draft-ietf-magma-snoop-02.txt document
in the magma list.

=> I can't see how it can be optional: either it is useful so is
recommended/required, or it is not useful so is not recommended/required.

   - illogical definition: you cannot join solicited nodes multicast
     group before you have address,

=> I don't understand: I can send a join message.

     you cannot do DAD without listening
     to solicited nodes multicast group
   
=> I agree.

=> no, layer-2 snooper can get the information (has someone joined
this group) only through MLD snooping for any group, i.e., ND is
not a special case.

=> this was already discussed and the consensus is that MLD is mandatory
to implement.

   - 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.

     and work as a multicast router to make queries
     (a switch can be powered off when host is attached
     or just powered off and loses the state)
   
=> the MLD state is a soft state so this is not a real problem.

=> same.

=> 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.

Regards

[email-masked]

---

From: Markku Savela <[email-masked]>
Date: Tue, 3 Sep 2002 20:27:22 +0300

> => 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. Remember, I'm talking about LINK
LOCAL MULTICAST groups used in IPv6 NEIGHTBOR DISCOVERY. And, as
linklocal all-nodes is ALREADY excempted from the MLD, what is left is
*ONLY* the solicited node multicast. I vote that, it too is exempted.

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. 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).

Additionally, when ND is protected by IPSEC, the switch needs to do
the IPSEC also.

> recommended/required, or it is not useful so is not

Right, I'm requesting it to be at least optional. I don't think it
(MLD for link local ND groups) is useful for anything.

> => I don't understand: I can send a join message.

Yes, with "::" source address. Kinky.. :)

> => 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).

> 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.

---

From: Greg Daley <[email-masked]>
Date: Wed, 04 Sep 2002 10:44:31 +1000

Hi Markku,

I'm not sure if this is just fuel for the fire,
or another idea you haven't seen.

> definetly cannot start querying at this point).

The draft I've written attempts to make some use of the
(possibly illogical) requirement that IPv6 nodes do MLD
on Solicited Nodes Multicast in order to do DAD.

here's the URL:
http://www.ietf.org/internet-drafts/draft-daley-ipv6-mcast-dad-00.txt

It allows an MLD router (the querier) to watch listener
state on the network and respond to a report if that
solicited nodes multicast address is not in use.
(indicating that DAD is successful and the address is unique).

It's not pretty, but it may be a the nearest thing to a
significant use for this requirement.

> (MLD for link local ND groups) is useful for anything.

As far as I can see, Optional doesn't really help, if there
are some nodes doing MLD for DAD and others aren't there will
never be applications which can rely on it (so the situation
is self perpetuating...;)

> Yes, with "::" source address. Kinky.. :)

I don't really see why you can't send from a tentative address
in this case. There are no responses being sent to unicast L3
addresses (and none off link).  using "::" means that anyone
else listening to your MLD report (existing nodes/routers)
will ignore it.

[cut section about l2snooping]
> about ND discovery part of it.

If you can get MLD for link-scope multicast addresses removed,
please do it entirely.

It doesn't help anyone to have half a standard.

Greg Daley

---

From: Robert Elz <[email-masked]>
Date: Wed, 04 Sep 2002 13:53:35 +0700

| ...and which totally bogus, as such switch cannot utilize the
  | information in any significant way.

Huh???

Perhaps we can step back and look at what is going on here.

When we have a multicast address, it is being sent to perhaps multiple
(but usually not all) nodes on a link.

When we have a link implemented by a switch, it (often) learns what
addresses are on each port (by noting the source MAC addr) and only
sends packets to the ports where an address occurs.

Since nothing is ever sent from a multicast address, and since it can
live on multiple ports (unlike a unicast address) it wouldn't matter if
something was, the switch can't use that method to work out which ports
a packet to a multicast address should be sent to.

It then has two choices - either send the packet to everyone, which
turns it (almost) into a broadcast, which we're trying to get away
from, or create some new protocol by which nodes notify the switch of
the multicast addresses they want sent to them.

So, let's assume for now that the latter has been done, because we
don't want multicast packets sent everywhere (normally).   Whenever a
node joins a multicast address, it engages in this link level protocol
so the switches can learn which multicast address goes where.

Now there's also the IP level multicast - the routers also (in general)
need to know which links multicast packets need to be sent to, so at the
IP level there's the MLD protocol by which a node informs a router that
packets for some (IP level) multicast address should be sent to it (or
really, just sent to the link where the node resides).

So, when a node joins a multicast address it needs to engage in the MLD
protocol to allow the routers to find out what is going on.

So, for every (general) multicast address, the node would have to run
two protocols, the link level one, and the IP level one, so all the right
devices know where multicast packets should get sent.

That's dumb - the two of them convey essntially the same information
(especially when viewed from the point of view of the relevant receiver,
with the other knowledge it has - the router knows which link by the
link the packet is received from, the switch knows which port by the port
the packet is received from).   So, rather than use two protocols, the
switch and the router both just use the contents of one packet, and get
their information from that.   You can call this a "layer violation"
if you like, but this isn't unusual, we do lots of "layer violations"
in the name of efficiency (I don't see you refusing to implement the
TCP pseudo-header for example, but that's a layer violation too...)

Now, in the special case of link local multicast, the router level (IP)
protocol isn't useful for anything - the routers know which link a link
level multicast belongs on (the link it is sent on, and nothing else),
so no IP level protocol is needed for this particular case.   But the
link level protocol still is, and as the link level protocol is using
the same packet formats as the IP level protocol (the same exact content)
it still needs to get sent.

You can (if you want to) just consider this a link level protocol, with
a strange packet format - but it is required for the switches to be able
to do some kind of sane multicast filtering.   And given that the
particular multicast packets are ones which usually should go nowhere,
it really is an advantage to have them filtered, rather than broadcast.

Just send the MLD packets, like the spec says.

kre

---

From: Francis Dupont <[email-masked]>
Date: Wed, 04 Sep 2002 09:36:49 +0200

...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
   
=> I vote against.

   
   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.

=> so MLD snooping is better?

   
=> 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.

   
=> actual experience (i.e., when a switch is not ultra cheap, it
supports layer-2 snooping for multicast pruning) shows you are wrong.

=> 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

PS: this discussion should not be in the mobile ip list: the magma list
seems far better.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 04 Sep 2002 09:31:12 -0400

Hi All,

The update to IGMPv3/MLDv2 that Francis mentioned is being
developed by the magma WG.  So, it would probably be 
most productive to move the discussion of how/if to join
link-local multicast groups to the magma list.

Thanks,
Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 04 Sep 2002 09:31:12 -0400

Hi All,

Thanks,
Margaret