IETF Logo Mail Archive

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

Sumandra Majee <S.Majee@F5.com> Wed, 13 April 2016 22:52 UTC

Return-Path: <prvs=904b2bfe1=S.Majee@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 7824612E1F3 for <sfc@ietfa.amsl.com>; Wed, 13 Apr 2016 15:52:59 -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 bvPo2BA_BLfy for <sfc@ietfa.amsl.com>; Wed, 13 Apr 2016 15:52:57 -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 4990812E1F0 for <sfc@ietf.org>; Wed, 13 Apr 2016 15:52:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1460587978; x=1492123978; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=OQSje9reGrQOY6FtyVpYDdlGrpWVl4TwppIPhJ04Y5w=; b=ezRVVkxUyeI9z5OGFGfcARgnz/J0ENHABXr+VevXJMurSJXjz3zfEFJC OuMPePmmkzKP6Qrh5sr+JhZQgd/Qw57X9ZUTA5qm1IFWEmKILQ8wfb5Av aGfgO5IevbuvA8jDlodiXc+2dMUSnaQT/H+1Jpy/bKTKFC+DF5o87IblT k=;
X-IronPort-AV: E=Sophos;i="5.24,481,1454976000"; d="scan'208";a="212841750"
Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP; 13 Apr 2016 22:52:57 +0000
Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by SEAEXCHMBX07.olympus.F5Net.com (192.168.15.50) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Wed, 13 Apr 2016 15:52:56 -0700
Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1156.000; Wed, 13 Apr 2016 15:52:56 -0700
From: Sumandra Majee <S.Majee@F5.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
Thread-Index: AQHRivfiB6+8DFWMK0eTkw1/L1AdMJ+IWo4AgAB+fAD//79zAA==
Date: Wed, 13 Apr 2016 22:52:56 +0000
Message-ID: <D33418AB.4FF2A%s.majee@f5.com>
References: <m3egarz7kh.wl-narten@us.ibm.com> <D333E2BE.4FEC1%s.majee@f5.com> <CDF2F015F4429F458815ED2A6C2B6B0B6D77FCF8@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B6D77FCF8@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.4.150722
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.168.15.239]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <9199FE1188351E4AA18F113E1EEF8898@F5.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/sfc/5thE4HgmHrMbOoU2tjPAmfuCzOE>
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: Wed, 13 Apr 2016 22:52:59 -0000

Inline

On 4/13/16, 12:43 PM, "Ron Parker" <Ron_Parker@affirmednetworks.com> wrote:

>Sumandra,
>
>I don't object to the scratchpad nature of the MD-type-1 metadata.   But
>I have a small reservation and a large reservation around other aspects
>of it:
>
>* small reservation -- why call this 4 context headers of 4 bytes each?
>It would be much more intuitive to call it a 16 byte scratch pad.   The
>former implies structure that is present, at best, in an
>implementation-specific manner.
[SM] If you are suggesting that it be called as 16 byte context
information, yes sure I don’t have any objection.
>
>* large reservation -- since this is a scratch pad, it does not seem
>justifiable to make it mandatory.
[SM]  To me MD=1 means LEN = 24B and there is 16B context header that has
some relevant information for one or more SF in the chain. Many flow based
engines like LB, Firewall, various proxy based optimizers etc. do save
states. In that case if we want to carry only the forwarding part of NSH
then why not use MD type=2 with LEN=0.
>
>My objections would be removed if it were a 16-byte scratchpad that was
>optional. 
>
>Thanks.
>
>   Ron
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee
>Sent: Wednesday, April 13, 2016 3:11 PM
>To: Thomas Narten <narten@us.ibm.com>; sfc@ietf.org
>Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
>
>Thomas,
>
>I do support the adoption of this draft.
>
>The overriding concern seems to be that for MD type 1 the semantics of
>context header is not standardized, and my view is that it is GOOD that
>this draft considers context info area to be a scratchpad.
>
>A) I don¹t think neither DC allocation and mobility allocation of context
>headers will satisfy all cases. Our implementation uses context header
>scratchpad to put some different information.
>
>B) Standardizing context header too early also has a higher chance of not
>meeting the actual implementation need. This is a new technology that
>doesn¹t have much milage.
>
>C) YES interoperability is an issue. And I would like to see the
>allocation draft(s) reserve 3/4 bits to specify the allocation
>type/schema itself. I would like to see a context header registry for MD
>type 1 allocation itself. However that can be addressed separately in the
>allocation draft(s).
>
>Sumandra
>
>
>On 3/30/16, 7:48 PM, "sfc on behalf of Thomas Narten"
><sfc-bounces@ietf.org on behalf of narten@us.ibm.com> wrote:
>
>>Dear WG:
>>
>>This note begins a WG last call on draft-ietf-sfc-nsh-04.txt
>>(https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/).
>>
>>The editors of the NSH document have indicated that they have addressed
>>all known comments and that there are no open issues with the current
>>version of the document.
>>
>>Substantive comments to the list please, editorial comments can go
>>directly to the document editors.
>>
>>We'll also get a brief update from the editors at next week's meeting.
>>If there are any remaining issues with the document, raising them
>>before the meeting would be especially helpful.
>>
>>For the chairs,
>>Thomas
>>
>>_______________________________________________
>>sfc mailing list
>>sfc@ietf.org
>>https://www.ietf.org/mailman/listinfo/sfc
>
>_______________________________________________
>sfc mailing list
>sfc@ietf.org
>https://www.ietf.org/mailman/listinfo/sfc

v2.23.0 | Report a Bug | By Email