[ovs-discuss] Talk Proprosal: OVN control of the black box.

[Raymond Burkholder]

> > > I went through Dustin Spinhirne's OVN Tutorial.  It helped immensely
> > > in understanding OVS/OVN interactions.  And also highlighted some of
> > > the shortcomings.
> > >
> > > Of many, two, possibly related, questions/ideas come to mind.  1)
> > > OVN seems to be more focused on the hypervisor side of things,
> 
> Do you mean, as opposed to container systems, or as opposed to something
> else?  OVN is meant to support both VMs and containers, in essentially the
> same way, so probably when we design the tutorial we should cover both.

Yes, I can see how it works with both containers and VMs.  Examples for both
might be useful, but if time is short, it isn't completely useful.  Veth
seems to be a common use scenario, but if something like macvlan or ipvlan
or others are alternate choices, examples with those might be useful.  I
havn't quite figured out use-cases for those, if they do exist.

But that wasn't quite where I was going.  I am using OVS in a routing /
switching use-case for the physical network.  I am trying to come up with an
appropriate controller solution for the openflow aspects of OVS when using
routers to connect hypervisors together.  I'll expand on this more below
where you ask a different question.

> 
> > > and 2) ecmp / routing still needs to be defined/implemented.
> 
> I guess that you do not mean this comment for logical networks, since OVN
> already supports logical routing and because ECMP does not really make
> sense at the logical level.

Yes, ECMP doesn't make sense at the logical level.  But at the physical
level it does.  Which I'll expand on for one of your other comments.

> 
> So I guess that you must be talking about ECMP and routing at the physical
> level.  What support do you think that we should add?  Or do you mean that
> we should explain in the tutorial how they interact with OVN?

The support I am thinking of adding is for OVN control of a physical
network.  Which couldn't be explained in a tutorial, because I don't think
that exists yet.

> 
> > > As a solution, I have been thinking along the lines of adding
> > > additional smarts to the OVN controller.
> > >
> > > In looking at techniques in Ryu where LLDP and link state can be
> > > communicated back to a controller so it effectively has an idea of
> > > the topology of the network.  It would be interesting to re-code the
> > > Ryu examples into an OVN/OVS context.
> > >
> > > The  topology meta-information could be used to perform some
> > > max-flow/min-cost calculations.  This information could be
> > > communicated back to the local OVN agent, which could be used to
> > > influence the routing/flow-control in the local OVS instance.
> > >
> > > This then gets OVN/OVS integrated into the over-all network, helps
> > > with over-all routing decisions (which is known to be lacking), and
> > > may help resolve some known resiliency/redundancy shortcomings.
> > >
> > > Is there general community interest in accepting such a solution?
> > > If so, I would be willing to start on working on details.  If there
> > > are members of the community who are familiar with the
> > > max-flow/min-cost calculations as they relate to network flow
> > > control, I would really like to hear from them about implementation
> gotchas, improvements, alternatives, ....
> 
> Until now, OVN has not interacted much with the physical network.  It's

It is the 'until now'.  Maybe now is good to start thinking about that
interaction.  Unless the interaction is not appropriate and operators deal
with in a different way?

> generally considered as a black box.  The idea is that OVN simply
addresses a
> tunnel packet to an IP address and the physical network is responsible for
> delivering it to that IP address in a robust, efficient manner.  It sounds
like
> you'd like OVN to support being more tightly bound to the physical
network.

yes

> Probably, you should say more about how you want that to happen.  I do
> wonder whether it's really something that needs to be integrated into OVN
> at all, because I think that most of the possibilities could be
implemented
> without OVN's participation, but certainly that's just a question and not
a

How do you currently see that happening in networks of today?

> conclusion.

I think the key here is that I'm trying to build the innards of the 'black
box' you mention.  Ie, openvswitch supports openflow.  Openflow can be used
in the physical network to support packet routing/switching from one end of
the network to the other (the black box).  But openflow needs some kind of
controller.  Either a central one, or a distributed one, or a combo one
(central controller talking to distributed agents for each switch/router,
much like the OVN controller/agent scenario currently implemented for
virtualization).

I looked at a number of controllers:  frenetic, faucet, ryu, ...

Ryu came closest to meeting my needs, but would require quite a bit of work
to implement a controller/agent strategy.

But having looked at OVN, and how closely it ties to OVS/openflow, I am
thinking that there might be a way to extend OVN such that it can support
the black-box, ie, the physical network which transports those packets.  

The reason I am bringing this up is that there appear to be various work
arounds to get redundant gateways to the physical network implemented for
OVN.  I'm thinking that if we integrate the physical network into the
solution, the redundant/load-balanced gateway problem goes away.  

The way to make it go away is to have the main OVN controller make a
determination of how to load balance traffic, and as part of that, determine
appropriate exit and entry points for traffic.

For example, if a hypervisor has two routed ports to two layer 3 switches
(for resiliency and redundancy), OVN and its agents can assign certain flows
to one exit port, and other flows to the other port.  And then in the core,
more balancing and routing and switching can be performed.  And when it
reaches the edge or another hypervisor, the opposite happens.

So OVN wouldn't necessarily be only about dealing with encapsulation.  It
would also be about routing and flow handling end to end.  I am thinking
that way because it has already been designed as a controller / agent combo,
which, in itself, provides some safety features:  if the controller goes
down, local agents can continue their control based upon the last
information they received.  And if a local agent goes down, well, other
agents on other devices are still operational.

Bottom line, is there room for black box control?  How do other operators
handle black box control?

> 
> > > Perhaps the Boston Summit could be used to: 1) make a general call
> > > to action in a talk, and 2) talk in the hallways about the
> > > techniques required to implement a solution.
> 
> Would you like to propose a talk?  I'd love to hear a talk on the topic.

Well, the talk would try to flesh out the thoughts about the above.  The
above could possibly be the talk proposal ;-)  The stuff mentioned above are
ideas still in the conceptual stage.  If that is appropriate for this venue.




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.