[Idr] New Version Notification for draft-hr-idr-rfc5575bis-02.txt

Christoph Loibl <c@tix.at> Thu, 17 November 2016 19:14 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 1BC881294E8 for <idr@ietfa.amsl.com>; Thu, 17 Nov 2016 11:14:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 iysD4LLuVfMR for <idr@ietfa.amsl.com>; Thu, 17 Nov 2016 11:14:41 -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 B5157128DF6 for <idr@ietf.org>; Thu, 17 Nov 2016 11:14:41 -0800 (PST)
Received: from 80-110-123-236.cgn.dynamic.surfer.at ([80.110.123.236] helo=[192.168.67.254]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1c7S0A-0002Q8-Cv; Thu, 17 Nov 2016 20:05:39 +0100
From: Christoph Loibl <c@tix.at>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Message-Id: <F86B623E-CC10-43DF-ADB7-788145337F89@tix.at>
Date: Thu, 17 Nov 2016 20:14:37 +0100
To: idr wg <idr@ietf.org>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ldACPeRfFbA86wDr4Gn7ARtJle0>
Cc: Danny McPherson <dmcpherson@verisign.com>, Christoph Loibl <cl@tix.at>, Susan Hares <shares@ndzh.com>, Robert Raszuk <robert@raszuk.net>
Subject: [Idr] New Version Notification for draft-hr-idr-rfc5575bis-02.txt
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, 17 Nov 2016 19:14:44 -0000

Hi,

We submitted an updated version of our draft and are happy to receive feedback:

Name:		draft-hr-idr-rfc5575bis
Revision:	02
Title:		Dissemination of Flow Specification Rules
Document date:	2016-11-16
Group:		Individual Submission
Pages:		31
URL:            https://www.ietf.org/internet-drafts/draft-hr-idr-rfc5575bis-02.txt
Status:         https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/
Htmlized:       https://tools.ietf.org/html/draft-hr-idr-rfc5575bis-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-hr-idr-rfc5575bis-02

The draft is meant to replace RFC5575, to correct unclear specifications in the flow filter types, redefine (clarify) the traffic-redirect action and add a traffic-rate-packets action. It also provides originally missing rules for interfering traffic filtering actions and corrects many smaller errors found in RFC5575.

This is the output of may discussions regarding flow specification scaling, stability and of a multi-vendor interop test performed. We joined forces in order to address many/all of the issues found.

See the abstact below.

Christoph


Abstract:
  This document updates RFC5575 which defines a Border Gateway Protocol
  Network Layer Reachability Information (BGP NLRI) encoding format
  that can be used to distribute traffic flow specifications.  This
  allows the routing system to propagate information regarding more
  specific components of the traffic aggregate defined by an IP
  destination prefix.  This draft specifies IPv4 traffic flow
  specifications via a BGP NLRI which carries traffic flow
  specification filter, and an Extended community value which encodes
  actions a routing system can take if the packet matches the traffic
  flow filters.  The flow filters and the actions are processed in a
  fixed order.  Other drafts specify IPv6, MPLS addresses, L2VPN
  addresses, and NV03 encapsulation of IP addresses.

  This document updates RFC5575 to correct unclear specifications in
  the flow filters and to provide rules for actions which interfere
  (e.g. redirection of traffic and flow filtering).

  Applications which use the bgp flow specification are: 1) application
  which automate of inter-domain coordination of traffic filtering,
  such as what is required in order to mitigate (distributed) denial-
  of-service attacks; 2) application which control traffic filtering in
  the context of a BGP/MPLS VPN service, and 3) applications with
  centralized control of traffic in a SDN or NFV context.  Some of
  deployments of these three applications can be handled by the strict
  ordering of the BGP NLRI traffic flow filters, and the strict actions
  encoded in the Extended Community Flow Specification actions.


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