> On Jun 10, 2016, at 3:59 PM, Ben Pfaff wrote:
>
> After talking to Justin, I think I'm going to take a few days (maybe
> Wednesday through Friday next week) to hack on etcd related stuff, with
> the goal being to come up with a detailed to-do list and try to verify
> that the stuff that I thin
On Fri, Jun 10, 2016 at 05:31:15PM -0400, Russell Bryant wrote:
> On Fri, Jun 10, 2016 at 5:08 PM, Ben Pfaff wrote:
>
> > I've obtained a little more information from a conversation on Twitter
> > with Xiang Li, a CoreOS developer, see below.
> >
> > On Fri, Jun 10, 2016 at 01:14:29PM -0700, Ben
Adding another point to the thread. Per earlier John McDowell's suggestion
if I disable port security for each of the ports involved, I get the
traffic through as needed. But to be more elegant (and secure) I am trying
to create ACL override specifically for this specific flows added.
-Murali
>
On Fri, Jun 10, 2016 at 5:08 PM, Ben Pfaff wrote:
> I've obtained a little more information from a conversation on Twitter
> with Xiang Li, a CoreOS developer, see below.
>
> On Fri, Jun 10, 2016 at 01:14:29PM -0700, Ben Pfaff wrote:
> > This leaves me with the following discussion questions:
> >
Help needed :)
Currently I added APIs to northd for custom flows in this format
lflow-add LSWITCH DIRECTION PRIORITY MATCH ACTION FLOWID [FLOWTYPE]
add a logical flow identified by FLOWID
lflow-del LSWITCH FLOWID delete a logical flow identified by FLOWID
This wa
I've obtained a little more information from a conversation on Twitter
with Xiang Li, a CoreOS developer, see below.
On Fri, Jun 10, 2016 at 01:14:29PM -0700, Ben Pfaff wrote:
> This leaves me with the following discussion questions:
>
> - Is lack of non-amd64 support a blocker? It's going t
Andy Zhou spent some time last week investigating etcd 3.0 as a possible
database target for OVN. Based on some of what he found out, and a
little digging of my own, here's a summary of my thoughts on it in the
format used previously for
http://openvswitch.org/pipermail/dev/2016-March/067479.html:
I think that if we come up with a good overall design, it should be
able to handle different MTUs without needing to special case them -
after all, we're already talking about 2 different MTUs (encapsulated
and not) - so I don't think that having more would really make a
significant difference. I w
If it helps any, the entire underlying physical network should use the same
MTU, at least in the simplest case. In other words, all provider networks
use the native MTU and all self-service/project networks use the native MTU
minus overlay protocol overhead, or 58 bytes for Geneve with IPv4
endpoin
