On Oct 28, 2015 19:17, "Russell Bryant" <rbry...@redhat.com> wrote: > > On 10/28/2015 05:14 PM, Giuseppe (Pino) de Candia wrote: > > On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant <rbry...@redhat.com > > <mailto:rbry...@redhat.com>> wrote: > > > > I read through the proposed SFC API here: > > > > http://docs.openstack.org/developer/networking-sfc/api.html > > > > I'm looking at implementing what would be required to support this API > > in OVN. I have a prototype, but I had to make some pretty big > > assumptions, so I wanted to clarify the intent of the API. > > > > First, does it assume that all of the neutron ports in a chain are on > > the same Neutron network? That keeps things simple. If its intended to > > allow a chain of ports on different networks, is it just required that > > you pick ports that all have addresses routable from one port to the > > next in the chain? An arbitrary set of ports can't always work, so > > there has to be some bounds around what set of ports are valid to be in > > a chain. > > > > > > Hi Russell, > > > > We have similarly been experimenting with a MidoNet implementation of > > the SFC API. > > Great! It's nice to have multiple people looking at this with different > implementations in mind. That should help us shake out these sorts of > issues before the API is too locked down. Thanks for jumping in. :-) > > > I hope there's no restriction on the location of the Neutron ports in a > > chain. > > Yes, that makes sense. Cathy's response seems to support that there > isn't a limitation. We do need to clearly define it in the API > reference though. Maybe something like ... > > All ports must: > * be owned by the tenant. > * have IP addresses such that the address of port N+1 in the chain > is routable from port N in the chain.
I guess you're just brainstorming... But I hope we don't adopt the second restriction. > > > In terms of addresses, I believe the API is lacking (or we use a > > chain_parameter?) a way to indicate the service insertion model: > > - L2 - The service can accept packets sent from any MAC (service NIC in > > promiscuous mode). The MAC address may be used to identify where the > > packet came from before it entered the chain. > > If the ports in the chain don't have to all be on the same L2 network, > then it doesn't seem like you could use the source MAC address to know > where the packet came from before it entered the chain. > > > - L3 - The service expects packets to be routed to it. So the > > destination MAC of the packet must be set to the service's NIC's MAC. > > This seems to make more sense to me. You've got the "coorelation chain > parameter" to know what chain the packet is in, and you use the source > IP address to know where the packet came from originally before it > entered the chain. > > > > > > > > > Second, where is it expected that the match is applied? The API for > > creating a port chain doesn't associate the chain with a network, but > > just matching "globally" doesn't make any sense. If all ports are > > expected to be on the same network, is the match applied for any traffic > > entering that network from any port? > > > > > > Here's what we were thinking for MidoNet: > > > > use the logical_source_port in the flow classifier: when we render the > > SFC API in MidoNet's models we will associate the chain with the source > > port. > > > > Our packet pipeline (for packets egressing the VM) is: > > > > 1. Port Mirroring > > 2. Service Chaining > > 3. Filtering (Port Security, anti-spoofing, Security Groups) > > OK, so it sounds like you're applying the "flow classifier" to packets > as the come from a neutron port and enter a neutron network. That makes > sense. > > Which ports' traffic do you apply the flow classifier to? That's the > key piece I'm missing. > > If the flow classifier includes a logical-source-port match, then it's > easy. You only check traffic from a specific Neutron port. The same > seems to apply if you only specified a logical-destination port, since > in that case you'd be matching on traffic ingressing the VM. > > If tenant A creates the port chain and both logical-source-port and > logical-destination-port are not specified, then what packets do you > apply the flow classifier to? > > > > > > > Do you think we can standardise on a single order in all > > implementations? We'd be happy to change the order if it makes sense. > > I think we do need to standardize where we can, yes. We want the > resulting network behavior from the end user perspective to be as close > as possible to the same thing regardless of backend. > > > I'm in Tokyo this week, so if the group working on this would like to > > talk in person, that would be great too. > > > > > > I'd love to be included. > > OK, it's probably best that we try to keep it on the mailing list as > much as possible. I really don't want to exclude anyone, and it's > important that this stuff is written down anyway. > > There is an "NFV foundation elements" design summit session where I > think networking-sfc is going to be discussed, but unfortunately I have > a regular conference talk at the same time. > > > Great topic, thanks! > > Thanks for jumping in! > > -- > 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
