Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Murali R]

Cool. That works.

On Mon, Oct 5, 2015 at 9:05 AM, Russell Bryant  wrote:

> On 10/05/2015 04:28 PM, Murali R wrote:
> > Yes. So we can define multiple logical switches per network and ovn
> > keeps vlan maps that ovs agent used to maintain and do the tunneling. My
> > confusion was from lport-add command that did not have host info, so if
> > there is no neutron, the cms has to maintain the host to lport
> > association and we can't query from NB-DB. Makes sense.
>
> The host to lport mappings are maintained by ovn-controller in the Port
> Binding table of the OVN Southbound database.
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Murali R]

Yes. So we can define multiple logical switches per network and ovn keeps
vlan maps that ovs agent used to maintain and do the tunneling. My
confusion was from lport-add command that did not have host info, so if
there is no neutron, the cms has to maintain the host to lport association
and we can't query from NB-DB. Makes sense.

-Murali

On Fri, Oct 2, 2015 at 11:46 AM, Russell Bryant  wrote:

> On 10/02/2015 02:26 PM, Murali R wrote:
> > Hi Russell,
> >
> > Thank you these are really good. Had a quick question. When you create a
> > logical switch in your first script (line 23) - at what point is it
> > associated with br-int ? Is it on line 45? So I can create any switch
> > and when I associated logical port it associates logical switch ? Or is
> > there a different way we can associate logical-phy switches? I was
> > looking to get the logical associations during startup initialization.
>
> To clarify, I believe you're talking about the first script from the
> tutorial [1], which is:
>
>
> https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env1/setup.sh
>
> Most of that script is all configuring logical topology.  OVN does
> nothing to the network until ovn-controller sees a port appear on br-int
> that maps to a logical port.  This mapping is done by setting the
> "iface-id" to the name of the logical port.
>
> Once ovn-controller has mapped a port on br-int to a logical port, it
> can configure the switch appropriately for that port.
>
> Does that make sense?
>
> [1]
> https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 10/05/2015 04:28 PM, Murali R wrote:
> Yes. So we can define multiple logical switches per network and ovn
> keeps vlan maps that ovs agent used to maintain and do the tunneling. My
> confusion was from lport-add command that did not have host info, so if
> there is no neutron, the cms has to maintain the host to lport
> association and we can't query from NB-DB. Makes sense.

The host to lport mappings are maintained by ovn-controller in the Port
Binding table of the OVN Southbound database.

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 09/27/2015 04:18 PM, Russell Bryant wrote:
> On 09/27/2015 06:50 AM, Kevin Benton wrote:
>> Assuming it implements the normal provider networks API, you just
>> specify the segmentation_id when you create the network. 
>>
>> neutron net-create NET_NAME --provider:network_type vlan
>> --provider:physical_network physnet1 --provider:segmentation_id VLAN_TAG
> 
> Yes, the OVN plugin will implement the normal provider networks API.
> It's a WIP.
> 
> My first goal was to just implement support for "--provider:network_type
> flat" end to end.  I have the OVN side merged and now I'm working on the
> Neutron plugin piece.  Once that's done, I'll go back add add VLAN
> support, which shouldn't be very difficult at that point.  I'm aiming to
> have all of that done by the Tokyo summit (among other things).

Just as a brief follow-up here, I finished the VLAN provider network
support for OVN here:

https://github.com/openvswitch/ovs/commit/779e72cc57a106251cc9e6696e8c9aabb56d30b5

I also wrote an OVN tutorial this week.  Examples 4 and 5 cover how
provider networks are modeled in OVN.

https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md

I have the Neutron API patch posted here:

https://review.openstack.org/#/c/228573/

I did the patch before I finished the VLAN support.  Adding the VLAN bit
will be a trivial update, though.

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Murali R]

Hi Russell,

Thank you these are really good. Had a quick question. When you create a
logical switch in your first script (line 23) - at what point is it
associated with br-int ? Is it on line 45? So I can create any switch and
when I associated logical port it associates logical switch ? Or is there a
different way we can associate logical-phy switches? I was looking to get
the logical associations during startup initialization.

On Fri, Oct 2, 2015 at 8:27 AM, Russell Bryant  wrote:

> On 09/27/2015 04:18 PM, Russell Bryant wrote:
> > On 09/27/2015 06:50 AM, Kevin Benton wrote:
> >> Assuming it implements the normal provider networks API, you just
> >> specify the segmentation_id when you create the network.
> >>
> >> neutron net-create NET_NAME --provider:network_type vlan
> >> --provider:physical_network physnet1 --provider:segmentation_id VLAN_TAG
> >
> > Yes, the OVN plugin will implement the normal provider networks API.
> > It's a WIP.
> >
> > My first goal was to just implement support for "--provider:network_type
> > flat" end to end.  I have the OVN side merged and now I'm working on the
> > Neutron plugin piece.  Once that's done, I'll go back add add VLAN
> > support, which shouldn't be very difficult at that point.  I'm aiming to
> > have all of that done by the Tokyo summit (among other things).
>
> Just as a brief follow-up here, I finished the VLAN provider network
> support for OVN here:
>
>
> https://github.com/openvswitch/ovs/commit/779e72cc57a106251cc9e6696e8c9aabb56d30b5
>
> I also wrote an OVN tutorial this week.  Examples 4 and 5 cover how
> provider networks are modeled in OVN.
>
> https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md
>
> I have the Neutron API patch posted here:
>
> https://review.openstack.org/#/c/228573/
>
> I did the patch before I finished the VLAN support.  Adding the VLAN bit
> will be a trivial update, though.
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 10/02/2015 02:26 PM, Murali R wrote:
> Hi Russell,
> 
> Thank you these are really good. Had a quick question. When you create a
> logical switch in your first script (line 23) - at what point is it
> associated with br-int ? Is it on line 45? So I can create any switch
> and when I associated logical port it associates logical switch ? Or is
> there a different way we can associate logical-phy switches? I was
> looking to get the logical associations during startup initialization.

