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

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/ <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 <https://datatracker.ietf.org/doc/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 <mailto:c@tix.at> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at <http://www.nextlayer.at/>