From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Sven Eckelmann <sven@narfation.org>
Cc: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [PATCH v4 1/2] batman-adv: mcast: detect, distribute and maintain multicast router presence
Date: Tue, 11 Jun 2019 16:12:14 +0200 [thread overview]
Message-ID: <20190611141214.GA2877@otheros> (raw)
In-Reply-To: <1705254.clgQh6sisM@sven-edge>
On Tue, Jun 11, 2019 at 07:44:12AM +0200, Sven Eckelmann wrote:
> On Tuesday, 11 June 2019 01:14:14 CEST Linus Lüssing wrote:
> > I'm currently unsure when we would need that. Are you suggesting
> > to interpret it that way, just in case we might need it some day?
> >
> > Note that this would also be a "soft compatibility break". So old
> > nodes would still interpret 0x1f the same way as 0x07, meaning
> > they would send all multicast traffic to nodes announcing either
> > 0x1f or 0x07. It'd be a "soft break" because it wouldn't cause
> > packet loss, old nodes would just overestimate.
>
> I am just unsure how we could/would interpret this in the future. Not that we
> need support for it in the first version.
Ah, okay. Yes, then I think I would prefer to interpret WANT_ALL_IPV{4,6} +
WANT_NO_RTR{4,6} as WANT_ALL_LL{4,6} in the future (just, but all
link-local).
I'll change the code in PATCH 1/2 to always unset WANT_NO_RTR{4,6}
in the transmitted TVLV if WANT_ALL_IPV{4,6} is set for now, to allow to
reuse and interpret it that way in the future.
(An alternative would have been to keep it as is and adding
another flag in the future if the use case for all-link-local-only
came up. The advantage of transmitting WANT_NO_RTR{4,6} independent of
WANT_ALL_IPV{4,6} would have been some additional (debug) information.
But on the other hand, adding yet another flag in the future would just
get more messy/confusing.)
next prev parent reply other threads:[~2019-06-11 14:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-10 0:45 [PATCH v4 0/2] batman-adv: Add routeable multicast optimizations Linus Lüssing
2019-06-10 0:45 ` [PATCH v4 1/2] batman-adv: mcast: detect, distribute and maintain multicast router presence Linus Lüssing
2019-06-10 5:39 ` Sven Eckelmann
2019-06-10 7:24 ` Sven Eckelmann
2019-06-10 23:14 ` Linus Lüssing
2019-06-10 23:45 ` Linus Lüssing
2019-06-11 5:44 ` Sven Eckelmann
2019-06-11 14:12 ` Linus Lüssing [this message]
2019-06-10 0:45 ` [PATCH v4 2/2] batman-adv: mcast: apply optimizations for routeable packets, too 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=20190611141214.GA2877@otheros \
--to=linus.luessing@c0d3.blue \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=sven@narfation.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