Open Stack

Hi Pino,

Please see inline.

Cathy

From: Giuseppe (Pino) de Candia [mailto:gdecandia at midokura.com]
Sent: Monday, November 02, 2015 10:22 PM
To: Cathy Zhang
Cc: Henry Fourie; OpenStack Development Mailing List (not for usage questions); Irena Berezovsky
Subject: Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

On Mon, Nov 2, 2015 at 9:56 PM, Cathy Zhang <Cathy.H.Zhang at huawei.com<mailto:Cathy.H.Zhang at huawei.com>> wrote:


From: Giuseppe (Pino) de Candia [mailto:gdecandia at midokura.com<mailto:gdecandia at midokura.com>]
Sent: Saturday, October 31, 2015 10:08 PM
To: Cathy Zhang
Cc: Henry Fourie; OpenStack Development Mailing List (not for usage questions); Irena Berezovsky
Subject: RE: [openstack-dev] [neutron][networking-sfc] API clarification questions

>
> 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?

Cathy> You can always modify the MAC which will work for both L2 and L3 service.
I don't think that works. For L3 services, the packet's destination MAC must be set equal to the service port's MAC. That means that all the original destination MACs get re-written to a single MAC.

In my L2 use-case, the VLAN is being used for signaling, and the VNF instance is shared across multiple tenants with overlapping IPs. Therefore, I use the MAC to identify the service chain instance and get a packet back on its original network path.

Cathy> Not sure why you use MAC to identify the service chain instance? It is better to use a separate chain ID for this purpose.

So, I won't modify the packet at all. Can you suggest another solution? And why so much resistance to adding a flag when we can actually show use-cases? Note that this is already actually running code today, using MidoNet's service chaining API.

Cathy> If you use a separate chainID, then you will not need a flag to handle the use cases. If you really need a flag, one way is to extend the SF parameter to specify a L2/L3 type.

thanks,
Pino


Thanks,

Cathy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151102/3420cd01/attachment.html>