[ovs-dev] [ovs-discuss] Geneve remote_ip as flow for OVN hosts
Leonid Grossman
lgrossman at nvidia.com
Thu Dec 13 18:07:31 UTC 2018
Hi Ben,
You are right, we briefly discussed this at ovscon; in-person meeting sounds as a good way to progress.
Venu/Girish/myself are available next Wed - will this work for you?
We can come over to VMware campus, or host the meeting here at Nvidia (Santa Clara HQ, San Tomas and Walsh)
to discuss the use case in more details (other use cases like NFV should be able benefit too),
and perhaps demo the proposed code changes.
Please pick the time/place and let us know.
Best, Leonid
> -----Original Message-----
> From: ovs-discuss-bounces at openvswitch.org <ovs-discuss-
> bounces at openvswitch.org> On Behalf Of Ben Pfaff
> Sent: Wednesday, December 12, 2018 12:51 PM
> To: venugopal iyer <iyervl at ymail.com>
> Cc: ovs dev <dev at openvswitch.org>; Guru Shetty <guru at ovn.org>; Girish
> Moodalbail <gmoodalbail at nvidia.com>; discuss at openvswitch.org
> Subject: Re: [ovs-discuss] [ovs-dev] Geneve remote_ip as flow for OVN
> hosts
>
> If I'm not mistaken, we briefly discussed this at ovscon. It seems to me that
> this is a fairly complicated issue and proposal, and it might benefit from in-
> person discussion. I seem to recall that you are local to the Bay Area, and, if
> so, do you think we could take some time, perhaps next week, to have a
> meeting over it? Otherwise, I will continue to study it.
>
> On Thu, Nov 29, 2018 at 05:40:45PM +0000, venugopal iyer wrote:
> > Sorry for the resend, I am not sure how the pictures will render in the text
> doc, so am attaching the PDF too.
> > thanks,
> > -venu
> >
> > On Thursday, November 29, 2018, 9:26:54 AM PST, venugopal iyer
> <iyervl at ymail.com> wrote:
> >
> > Thanks, Ben.
> >
> > Sorry for the delay. Please find attached a draft design proposal and
> > let me know your comments etc. I did some quick prototyping
> to check for feasibility too; I can share that, if it helps.
> > Note, the document is a draft and, I admit, there might be things
> > that I haven't thought about/through, or missed. I am attaching a text doc,
> assuming it might be easier, but if you'd like it in a different format, please let
> me know.
> >
> > thanks!
> > -venu
> >
> > On Wednesday, October 31, 2018, 10:30:23 AM PDT, Ben Pfaff
> <blp at ovn.org> wrote:
> >
> > Honestly the best thing to do is probably to propose a design or, if
> > it's simple enough, to send a patch. That will probably be more
> > effective at sparking a discussion.
> >
> > On Wed, Oct 31, 2018 at 03:33:48PM +0000, venugopal iyer wrote:
> > > Hi:
> > > Just wanted to check if folks had any thoughts on the use case
> > >Girish outlined below. We do have a real use case for this and are
> interested in looking at options for supporting more than one VTEP IP.It is
> currently a limitation for us, wanted to know if there are similar use cases
> folks are looking at/interested in addressing.
> > >
> > > thanks,
> > > -venu
> > >
> > > On Thursday, September 6, 2018, 9:19:01 AM PDT, venugopal iyer
> > >via dev <ovs-dev at openvswitch.org> wrote:
> > >
> > > Would it be possible for the association <logical port|dst MAC,
> > >VTEP> to be made when the logical port is instantiated on a node?
> > >and relayed on to the SB by the controller, e.g. assuming a
> > >mechanism to specify/determine a physical port mapping for a logical
> > >port for a VM. The <physical port,encap-ip> mappings can be
> > >specified as configuration on the chassis. In the absence of physical port
> information for a logical port/VM, I suppose we could default to an encap-ip.
> > >
> > >
> > > just a thought,
> > > -venu
> > > On Wednesday, September 5, 2018, 2:03:35 PM PDT, Ben Pfaff
> > > <blp at ovn.org> wrote:
> > >
> > > How would OVN know which IP to use for a given logical port on a
> > >chassis?
> > >
> > > I think that the "multiple tunnel encapsulations" is meant to cover,
> > > say, Geneve vs. STT vs. VXLAN, not the case you have in mind.
> > >
> > > On Wed, Sep 05, 2018 at 09:50:32AM -0700, Girish Moodalbail wrote:
> > > > Hello all,
> > > >
> > > > I would like to add more context here. In the diagram below
> > > >
> > > > +----------------------------------+
> > > > |ovn-host |
> > > > | |
> > > > | |
> > > > | +-------------------------+|
> > > > | | br-int ||
> > > > | +----+-------------+------+|
> > > > | | | |
> > > > | +--v-----+ +---v----+ |
> > > > | | geneve | | geneve | |
> > > > | +--+-----+ +---+----+ |
> > > > | | | |
> > > > | +-v----+ +--v---+ |
> > > > | | IP0 | | IP1 | |
> > > > | +------+ +------+ |
> > > > +----------+ eth0 +-----+ eth1 +---+
> > > > +------+ +------+
> > > >
> > > > eth0 and eth are, say, in its own physical segments. The VMs that
> > > > are instantiated in the above ovn-host will have multiple
> > > > interfaces and each of those interface need to be on a different
> Geneve VTEP.
> > > >
> > > > I think the following entry in OVN TODOs (
> > > > https://github.com/openvswitch/ovs/blob/master/ovn/TODO.rst)
> > > >
> > > > ---------------8<------------------8<---------------
> > > > Support multiple tunnel encapsulations in Chassis.
> > > >
> > > > So far, both ovn-controller and ovn-controller-vtep only allow
> > > > chassis to have one tunnel encapsulation entry. We should extend
> > > > the implementation to support multiple tunnel encapsulations
> > > > ---------------8<------------------8<---------------
> > > >
> > > > captures the above requirement. Is that the case?
> > > >
> > > > Thanks again.
> > > >
> > > > Regards,
> > > > ~Girish
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Sep 4, 2018 at 3:00 PM Girish Moodalbail
> > > > <gmoodalbail at gmail.com>
> > > > wrote:
> > > >
> > > > > Hello all,
> > > > >
> > > > > Is it possible to configure remote_ip as a 'flow' instead of an
> > > > > IP address (i.e., setting ovn-encap-ip to a single IP address)?
> > > > >
> > > > > Today, we have one VTEP endpoint per OVN host and all the VMs
> > > > > that connects to br-int on that OVN host are reachable behind
> > > > > this VTEP endpoint. Is it possible to have multiple VTEP
> > > > > endpoints for a br-int bridge and use Open Flow flows to select one of
> the VTEP endpoint?
> > > > >
> > > > >
> > > > > +----------------------------------+
> > > > > |ovn-host |
> > > > > | |
> > > > > | |
> > > > > | +-------------------------+|
> > > > > | | br-int ||
> > > > > | +----+-------------+------+|
> > > > > | | | |
> > > > > | +--v-----+ +---v----+ |
> > > > > | | geneve | | geneve | |
> > > > > | +--+-----+ +---+----+ |
> > > > > | | | |
> > > > > | +-v----+ +--v---+ |
> > > > > | | IP0 | | IP1 | |
> > > > > | +------+ +------+ |
> > > > > +----------+ eth0 +-----+ eth1 +---+
> > > > > +------+ +------+
> > > > >
> > > > > Also, we don't want to bond eth0 and eth1 into a bond interface
> > > > > and then use bond's IP as VTEP endpoint.
> > > > >
> > > > > Thanks in advance,
> > > > > ~Girish
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > > > _______________________________________________
> > > > discuss mailing list
> > > > discuss at openvswitch.org
> > > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> > >
> > > _______________________________________________
> > > dev mailing list
> > > dev at openvswitch.org
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> > >
> > > _______________________________________________
> > > dev mailing list
> > > dev at openvswitch.org
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> > >too, I can share that if it helps.
> >
> >
>
>
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
More information about the dev
mailing list