To clarify, I believe you're talking about the first script from the
tutorial [1], which is:

  https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env1/setup.sh

Most of that script is all configuring logical topology.  OVN does
nothing to the network until ovn-controller sees a port appear on br-int
that maps to a logical port.  This mapping is done by setting the
"iface-id" to the name of the logical port.

Once ovn-controller has mapped a port on br-int to a logical port, it
can configure the switch appropriately for that port.

Does that make sense?

[1] https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 09/30/2015 06:01 PM, Murali R wrote:
> Yes, sfc without nsh is what I am looking into and I am thinking ovn can
> have a better approach.
> 
> I did an implementation of sfc around nsh that used ovs & flows from
> custom ovs-agent back in mar-may. I added fields in ovs agent to send
> additional info for actions as well. Neutron side was quite trivial. But
> the solution required an implementation of ovs to listen on a different
> port to handle nsh header so doubled the number of tunnels. The ovs code
> we used/modified to was either from the link you sent or some other
> similar impl from Cisco folks (I don't recall) that had actions and
> conditional commands for the field. If we have generic ovs code to
> compare or set actions on any configured address field was my thought.
> But haven't thought through much on how to do that. In any case, with
> ovn we cannot define custom flows directly on ovs, so that approach is
> dated now. But hoping some similar feature can be added to ovn which can
> transpose some header field to geneve options.

Thanks for the detail of what you're trying to do.

I'm not sure how much you've looked into how OVN works.  OVN works by
defining the network in terms of "logical flows".  These logical flows
look similar to OpenFlow, but it talks about network resources in the
logical sense (not based on where they are physically located).  I think
we can implement SFC purely in the logical space.  So, most of the work
I think is in defining the northbound db schema and then converting that
into the right logical flows.  I looked at the API being proposed by the
networking-sfc project, and that's giving me a pretty good idea of what
the northbound schema could look like for OVN.

https://git.openstack.org/cgit/openstack/networking-sfc/tree/doc/source/api.rst

The networking-sfc API talks about a "chain parameter".  That's where
NSH could come in.  The spec proposes "mpls" as something OVS can
already support.  Given a single VIF, we need a way to differentiate
traffic associated with different chains.  This is *VERY* similar to
what OVN is already doing with parent/child ports, originally intended
for the containers-in-VM use case.  This same concept seems to fit here
quite well.  Today, we only support VLAN IDs for this, but we could
extend it to support mpls, NSH, or whatever.

Anyway, those are just my high level thoughts so far.  I haven't tried
to really dig into a detailed design yet.

> I am trying something right now with ovn and will be attending ovs
> conference in nov. I am skipping openstack summit to attend something
> else in far-east during that time. But lets keep the discussion going
> and collaborate if you work on sfc.

I look forward to meeting you in November!  :-)

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Murali R]

Russell,

" These logical flows
look similar to OpenFlow, but it talks about network resources in the
logical sense (not based on where they are physically located).  I think
we can implement SFC purely in the logical space. "

Exactly. I was in the ovn presentation at Vancouver and at that time it
felt we could use these for sfc and that is why I am on this project now. I
am checking if the logical flows will do what I want to do. Or we can
extend the internal impl without impacting the larger neutron or other cms
interaction. For a standalone solutions number of flows to manage is too
much with plain ovs and ovs-agent has its own limitation on how we can
define custom flows..

Missed the ovn meeting today but have notes from log. Nice usage blog :)
Thank you for all you do Russell, helping us get overboard.

-Murali

On Thu, Oct 1, 2015 at 7:32 AM, Russell Bryant  wrote:

> On 09/30/2015 06:01 PM, Murali R wrote:
> > Yes, sfc without nsh is what I am looking into and I am thinking ovn can
> > have a better approach.
> >
> > I did an implementation of sfc around nsh that used ovs & flows from
> > custom ovs-agent back in mar-may. I added fields in ovs agent to send
> > additional info for actions as well. Neutron side was quite trivial. But
> > the solution required an implementation of ovs to listen on a different
> > port to handle nsh header so doubled the number of tunnels. The ovs code
> > we used/modified to was either from the link you sent or some other
> > similar impl from Cisco folks (I don't recall) that had actions and
> > conditional commands for the field. If we have generic ovs code to
> > compare or set actions on any configured address field was my thought.
> > But haven't thought through much on how to do that. In any case, with
> > ovn we cannot define custom flows directly on ovs, so that approach is
> > dated now. But hoping some similar feature can be added to ovn which can
> > transpose some header field to geneve options.
>
> Thanks for the detail of what you're trying to do.
>
> I'm not sure how much you've looked into how OVN works.  OVN works by
> defining the network in terms of "logical flows".  These logical flows
> look similar to OpenFlow, but it talks about network resources in the
> logical sense (not based on where they are physically located).  I think
> we can implement SFC purely in the logical space.  So, most of the work
> I think is in defining the northbound db schema and then converting that
> into the right logical flows.  I looked at the API being proposed by the
> networking-sfc project, and that's giving me a pretty good idea of what
> the northbound schema could look like for OVN.
>
>
> https://git.openstack.org/cgit/openstack/networking-sfc/tree/doc/source/api.rst
>
> The networking-sfc API talks about a "chain parameter".  That's where
> NSH could come in.  The spec proposes "mpls" as something OVS can
> already support.  Given a single VIF, we need a way to differentiate
> traffic associated with different chains.  This is *VERY* similar to
> what OVN is already doing with parent/child ports, originally intended
> for the containers-in-VM use case.  This same concept seems to fit here
> quite well.  Today, we only support VLAN IDs for this, but we could
> extend it to support mpls, NSH, or whatever.
>
> Anyway, those are just my high level thoughts so far.  I haven't tried
> to really dig into a detailed design yet.
>
> > I am trying something right now with ovn and will be attending ovs
> > conference in nov. I am skipping openstack summit to attend something
> > else in far-east during that time. But lets keep the discussion going
> > and collaborate if you work on sfc.
>
> I look forward to meeting you in November!  :-)
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Murali R]

