IETF Logo Mail Archive

Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

"Paul Quinn (paulq)" <paulq@cisco.com> Thu, 14 April 2016 17:03 UTC

Return-Path: <paulq@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9275612DB67 for <sfc@ietfa.amsl.com>; Thu, 14 Apr 2016 10:03:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 v8bS5qjvJ1g2 for <sfc@ietfa.amsl.com>; Thu, 14 Apr 2016 10:03:40 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E870B12D96F for <sfc@ietf.org>; Thu, 14 Apr 2016 10:03:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2209; q=dns/txt; s=iport; t=1460653419; x=1461863019; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vrPoOc0l6Vf2FdkOqYFfS+Aec7lEQNJ1hHdVwKeRFM4=; b=USU5q4Pxe2sOfbnQPfnHbll2q9lRzI4e1KiX6qiH88Me52RReXVjtSa8 U5Uc1foIgmZSQrcMGgkE1YetZDOgLYyGAG6+hPTJpxLnklFTp72BqB10a XiFiH3wDrKOsEjLnP6EAo8QlFzVEiDsAZiLIEBwXaTcahBOciy2u20UXp s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AMAgDYzA9X/5NdJa1egziBUAa6KQENgXGGDgKBPDgUAQEBAQEBAWUnhEEBAQEDAR0dPwUHBAIBCA4DBAEBAR4JBzIUCQgCBA4FiCEIwmwBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGBdYJWhD2DLYIrAQSHcIcUiQcBjgyBZ4ROiFuGIYkHAR4BAUKDZ2yISH4BAQE
X-IronPort-AV: E=Sophos;i="5.24,485,1454976000"; d="scan'208";a="260687867"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 17:03:39 +0000
Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3EH3dx8008225 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 17:03:39 GMT
Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 12:03:38 -0500
Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 12:03:38 -0500
From: "Paul Quinn (paulq)" <paulq@cisco.com>
To: Dave Dolson <ddolson@sandvine.com>
Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
Thread-Index: AQHRivfXi0m0zbDrFUiQMfrqrpCL9J+HIR6AgAADWICAAFnogIAAy/MAgAGYJgCAADqXAA==
Date: Thu, 14 Apr 2016 17:03:38 +0000
Message-ID: <0B2F4CF8-B94B-461F-92B2-ACC214D3E907@cisco.com>
References: <m3egarz7kh.wl-narten@us.ibm.com> <E8355113905631478EFF04F5AA706E9830F1BBAC@wtl-exchp-2.sandvine.com> <CDF2F015F4429F458815ED2A6C2B6B0B6D77F0B6@MBX021-W3-CA-2.exch021.domain.local> <14F8542B-9EE1-40DF-8DA2-E6E5048A16A3@cisco.com> <E8355113905631478EFF04F5AA706E9830F1D4A7@wtl-exchp-2.sandvine.com> <E8355113905631478EFF04F5AA706E9830F20863@wtl-exchp-2.sandvine.com>
In-Reply-To: <E8355113905631478EFF04F5AA706E9830F20863@wtl-exchp-2.sandvine.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.131.118.100]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EF1F82DA8216F746BE33456A41FFC383@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/sfc/SLWTtT4xBsG2G5wYTvWuz2RgDt4>
Cc: "uri.elzur@intel.com" <uri.elzur@intel.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 14 Apr 2016 17:03:41 -0000

Hi Dave,

Sorry, I was traveling yesterday.  In principal I don't have any issues with the text since it doesn't impose requirements but rather clarifies a possible behavior.

I do wonder about how common this will be: a control of sorts is needed for semantic meaning -- in type 1 or type 2 cases.

Paul

> On Apr 14, 2016, at 9:33 AM, Dave Dolson <ddolson@sandvine.com> wrote:
> 
> Paul and Uri, can you please comment as to whether you agree or disagree with this wording?
> 
> I feel that it allows the actual content to be opaque while giving guidance for
> service functions that create or replay packets in the chain.
> 
> From my point of view, this is how such devices will work anyhow.
> 
> -Dave
> 
> 
> 
> -----Original Message-----
> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
> Sent: Wednesday, April 13, 2016 9:13 AM
> To: Paul Quinn (paulq); Ron Parker
> Cc: Thomas Narten; sfc@ietf.org
> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
> 
> Paul,
> Are you unhappy with the metadata constraints I suggested below?
> Perhaps qualified by "In the absence of out-of-band configuration..." ?
> 
> I believe that the schemes proposed in these drafts satisfy the constraints:
> - draft-sfc-nsh-dc-allocation-4, 
> - draft-napper-sfc-nsh-broadband-allocation-00 
> 
> (I thought there were more allocation schemes, but I guess they expired.)
> 
> I'll update it here:
> 
>   In the absence of out-of-band configuration to indicate otherwise,
>   metadata used in NSH headers must meet the condition that
>   a transport-layer-stateful Service Function can save away
>   metadata values that it has witnessed.  An injected packet can
>   therefore be assigned a clone of metadata taken from an earlier
>   packet going in the same direction.  For example, a Service Function
>   can send a TCP packet using metadata cloned from another TCP packet
>   of the same connection and direction.
> 
>   Note that the Service Function need not know the meaning of the
>   metadata; it just needs to know it is safe to clone in this manner.
> 
> 
> -Dave
> 
>

v2.23.0 | Report a Bug | By Email