[sfc] Opsdir last call review of draft-farrel-sfc-convent-05
Zitao Wang <wangzitao@huawei.com> Tue, 30 January 2018 00:15 UTC
Return-Path: <wangzitao@huawei.com>
X-Original-To: sfc@ietf.org
Delivered-To: sfc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 029BD12711A; Mon, 29 Jan 2018 16:15:39 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Zitao Wang <wangzitao@huawei.com>
To: ops-dir@ietf.org
Cc: draft-farrel-sfc-convent.all@ietf.org, ietf@ietf.org, sfc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.70.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151727133894.27336.11581082683338694561@ietfa.amsl.com>
Date: Mon, 29 Jan 2018 16:15:39 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/2wYVpy1HfxVQhUEsreyP7sMi20w>
Subject: [sfc] Opsdir last call review of draft-farrel-sfc-convent-05
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 30 Jan 2018 00:15:39 -0000
Reviewer: Zitao Wang Review result: Ready I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed:draft-farrel-sfc-convent-05 Summary: This document describes the use of the Network Service Header (NSH) in a Service Function Chaining (SFC) enabled network with no payload data and carrying only metadata. This is achieved by defining a new NSH "Next Protocol" type value of "None". This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes. It is expected that other documents will describe specific use cases in more detail and will define the protocol mechanics for each use case. Major issue: None Minor issue: Suggest adding a termnology section to introduce the abbreviations which be used in this document, such as SFP, NSH, SF, SFI, etc.