Apologize typo "...us get overboard." ==> should be "... get us onboard" :)

On Thu, Oct 1, 2015 at 11:38 AM, Murali R  wrote:

> Russell,
>
> " These logical flows
> look similar to OpenFlow, but it talks about network resources in the
> logical sense (not based on where they are physically located).  I think
> we can implement SFC purely in the logical space. "
>
> Exactly. I was in the ovn presentation at Vancouver and at that time it
> felt we could use these for sfc and that is why I am on this project now. I
> am checking if the logical flows will do what I want to do. Or we can
> extend the internal impl without impacting the larger neutron or other cms
> interaction. For a standalone solutions number of flows to manage is too
> much with plain ovs and ovs-agent has its own limitation on how we can
> define custom flows..
>
> Missed the ovn meeting today but have notes from log. Nice usage blog :)
> Thank you for all you do Russell, helping us get overboard.
>
> -Murali
>
> On Thu, Oct 1, 2015 at 7:32 AM, Russell Bryant  wrote:
>
>> On 09/30/2015 06:01 PM, Murali R wrote:
>> > Yes, sfc without nsh is what I am looking into and I am thinking ovn can
>> > have a better approach.
>> >
>> > I did an implementation of sfc around nsh that used ovs & flows from
>> > custom ovs-agent back in mar-may. I added fields in ovs agent to send
>> > additional info for actions as well. Neutron side was quite trivial. But
>> > the solution required an implementation of ovs to listen on a different
>> > port to handle nsh header so doubled the number of tunnels. The ovs code
>> > we used/modified to was either from the link you sent or some other
>> > similar impl from Cisco folks (I don't recall) that had actions and
>> > conditional commands for the field. If we have generic ovs code to
>> > compare or set actions on any configured address field was my thought.
>> > But haven't thought through much on how to do that. In any case, with
>> > ovn we cannot define custom flows directly on ovs, so that approach is
>> > dated now. But hoping some similar feature can be added to ovn which can
>> > transpose some header field to geneve options.
>>
>> Thanks for the detail of what you're trying to do.
>>
>> I'm not sure how much you've looked into how OVN works.  OVN works by
>> defining the network in terms of "logical flows".  These logical flows
>> look similar to OpenFlow, but it talks about network resources in the
>> logical sense (not based on where they are physically located).  I think
>> we can implement SFC purely in the logical space.  So, most of the work
>> I think is in defining the northbound db schema and then converting that
>> into the right logical flows.  I looked at the API being proposed by the
>> networking-sfc project, and that's giving me a pretty good idea of what
>> the northbound schema could look like for OVN.
>>
>>
>> https://git.openstack.org/cgit/openstack/networking-sfc/tree/doc/source/api.rst
>>
>> The networking-sfc API talks about a "chain parameter".  That's where
>> NSH could come in.  The spec proposes "mpls" as something OVS can
>> already support.  Given a single VIF, we need a way to differentiate
>> traffic associated with different chains.  This is *VERY* similar to
>> what OVN is already doing with parent/child ports, originally intended
>> for the containers-in-VM use case.  This same concept seems to fit here
>> quite well.  Today, we only support VLAN IDs for this, but we could
>> extend it to support mpls, NSH, or whatever.
>>
>> Anyway, those are just my high level thoughts so far.  I haven't tried
>> to really dig into a detailed design yet.
>>
>> > I am trying something right now with ovn and will be attending ovs
>> > conference in nov. I am skipping openstack summit to attend something
>> > else in far-east during that time. But lets keep the discussion going
>> > and collaborate if you work on sfc.
>>
>> I look forward to meeting you in November!  :-)
>>
>> --
>> Russell Bryant
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Murali R]

Russell,

Are any additional options fields used in geneve between hypervisors at
this time? If so, how do they translate to vxlan when it hits gw? For
instance, I am interested to see if we can translate a custom header info
in vxlan to geneve headers and vice-versa. And if there are flow commands
available to add conditional flows at this time or if it is possible to
extend if need be.

Thanks
Murali

On Sun, Sep 27, 2015 at 1:14 PM, Russell Bryant  wrote:

> On 09/27/2015 02:26 AM, WANG, Ming Hao (Tony T) wrote:
> > Russell,
> >
> > Thanks for your valuable information.
> > I understood Geneve is some kind of tunnel format for network
> virtualization encapsulation, just like VxLAN.
> > But I'm still confused by the connection between Geneve and VTEP.
> > I suppose VTEP should be on behalf of "VxLAN Tunnel Endpoint", which
> should be used for VxLAN only.
> >
> > Does it become some "common tunnel endpoint" in OVN, and can be also
> used as a tunnel endpoint for Geneve?
>
> When using VTEP gateways, both the Geneve and VxLAN protocols are being
> used.  Packets between hypervisors are sent using Geneve.  Packets
> between a hypervisor and the gateway are sent using VxLAN.
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 09/30/2015 03:29 PM, Murali R wrote:
> Russell,
> 
> Are any additional options fields used in geneve between hypervisors at
> this time? If so, how do they translate to vxlan when it hits gw? For
> instance, I am interested to see if we can translate a custom header
> info in vxlan to geneve headers and vice-versa. 

Yes, geneve options are used. Specifically, there are three pieces of
metadata sent: a logical datapath ID (the logical switch, or network),
the source logical port, and the destination logical port.

Geneve is only used between hypervisors. VxLAN is only used between
hypervisors and a VTEP gateway. In that case, the additional metadata is
not included. There's just a tunnel ID in that case, used to identify
the source/destination logical switch on the VTEP gateway.

