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