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

zhang.zheng@zte.com.cn Thu, 15 December 2016 09:34 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 2B393129B33 for <idr@ietfa.amsl.com>; Thu, 15 Dec 2016 01:34:05 -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=unavailable 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 XwQ9RMHmC9xm for <idr@ietfa.amsl.com>; Thu, 15 Dec 2016 01:34:01 -0800 (PST)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id C61F9129C58 for <idr@ietf.org>; Thu, 15 Dec 2016 01:34:00 -0800 (PST)
X-MAILFROM: <zhang.zheng@zte.com.cn>
X-RCPTTO: <idr@ietf.org>
X-FROMIP: 192.168.168.120
X-SEG-Scaned: 1
X-Received: unknown,192.168.168.120,20161215173242
Received: from unknown (HELO out1.zte.com.cn) (192.168.168.120) by localhost with SMTP; 15 Dec 2016 09:32:42 -0000
X-MAILFROM: <zhang.zheng@zte.com.cn>
X-RCPTTO: <robert@raszuk.net>
X-FROMIP: 10.30.3.20
X-SEG-Scaned: 1
X-Received: unknown,10.30.3.20,20161215172936
Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 15 Dec 2016 09:29:36 -0000
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uBF9Xj7b092636; Thu, 15 Dec 2016 17:33:45 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
In-Reply-To: <5DB3C819-FEAE-48A7-A755-E1683E410D16@tix.at>
To: Christoph Loibl <c@tix.at>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFD9436B83.1BA7CF11-ON4825808A.0032742A-4825808A.003488B4@zte.com.cn>
From: zhang.zheng@zte.com.cn
Date: Thu, 15 Dec 2016 17:34:21 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-12-15 17:33:45, Serialize complete at 2016-12-15 17:33:45
Content-Type: multipart/alternative; boundary="=_alternative 003488B24825808A_="
X-MAIL: mse01.zte.com.cn uBF9Xj7b092636
X-HQIP: 127.0.0.1
X-HQIP: 127.0.0.1
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/7nIR38yF5kVnjxQoZHP0JAc7m_E>
Cc: zhu.xiaolong@zte.com.cn, idr@ietf.org, robert@raszuk.net, shen.yiming@zte.com.cn, 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: Thu, 15 Dec 2016 09:34:05 -0000

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