> And if there are flow
> commands available to add conditional flows at this time or if it is
> possible to extend if need be.

I'm not quite sure I understand this part.  Could you expand on what you
have in mind?

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 09/30/2015 04:09 PM, Murali R wrote:
> Russel,
> 
> For instance if I have a nsh header embedded in vxlan in the incoming
> packet, I was wondering if I can transfer that to geneve options
> somehow. This is just as an example. I may have header other info either
> in vxlan or ip that needs to enter the ovn network and if we have
> generic ovs commands to handle that, it will be useful. If commands
> don't exist but extensible then I can do that as well.

Well, OVS itself doesn't support NSH yet.  There are patches on the OVS
dev mailing list for it, though.

http://openvswitch.org/pipermail/dev/2015-September/060678.html

Are you interested in SFC?  I have been thinking about that and don't
think it will be too hard to add support for it in OVN.  I'm not sure
when I'll work on it, but it's high on my personal todo list.  If you
want to do it with NSH, that will require OVS support first, of course.

If you're interested in more generic extensibility of OVN, there's at
least going to be one talk about that at the OVS conference in November.
 If you aren't there, it will be on video.  I'm not sure what ideas they
will be proposing.

Since we're on the OpenStack list, I assume we're talking in the
OpenStack context.  For any feature we're talking about, we also have to
talk about how that is exposed through the Neutron API.  So, "generic
extensibility" doesn't immediately make sense for the Neutron case.

SFC certainly makes sense.  There's a Neutron project for adding an SFC
API and from what I've seen so far, I think we'll be able to extend OVN
such that it can back that API.

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Murali R]

Russel,

For instance if I have a nsh header embedded in vxlan in the incoming
packet, I was wondering if I can transfer that to geneve options somehow.
This is just as an example. I may have header other info either in vxlan or
ip that needs to enter the ovn network and if we have generic ovs commands
to handle that, it will be useful. If commands don't exist but extensible
then I can do that as well.





On Wed, Sep 30, 2015 at 12:49 PM, Russell Bryant  wrote:

> On 09/30/2015 03:29 PM, Murali R wrote:
> > Russell,
> >
> > Are any additional options fields used in geneve between hypervisors at
> > this time? If so, how do they translate to vxlan when it hits gw? For
> > instance, I am interested to see if we can translate a custom header
> > info in vxlan to geneve headers and vice-versa.
>
> Yes, geneve options are used. Specifically, there are three pieces of
> metadata sent: a logical datapath ID (the logical switch, or network),
> the source logical port, and the destination logical port.
>
> Geneve is only used between hypervisors. VxLAN is only used between
> hypervisors and a VTEP gateway. In that case, the additional metadata is
> not included. There's just a tunnel ID in that case, used to identify
> the source/destination logical switch on the VTEP gateway.
>
> > And if there are flow
> > commands available to add conditional flows at this time or if it is
> > possible to extend if need be.
>
> I'm not quite sure I understand this part.  Could you expand on what you
> have in mind?
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Murali R]

Yes, sfc without nsh is what I am looking into and I am thinking ovn can
have a better approach.

I did an implementation of sfc around nsh that used ovs & flows from custom
ovs-agent back in mar-may. I added fields in ovs agent to send additional
info for actions as well. Neutron side was quite trivial. But the solution
required an implementation of ovs to listen on a different port to handle
nsh header so doubled the number of tunnels. The ovs code we used/modified
to was either from the link you sent or some other similar impl from Cisco
folks (I don't recall) that had actions and conditional commands for the
field. If we have generic ovs code to compare or set actions on any
configured address field was my thought. But haven't thought through much
on how to do that. In any case, with ovn we cannot define custom flows
directly on ovs, so that approach is dated now. But hoping some similar
feature can be added to ovn which can transpose some header field to geneve
options.

I am trying something right now with ovn and will be attending ovs
conference in nov. I am skipping openstack summit to attend something else
in far-east during that time. But lets keep the discussion going and
collaborate if you work on sfc.

On Wed, Sep 30, 2015 at 2:11 PM, Russell Bryant  wrote:

> On 09/30/2015 04:09 PM, Murali R wrote:
> > Russel,
> >
> > For instance if I have a nsh header embedded in vxlan in the incoming
> > packet, I was wondering if I can transfer that to geneve options
> > somehow. This is just as an example. I may have header other info either
> > in vxlan or ip that needs to enter the ovn network and if we have
> > generic ovs commands to handle that, it will be useful. If commands
> > don't exist but extensible then I can do that as well.
>
> Well, OVS itself doesn't support NSH yet.  There are patches on the OVS
> dev mailing list for it, though.
>
> http://openvswitch.org/pipermail/dev/2015-September/060678.html
>
> Are you interested in SFC?  I have been thinking about that and don't
> think it will be too hard to add support for it in OVN.  I'm not sure
> when I'll work on it, but it's high on my personal todo list.  If you
> want to do it with NSH, that will require OVS support first, of course.
>
> If you're interested in more generic extensibility of OVN, there's at
> least going to be one talk about that at the OVS conference in November.
>  If you aren't there, it will be on video.  I'm not sure what ideas they
> will be proposing.
>
> Since we're on the OpenStack list, I assume we're talking in the
> OpenStack context.  For any feature we're talking about, we also have to
> talk about how that is exposed through the Neutron API.  So, "generic
> extensibility" doesn't immediately make sense for the Neutron case.
>
> SFC certainly makes sense.  There's a Neutron project for adding an SFC
> API and from what I've seen so far, I think we'll be able to extend OVN
> such that it can back that API.
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 09/27/2015 06:50 AM, Kevin Benton wrote:
> Assuming it implements the normal provider networks API, you just
> specify the segmentation_id when you create the network. 
> 
> neutron net-create NET_NAME --provider:network_type vlan
> --provider:physical_network physnet1 --provider:segmentation_id VLAN_TAG

Yes, the OVN plugin will implement the normal provider networks API.
It's a WIP.

My first goal was to just implement support for "--provider:network_type
flat" end to end.  I have the OVN side merged and now I'm working on the
Neutron plugin piece.  Once that's done, I'll go back add add VLAN
support, which shouldn't be very difficult at that point.  I'm aiming to
have all of that done by the Tokyo summit (among other things).

> On Sun, Sep 27, 2015 at 9:50 AM, WANG, Ming Hao (Tony T)
> >
> wrote:
> 
> Russell,
> 
> Another question is about "localnet". It is a very useful feature. :-)
> 
> Is it possible to assign which VLAN tag will be used for a specific
> provider network?
> In your example in
> 
> https://github.com/openvswitch/ovs/commit/c02819293d52f7ea7b714242d871b2b01f57f905
> : "physnet1" is used as physical network, and br-eth1 is used as the
> provider network OpenFlow switch.
> If we can assign the VLAN tag of the provider network, is the VLAN
> tag translation done by "br-int" or "br-eth1"?


