lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 7 Jan 2015 23:24:12 +0000
From:	Thomas Graf <tgraf@...g.ch>
To:	Jesse Gross <jesse@...ira.com>
Cc:	Tom Herbert <therbert@...gle.com>,
	David Miller <davem@...emloft.net>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Pravin B Shelar <pshelar@...ira.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>
Subject: Re: [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented

On 01/07/15 at 02:45pm, Jesse Gross wrote:
> My concern is that having multiple (and potentially overlapping)
> extensions is going to make the VXLAN code very messy and hard to
> follow. I think there's already quite a big of complexity there from
> the DOVE extensions (which are basically dead at this point to the
> best of my knowledge). We already see this some with the discussion
> over the header struct but that's just the beginning - can you imagine
> the code that checks a single bit for several different
> interpretations?

I'm not disagreeing with you Jesse. I think it's manageable though.
I don't think the code as proposed is overly difficult to understand
or messy. I'm glad to adjust the struct definition if the union style
is considered messy, no problem.

We have these reserved bits in a widely used protocol and it is our
choice to make use of these bits or not. My opinion is that we should.
Good candidates to me seem to be GBP for security labels, RCO for
checksumming and GPE for non-L2 over VXLAN.

I would love for everybody to switch over to Geneve or GUE and as you
know I'm highly interested in pushing it forward. Reality is that it
might be another couple of years for it to become fully established.

> Not to mention the fact that the location of the bits
> in some of these proposals has already been shuffled several times. It
> seems very painful...

I don't really want to defend the process behind these drafts. I
believe that code defines the standard, in particular open source code.
As for GBP, we are the authors of the draft and this has been deployed
to hardware as well so this won't change.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