since the classifier will be defined in context of a tenant, it should get 
populated wherever an endpoint for the tenant is seen. So, 1st vm creation for 
that specific tenant on a node should be the trigger.

Thanks,
Daya

From: netvirt-dev-boun...@lists.opendaylight.org 
[mailto:netvirt-dev-boun...@lists.opendaylight.org] On Behalf Of Brady Allen 
Johnson
Sent: Thursday, December 15, 2016 12:19 PM
To: Manuel Buil <manuel.b...@ericsson.com>; netvirt-...@lists.opendaylight.org; 
sfc-dev@lists.opendaylight.org
Subject: Re: [netvirt-dev] Bug in netvirt - sfc


Netvirt devs,

Does Manuel's approach sound reasonable to the Netvirt community?

As Manuel mentioned, the Netvirt SFC classifier rules are only populated on 
compute nodes where there is a service function (hence where there is a SFF). 
So if we have a configuration where the client VM is on computeA and all the 
SFC entities (SFs and SFF) are on computeB, then there will be no 
classification rules on computeA, and the VM on computeA cant use SFC.

What do you think would be better?

  *   populate classification on every compute node
     *   this may not be possible if no VMs exist on some computes
  *   populate classification on every compute that has a VM
     *   the trigger would be VM creation

Thanks,

Brady

On 13/12/16 15:31, Manuel Buil wrote:
Hi guys,

While debugging some problems in SFC OPNFV, we found out that there is a 
special case where the current implementation of ODL does not work: if the 
client does not share the compute host with a SF. Observing netvirt code, it 
can be seen that it implements flows in the compute nodes which are part of the 
RenderedServicePathHopList, i.e. compute nodes which are considered SFFs. 
However, in the case I mentioned, the compute node where the client sits is not 
part of the RenderedServicePathHopList and therefore, the method 
NetvirtSfcWorkaroundOF13Provider.handleRenderedServicePath does nothing in that 
compute. As a consequence, the classification rules are not implemented in that 
compute node (the vxlan-gpe interface either).

Probably we should discuss how to fix this but one solution could be 
implementing the classifier rules and the vxlan-gpe port in all computes. This 
would be ok if the defined ACL just says for example the tcp port. However, if 
it also specifies information related to the traffic source (e.g. source IP, 
mac...) maybe there could be some logic so that the classifier is implemented 
in the corresponding compute host.

Any thoughts?

Thanks,
Manuel




_______________________________________________

netvirt-dev mailing list

netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>

https://lists.opendaylight.org/mailman/listinfo/netvirt-dev

_______________________________________________
sfc-dev mailing list
sfc-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

Reply via email to