-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 09/27/2015 02:26 AM, WANG, Ming Hao (Tony T) wrote:
> Russell,
> 
> Thanks for your valuable information.
> I understood Geneve is some kind of tunnel format for network virtualization 
> encapsulation, just like VxLAN.
> But I'm still confused by the connection between Geneve and VTEP.
> I suppose VTEP should be on behalf of "VxLAN Tunnel Endpoint", which should 
> be used for VxLAN only.
> 
> Does it become some "common tunnel endpoint" in OVN, and can be also used as 
> a tunnel endpoint for Geneve?

When using VTEP gateways, both the Geneve and VxLAN protocols are being
used.  Packets between hypervisors are sent using Geneve.  Packets
between a hypervisor and the gateway are sent using VxLAN.

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[WANG, Ming Hao (Tony T)]

Russell and Kevin,

Thanks for your detail information!
I got it.

Thanks again,
Tony

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Monday, September 28, 2015 4:18 AM
To: Kevin Benton; OpenStack Development Mailing List (not for usage questions)
Cc: WANG, Ming Hao (Tony T)
Subject: Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to 
setup multiple neutron networks for one container?

On 09/27/2015 06:50 AM, Kevin Benton wrote:
> Assuming it implements the normal provider networks API, you just 
> specify the segmentation_id when you create the network.
> 
> neutron net-create NET_NAME --provider:network_type vlan 
> --provider:physical_network physnet1 --provider:segmentation_id 
> VLAN_TAG

Yes, the OVN plugin will implement the normal provider networks API.
It's a WIP.

My first goal was to just implement support for "--provider:network_type flat" 
end to end.  I have the OVN side merged and now I'm working on the Neutron 
plugin piece.  Once that's done, I'll go back add add VLAN support, which 
shouldn't be very difficult at that point.  I'm aiming to have all of that done 
by the Tokyo summit (among other things).

> On Sun, Sep 27, 2015 at 9:50 AM, WANG, Ming Hao (Tony T) 
> <tony.a.w...@alcatel-lucent.com 
> <mailto:tony.a.w...@alcatel-lucent.com>>
> wrote:
> 
> Russell,
> 
> Another question is about "localnet". It is a very useful feature. 
> :-)
> 
> Is it possible to assign which VLAN tag will be used for a specific
> provider network?
> In your example in
> 
> https://github.com/openvswitch/ovs/commit/c02819293d52f7ea7b714242d871b2b01f57f905
> : "physnet1" is used as physical network, and br-eth1 is used as the
> provider network OpenFlow switch.
> If we can assign the VLAN tag of the provider network, is the VLAN
> tag translation done by "br-int" or "br-eth1"?


--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[WANG, Ming Hao (Tony T)]

Russell,

Another question is about "localnet". It is a very useful feature. :-)

Is it possible to assign which VLAN tag will be used for a specific provider 
network?
In your example in 
https://github.com/openvswitch/ovs/commit/c02819293d52f7ea7b714242d871b2b01f57f905
 : "physnet1" is used as physical network, and br-eth1 is used as the provider 
network OpenFlow switch.
If we can assign the VLAN tag of the provider network, is the VLAN tag 
translation done by "br-int" or "br-eth1"?


Thanks,
Tony

-Original Message-
From: WANG, Ming Hao (Tony T) 
Sent: Sunday, September 27, 2015 2:26 PM
To: 'Russell Bryant'; OpenStack Development Mailing List (not for usage 
questions)
Subject: RE: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to 
setup multiple neutron networks for one container?

Russell,

Thanks for your valuable information.
I understood Geneve is some kind of tunnel format for network virtualization 
encapsulation, just like VxLAN.
But I'm still confused by the connection between Geneve and VTEP.
I suppose VTEP should be on behalf of "VxLAN Tunnel Endpoint", which should be 
used for VxLAN only.

Does it become some "common tunnel endpoint" in OVN, and can be also used as a 
tunnel endpoint for Geneve?

Thanks,
Tony
-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Friday, September 25, 2015 12:04 AM
To: WANG, Ming Hao (Tony T); OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to 
setup multiple neutron networks for one container?

On 09/24/2015 10:37 AM, WANG, Ming Hao (Tony T) wrote:
> Russell,
> 
> Thanks for your detail explanation and kind help!
> I have understand how container in VM can acquire network interfaces in 
> different neutron networks now.
> For the connections between compute nodes, I think I need to study Geneve 
> protocol and VTEP first.
> Any further question, I may need to continue consulting you. :-)

OVN uses Geneve in conceptually the same way as to how the Neutron reference 
implementation (ML2+OVS) uses VxLAN to create overlay networks among the 
compute nodes for tenant overlay networks.

VTEP gateways or provider networks come into play when you want to connect 
these overlay networks to physical, or "underlay" networks.

Hope that helps,

--
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[WANG, Ming Hao (Tony T)]

