Re: [sfc-dev] [netvirt-dev] Bug in netvirt - sfc

2016-12-15 Thread Sam Hague
On Dec 15, 2016 1:49 AM, "Brady Allen Johnson" <
brady.allen.john...@ericsson.com> wrote:

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

In the existing code it is easiest to just add all the flows to all nodes.
There is a main loop that goes through all hops and all nodes installing
flows. Just  expand that to include the extra nodes -  relax the sff check.
Big issue is that the gpe  vtep is installed by sfc so that needs to be
added. Other issue is we need a vm port as you mention. That won't happen
until there is a vm. I can't recall right now,  but the table 0/1 flows
check in_port and the classifier flows may not need the port. So we might
be OK. Otherwise,  we need to tie netvirt sfc into the vm creation flow.

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
listnetvirt-dev@lists.opendaylight.orghttps://lists.opendaylight.org/mailman/listinfo/netvirt-dev



___
netvirt-dev mailing list
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


Re: [sfc-dev] [netvirt-dev] Bug in netvirt - sfc

2016-12-14 Thread Brady Allen Johnson

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
 o this may not be possible if no VMs exist on some computes
 * populate classification on every compute that has a VM
 o 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
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