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

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