[ovs-discuss] [ovn4nfv]

Muralidharan Rangachari Muralidharan.Rangachari at huawei.com
Thu May 19 00:52:21 UTC 2016


John, thank you for quick review. I am up against some time here.
Sorry if I interrupted you :)

>> However I must be missing something fundamental as this looks
>> almost exactly like the current ACL schema with the addition
>> of a label, useful for deleting flows. 

Yes it is similar. I have been saying the schema would look like the 
one for ACL one. Not sure if we need some refactoring. I'll think about it
in my next iter. The flow_id is the external id (nsh or mpls or something
else - initially mpls tag) that CMS uses to identify/tag.

>> Are you thinking about adding custom match/action fields. If so then 
>> problem becomes hard as (I think ) they need to exist in OVS. 

Yes, the real issue is in custom match actions. Today I was able to
get the db stuff working, so next is to get the translations. Then
was looking at existing code - probably will ping someone for help.
It probably makes sense to use name value pairs. Initially I thought 
maybe I can just build the string outside for match & action. Probably 
it is a good idea to have it enumerated. Still investigating.

>> For example in mobile using GTP, OVS would have to understand the GTP 
>> protocol, for custom actions not quite sure what needs to be done. 
>> So if the real issue is adding custom match/actions I need to defer 
>> to the core OVS team.

Actually I am not planning anything around GTP right now. Just use the mpls 
tag that ovs already understands. It could get complicated later. However, I 
am looking if some translations to local geneve headers needed. Also see if
we can have a stateful ingress-egress flow defined -something I've been thinking.
Not sure whether we can stretch conn-track for that. Will be awesome if possible. 
It will obliterate requirement for service aware vnfs.

A broader question was will this be useful for anyone or even sfc api 
development? I have to get this done for my req - so will keep in my repo. If we 
find a broader use, we can plan merging.

-Murali




More information about the discuss mailing list