Re: [Idr] Flowspec draft-ietf-idr-rfc5575bis last (known) issue that needs to be resolved

Christoph Loibl <c@tix.at> Thu, 14 February 2019 20:05 UTC

Return-Path: <c@tix.at>
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 38DDD131189 for <idr@ietfa.amsl.com>; Thu, 14 Feb 2019 12:05:29 -0800 (PST)
X-Quarantine-ID: <OP4qBaT2L0tR>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): X-Spam-Report: ...affic Action Interference\342\200\235: [...] \n\tCon[...]
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] 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 OP4qBaT2L0tR for <idr@ietfa.amsl.com>; Thu, 14 Feb 2019 12:05:27 -0800 (PST)
Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9FD12867A for <idr@ietf.org>; Thu, 14 Feb 2019 12:05:26 -0800 (PST)
Received: from 80-110-113-237.cgn.dynamic.surfer.at ([80.110.113.237] helo=[192.168.66.207]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1guNDL-0002or-38; Thu, 14 Feb 2019 21:02:32 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Christoph Loibl <c@tix.at>
In-Reply-To: <20190125223507.GA10088@pfrc.org>
Date: Thu, 14 Feb 2019 21:05:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <564B1465-427F-4D27-9153-ADC50EDA4F9E@tix.at>
References: <6FC8208F-DB08-4DE4-BFEB-518A806B11DB@tix.at> <20190125223507.GA10088@pfrc.org>
To: idr wg <idr@ietf.org>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bKBAfUZFDdeTxTfLEIASd7tG7Ps>
Subject: Re: [Idr] Flowspec draft-ietf-idr-rfc5575bis last (known) issue that needs to be resolved
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 14 Feb 2019 20:05:29 -0000

Hi Jeffrey, IDR

After reviewing the feedback that I received on my last mail regarding the draft rfc5575bis (on the list as well as from the authors and Jie). I propose the following changes to the draft regarding  "Section 7.6. Rules on Traffic Action Interference”:

*) Replace Section 7.6. Rules on Traffic Action Interference with the following:

<TEXT>

7.6. Considerations on Traffic Action Interference

Since traffic actions are represented as BGP extended community values,
traffic actions may interfere with each other (ie. there may be more then
one conflicting traffic-rate action associated with a single 
flow-filter). Traffic action interference has no impact on BGP propagation
of flow filters (all communities should be propagated according to BGP policies). 

If a flow filter associated with interfering flow actions is selected for
packet forwarding, it is a implementation decision which of the interfering 
traffic action is selected. Implementors of this specification SHOULD 
document the behaviour of their implementation in such cases.

Operators are encouraged to make use of the BGP policy framework 
supported by their implementation in order to achieve a predictable behaviour 
for their application (ie. match - replace - delete communities on 
administrative boundaries).

</TEXT>

I will upload the changes soon if I receive no objections. However, I am happy to receive feedback on this.

Christoph 

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at



> On 25.01.2019, at 23:35, Jeffrey Haas <jhaas@pfrc.org> wrote:
> 
>> *) Suggested solution B - only document the behaviour:
>> 
>> We can add to the operational consideration section that there may be
>> interfering traffic actions. FS filters with interfering actions shall
>> still be propagated but the actual selection of the appropriate actions is
>> up to the implementation. If a network/fs-domain wide predictable
>> behaviour is needed for an application this can still be achieved by using
>> custom BGP communities and BGP policies (plus rewriting those to the
>> appropriated actions).
>> 
>> This is very “lightweight” and I think that solution B may easily find
>> consensus. However the benefit over RFC5575 is only very little.
>> 
>> Any preferences how we should proceed?
> 
> I'd suggest B.
> 
> The text I would suggest would roughly say:
> Traffic actions are encoded as BGP extended communities.  Traffic actions,
> in many cases, are expected to only be encoded once.  For example, only a
> single valid traffic-rate-bytes extended community can be processed at a
> time.  Operators should take precautions to not introduce conflicting
> actions as a result of policy configuration.
> 
> ...
> 
> There may be some worth in adding a similar comment to implementors about
> having good policy mechanisms to make this job easy for operators.