[openstack-dev] [neutron][networking-sfc] API clarification questions
Giuseppe (Pino) de Candia
gdecandia at midokura.com
Sat Oct 31 13:08:28 UTC 2015
On Oct 28, 2015 19:17, "Russell Bryant" <rbryant at 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 <rbryant at redhat.com
> > <mailto:rbryant at 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
> > 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
> > the same Neutron network? That keeps things simple. If its
> > allow a chain of ports on different networks, is it just required
> > 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
> > 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
> > 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,
> > 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
> > 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
> 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
> > 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-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev