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.qia...@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 <russ...@ovn.org> > 2017/08/04 22:06 > > 收件人: wang.qia...@zte.com.cn, > 抄送: Miguel Angel Ajo Pelayo <majop...@redhat.com>, ovs dev > <d...@openvswitch.org>, xurong00037997 <xu.r...@zte.com.cn>, > zhou.huij...@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.qia...@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 > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev