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

zhang.zheng@zte.com.cn Fri, 16 December 2016 08:25 UTC

Return-Path: <zhang.zheng@zte.com.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A9C129568 for <idr@ietfa.amsl.com>; Fri, 16 Dec 2016 00:25:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.096
X-Spam-Level:
X-Spam-Status: No, score=-107.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByRUqORPLpya for <idr@ietfa.amsl.com>; Fri, 16 Dec 2016 00:25:31 -0800 (PST)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E7F261294DF for <idr@ietf.org>; Fri, 16 Dec 2016 00:25:30 -0800 (PST)
X-MAILFROM: <zhang.zheng@zte.com.cn>
X-RCPTTO: <rraszuk@gmail.com>
X-FROMIP: 10.30.3.20
X-SEG-Scaned: 1
X-Received: unknown,10.30.3.20,20161216162403
Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 16 Dec 2016 08:24:03 -0000
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uBG8P1C4044310; Fri, 16 Dec 2016 16:25:01 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
In-Reply-To: <CA+b+ERk8Jb6m_m9E5KfVS24Y8vYcP1foOHh6Nv_2Zzkx7OYvqQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFCE474E4F.507BC2C5-ON4825808B.002C95B8-4825808B.002E3CCC@zte.com.cn>
From: zhang.zheng@zte.com.cn
Date: Fri, 16 Dec 2016 16:25:34 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-12-16 16:25:01, Serialize complete at 2016-12-16 16:25:01
Content-Type: multipart/alternative; boundary="=_alternative 002E3CC94825808B_="
X-MAIL: mse01.zte.com.cn uBG8P1C4044310
X-HQIP: 127.0.0.1
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/a0bNT4TsYDmn70rQtgmk2PUORyU>
Cc: zhu.xiaolong@zte.com.cn, idr wg <idr@ietf.org>, shen.yiming@zte.com.cn, rraszuk@gmail.com, Idr <idr-bounces@ietf.org>, zhu.tong@zte.com.cn
Subject: Re: [Idr] One question about "Terminal Action bit" in RFC5575
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2016 08:25:35 -0000

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