Open Stack

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
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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151031/331706bc/attachment.html>