Open Stack

On Oct 29, 2015 08:37, "Cathy Zhang" <Cathy.H.Zhang at huawei.com> wrote:
>
> Hi Giuseppe,
>
>
>
> Please see inline,
>
>
>
> Regards,
>
> Cathy
>
>
>
> From: Giuseppe (Pino) de Candia [mailto:gdecandia at midokura.com]
> Sent: Wednesday, October 28, 2015 5:15 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Cathy Zhang; Henry Fourie; Irena Berezovsky
> Subject: Re: [openstack-dev] [neutron][networking-sfc] API clarification
questions
>
>
>
> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant <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.
>
>
>
> I hope there's no restriction on the location of the Neutron ports in a
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.
>
> - 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.
>
>
>
> Any thoughts on this?
>
>
>
> Cathy> No restriction as long as the ports are routable. Originally we
think we need to specify L2 and L3 service type. But later we found out it
is not needed if we program the switch to set the next hop destination to
the service function’s MAC. This way no matter whether it is L2 or L3, it
always works.
>

Hi Cathy, my understanding is that:
-for an L2 service, don't modify the packet (ignoring possible
encapsulation to signal policy )
-for an L3 service, set the dst MAC in the packet equal to the the service
port's MAC

How can the SDN implementation know which kind of service it's dealing with
to decide whether to modify the MAC?

Thanks,
Pino

>
>>
>>
>> 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.
>
>
>
> Cathy> Yes, that is the way to specify the flow classifier. Note that one
or more flow classifiers can be associated with the same chain.
>
>
>
> Our packet pipeline (for packets egressing the VM) is:
>
> Port Mirroring
> Service Chaining
> Filtering (Port Security, anti-spoofing, Security Groups)
>
>
>
> 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'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.
>
>
>
> Great topic, thanks!
>
>
>
> Cathy> I discussed briefly with Russell in yesterday’s Neutron design
session. If needed, we can meet in today’s Neutron NFV session.
>
>
>
> Thanks,
>
> Cathy
>
>
>
>
>
> Pino
>
>
>>
>>
>> --
>> 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/98064da8/attachment.html>