[ovs-dev] OVN: Use of Tunnel Keys

[Ben Pfaff]

On Wed, Apr 29, 2015 at 05:46:17PM -0700, Justin Pettit wrote:
> Anyway, I figure this is a good place to start the conversation, so
> let's go.  :-)

I thought I'd have a lot of comments to add to this, but you were
thorough.  Thanks.

Just to be clear about the alternatives, I think they are:

        1. Tunnel key carries destination logical port identifier
           (LPID).

        2. Tunnel key carries logical network identifier (VNI) plus
           source LPID, and the latter can be scoped within the former.

I tend to agree that scheme #2 is probably what we will end up with, for
the reasons you've already identified and because it's more compatible
with VTEP gateways.

(However, I'm not sure that I believe the claim that it's easier to
assign unique LPIDs within a VNI, because I think that in either case
we'll be assigning them centrally at ovn-northd.)

I want to expand the consequences on multicast and broadcast (that you
already mentioned).  In scheme #1, both are easy: the logical flow table
just replicates the packet to every destination LPID.  In fact, that
part of OVN is already used in a nontrivial way: you can configure any
number of logical ports to have an "unknown" set of MACs, and in that
case packets to any destination MAC that isn't specifically configured
on another port will be sent to the logical port or ports configured for
"unknown".  That's a useful feature for, e.g. supporting a logical port
that connects to a VM that has a bridge in it that would run in
"promiscuous mode" (though it's only really difficult to support
multiple logical ports configured as "unknown").  It would also be
useful for implementing port mirroring (SPAN) within a logical network.

That kind of thing is really hard in scheme #2, because whether the
source HV should actually send multiple copies of a packet going to
multiple destination logical ports depends on whether those destination
logical ports are on the same HV (you brought this up briefly already).
It needs to send only one copy per HV, not one copy per logical port.
That's easy if you have predefined multicast/broadcast groups; for
example, we'd probably have a predefined "broadcast" port ID that just
sends a copy of the packet to every HV in the logical network.  To
support the example multiple "unknown" MACs, we'd need a way for the
OVN_Southbound database to define "multicast groups" of logical ports,
which ovn-controller would translate into sending a packet to each HV
that contains one or more of those logical ports.  Port mirroring might
be more trouble in that model since you'd need one multicast group for
every logical port.

A cleaner alternative would be to make OpenFlow somehow capable of
deduplicating packets: send two packets to a given tunnel (HV) and only
one actually gets sent.  If we can come up with a clean way to do that,
a way that is general-purpose and likely to be useful in other
circumstances (I've certainly thought of this dedup problem before in
OpenFlow circumstances) then that might be better than the "predefined
groups" idea.