Chr=
istoph
Christoph Loibl <c@tix.at> =E5=86=99=E4=BA=8E 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-rfc557=
5bis/
> Section 7.6. Rules on Traffic Action Interfer=
ence
> 

> During writing this section we were actually discussing single 

> flowspec NLRIs with conflicting actions like:
> 

> rule 1
> =C2=A0 =C2=A0 traffic-rate: 10Mbps
> =C2=A0 =C2=A0 traffic-rate: 20Mbps
> 

> or
> 

> rule 1
> =C2=A0 =C2=A0redirect: A
> =C2=A0 =C2=A0redirect: 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 followi=
ng


> behaviour (this is nowhere written yet):
> 

> rule 1 

> 

> =C2=A0 =C2=A0traffic-rate: 10Mbps 

> 

> =C2=A0 =C2=A0traffic-marking: DSCP=3D10 

> 

> =C2=A0 =C2=A0traffic-action: T=3D1 S=3D1 


> 

> after this rule 2 gets applied
> 

> 

> rule 2 

> 

> =C2=A0 =C2=A0traffic-rate: 20Mbps 

> 

> =C2=A0 =C2=A0redirect: nexthop =3D 192.168.1.2 

> 

> =C2=A0 =C2=A0traffic-action: T=3D0 S=3D0 


> 

> The resulting action for that flow is:
> 

> =C2=A0 =C2=A0 traffic-rate: 20Mbps
> =C2=A0 =C2=A0 traffic-marking: DSCP=3D10
> =C2=A0 =C2=A0 redirect: nexthop =3D 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 trivi=
al.
> 

> Christoph
> 

> On 14 Dec 2016, at 09:59, zhang.zheng@zte.com.cn wrote:
> 

> 

> Hi all, 

> 

> =C2=A0 =C2=A0 About RFC5575, it seems like that the definition of
"Terminal 

> Action bit" is blurred. 

> 

> =C2=A0 =C2=A0 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).=C2=A0 If not set, the evaluation of the traffic
filter 

> stops when this rule is applied. 

> 

> =C2=A0 =C2=A0 How can routers do when many rules that define variant
actions 

> are applied to a same flow? 

> 

> =C2=A0 =C2=A0For 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 

> 

> =C2=A0 =C2=A0traffic-rate: 10Mbps 

> 

> =C2=A0 =C2=A0traffic-marking: DSCP=3D10 

> 

> =C2=A0 =C2=A0traffic-action: T=3D1 S=3D1 

> 

> 

> rule 2 

> 

> =C2=A0 =C2=A0traffic-rate: 20Mbps 

> 

> =C2=A0 =C2=A0redirect: nexthop =3D 192.168.1.2 

> 

> =C2=A0 =C2=A0traffic-action: T=3D0 S=3D0 

> 

> 

> rule 3 

> 

> =C2=A0 =C2=A0traffic-rate: 30Mbps 

> 

> =C2=A0 =C2=A0traffic-marking: DSCP=3D30 

> 

> =C2=A0 =C2=A0redirect: nexthop =3D 192.168.2.2 

> 

> =C2=A0 =C2=A0traffic-action: T=3D1 S=3D1 =C2=A0 

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 

> 

> rule 4 

> 

> =C2=A0 =C2=A0traffic-rate: 40Mbps 

> 

> =C2=A0 =C2=A0traffic-marking: DSCP=3D40 

> 

> =C2=A0 =C2=A0traffic-action: T=3D0 S=3D0 

> 

> _______________________________________________

> 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