On Mon, Nov 2, 2015 at 9:56 PM, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
> > > > > *From:* Giuseppe (Pino) de Candia [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. 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 >
__________________________________________________________________________ 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