[ovs-dev] 答复: Re: 答复: Re: [PATCH] ovn: Support for taas(tap-as-a-service) function

Ben Pfaff blp at ovn.org
Mon Aug 7 03:03:19 UTC 2017


I am having a very hard time understanding what you're writing here.
Russell's point makes sense to me, but I don't understand your response.
Can you give some examples?

On Mon, Aug 07, 2017 at 09:40:06AM +0800, wang.qianyu at zte.com.cn wrote:
> Not add new logical_mirror_switch, just use logical_switch of course can 
> capture the use case. But logical_switch pipeline is complex for flow 
> monitor. Flow monitor should ignore some tables such as port_security, lb 
> and so on. And also should consider normal function for normal ports. I 
> think add a new type of switch and the corresponding pipeline may be more 
> clear in logical.
> 
> Is there some adverse effect to add new type switch?
> 
> Thanks.
> 
> 
> 
> 
> Russell Bryant <russell at ovn.org>
> 2017/08/04 22:06
>  
>         收件人:        wang.qianyu at zte.com.cn, 
>         抄送:  Miguel Angel Ajo Pelayo <majopela at redhat.com>, ovs dev 
> <dev at openvswitch.org>, xurong00037997 <xu.rong at zte.com.cn>, 
> zhou.huijing at zte.com.cn
>         主题:  Re: 答复: Re: [ovs-dev] [PATCH] ovn: Support for 
> taas(tap-as-a-service) function
> 
> 
> 
> 
> On Thu, Aug 3, 2017 at 8:52 PM, <wang.qianyu at zte.com.cn> wrote:
> Miguel Ángel and Russell 
> 
> Thanks for your reviews. 
> 
> Current taas function just for port monitor, in this situation, we can 
> simplify the design by just add new port type. But we have the plane to 
> add flow_classifier to tap_flow to monitor special flows of given port. 
> The flow_classifier definition may like as follow: 
> 'flow_classifiers': { 
>         'id': {'allow_post': False, 'allow_put': False, 
>                'validate': {'type:uuid': None}, 'is_visible': True, 
>                'primary_key': True}, 
>         'tenant_id': {'allow_post': True, 'allow_put': False, 
>                       'validate': {'type:string': None}, 
>                       'required_by_policy': True, 'is_visible': True}, 
>         'name': {'allow_post': True, 'allow_put': True, 
>                  'validate': {'type:string': None}, 
>                  'is_visible': True, 'default': ''}, 
>         'description': {'allow_post': True, 'allow_put': True, 
>                         'validate': {'type:string': None}, 
>                         'is_visible': True, 'default': ''}, 
>         'protocol': {'allow_post': True, 'allow_put': True, 
>                      'validate': {'type:string': None}, 
>                      'is_visible': True, 'default': ''}, 
>         'src_port_range_min': {'allow_post': True, 'allow_put': True, 
>                                'convert_to': attr.convert_to_int, 
>                                'is_visible': True, 'default': 0}, 
>         'src_port_range_max': {'allow_post': True, 'allow_put': True, 
>                                'convert_to': attr.convert_to_int, 
>                                'is_visible': True, 'default': 0}, 
>         'dst_port_range_min': {'allow_post': True, 'allow_put': True, 
>                                'convert_to': attr.convert_to_int, 
>                                'is_visible': True, 'default': 0}, 
>         'dst_port_range_max': {'allow_post': True, 'allow_put': True, 
>                                'convert_to': attr.convert_to_int, 
>                                'is_visible': True, 'default': 0}, 
>         'src_ip_prefix': {'allow_post': True, 'allow_put': True, 
>                           'validate': {'type:subnet': 
> attr._validate_subnet}, 
>                           'is_visible': True, 'default': '0.0.0.0/0'}, 
>         'dst_ip_prefix': {'allow_post': True, 'allow_put': True, 
>                           'validate': {'type:subnet': 
> attr._validate_subnet}, 
>                           'is_visible': True, 'default': '0.0.0.0/0'} 
>     } 
> 
> This may need more complex pipeline. So I think add a new table and new 
> pipeline may be a easier way. 
> 
> Thanks for sharing the info on future capabilities.
> 
> We have a very flexible syntax for traffic classification in OVN.  It's 
> the logical flow match syntax (see logical flows in the southbound 
> database).  We expose this syntax in the northbound database in the 
> "match" column of the ACL table.
> 
> This would be another use case where we could use this syntax in the 
> northbound database.  Expanding on my preview proposal:
> 
>  - a new port type of 'mirror'
> 
>  - when port type=mirror, an option to identify which port is being 
> mirrored
> 
>  - (the new part) when port type=mirror, an option that may be used to 
> specify traffic classification for the subset of traffic on a port to 
> mirror, in "match" syntax
> 
> Do you think this captures the use case?
> 
> -- 
> Russell Bryant
> 
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev


More information about the dev mailing list