[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160506152820.GD11058@orbyte.nwl.cc>
Date: Fri, 6 May 2016 17:28:20 +0200
From: Phil Sutter <phil@....cc>
To: Edward Cree <ecree@...arflare.com>
Cc: Stephen Hemminger <stephen@...workplumber.org>,
netdev <netdev@...r.kernel.org>,
"John W. Linville" <linville@...driver.com>
Subject: Re: [PATCH iproute2] geneve: fix IPv6 remote address reporting
On Fri, May 06, 2016 at 04:14:11PM +0100, Edward Cree wrote:
> On 06/05/16 15:43, Phil Sutter wrote:
> > On Fri, May 06, 2016 at 03:28:25PM +0100, Edward Cree wrote:
> >> Since we can only configure unicast, we probably want to be able to
> >> display unicast, rather than multicast.
> > Furthermore, the kernel even rejects multicast peer addresses.
> Yes, but a future kernel might not, and iproute2 is meant to be forward-
> compatible.
Sorry, but I fail to see how this might break forward compatibility.
Quite the contrary, suppose geneve in future supported multicast peers,
current iproute2 would fail to recognize it's existence. What am I
missing here?
> > Why do you then propose a dubious fix to a dubious check instead of
> > getting rid of it in the first place?
> Because John Linville clearly had some reason for putting a check there,
> and he probably knows better than me. Chesterton's fence.
A valid point, indeed. In my opinion the same applies to your patch as
well, as instead of removing the fence you're moving it to the other
lane. :)
Cheers, Phil
Powered by blists - more mailing lists