Russell,

Thanks for your valuable information.
I understood Geneve is some kind of tunnel format for network virtualization 
encapsulation, just like VxLAN.
But I'm still confused by the connection between Geneve and VTEP.
I suppose VTEP should be on behalf of "VxLAN Tunnel Endpoint", which should be 
used for VxLAN only.

Does it become some "common tunnel endpoint" in OVN, and can be also used as a 
tunnel endpoint for Geneve?

Thanks,
Tony
-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Friday, September 25, 2015 12:04 AM
To: WANG, Ming Hao (Tony T); OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to 
setup multiple neutron networks for one container?

On 09/24/2015 10:37 AM, WANG, Ming Hao (Tony T) wrote:
> Russell,
> 
> Thanks for your detail explanation and kind help!
> I have understand how container in VM can acquire network interfaces in 
> different neutron networks now.
> For the connections between compute nodes, I think I need to study Geneve 
> protocol and VTEP first.
> Any further question, I may need to continue consulting you. :-)

OVN uses Geneve in conceptually the same way as to how the Neutron reference 
implementation (ML2+OVS) uses VxLAN to create overlay networks among the 
compute nodes for tenant overlay networks.

VTEP gateways or provider networks come into play when you want to connect 
these overlay networks to physical, or "underlay" networks.

Hope that helps,

--
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Kevin Benton]

Assuming it implements the normal provider networks API, you just specify
the segmentation_id when you create the network.

neutron net-create NET_NAME --provider:network_type vlan
--provider:physical_network physnet1 --provider:segmentation_id VLAN_TAG

On Sun, Sep 27, 2015 at 9:50 AM, WANG, Ming Hao (Tony T) <
tony.a.w...@alcatel-lucent.com> wrote:

> Russell,
>
> Another question is about "localnet". It is a very useful feature. :-)
>
> Is it possible to assign which VLAN tag will be used for a specific
> provider network?
> In your example in
> https://github.com/openvswitch/ovs/commit/c02819293d52f7ea7b714242d871b2b01f57f905
> : "physnet1" is used as physical network, and br-eth1 is used as the
> provider network OpenFlow switch.
> If we can assign the VLAN tag of the provider network, is the VLAN tag
> translation done by "br-int" or "br-eth1"?
>
>
> Thanks,
> Tony
>
> -Original Message-
> From: WANG, Ming Hao (Tony T)
> Sent: Sunday, September 27, 2015 2:26 PM
> To: 'Russell Bryant'; OpenStack Development Mailing List (not for usage
> questions)
> Subject: RE: [openstack-dev] [neutron + ovn] Does neutron ovn plugin
> support to setup multiple neutron networks for one container?
>
> Russell,
>
> Thanks for your valuable information.
> I understood Geneve is some kind of tunnel format for network
> virtualization encapsulation, just like VxLAN.
> But I'm still confused by the connection between Geneve and VTEP.
> I suppose VTEP should be on behalf of "VxLAN Tunnel Endpoint", which
> should be used for VxLAN only.
>
> Does it become some "common tunnel endpoint" in OVN, and can be also used
> as a tunnel endpoint for Geneve?
>
> Thanks,
> Tony
> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: Friday, September 25, 2015 12:04 AM
> To: WANG, Ming Hao (Tony T); OpenStack Development Mailing List (not for
> usage questions)
> Subject: Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin
> support to setup multiple neutron networks for one container?
>
> On 09/24/2015 10:37 AM, WANG, Ming Hao (Tony T) wrote:
> > Russell,
> >
> > Thanks for your detail explanation and kind help!
> > I have understand how container in VM can acquire network interfaces in
> different neutron networks now.
> > For the connections between compute nodes, I think I need to study
> Geneve protocol and VTEP first.
> > Any further question, I may need to continue consulting you. :-)
>
> OVN uses Geneve in conceptually the same way as to how the Neutron
> reference implementation (ML2+OVS) uses VxLAN to create overlay networks
> among the compute nodes for tenant overlay networks.
>
> VTEP gateways or provider networks come into play when you want to connect
> these overlay networks to physical, or "underlay" networks.
>
> Hope that helps,
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[WANG, Ming Hao (Tony T)]

Russell,

Thanks for your detail explanation and kind help!
I have understand how container in VM can acquire network interfaces in 
different neutron networks now.
For the connections between compute nodes, I think I need to study Geneve 
protocol and VTEP first.
Any further question, I may need to continue consulting you. :-) 

Thanks for your help again, 
Tony

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Wednesday, September 23, 2015 10:22 PM
To: OpenStack Development Mailing List (not for usage questions); WANG, Ming 
Hao (Tony T)
Subject: Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to 
setup multiple neutron networks for one container?

I'll reply to each of your 3 messages here:

On 09/23/2015 05:57 AM, WANG, Ming Hao (Tony T) wrote:
> Hi Russell,
> 
> I just realized OVN plugin is an independent plugin of OVS plugin.

Yes, it's a plugin developed in the "networking-ovn" project.

http://git.openstack.org/cgit/openstack/networking-ovn/

> In this case, how do we handle the provider network connections between 
> compute nodes? Is it handled by OVN actually?

I'm going to start by explaining the status of OVN itself, and then I'll come 
back and address the Neutron integration:

 -- OVN --

OVN implements logical networks as overlays using the Geneve protocol.
Connecting from logical to physical networks is done by one of two ways.

The first is using VTEP gateways.  This could be hardware or software gateways 
that implement the hardware_vtep schema.  This is typically a TOR switch that 
supports the vtep schema, but I believe someone is going to build a software 
version based on ovs and dpdk.  OVN includes a daemon called 
"ovn-controller-vtep" that is run for each vtep gateway to manage connectivity 
between OVN networks and the gateway.  It could run on the switch itself, or 
some other management host.  The last set of patches to get this working 
initially were merged just 8 days ago.

