Re: [Idr] One question about "Terminal Action bit" in RFC5575

Hi Robert,

    Thank you for your response. I understand the meaning of your 
example. But I am not known very clearly about where this function 
will be used. If we want to redirect one flow to one vrf, why don't 
we define the associated actions in the vrf’s rules? Once there is 
something wrong with one flow, it may be hard to find out the wrong 
rule, because many rules may influence the flow’s action, isn't it?

Thanks,
Sandy

rraszuk@gmail.com 写于 2016/12/15 23:56:58:

> Hi Sandy,
> 
> > 2, What’s the benefit of "Terminal Action bit"?
> 
> The meaning of this flag was to indicate requirement analogy of 
> "continue" statement when executing your traffic filtering actions 
> on the matched traffic. Example - you may want to redirect to a vrf 
> with or without remarking the traffic with different. Not really 
> much more to it.
> 
> Best regards,
> R. 
> 
> On Thu, Dec 15, 2016 at 10:34 AM, <zhang.zheng@zte.com.cn> wrote:
> 
> Hi Christoph, 
> 
>     Thank you very much for your response. Glad to hear that the RFC 
> will be revised Clearly. 
> 
>     From your specification, I have two questions for it: 
> 
> 1, If it is valid that define the same action with different 
> values in one same rule? 
> 
> 2, What’s the benefit of "Terminal Action bit"? I think that your 
> action merging may be one of the solutions. But the network manager 
> cannot get the result from the same rule directly. It may cause the 
> confusion of network manager, isn't it? 
> 
> Thanks, 
> Sandy 
> 
> Christoph Loibl <c@tix.at> 写于 2016/12/14 18:58:53:
> 
> > Hi, 
> > 
> > Your example perfectly makes sense to me, and I understand that 
> > there are several sections in RFC5575 that are a little unclear. 
> > RFC5575 does not explain what should happen in your case, nor does 
> > it explain anything in case of action-interference. 
> > 
> > This is why we currently working on a rfc557bis that should help us 
> > to fix those problems and improve interoperability for flowspec. 
> > Have a look at: 
> > 
> > https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/ 
> > Section 7.6. Rules on Traffic Action Interference 
> > 
> > During writing this section we were actually discussing single 
> > flowspec NLRIs with conflicting actions like: 
> > 
> > rule 1 
> >     traffic-rate: 10Mbps 
> >     traffic-rate: 20Mbps 
> > 
> > or 
> > 
> > rule 1 
> >    redirect: A 
> >    redirect: B 
> > 
> > I think we shall extend this section to also explain your case. 
> > Currently this is not explained even in our submitted draft draft-
> > hr-idr-rfc5575bis latest revision. In that case it may make sense to
> 
> > have a "latest" action wins behaviour. I suggest the following 
> > behaviour (this is nowhere written yet):
> 
> > 
> > Suggestion: In your example the action for a flow matching all your 
> > rules should be a merge of rule 1 and rule 2: 
> > 
> > rule 1 
> > 
> >    traffic-rate: 10Mbps 
> > 
> >    traffic-marking: DSCP=10 
> > 
> >    traffic-action: T=1 S=1 
> 
> > 
> > after this rule 2 gets applied 
> > 
> > 
> > rule 2 
> > 
> >    traffic-rate: 20Mbps 
> > 
> >    redirect: nexthop = 192.168.1.2 
> > 
> >    traffic-action: T=0 S=0 
> 
> > 
> > The resulting action for that flow is: 
> > 
> >     traffic-rate: 20Mbps 
> >     traffic-marking: DSCP=10 
> >     redirect: nexthop = 192.168.1.2 
> > 
> > Since on the second rule the terminal-bit is 0 there is no other 
> > rule to be evaluated. 
> > 
> > To the "latest" applied action wins. However this is only one 
> > suggested behaviour. There are plenty of other options. It should 
> > also be considered that implementing such a behaviour may not be 
trivial. 
> > 
> > Christoph 
> > 
> > On 14 Dec 2016, at 09:59, zhang.zheng@zte.com.cn wrote: 
> > 
> > 
> > Hi all, 
> > 
> >     About RFC5575, it seems like that the definition of "Terminal 
> > Action bit" is blurred. 
> > 
> >     In section 7, the "Terminal Action bit" is defined as follows: 
> > Terminal Action (bit 47): When this bit is set, the traffic filtering 
> > engine will apply any subsequent filtering rules (as defined by the 
> > ordering procedure).  If not set, the evaluation of the traffic filter 

> > stops when this rule is applied. 
> > 
> >     How can routers do when many rules that define variant actions 
> > are applied to a same flow? 
> > 
> >    For example, there are four rules that can be applied to one same 
flow. 
> > And the sequence has been determined as below. When router executes 
rule 1, 
> > the "Terminal Action Bit" is set. It indicated that next rule should 
be 
> > executed. When router execute rule 2, which action should be executed? 

> > Only redirect? Or/and traffic-marking? Which traffic-rate should be 
> > selected? 
> > 
> > rule 1 
> > 
> >    traffic-rate: 10Mbps 
> > 
> >    traffic-marking: DSCP=10 
> > 
> >    traffic-action: T=1 S=1 
> > 
> > 
> > rule 2 
> > 
> >    traffic-rate: 20Mbps 
> > 
> >    redirect: nexthop = 192.168.1.2 
> > 
> >    traffic-action: T=0 S=0 
> > 
> > 
> > rule 3 
> > 
> >    traffic-rate: 30Mbps 
> > 
> >    traffic-marking: DSCP=30 
> > 
> >    redirect: nexthop = 192.168.2.2 
> > 
> >    traffic-action: T=1 S=1   
> >                   
> > 
> > rule 4 
> > 
> >    traffic-rate: 40Mbps 
> > 
> >    traffic-marking: DSCP=40 
> > 
> >    traffic-action: T=0 S=0 
> > 
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr 
> > 
> > -- 
> > Christoph Loibl
> > c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at 