Re: [ovs-dev] SFC-Summary: MultiTenant
Hi Kyle/Russell, -Original Message- From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Kyle Mestery Sent: Tuesday, July 12, 2016 9:19 AM To: Russell Bryant Cc: dev@openvswitch.org; John McDowall Subject: Re: [ovs-dev] SFC-Summary: MultiTenant On Tue, Jul 12, 2016 at 9:52 AM, Russell Bryant wrote: > On Tue, Jun 28, 2016 at 12:05 PM, Ryan Moats wrote: > >> John McDowall wrote on 06/28/2016 >> 10:54:31 >> AM: >> >> > From: John McDowall >> > To: Ryan Moats/Omaha/IBM@IBMUS, Na Zhu >> > Cc: "dev@openvswitch.org" >> > Date: 06/28/2016 10:54 AM >> > Subject: Re: [ovs-dev] SFC-Summary: MultiTenant >> > >> > Ryan, >> > >> > Putting on my vendor hat for a minute or two…. >> > >> > The way we have solved this is our VNF supports multiple interfaces >> > (I.e. Multiple port-pairs) that can be partitioned into different >> > networks. So a single VNF can act in multiple tenant. I believe >> > most other vendors have similar solutions and perhaps other approaches. >> >> That's a way to do it, and it doesn't require OVN to know any more >> than what we are currently programming... >> >> > >> > How would you like a VNF to behave to support multi-tenancy? >> >> I've been trying to work out how to be multi-tenant at the VNF port >> level, and there's where I run into problems... >> > > I was thinking this could be handled with child / sub-ports. We do > this today for containers in VMs. We can have a single VIF for a VM > that is connected to multiple networks that are owned by separate > tenants. Some sort of encapsulation (VLAN ID, MPLS header, whatever) > would be used to differentiate the traffic for each networking in/out > of that VIF. I had started adding the ability to use MPLS for this in > my prototype for this reason, as that was what networking-sfc had defined. > This makes the assumption that the thing on the other end of the port (the VNF, I guess) is not only MPLS aware, but also "tenant to label" aware. How does that information (tenant to MPLS label) get passed to the VNF? Apologies if this is already handled somehow with the networking-sfc API. Cathy> From networking-sfc point of view, there is no need for the VNF to be MPLS or VLAN aware. A key point of using MPLS or "NSH in the future" is to simplify the OVS's SFC forwarding table, i.e. instead of forwarding based on the n-tuple of the packet, the OVS can forward the packet to the next VNF based on a simple "chain-ID" carried in the MPLS or NSH. But once the OVS figures out the egress port for the packet, the OVS can either forward the packet with the "chain-ID" if the VNF is MPLS/NSH aware or strips off the MPLS/NSH header from the packet and then forward it to the VNF if the VNF is the MPLS/NSH unaware. Cathy> Let's assume that this sub-port mechanism can be used to support multi-tenancy (we still need to test whether a VM created by Nova can support multi-tenancy or not since according to Nova API, a VM is only associated with one tenant). If the VNF will provide the same treatment for different tenants, then there is no need for the VNF to be tenant aware. But if the VNF needs to provide different treatment for different tenants, then VNF needs to be tenant aware or "tenant to label" aware as Kyle said. One way to support this latter case is to make the VNF be MPLS/NSH aware. That is, the chain-ID label can uniquely identify the tenant since each chain ID is associated with one tenant. Thanks, Cathy > -- > Russell Bryant > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] SFC-Summary: MultiTenant
Hi Kyle, -Original Message- From: Kyle Mestery [mailto:mest...@mestery.com] Sent: Wednesday, July 13, 2016 8:12 AM To: Cathy Zhang Cc: Russell Bryant; dev@openvswitch.org; John McDowall Subject: Re: [ovs-dev] SFC-Summary: MultiTenant > > Cathy> From networking-sfc point of view, there is no need for the VNF to be > MPLS or VLAN aware. A key point of using MPLS or "NSH in the future" is to > simplify the OVS's SFC forwarding table, i.e. instead of forwarding based on > the n-tuple of the packet, the OVS can forward the packet to the next VNF > based on a simple "chain-ID" carried in the MPLS or NSH. But once the OVS > figures out the egress port for the packet, the OVS can either forward the > packet with the "chain-ID" if the VNF is MPLS/NSH aware or strips off the > MPLS/NSH header from the packet and then forward it to the VNF if the VNF is > the MPLS/NSH unaware. > > Cathy> Let's assume that this sub-port mechanism can be used to support > multi-tenancy (we still need to test whether a VM created by Nova can support > multi-tenancy or not since according to Nova API, a VM is only associated > with one tenant). If the VNF will provide the same treatment for different > tenants, then there is no need for the VNF to be tenant aware. But if the VNF > needs to provide different treatment for different tenants, then VNF needs to > be tenant aware or "tenant to label" aware as Kyle said. One way to support > this latter case is to make the VNF be MPLS/NSH aware. That is, the chain-ID > label can uniquely identify the tenant since each chain ID is associated with > one tenant. > The "service VM / container" concept has been around since LBaaS V2 days, I recall pushing some code in 2014 to allow this by creating an "advsvc" user, which would allow for an admin user to create entities on behalf of tenants. Something similar may exist for nova, though I'm not sure. Your comment above about making the VNF chain-ID aware means some sort of orchestration needs to happen to pass "tenant to chain-ID" information to the VNF though, which isn't there today based on this thread. networking-sfc assumes chains and VNFs are per-tenant today, and not multi-tenant, is what I've gotten out of this thread. Cathy> In networking-sfc, a port chain is per tenant, but VNF could be shared if the VNF has multiple ports(sub-ports) although each Neutron port itself is per tenant based on Neutron API spec. [1] https://github.com/openstack/neutron/blob/master/etc/policy.json > Thanks, > Cathy > > >> -- >> Russell Bryant >> ___ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] SFC-Summary: MultiTenant
Hi Kyle, This is what I thought was going on. So basically, networking-sfc is currently not providing multi-tenancy for VNFs using the chain, and you need to build chains (and VNFs) per-tenant. Cathy> If the "VLAN-aware-VM" feature of Neutron allows sub-ports of a VM (i.e. the VNF) to be associated with different tenants, then networking-sfc API will transparently support multi-tenancy VNF. Each chain is per tenant, but a VNF with multiple sub-ports can be shared by multiple chains with each chain associated with one sub-port. Thanks, Cathy > On Tue, Jul 12, 2016 at 9:18 AM, Kyle Mestery wrote: >> >> On Tue, Jul 12, 2016 at 9:52 AM, Russell Bryant wrote: >> > On Tue, Jun 28, 2016 at 12:05 PM, Ryan Moats wrote: >> > >> >> John McDowall wrote on 06/28/2016 >> >> 10:54:31 >> >> AM: >> >> >> >> > From: John McDowall >> >> > To: Ryan Moats/Omaha/IBM@IBMUS, Na Zhu >> >> > Cc: "dev@openvswitch.org" >> >> > Date: 06/28/2016 10:54 AM >> >> > Subject: Re: [ovs-dev] SFC-Summary: MultiTenant >> >> > >> >> > Ryan, >> >> > >> >> > Putting on my vendor hat for a minute or two…. >> >> > >> >> > The way we have solved this is our VNF supports multiple >> >> > interfaces (I.e. Multiple port-pairs) that can be partitioned >> >> > into different networks. So a single VNF can act in multiple >> >> > tenant. I believe most other vendors have similar solutions and perhaps >> >> > other approaches. >> >> >> >> That's a way to do it, and it doesn't require OVN to know any more >> >> than what we are currently programming... >> >> >> >> > >> >> > How would you like a VNF to behave to support multi-tenancy? >> >> >> >> I've been trying to work out how to be multi-tenant at the VNF >> >> port level, and there's where I run into problems... >> >> >> > >> > I was thinking this could be handled with child / sub-ports. We do >> > this today for containers in VMs. We can have a single VIF for a >> > VM that is connected to multiple networks that are owned by >> > separate tenants. Some sort of encapsulation (VLAN ID, MPLS >> > header, whatever) would be used to differentiate the traffic for >> > each networking in/out of that VIF. I had started adding the >> > ability to use MPLS for this in my prototype for this reason, as that was >> > what networking-sfc had defined. >> > >> >> This makes the assumption that the thing on the other end of the port >> (the VNF, I guess) is not only MPLS aware, but also "tenant to label" >> aware. How does that information (tenant to MPLS label) get passed to >> the VNF? Apologies if this is already handled somehow with the >> networking-sfc API. >> >> > -- >> > Russell Bryant >> > ___ >> > dev mailing list >> > dev@openvswitch.org >> > http://openvswitch.org/mailman/listinfo/dev >> ___ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] SFC-Summary: MultiTenant
Hi Russell, To add on Farhad's point, with current neutron and nova, we cannot create a multi-tenant VNF. Currently, nova checks whether the neutron port belongs to the same tenant as the VM itself. You attach a network interface (neutron port) to a VM using nova interface-attach, if the port and the VM are in different tenants, an error is given. As to the sub-ports feature of Neutron, although it allows the sub-ports to associate with different networks, it seems these networks need to all belong to the same tenant according to vlan-aware-vms spec http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html. It is not clear whether it can work properly if these networks belong to different tenants. DO you know this? We may need to send an email to Neutron team for clarification on this. Thanks, Cathy -Original Message- From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Farhad Sunavala Sent: Tuesday, July 12, 2016 7:59 PM To: dev@openvswitch.org Subject: Re: [ovs-dev] SFC-Summary: MultiTenant >I was thinking this could be handled with child / sub-ports. We do >this today for containers in VMs. We can have a single VIF for a VM >that is connected to multiple networks that are owned by separate >tenants. Some sort of encapsulation (VLAN ID, MPLS header, whatever) >would be used to differentiate the traffic for each networking in/out >of that VIF. I had started adding the ability to use MPLS for this in >my prototype for this reason, as that was what networking-sfc had defined. I have a quick question on the above. (multi-tenancy).Yes, I know the containers can be in different networks of the same tenant.How does it work when the containers are in different tenants ? Below is the latest spec for vlan-aware-vms https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html The trick is to create neutron ports (for the subports) and then link them to the trunk port using neutron trunk-subport-add TRUNK \ PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \ [PORT,...] In the above command all the neutron ports (trunk ports and subports) must be in the same tenant.As far as I know, a tenant will not see neutron ports from another tenant. Or will this command allow neutron ports from different tenants to be attached ? E.g. VM "X" consists of containers C1 in Tenant 1 with portID = C1 (network dn1)container C2 in Tenant 2 with portID = C2 (network dn2)The trunk port of VM "X" is in tenant 100 with portID = T1 (network dt) The above command will be neutron trunk-subport-add T1 \ A vlan 1 \ B vlan 2 Is my understanding correct? thanks,Farhad. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] SFC-Summary: MultiTenant
Hi Russell, Please see inline. Thanks, Cathy From: Russell Bryant [mailto:russ...@ovn.org] Sent: Tuesday, July 19, 2016 6:51 AM To: Cathy Zhang Cc: Farhad Sunavala; dev@openvswitch.org; Russell Bryant; Kyle Mestery Subject: Re: [ovs-dev] SFC-Summary: MultiTenant Even putting the multi-tenant considerations aside, I think sub-ports (tagging or encapsulation) are valuable as a mechanism to differentiate between different chains (traffic matched with different classifiers). Cathy> Definitely. Using virtual sub-ports to differentiate different chains will greatly improve the OVS performance since this eliminates the need for re-classification at each hop. It also solves the problem caused by “some SF/VNF could change the 5-tuple or n-tuple fields of the packets that are used for chain flow classification”. Based on info from John of Palo Alto networks, their VNF is alreadt using different virtual ports to differentiate different chains. I agree that it's also complex that it requires coordination with the VNF - both with the vendors and a mechanism to coordinate with VNFs at runtime. Cathy> The correlation between the sub-port and the chain needs to be communicated to the OVS as well as to the VNF. Networking-sfc’s chain API already has this info and passes this info down to the driver and OVS. The same information can be passed to VNF Manager which in turn passes to VNF. But as you said, we need coordination with the VNF manager. Different vendors could have different VNF managers. We need some agreement there. I'd really like to understand better what people building VNFs are doing and what they want. So many SFC conversations feel like vendors trying to guess. I haven't actually talked to any users myself. I just want to build what people will actually use. :-) Cathy> There are many different types of VNFs. Some VNFs could have a need for passing of some metadata to the next hop VNF. I would also like to hear more use cases☺ On Wed, Jul 13, 2016 at 6:18 PM, Cathy Zhang mailto:cathy.h.zh...@huawei.com>> wrote: Hi Russell, To add on Farhad's point, with current neutron and nova, we cannot create a multi-tenant VNF. Currently, nova checks whether the neutron port belongs to the same tenant as the VM itself. You attach a network interface (neutron port) to a VM using nova interface-attach, if the port and the VM are in different tenants, an error is given. As to the sub-ports feature of Neutron, although it allows the sub-ports to associate with different networks, it seems these networks need to all belong to the same tenant according to vlan-aware-vms spec http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html. It is not clear whether it can work properly if these networks belong to different tenants. DO you know this? We may need to send an email to Neutron team for clarification on this. Thanks, Cathy -Original Message- From: dev [mailto:dev-boun...@openvswitch.org<mailto:dev-boun...@openvswitch.org>] On Behalf Of Farhad Sunavala Sent: Tuesday, July 12, 2016 7:59 PM To: dev@openvswitch.org<mailto:dev@openvswitch.org> Subject: Re: [ovs-dev] SFC-Summary: MultiTenant >I was thinking this could be handled with child / sub-ports. We do >this today for containers in VMs. We can have a single VIF for a VM >that is connected to multiple networks that are owned by separate >tenants. Some sort of encapsulation (VLAN ID, MPLS header, whatever) >would be used to differentiate the traffic for each networking in/out >of that VIF. I had started adding the ability to use MPLS for this in >my prototype for this reason, as that was what networking-sfc had defined. I have a quick question on the above. (multi-tenancy).Yes, I know the containers can be in different networks of the same tenant.How does it work when the containers are in different tenants ? Below is the latest spec for vlan-aware-vms https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html The trick is to create neutron ports (for the subports) and then link them to the trunk port using neutron trunk-subport-add TRUNK \ PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \ [PORT,...] In the above command all the neutron ports (trunk ports and subports) must be in the same tenant.As far as I know, a tenant will not see neutron ports from another tenant.Or will this command allow neutron ports from different tenants to be attached ? E.g. VM "X" consists of containers C1 in Tenant 1 with portID = C1 (network dn1)container C2 in Tenant 2 with portID = C2 (network dn2)The trunk port of VM "X" is in tenant 100 with portID = T1 (network dt) The above command will be neutron trunk-subport-add T1 \ A vlan 1 \ B vlan 2 Is my understanding correct? thanks,Farhad. ___ dev mai
Re: [ovs-dev] [RFC PATCH v2 00/13] Add Network Service Header Support
+1 on Jesse's points! I would like to see real support for MD type 2 on OVS. I believe many others would like to see type 2 support too. Thanks, Cathy -Original Message- From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Jesse Gross Sent: Wednesday, July 20, 2016 9:44 AM To: Paul Quinn (paulq) Cc: dev@openvswitch.org; Manuel Buil; Wei Su (Su); Jiri Benc; László Sürü; Thomas F Herbert; nick.tausanovi...@netronome.com Subject: Re: [ovs-dev] [RFC PATCH v2 00/13] Add Network Service Header Support On Wed, Jul 20, 2016 at 5:06 PM, Paul Quinn (paulq) wrote: > >> On Jul 14, 2016, at 11:39 AM, Jesse Gross wrote: >> >> On Wed, Jul 13, 2016 at 10:44 PM, Elzur, Uri wrote: >>> +1 on starting w MD Type = 1 >>> >>> Not sure I understand the concern expressed with " implementations that >>> don't implement TLVs will become deployed and then when there is a use for >>> them it's no longer possible." - why will it not be possible to add MD >>> Type=2 later? >> >> As I said, it's a classic problem with IP options. Classic enough >> that people frequently content that TLVs are not usable at all >> because they don't get implemented which then becomes a self fulfilling >> prophesy. >> > > Jesse, the issue with IPv4 options has nothing do the actual option(s) but > rather the "cost" associated with the handling, particularly in hardware, of > variable length packets. This is a cost vs. benefit tradeoff. I'm fairly certain that had options been an integral part of handling IP from the start, router vendors would have decided to handle them rather than not processing IP. However, since there was little benefit at that time, it was generally decided that it wasn't worth it and certainly nobody is going to bother doing it today because everybody knows that options are unusable since no one implements them. I think in general it is a pretty well known property that extensibility is a use it or lose it type of thing. TCP has options as well that directly resemble IP and they are available and implemented today because they are necessary for common functionality. I am aware that TCP is primarily implemented at the software layer and not hardware but as I think we can see from the discussion in this thread, trying to limit implementations to the minimum functionality that seems necessary at the time is not only applicable to silicon. >> I think I've been extremely clear on this matter. I also think that >> I've been extremely consistent - I think I've said the same thing on >> every review of this patch series, so it should not exactly be a >> surprise. However, the bottom line is I want to see a complete >> implementation of the protocol and not a half measure that will catch >> people by surprise or limit future usage. That seems 100% reasonable >> to me. > > The adopted NSH draft clearly states that type-1 support in mandatory, and > that type-2 support is optional. As such the OVS patches are compliant. > Having said that, the current code also supports skipping the type-2 based on > the length of NSH conveyed in the first word of the header. This, I believe, > constitutes support: type-2 NSH packets, if used, are supported: the type-2 > info is skipped and OVS functions as expected. > > It appears that your definition of support differs from that, can you expand > on it please? As I have said, I would like to see real support for MD type 2 so that it is useable in the future. I don't think that this patch set fulfills that criteria. At this point, I have not heard a technical argument as to why MD type 2 support shouldn't be implemented now. I have given my reason why it is important to do it and the only objection seems to be that the authors don't wish to take the time. Considering that the discussion of how to do it has continued in another thread (thank you Jan for helping to move things forward), it seems more productive to focus on that rather that continue this debate. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Does OVS 2.4 support MPLS over VXLAN?
Hi, We have been using OVS 2.3 in our SFC development and testing and it supports MPLS over VXLAN. Now when we switched to OVS 2.4, it seems MPLS over VXLAN does not work. We are not sure if it is due to that OVS2.4 does not support MPLS over VXLAN or it is due to our own code problem. Could someone let me know whether OVS 2.4 supports MPLS over VXLAN? Thanks, Cathy ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
