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