The ovn-architecture document describes "Life Cycle of a VTEP gateway":


https://github.com/openvswitch/ovs/blob/master/ovn/ovn-architecture.7.xml#L820

or you can find a temporary copy of a rendered version here:

  http://www.russellbryant.net/ovs-docs/ovn-architecture.7.pdf

The second is what Neutron refers to as "provider networks".  OVN does support 
this, as well.  It was merge just a couple weeks ago.  The commit message for 
OVN "localnet" ports goes into quite a bit of detail about how this works in 
OVN:


https://github.com/openvswitch/ovs/commit/c02819293d52f7ea7b714242d871b2b01f57f905

 -- Neutron --

Both of these things are freshly implemented in OVN so the Neutron integration 
is a WIP.

For vtep gateways, there's not an established API.  networking-l2gw is the 
closest thing, but I've got some concerns with both the API and implementation. 
 As a first baby step, we're just going to provide a hack that lets an admin 
create a connection between a network and gateway using a neutron port with a 
special binding:profile.  We'll also be continuing to look at providing a 
proper API.

For provider networks, working with them in Neutron will be no different than 
it is today with the current OVS support.  I just have to finish the Neutron 
plugin integration, which I just started on yesterday.

> 
> Thanks,
> Tony
> 
> -Original Message-
> From: WANG, Ming Hao (Tony T)
> Sent: Wednesday, September 23, 2015 1:58 PM
> To: WANG, Ming Hao (Tony T); 'OpenStack Development Mailing List (not for 
> usage questions)'
> Subject: RE: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support 
> to setup multiple neutron networks for one container?
> 
> Hi Russell,
> 
> Is there any material to explain how OVN parent port work?

Note that while this uses a binding:profile hack for now, we're going to update 
the plugin to support the vlan-aware-vms API for this use case once that is 
completed.

http://docs.openstack.org/developer/networking-ovn/containers.html

http://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html

https://github.com/openvswitch/ovs/blob/master/ovn/CONTAINERS.OpenStack.md

https://github.com/shettyg/ovn-docker

> Thanks,
> Tony
> 
> -Original Message-
> From: WANG, Ming Hao (Tony T)
> Sent: Wednesday, September 23, 2015 10:02 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [neutron] Does neutron ovn plugin support to 
> setup multiple neutron networks for one container?
> 
> Russell,
> 
> Thanks for your info.
> If I want to assign multiple interfaces to a container on different 
> neutron networks(for example, netA and netB), is it mandatory to let 
> the VM hosting containers have network interfaces in netA and netB, 
> and ovn will help to direct the container 

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 09/24/2015 10:37 AM, WANG, Ming Hao (Tony T) wrote:
> Russell,
> 
> Thanks for your detail explanation and kind help!
> I have understand how container in VM can acquire network interfaces in 
> different neutron networks now.
> For the connections between compute nodes, I think I need to study Geneve 
> protocol and VTEP first.
> Any further question, I may need to continue consulting you. :-) 

OVN uses Geneve in conceptually the same way as to how the Neutron
reference implementation (ML2+OVS) uses VxLAN to create overlay networks
among the compute nodes for tenant overlay networks.

VTEP gateways or provider networks come into play when you want to
connect these overlay networks to physical, or "underlay" networks.

Hope that helps,

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[WANG, Ming Hao (Tony T)]

Hi Russell,

I just realized OVN plugin is an independent plugin of OVS plugin.
In this case, how do we handle the provider network connections between compute 
nodes? Is it handled by OVN actually?

Thanks,
Tony 

-Original Message-
From: WANG, Ming Hao (Tony T) 
Sent: Wednesday, September 23, 2015 1:58 PM
To: WANG, Ming Hao (Tony T); 'OpenStack Development Mailing List (not for usage 
questions)'
Subject: RE: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to 
setup multiple neutron networks for one container?

Hi Russell,

Is there any material to explain how OVN parent port work?

Thanks,
Tony

-Original Message-
From: WANG, Ming Hao (Tony T) 
Sent: Wednesday, September 23, 2015 10:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron] Does neutron ovn plugin support to setup 
multiple neutron networks for one container?

Russell,

Thanks for your info.
If I want to assign multiple interfaces to a container on different neutron 
networks(for example, netA and netB), is it mandatory to let the VM hosting 
containers have network interfaces in netA and netB, and ovn will help to 
direct the container traffic to its corresponding VM network interfaces?

from https://github.com/openvswitch/ovs/blob/master/ovn/CONTAINERS.OpenStack.md 
:
"This VLAN tag is stripped out in the hypervisor by OVN."
I suppose when the traffic goes out the VM, the VLAN tag has already been 
stripped out. 
When the traffic arrives ovs on physical host, it will be tagged with neutron 
local vlan. Is it right?

Thanks in advance,
Tony

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Wednesday, September 23, 2015 12:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Does neutron ovn plugin support to setup 
multiple neutron networks for one container?

On 09/22/2015 08:08 AM, WANG, Ming Hao (Tony T) wrote:
> Dear all,
> 
> For neutron ovn plugin supports containers in one VM, My understanding is one 
> container can't be assigned two network interfaces in different neutron 
> networks. Is it right?
> The reason:
> 1. One host VM only has one network interface.
> 2. all the VLAN tags are stripped out when the packet goes out the VM.
> 
> If it is True, does neutron ovn plugin or ovn has plan to support this?

You should be able to assign multiple interfaces to a container on different 
networks.  The traffic for each interface will be tagged with a unique VLAN ID 
on its way in and out of the VM, the same way it is done for each container 
with a single interface.

--
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

I'll reply to each of your 3 messages here:

On 09/23/2015 05:57 AM, WANG, Ming Hao (Tony T) wrote:
> Hi Russell,
> 
> I just realized OVN plugin is an independent plugin of OVS plugin.

Yes, it's a plugin developed in the "networking-ovn" project.

