public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] [PATCHv12 1/4] batman-adv: Always flood IGMP/MLD reports
Date: Sun, 10 Apr 2016 14:07:48 +0200	[thread overview]
Message-ID: <20160410120748.GG19310@otheros> (raw)
In-Reply-To: <4820570.LxUU2Z3eNS@prime>

On Thu, Apr 07, 2016 at 03:03:11PM +0200, Simon Wunderlich wrote:
> > To avoid compatibility issues with older nodes not yet implementing this
> > report handling, we need to force them to flood reports: We do this by
> > bumping the multicast TVLV version to 2, effectively disabling their
> > multicast optimization.
> 
> It looks like you register two containers, one with version 1 and version 2, 
> both with the same content. Do we really need to have both containers? 
> Wouldn't it be sufficient to register only version 2 and leave version 1 out?

The idea is to avoid unexpected regressions:

The advantage of registering two containers lies in a setup where you have a
non-bridged network with multicast TVLV v1 and rely on these optimizations.
If a new node with both containers is added, then the old nodes
won't mind. If only container v2 were registered, old nodes would
switch to flooding. Which might be seen as an undesired
regression, depending on the requirements of the network.

Note that if the new node has a bridge, then the TVLV v1 container
gets unregistered and only the v2 one is announced (see PATCH 2/4).
This is because we have to, otherwise we might have packet loss
(which is even worse than flooding).


The registeration of two containers is probably a minor improvement.
Haven't heard of any actual setups which would need it yet. On the
other hand it's not that much extra code, so it felt like a good
idea to add it for some extra compatibility courtesy.


I don't feel that strongly for it though. Let me know what you or
others would prefer.

Regards, Linus

  parent reply	other threads:[~2016-04-10 12:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-16  4:06 [B.A.T.M.A.N.] [PATCHv12 0/4] Multicast optimizations for bridges Linus Lüssing
2016-03-16  4:06 ` [B.A.T.M.A.N.] [PATCHv12 1/4] batman-adv: Always flood IGMP/MLD reports Linus Lüssing
2016-04-07 13:03   ` Simon Wunderlich
2016-04-07 13:24     ` Sven Eckelmann
2016-04-10 12:07     ` Linus Lüssing [this message]
2016-04-10 12:43       ` Linus Lüssing
2016-04-19  2:12     ` Linus Lüssing
2016-03-16  4:06 ` [B.A.T.M.A.N.] [PATCHv12 2/4] batman-adv: Add multicast optimization support for bridged setups Linus Lüssing
2016-04-07 13:43   ` Sven Eckelmann
2016-04-07 13:50   ` Sven Eckelmann
2016-04-19  2:22     ` Linus Lüssing
2016-04-24  7:07       ` Sven Eckelmann
2016-03-16  4:06 ` [B.A.T.M.A.N.] [PATCHv12 3/4] batman-adv: Adding logging of mcast flag changes Linus Lüssing
2016-03-16  4:06 ` [B.A.T.M.A.N.] [PATCHv12 4/4] batman-adv: Add debugfs table for mcast flags 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=20160410120748.GG19310@otheros \
    --to=linus.luessing@c0d3.blue \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox