Re: [ovs-discuss] [ovs-dev] Geneve remote_ip as flow for OVN hosts
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-boun...@openvswitch.org boun...@openvswitch.org> On Behalf Of Ben Pfaff > Sent: Wednesday, December 12, 2018 12:51 PM > To: venugopal iyer > Cc: ovs dev ; Guru Shetty ; Girish > Moodalbail ; disc...@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 +, 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 > 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 > 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 +, 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 wrote: > > > > > > Would it be possible for the association > >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 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 > > > 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
Re: [ovs-discuss] [ovs-dev] Geneve remote_ip as flow for OVN hosts
Hi, Ben: Agreed; mid/late next week should work for a meeting, will check with you about availability/logistics. thanks! -venu On Wednesday, December 12, 2018, 12:50:41 PM PST, Ben Pfaff wrote: 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 +, 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 > 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 >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 +, 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 > > wrote: > > > > Would it be possible for the association 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 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 > > 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 > > > wrote: > > > > > > > Hello all, > > > > > > > > Is it possible to configure remote_ip as a 'flow' instead of an IP > > > > address > > > > (i.e.,
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 +, 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 > 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 > 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 +, 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 > > wrote: > > > > Would it be possible for the association 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 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 > > 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 > > > 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 >
Re: [ovs-discuss] [ovs-dev] Geneve remote_ip as flow for OVN hosts
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 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 +, 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 > wrote: > > Would it be possible for the association 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 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 > 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 > > 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
Re: [ovs-discuss] [ovs-dev] Geneve remote_ip as flow for OVN hosts
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 +, 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 > wrote: > > Would it be possible for the association 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 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 > 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 > > 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 > > disc...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > ___ > dev mailing list
Re: [ovs-discuss] [ovs-dev] Geneve remote_ip as flow for OVN hosts
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 wrote: Would it be possible for the association 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 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 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 > 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 > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] Geneve remote_ip as flow for OVN hosts
Would it be possible for the association 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 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 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 > 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 > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
