Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

"Acee Lindem (acee)" <acee@cisco.com> Tue, 15 March 2016 21:21 UTC

Return-Path: <acee@cisco.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 D586912DDA9 for <idr@ietfa.amsl.com>; Tue, 15 Mar 2016 14:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Aw4nSOFTDEgS for <idr@ietfa.amsl.com>; Tue, 15 Mar 2016 14:21:22 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919E012DDAF for <idr@ietf.org>; Tue, 15 Mar 2016 14:21:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32341; q=dns/txt; s=iport; t=1458076879; x=1459286479; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EvXW/WoBJWxzSZ2akPKkXbuj4FqkrnbZYZPW1xailY0=; b=P+N1Xk3E1bmR6A6dojtfQSxbtTQxJzp2riHhx7WZEb436rfkHh/eogdT Z2jGMf3BXHrwU1vQthSayj2mmc3fS2NaIgmLDOGo45H70ICo4/cXTpfej UL94UDlt9cEry7Yt7nViRma4eTOEIwSFi8tUVUDK/KdJcUErZwZIAxAwq 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CxBAAZfOhW/xbLJq1egnqBIG4GvEUXAQmFbAIcgW8BAQEBAQFlJ4RBAQEBBAEBARoGSwsQAgEIEQMBAiEDBAMCAgIlCxQJCAEBBAENBRQHiAwOrxuPUAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEiV5+hFsNglOBOgWXTwGFboJyhSCBZYRJiFeGCoh0AWKCMIE1aollfgEBAQ
X-IronPort-AV: E=Sophos;i="5.24,341,1454976000"; d="scan'208,217";a="636280409"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2016 21:21:17 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2FLLGNW011110 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 21:21:17 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 17:21:15 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Tue, 15 Mar 2016 17:21:16 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Gunter Van De Velde <guntervandeveldecc@icloud.com>, Susan Hares <shares@ndzh.com>
Thread-Topic: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt
Thread-Index: AdF3MOvE/JSvgLOkQ3a9MB8GleM7AQAjLYsAAdLWJYA=
Date: Tue, 15 Mar 2016 21:21:16 +0000
Message-ID: <D30DF3F7.514CC%acee@cisco.com>
References: <000b01d17731$29d17230$7d745690$@ndzh.com> <FD1977C9-4898-4E01-BC88-0A9B7F29C56B@icloud.com>
In-Reply-To: <FD1977C9-4898-4E01-BC88-0A9B7F29C56B@icloud.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: multipart/alternative; boundary="_000_D30DF3F7514CCaceeciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/2dVqVWoZtVI18lwl_426BU0WkNQ>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.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: Tue, 15 Mar 2016 21:21:28 -0000

I’ve listened the to the IDR Interim WebEx recording and my opinion is consistent with Gunter. I believe we should move forward with option 1 and not embark on option 2 until the requirements are clear AND we reach consensus that we want to use BGP Flow-Spec for SDN policy distribution.
Thanks,
Acee

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> on behalf of Gunter Van De Velde <guntervandeveldecc@icloud.com<mailto:guntervandeveldecc@icloud.com>>
Date: Sunday, March 6, 2016 at 4:34 AM
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>
Cc: IDR List <idr@ietf.org<mailto:idr@ietf.org>>
Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

My consern with the concept of BGP-FS version 2 is that it means jumping to solution space, even before having a rough agreement on the requirements and scope for a SDN policy distribution mechanism.
An additional concern is about using BGP for NFV management as there may be more appropriate mechanisms available (outside BGP).

If the intent is to truly use BGP as a mechanism to distribute SDN policies and and related management information, then what does that mean exactly? what does such protocol extension
expose as capabilities? What are the use-cases that drive the need for existence of such technology? In that case it may be better to construct a tailor designed BGP Policy Distribution framework version 1 (BGP-PD version 1)

I believe in keeping changes to RFC5575 to a minimum, and only extend to simple match/action capabilities that "drive indirection" and "network wide" rules.
I also believe that before trying to document a solution space for BGP based SDN policy distribution, that both the problem space and intended protocol properties exposed as consumable SDN API’s need to be discussed and agreed upon. In that light i feel that the concept of a BGP-FS version 2 is not the right approach.

G/







On 05 Mar 2016, at 23:48, Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> wrote:

The interim on 3/7/2016 will have a discussion of revisions to the BGP Flow specification (BGP-FS) to add more features.  There are two suggested options:
1)      A minimal features to existing BGP-FS (option 1)
Add a few new match filters to the BGP-FS NLRI and few new actions to the BGP-FS actions (in Extended communities).  Actions would need to be done in a defined order. Each new actions would need to define conflicts with existing actions.

Best use case:  DoS attack prevention

2)      Create a BGP-FS version 2 (option 2)
Create a new BGP-FS NLRI (v2) with a field that indicates the ordering of the BGP NLRI.  Add new BGP-FS actions with an order field in the BGP Wide Communities.  Filters are done in the order defined in the filter.  Actions are done in the order defined in the actions.   Order numbers that tie are handled in a defined order.

Best use case: SDN/NFV filter management

A write-up on the issues and proposed solutions is contained in:
draft-hares-idr-flowspec-combo-01.txt. <https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/>    The WG can select both option 1 and option 2.  This is a WG work item call for input to the chairs on the scope of the WG item.  In you discussion of this topics, the chairs would appreciate if you would indicate if you would support IDR working on option 1, option 2 or both option 1 and 2.  This WG call items also includes a call for draft-hares-idr-flowspec-combo-01.txt as a write-up of the work-item options.  The WG may wish to split this draft into multiple drafts.

The following drafts are being consider for either option:
1)      draft-eddy-idr-flowspec-packet-rate
2)      draft-hao-idr-flowspec-nv03
3)      draft-hao-idr-flowspec-label
4)      draft-liang-idr-bgp-flowspec-time
5)      draft-litowski-idr-flowspec-interfaceset
6)      draft-vandevelde-idr-flowspec-path-redirect
7)      draft-li-idr-flowspec-rpd-01.txt
8)      draft-wu-idr-flowspec-yang.cfg.

If you wish to comment on any of these drafts, we will

We will conclude the Call for WG opinions on 3/17/2016 so these authors can have a day to revise and submit their drafts before the draft deadline.

Sue Hares and John Scudder

PS:
draft-li-idr-flowspec-rpd discusses limits on the distribution of the policy which has been recast in draft-hares-idr-flowspec-combo as a bgp-wide community of Container type 1 with an atom of BGP Flow Specification ordering. However,  this draft is included in the list to be able to update the mechanism from this draft into that context.

The yang model for BGP Flow specification is also included in this work item as it will need to be modified based on the approaches.  The yang model is in draft-wu-idr-flowspec-yang-cfg.  In your comments, please indicate if you feel these drafts or other drafts.

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr