IETF Logo Mail Archive

Re: [sfc] Mail regarding draft-quinn-sfc-problem-statement

"Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com> Thu, 06 March 2014 16:45 UTC

Return-Path: <wim.henderickx@alcatel-lucent.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CAF1A00EC for <sfc@ietfa.amsl.com>; Thu, 6 Mar 2014 08:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 FN0QCSVW2Xgd for <sfc@ietfa.amsl.com>; Thu, 6 Mar 2014 08:45:00 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id DF93C1A00AA for <sfc@ietf.org>; Thu, 6 Mar 2014 08:44:59 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s26GiqVI019340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Mar 2014 10:44:54 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s26Giprs008795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 17:44:52 +0100
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.10]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 6 Mar 2014 17:44:51 +0100
From: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, sfc <sfc@ietf.org>
Thread-Topic: [sfc] Mail regarding draft-quinn-sfc-problem-statement
Thread-Index: AQHPOJIO0/NvL3RLrEKcgK4AVpxdX5rUNNiA
Date: Thu, 06 Mar 2014 16:44:50 +0000
Message-ID: <CF3E5502.B4D3D%wim.henderickx@alcatel-lucent.com>
References: <CF3CBD9E.168A8%jguichar@cisco.com>
In-Reply-To: <CF3CBD9E.168A8%jguichar@cisco.com>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_CF3E5502B4D3Dwimhenderickxalcatellucentcom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/M-C2SRCBe84_YlEEAlcCgGeFhaI
Subject: Re: [sfc] Mail regarding draft-quinn-sfc-problem-statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 16:45:02 -0000

Jim my comment is to be more explicit in the problem statement and define more concretly why meta-data is required. Here are some reasons why meta-data might be used to convey policy information. This list is not complete.

  1.  Outband signalling might be to slow
  2.  Outband signalling might not scale to convey this information
  3.  Allows to correlate IPv4/IPv6 flows of a subscriber in-band
  4.  Allows to convey profile/policy information


From: "Jim Guichard (jguichar)" <jguichar@cisco.com<mailto:jguichar@cisco.com>>
Date: Wednesday 5 March 2014 16:43
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<mailto:wim.henderickx@alcatel-lucent.com>>, sfc <sfc@ietf.org<mailto:sfc@ietf.org>>
Subject: Re: [sfc] Mail regarding draft-quinn-sfc-problem-statement

Hi Wim,

Could you be more specific in what you would like to see called out in the problem statement and any potential text that you feel is missing? Right now I see that in section 3 (bullet point 4) of the problem statement we have the follow text:

"In addition to sharing of information, the use of metadata addresses several of the issues raised in section 2, most notably the de-coupling of policy from the topology, and the need for per-service classification (and re-classification)".

Does this not capture what you are asking for?

From: <Henderickx>, "Wim (Wim)" <wim.henderickx@alcatel-lucent.com<mailto:wim.henderickx@alcatel-lucent.com>>
Date: Monday, March 3, 2014 at 4:28 AM
To: sfc <sfc@ietf.org<mailto:sfc@ietf.org>>
Subject: [sfc] Mail regarding draft-quinn-sfc-problem-statement

With respect to the problem statement I see a lot of discussions to use the meta-data header to convey information with respect to policies, etc to service fucntions.
If it is a problem we want to tackle in SFC we should also capture this in draft-quinn-sfc-problem-statement.

v2.23.0 | Report a Bug | By Email