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
