Open Stack

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.

> 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