Re: [Idr] One question about "Terminal Action bit" in RFC5575
Robert Raszuk <robert@raszuk.net> Thu, 15 December 2016 15:57 UTC
Return-Path: <rraszuk@gmail.com>
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 8D0751296CD; Thu, 15 Dec 2016 07:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RMeAxkffTngM; Thu, 15 Dec 2016 07:57:00 -0800 (PST)
Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08DB1296D5; Thu, 15 Dec 2016 07:56:59 -0800 (PST)
Received: by mail-qk0-x242.google.com with SMTP id t184so121409qkd.1; Thu, 15 Dec 2016 07:56:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OM0jTW6xo6/kztpqQa+xW9GSeqCMXiC84wV9Cz0b/yw=; b=HMwFvDO+WxAaTlw8oee4PaScaNS/RbC4f5KRL61Vm7G1bgtgLGJ8tBfJdHOPnAqTvC dI5WJgc9gj61+S/T0dLRsaq9mMlsWnfPT/oU2oEDeXfjQeI/B4I166DWVj7bw5pNtUr9 pLGNoMS2ZLD1viQlH61AP6FusC+DyZOdEkFD6/HYXiMF5N7RmVmyj/QXg56XWX99B4hM uq1GtOlxbKzlgkSjmCTbgorNyXCHMaCn7JX3oG84CgYZmP2iUf3qIZAM4wBoouEhX18x KLAH4vpJEHzrOfgjHAVzcUMOrxPN0SZ3PhKR0UjFKgFkq/B4k1CEcuHahMDHk5KtPsGI 7JmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OM0jTW6xo6/kztpqQa+xW9GSeqCMXiC84wV9Cz0b/yw=; b=dENagqF3plpbiRP5yr2FLwHqbh97UyLgjQSyzBp4Dc5h/+Q1y81jM4Am6gcivgwkzz i3ZPw76MTOxptO6sU8Q8LBfbSA0qLalmD0EgKrH1uJgDyREPtXK5S16tD0I7bxAlIOVg 4pj9AWXE5cLXglk9CV7G0CHCid/3U8U/hUQfXa0C0esCbEh43qMtXwC/yr25sCwKLgid ZXjI7S35jK6rU466s7d2Oh5OGer5lp6w1kMafy0i9TPs3vELaxMqnNjzmccl1Gia/ApW 6MhPXgO2GUq1Xr3F0KuQ9fVwUpqgLgh34FTf74R64sFTRYTURl4ucmS0Nuy0vgKAxVKl cJqQ==
X-Gm-Message-State: AIkVDXJiu09J8U5gpD3XG+3w47nd47kg3slwT/krDvXaaj0FyMgPzoctyMfHvElgxKaVq7JDcLWReahE/4Zw+Q==
X-Received: by 10.55.156.81 with SMTP id f78mr1810108qke.123.1481817418990; Thu, 15 Dec 2016 07:56:58 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Thu, 15 Dec 2016 07:56:58 -0800 (PST)
In-Reply-To: <OFD9436B83.1BA7CF11-ON4825808A.0032742A-4825808A.003488B4@zte.com.cn>
References: <5DB3C819-FEAE-48A7-A755-E1683E410D16@tix.at> <OFD9436B83.1BA7CF11-ON4825808A.0032742A-4825808A.003488B4@zte.com.cn>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 15 Dec 2016 16:56:58 +0100
X-Google-Sender-Auth: J7XLPDV3YdLhjagcScWfIKIeyGY
Message-ID: <CA+b+ERk8Jb6m_m9E5KfVS24Y8vYcP1foOHh6Nv_2Zzkx7OYvqQ@mail.gmail.com>
To: "zhang.zheng" <zhang.zheng@zte.com.cn>
Content-Type: multipart/alternative; boundary="94eb2c075ab4e187d50543b4800f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/HJhymtLu9DtPsUdTdCRQDIB3FH0>
Cc: zhu.xiaolong@zte.com.cn, idr wg <idr@ietf.org>, 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 15:57:04 -0000
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 >
- [Idr] Genart LC review: draft-ietf-idr-large-comm… Robert Sparks
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Job Snijders
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Robert Sparks
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Jakob Heitz (jheitz)
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Jakob Heitz (jheitz)
- Re: [Idr] One question about "Terminal Action bit… Christoph Loibl
- [Idr] One question about "Terminal Action bit" in… zhang.zheng
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Robert Sparks
- Re: [Idr] One question about "Terminal Action bit… zhang.zheng
- Re: [Idr] One question about "Terminal Action bit… Robert Raszuk
- Re: [Idr] One question about "Terminal Action bit… zhang.zheng
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Jari Arkko