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

zhang.zheng@zte.com.cn Wed, 14 December 2016 09:00 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 876B612952F for <idr@ietfa.amsl.com>; Wed, 14 Dec 2016 01:00:32 -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 SzUIWaScvQn1 for <idr@ietfa.amsl.com>; Wed, 14 Dec 2016 01:00: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 853831294FD for <idr@ietf.org>; Wed, 14 Dec 2016 01:00:30 -0800 (PST)
X-MAILFROM: <zhang.zheng@zte.com.cn>
X-RCPTTO: <idr@ietf.org>
X-FROMIP: 10.30.3.20
X-SEG-Scaned: 1
X-Received: unknown,10.30.3.20,20161214165828
Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 14 Dec 2016 08:58:28 -0000
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uBE8xrKh034413; Wed, 14 Dec 2016 16:59:53 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
In-Reply-To: <f4a5b4be6cb94663ae5c98b7780f122e@XCH-ALN-014.cisco.com>
To: "Idr" <idr-bounces@ietf.org>, robert@raszuk.net, idr@ietf.org
MIME-Version: 1.0
Sensitivity:
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF716322A9.48ACEC54-ON48258089.002B5092-48258089.00316E72@zte.com.cn>
From: zhang.zheng@zte.com.cn
Date: Wed, 14 Dec 2016 16:59:59 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-12-14 16:59:34, Serialize complete at 2016-12-14 16:59:34
Content-Type: multipart/alternative; boundary="=_alternative 00316E7048258089_="
X-MAIL: mse01.zte.com.cn uBE8xrKh034413
X-HQIP: 127.0.0.1
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/iAd-vOqq7ukyQssc2I8QufGtwq4>
Cc: zhu.xiaolong@zte.com.cn, shen.yiming@zte.com.cn, zhu.tong@zte.com.cn
Subject: [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: Wed, 14 Dec 2016 09:00:32 -0000

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