IETF Logo Mail Archive

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

Sunil Vallamkonda <sunilvk@f5.com> Thu, 21 April 2016 18:45 UTC

Return-Path: <prvs=9127ea76a=sunilvk@f5.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 3914412DD77 for <sfc@ietfa.amsl.com>; Thu, 21 Apr 2016 11:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.017
X-Spam-Level:
X-Spam-Status: No, score=-8.017 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.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 LcFmE4IswrvI for <sfc@ietfa.amsl.com>; Thu, 21 Apr 2016 11:45:00 -0700 (PDT)
Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E2012DC64 for <sfc@ietf.org>; Thu, 21 Apr 2016 11:45:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1461264301; x=1492800301; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yw209tQV22wGG0JWs4ds4WHLyV9dCwib8/esN9sC02o=; b=Bl8RbnoQX/2X9RNAUi66IqvYwJAD+GJ58TIIQMD8C9MJBg6Rpo2eKZJR qU4iQCaHF9NqkW4zlQT4AwquUTAC0MONkP1wmdynbIlXVGnyRdjV2U7fg b0k2xqNNRlY30/RFx8LyxqUxtYQf5ahzAjJoVePLDU2wA72EXraiGCh2n s=;
X-IronPort-AV: E=Sophos;i="5.24,513,1454976000"; d="scan'208";a="215017457"
Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 21 Apr 2016 18:45:01 +0000
Received: from SEAEXCHMBX06.olympus.F5Net.com (192.168.15.49) by SEAEXCHMBX08.olympus.F5Net.com (192.168.15.227) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 21 Apr 2016 11:44:59 -0700
Received: from SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a]) by SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a%12]) with mapi id 15.00.1156.000; Thu, 21 Apr 2016 11:44:59 -0700
From: Sunil Vallamkonda <sunilvk@f5.com>
To: "Paul Quinn (paulq)" <paulq@cisco.com>, Dave Dolson <ddolson@sandvine.com>
Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
Thread-Index: AQHRivfiCTJ8b8qeo0249+QoeHMadZ+HQqWAgAADV4CAAFnsgIAAy/AAgAGYJgCAADqXAIAKpR0w
Date: Thu, 21 Apr 2016 18:44:59 +0000
Message-ID: <0bc0c81e19f24f16a4bacb0e896d291f@SEAEXCHMBX06.olympus.F5Net.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> <0B2F4CF8-B94B-461F-92B2-ACC214D3E907@cisco.com>
In-Reply-To: <0B2F4CF8-B94B-461F-92B2-ACC214D3E907@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.168.15.239]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/sfc/knYOn81rvrw3DFjbEOMFNXNLNE8>
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, 21 Apr 2016 18:45:02 -0000

Hi Paul,

Does MDType 1 need to be a MUST ?
If so, can Context header be customizable per implementation ?
Futher re: Sec.3.4, is there way for "Context Headers to carry no metadata MUST be set to zero", is it possible have a bit in header to indicate to ignore Context header for recipient to skip reading them ? 

Thanks,
Sunil.

-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, April 14, 2016 10:04 AM
To: Dave Dolson <ddolson@sandvine.com>
Cc: uri.elzur@intel.com; sfc@ietf.org
Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

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
> 
> 

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

v2.23.0 | Report a Bug | By Email