http://git.openstack.org/cgit/openstack/networking-ovn/

> In this case, how do we handle the provider network connections between 
> compute nodes? Is it handled by OVN actually?

I'm going to start by explaining the status of OVN itself, and then I'll
come back and address the Neutron integration:

 -- OVN --

OVN implements logical networks as overlays using the Geneve protocol.
Connecting from logical to physical networks is done by one of two ways.

The first is using VTEP gateways.  This could be hardware or software
gateways that implement the hardware_vtep schema.  This is typically a
TOR switch that supports the vtep schema, but I believe someone is going
to build a software version based on ovs and dpdk.  OVN includes a
daemon called "ovn-controller-vtep" that is run for each vtep gateway to
manage connectivity between OVN networks and the gateway.  It could run
on the switch itself, or some other management host.  The last set of
patches to get this working initially were merged just 8 days ago.

The ovn-architecture document describes "Life Cycle of a VTEP gateway":


https://github.com/openvswitch/ovs/blob/master/ovn/ovn-architecture.7.xml#L820

or you can find a temporary copy of a rendered version here:

  http://www.russellbryant.net/ovs-docs/ovn-architecture.7.pdf

The second is what Neutron refers to as "provider networks".  OVN does
support this, as well.  It was merge just a couple weeks ago.  The
commit message for OVN "localnet" ports goes into quite a bit of detail
about how this works in OVN:


https://github.com/openvswitch/ovs/commit/c02819293d52f7ea7b714242d871b2b01f57f905

 -- Neutron --

Both of these things are freshly implemented in OVN so the Neutron
integration is a WIP.

For vtep gateways, there's not an established API.  networking-l2gw is
the closest thing, but I've got some concerns with both the API and
implementation.  As a first baby step, we're just going to provide a
hack that lets an admin create a connection between a network and
gateway using a neutron port with a special binding:profile.  We'll also
be continuing to look at providing a proper API.

For provider networks, working with them in Neutron will be no different
than it is today with the current OVS support.  I just have to finish
the Neutron plugin integration, which I just started on yesterday.

> 
> Thanks,
> Tony 
> 
> -Original Message-
> From: WANG, Ming Hao (Tony T) 
> Sent: Wednesday, September 23, 2015 1:58 PM
> To: WANG, Ming Hao (Tony T); 'OpenStack Development Mailing List (not for 
> usage questions)'
> Subject: RE: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support 
> to setup multiple neutron networks for one container?
> 
> Hi Russell,
> 
> Is there any material to explain how OVN parent port work?

Note that while this uses a binding:profile hack for now, we're going to
update the plugin to support the vlan-aware-vms API for this use case
once that is completed.

http://docs.openstack.org/developer/networking-ovn/containers.html

http://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html

https://github.com/openvswitch/ovs/blob/master/ovn/CONTAINERS.OpenStack.md

https://github.com/shettyg/ovn-docker

> Thanks,
> Tony
> 
> -Original Message-
> From: WANG, Ming Hao (Tony T) 
> Sent: Wednesday, September 23, 2015 10:02 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [neutron] Does neutron ovn plugin support to 
> setup multiple neutron networks for one container?
> 
> Russell,
> 
> Thanks for your info.
> If I want to assign multiple interfaces to a container on different
> neutron networks(for example, netA and netB), is it mandatory to let
> the VM hosting containers have network interfaces in netA and netB,
> and ovn will help to direct the container traffic to its
> corresponding VM network interfaces?
> 
> from 
> https://github.com/openvswitch/ovs/blob/master/ovn/CONTAINERS.OpenStack.md :
> "This VLAN tag is stripped out in the hypervisor by OVN."
> I suppose when the traffic goes out the VM, the VLAN tag has already been 
> stripped out. 
> When the traffic arrives ovs on physical host, it will be tagged with neutron 
> local vlan. Is it right?

Hopefully the links provided in response to the above mail help explain
it.  In short, the VM only needs one network interface and all traffic
for all containers go over that network interface.  To put each
container on different Neutron networks, the hypervisor needs to be able
to differentiat

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[WANG, Ming Hao (Tony T)]

Hi Russell,

Is there any material to explain how OVN parent port work?

Thanks,
Tony

-Original Message-
From: WANG, Ming Hao (Tony T) 
Sent: Wednesday, September 23, 2015 10:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron] Does neutron ovn plugin support to setup 
multiple neutron networks for one container?

Russell,

Thanks for your info.
If I want to assign multiple interfaces to a container on different neutron 
networks(for example, netA and netB), is it mandatory to let the VM hosting 
containers have network interfaces in netA and netB, and ovn will help to 
direct the container traffic to its corresponding VM network interfaces?

from https://github.com/openvswitch/ovs/blob/master/ovn/CONTAINERS.OpenStack.md 
:
"This VLAN tag is stripped out in the hypervisor by OVN."
I suppose when the traffic goes out the VM, the VLAN tag has already been 
stripped out. 
When the traffic arrives ovs on physical host, it will be tagged with neutron 
local vlan. Is it right?

Thanks in advance,
Tony

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Wednesday, September 23, 2015 12:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Does neutron ovn plugin support to setup 
multiple neutron networks for one container?

On 09/22/2015 08:08 AM, WANG, Ming Hao (Tony T) wrote:
> Dear all,
> 
> For neutron ovn plugin supports containers in one VM, My understanding is one 
> container can't be assigned two network interfaces in different neutron 
> networks. Is it right?
> The reason:
> 1. One host VM only has one network interface.
> 2. all the VLAN tags are stripped out when the packet goes out the VM.
> 
> If it is True, does neutron ovn plugin or ovn has plan to support this?

You should be able to assign multiple interfaces to a container on different 
networks.  The traffic for each interface will be tagged with a unique VLAN ID 
on its way in and out of the VM, the same way it is done for each container 
with a single interface.

--
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev