Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

[Dan Luedtke <[e-mail]>]

Hi,

Erik Nordmark wrote:
> But the draft is also addressing the other cases of multicast:
>  - periodic RAs
An EAND host ignores RA multicast until its internal timer suggests to
request a new unicast RA. In the meantime an other router may have
become the default router or some options of the initial RA are
re-accounced with a zero lifetime. For example, a set of RDNSS and/or
one or more prefixes may have been added or removed (prefix lifetime
of zero removes the prefix from the link, right?). The only way to
remove a prefix from the link with EAND hosts present is to fade it
out by decreasing the lifetime over time. A sudden removal, which is
used in some fail-over scenarios, is not supported if I understand the
draft correctly. So a new unicast RA has to be send out to all EAND
hosts that may be affected by such a prefix removal by the router.
This implies keeping much more state information in the router than I
would like to see there. Especially on very populated links.


Erik Nordmark wrote:
> - multicast NS/NA for the purposes of duplicate address detection
Which are addressed to the solicited node multicast address which is
distinguished by 2^24 bytes. Ideally this is a one node group in a
link with about 16 million nodes. In reality this is not the case but
these groups are _mostly_ populated by only one node. And ideally the
packets won't be flooded to nodes that are not member of the group.
Again we come to the point were we try to solve a link-layer problem
at the network layer. Don't get me wrong, I see the problem but I just
can't support a draft introducing more complexity at the wrong layer.

Erik Nordmark wrote:
> - a host sending a multicast NS to its peer when the routers already
> know the MAC address of the peer; redirect messages solve that without
> any multicasts
In some setups redirect messages are ignored (which is not always a
good idea, but these cases exist) by hosts. These hosts would have to
accept redirect messages. Replacing multicast with redirect messages,
and thus requiring a third party in the communication with a neighbor,
seems too complex to me. As a network engineer I would like to stick
with multicast and not having a router acting as message broker for
on-link communication.


Lorenzo Colitti wrote:
>There is a huge difference; in fact, it's quite a fundamental change in the architecture to have a limited set of layer 3 devices be gatekeepers for all on-link communication.
I would go one step further and say: If routers become gatekeepers for
the communication between hosts, then they could as well *route* the
traffic. The proposed solution is something between real on-link
communication and real routing.


Although I find this draft interesting and would like to take the
challenge of implementing it in my existing software just to see how
different the outcome is in reality, I object this draft. It
concentrates too much power at too few devices thus changing the whole
way the on-link communication should work. Furthermore, as I
understand, EAND will be *added* to the current IPv6 stacks in nodes
leading to a more complex stack. It can not replace current code for
the sake of legacy compatibility which is needed in link-layers
without router (thinking of ad-hoc wifi for example). If EAND becomes
standard I will probably implement it, until then I have to object it
for the reasons I mentioned in this thread.


Best regards

Dan