From: Thomas Graf <tgraf-G/eBtMaohhA@public.gmane.org>
To: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Cc: "dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org"
<dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org>,
Linux Netdev List
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Stephen Hemminger
<stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>,
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
Tom Herbert <therbert-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented
Date: Wed, 7 Jan 2015 23:24:12 +0000 [thread overview]
Message-ID: <20150107232412.GD21149@casper.infradead.org> (raw)
In-Reply-To: <CAEP_g=_Xr=6nVoeVT8dgRZoM0bNXDiiua5GrjweZ1GaT1ixhZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
next prev parent reply other threads:[~2015-01-07 23:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-07 2:05 [PATCH 0/6 net-next] VXLAN Group Policy Extension Thomas Graf
2015-01-07 2:05 ` [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented Thomas Graf
2015-01-07 3:46 ` Tom Herbert
2015-01-07 10:27 ` Thomas Graf
2015-01-07 22:45 ` Jesse Gross
[not found] ` <CAEP_g=_Xr=6nVoeVT8dgRZoM0bNXDiiua5GrjweZ1GaT1ixhZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-07 23:24 ` Thomas Graf [this message]
[not found] ` <20150107232412.GD21149-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
2015-01-08 0:02 ` Tom Herbert
2015-01-08 0:14 ` Thomas Graf
[not found] ` <20150108001401.GG21149-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
2015-01-08 0:23 ` Tom Herbert
2015-01-07 2:05 ` [PATCH 2/6] vxlan: Group Policy extension Thomas Graf
2015-01-07 16:05 ` Tom Herbert
[not found] ` <CA+mtBx_Jj-tUM1nbHd2fHb0-=QpK3tcQgA=smWmg=cB-fupdGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-07 16:21 ` Thomas Graf
2015-01-07 16:56 ` Tom Herbert
[not found] ` <CA+mtBx_A_M3+irq7w4nNCyPZBgM7ja+wfJT4w4Q0Yo6GMGYVgA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-07 17:21 ` Thomas Graf
2015-01-07 2:05 ` [PATCH 3/6] vxlan: Only bind to sockets with correct extensions enabled Thomas Graf
2015-01-07 22:45 ` Jesse Gross
2015-01-07 22:52 ` Thomas Graf
2015-01-07 2:05 ` [PATCH 4/6] vxlan: Fail build if VXLAN header is misdefined Thomas Graf
2015-01-07 2:05 ` [PATCH 5/6] openvswitch: Rename GENEVE_TUN_OPTS() to TUN_METADATA_OPTS() Thomas Graf
2015-01-07 22:46 ` Jesse Gross
2015-01-07 22:55 ` Thomas Graf
2015-01-07 2:05 ` [PATCH 6/6] openvswitch: Support VXLAN Group Policy extension Thomas Graf
2015-01-07 22:46 ` Jesse Gross
2015-01-07 23:01 ` Thomas Graf
2015-01-08 1:18 ` Jesse Gross
2015-01-08 10:22 ` Thomas Graf
-- strict thread matches above, loose matches on Subject: below --
2015-01-08 22:47 [PATCH 0/6 net-next v2] VXLAN Group Policy Extension Thomas Graf
2015-01-08 22:47 ` [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented Thomas Graf
2015-01-12 12:26 [PATCH 0/6 net-next v3] VXLAN Group Policy Extension Thomas Graf
2015-01-12 12:26 ` [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented Thomas Graf
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=20150107232412.GD21149@casper.infradead.org \
--to=tgraf-g/ebtmaohha@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org \
--cc=jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org \
--cc=therbert-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.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;
as well as URLs for NNTP newsgroup(s).