From: Simon Wunderlich <sw@simonwunderlich.de>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] Enhancements for Unsolicited Neigh. Adv. / grat ARP Reply
Date: Fri, 8 Aug 2014 16:06:00 +0200 [thread overview]
Message-ID: <201408081606.01045.sw@simonwunderlich.de> (raw)
In-Reply-To: <1407007130-23077-1-git-send-email-linus.luessing@web.de>
Hello Linus,
thank you very much for the patch proposal.
> Hi there,
>
> Here's a little, rough patch to illustrate the idea we discussed a little
> at the last Wireless Battle Mesh, that is forwarding the noisy IPv6
> Unsolicited Neighbor Advertisements and gratuitous ARP Replies via unicast.
>
> Currently these ugly unsol. NAs cause about 40% of ICMPv6 multicast
> overhead in our networks here.
I think it's quite a good idea - to motivate your proposal, I'd suggest to add
some information on how many broadcasts you think you can save in your
networks - 40% of ICMPv6 traffic is a little vague, since we don't know how
much of your traffic is ICMPv6 and what you have already blocked.
>
> A little more detailed explanation with some pictures can be found here:
>
> https://www.open-mesh.org/projects/batman-adv/wiki/Unicasting-unsolicited-n
> eighbor-advertisements
Nice page. :)
>
> In the few, simple scenarios with bridged-in hosts in VMs, the patch
> seemed to do what it was supposed to do uppon roaming. Unsol. NAs did only
> appear on the node the host roamed away from.
>
> If I remember correctly, there were also some worries about how this
> might work together with BLA-II. I gave it a little more thought and
> had a look at the BLA-II source code, but couldn't find any issues.
I don't see any issues either - as you've implemented, it should be similarly
working as the DHCP requests from client.
>
> The only BLA-II related non-ideal thing I could think of so far is
> noted in the code of this patch at the according place (but I think
> that might not matter much in practice).
You describe that this feature could be used for hot-swapping, and as far as I
understand, turning on that feature could break IPv6 hotswapping? I don't know
how much this is actually used and its probably not the most common thing for
our networks (and isn't reliable anyway), but you should make you feature
optional with a sysfs option or similar. Then users or firmware engineers can
turn that feature on as required, just as BLA and others.
Thanks,
Simon
next prev parent reply other threads:[~2014-08-08 14:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-02 19:18 [B.A.T.M.A.N.] Enhancements for Unsolicited Neigh. Adv. / grat ARP Reply Linus Lüssing
2014-08-02 19:18 ` [B.A.T.M.A.N.] [PATCH RFC] batman-adv: unicasting grat. ARP Reply / unsol. neigh. Advertisement Linus Lüssing
2014-08-08 14:06 ` Simon Wunderlich [this message]
2014-09-01 7:27 ` [B.A.T.M.A.N.] Enhancements for Unsolicited Neigh. Adv. / grat ARP Reply Linus Lüssing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201408081606.01045.sw@simonwunderlich.de \
--to=sw@simonwunderlich.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.