Open Stack

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

>
>
>
>
> *From:* Giuseppe (Pino) de Candia [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.

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.

thanks,
Pino


> Thanks,
>
> Cathy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151102/d75a097e/attachment.html>