Hi Pino,

Please see inline.

Cathy

From: Giuseppe (Pino) de Candia [mailto:gdecan...@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.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:


From: Giuseppe (Pino) de Candia 
[mailto:gdecan...@midokura.com<mailto:gdecan...@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

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to