Re: [ovs-dev] 答复: Re: 答复: Re: 答复: Re: [PATCH] ovn: Support for taas(tap-as-a-service) function
You keep mentioning "a new type of switch". I don't understand this.
Who has proposed adding a new type of switch, and what kind of switch
would this be?
On Mon, Aug 07, 2017 at 01:37:52PM +0800, wang.qia...@zte.com.cn wrote:
> If we do not add a new type of switch, we should write flag to a reg to
> indicate the matched packets which are cloned to monitor.
>
> This reg should add to all the pipeline stages of logical switch(both
> ingress and egress) to distinguish from normal flow. Is this right for
> Russell's point?
>
> If we add a new type of switch, we could define a new pipeline like bellow
> for the monitor function, this have no influence on normal pipeline.
>
> /* Logical mirror switch ingress stages. */ \
> PIPELINE_STAGE(MSWITCH, IN, MIRROR_IN, 0, "lms_in_port") \
> PIPELINE_STAGE(MSWITCH, IN, FLOW_FILTER, 1, "lms_in_flow_filter")\
> PIPELINE_STAGE(MSWITCH, IN, OUT_LK, 2, "lms_in_out_lk") \
> \
> /* Logical mirror switch egress stages. */\
> PIPELINE_STAGE(MSWITCH, OUT, FLOW_FILTER, 0, "lms_out_flow_filter")\
> PIPELINE_STAGE(MSWITCH, OUT, DELIVERY,1, "lms_out_delivery")
>
> I think the new defined switch is easy to understand.
>
> Thanks
>
>
>
>
>
>
> Ben Pfaff <b...@ovn.org>
> 2017/08/07 11:03
>
> 收件人：wang.qia...@zte.com.cn,
> 抄送： Russell Bryant <russ...@ovn.org>, ovs dev
> <d...@openvswitch.org>, zhou.huij...@zte.com.cn, xurong00037997
> <xu.r...@zte.com.cn>, Miguel Angel Ajo Pelayo <majop...@redhat.com>
> 主题： Re: [ovs-dev] 答复: Re: 答复: Re: [PATCH] ovn: Support
> for taas(tap-as-a-service) function
>
>
> 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,
> >
Re: [ovs-dev] 答复: Re: 答复: Re: 答复: Re: [PATCH] ovn: Support for taas(tap-as-a-service) function
I think consuming a bit in reg to indicate if a packet is mirror packet or
regular packet is doable as well. And it is easy to implement.
Other table like port_security can check if it a mirror packet and do the
right actions(drop or forwarding to next table).
Thanks
Zhenyu Gao
2017-08-07 13:37 GMT+08:00 <wang.qia...@zte.com.cn>:
> If we do not add a new type of switch, we should write flag to a reg to
> indicate the matched packets which are cloned to monitor.
>
> This reg should add to all the pipeline stages of logical switch(both
> ingress and egress) to distinguish from normal flow. Is this right for
> Russell's point?
>
> If we add a new type of switch, we could define a new pipeline like bellow
> for the monitor function, this have no influence on normal pipeline.
>
> /* Logical mirror switch ingress stages. */ \
> PIPELINE_STAGE(MSWITCH, IN, MIRROR_IN, 0, "lms_in_port") \
> PIPELINE_STAGE(MSWITCH, IN, FLOW_FILTER, 1, "lms_in_flow_filter")\
> PIPELINE_STAGE(MSWITCH, IN, OUT_LK, 2, "lms_in_out_lk") \
> \
> /* Logical mirror switch egress stages. */\
> PIPELINE_STAGE(MSWITCH, OUT, FLOW_FILTER, 0, "lms_out_flow_filter")\
> PIPELINE_STAGE(MSWITCH, OUT, DELIVERY,1, "lms_out_delivery")
>
> I think the new defined switch is easy to understand.
>
> Thanks
>
>
>
>
>
>
> Ben Pfaff <b...@ovn.org>
> 2017/08/07 11:03
>
> 收件人：wang.qia...@zte.com.cn,
> 抄送： Russell Bryant <russ...@ovn.org>, ovs dev
> <d...@openvswitch.org>, zhou.huij...@zte.com.cn, xurong00037997
> <xu.r...@zte.com.cn>, Miguel Angel Ajo Pelayo <majop...@redhat.com>
> 主题： Re: [ovs-dev] 答复: Re: 答复: Re: [PATCH] ovn: Support
> for taas(tap-as-a-service) function
>
>
> 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_pu
[ovs-dev] 答复: Re: 答复: Re: 答复: Re: [PATCH] ovn: Support for taas(tap-as-a-service) function
If we do not add a new type of switch, we should write flag to a reg to
indicate the matched packets which are cloned to monitor.
This reg should add to all the pipeline stages of logical switch(both
ingress and egress) to distinguish from normal flow. Is this right for
Russell's point?
If we add a new type of switch, we could define a new pipeline like bellow
for the monitor function, this have no influence on normal pipeline.
/* Logical mirror switch ingress stages. */ \
PIPELINE_STAGE(MSWITCH, IN, MIRROR_IN, 0, "lms_in_port") \
PIPELINE_STAGE(MSWITCH, IN, FLOW_FILTER, 1, "lms_in_flow_filter")\
PIPELINE_STAGE(MSWITCH, IN, OUT_LK, 2, "lms_in_out_lk") \
\
/* Logical mirror switch egress stages. */\
PIPELINE_STAGE(MSWITCH, OUT, FLOW_FILTER, 0, "lms_out_flow_filter")\
PIPELINE_STAGE(MSWITCH, OUT, DELIVERY,1, "lms_out_delivery")
I think the new defined switch is easy to understand.
Thanks
Ben Pfaff <b...@ovn.org>
2017/08/07 11:03
收件人：wang.qia...@zte.com.cn,
抄送： Russell Bryant <russ...@ovn.org>, ovs dev
<d...@openvswitch.org>, zhou.huij...@zte.com.cn, xurong00037997
<xu.r...@zte.com.cn>, Miguel Angel Ajo Pelayo <majop...@redhat.com>
主题： Re: [ovs-dev] 答复: Re: 答复: Re: [PATCH] ovn: Support
for taas(tap-as-a-service) function
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,
>
