[sfc] Tsvart last call review of draft-ietf-sfc-nsh-19
Wesley Eddy <wes@mti-systems.com> Tue, 22 August 2017 18:41 UTC
Return-Path: <wes@mti-systems.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 38BF2132A12; Tue, 22 Aug 2017 11:41:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Wesley Eddy <wes@mti-systems.com>
To: tsv-art@ietf.org
Cc: ietf@ietf.org, sfc@ietf.org, draft-ietf-sfc-nsh.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.58.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150342731718.6066.9872092086965343963@ietfa.amsl.com>
Date: Tue, 22 Aug 2017 11:41:57 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/8o2qCGOCIBSRXF1Oj5iJRK5YiTQ>
Subject: [sfc] Tsvart last call review of draft-ietf-sfc-nsh-19
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, 22 Aug 2017 18:41:57 -0000
Reviewer: Wesley Eddy Review result: Not Ready In general, the document describes the NSH structure and some loose examples of how it might be used, but this isn't a very clear protocol specification. It's mostly just about NSH format and less on the expected behaviors of NSH speakers, how to maintain state of the NSH peers or other data structures, etc. It seems like there could easily be problems in interoperations between vendors coding solely based on the document. Section 5 on fragmentation considerations is nebulous and has technical issues. Specifically, it says that PMTUD should be used when NSH is encapsulated in IP. PMTUD requires ICMP to work, and has known issues when ICMP is blocked in the path. Is there a requirement is SFC networks running NSH that ICMP needs to be carried by the network? Further, there is no discussion here on PLPMTUD versus PMTUD, nor reference to the specific RFCs, algorithms, and options or configuration parameters suggested to do this properly in SFC systems. In Section 6, the assumptions, expectations, or hard requirements for mapping NSH onto an underlying "transport" are not very clear. Only examples are given, and some of these (e.g. Ethernet) are not capable of doing things like detecting fragmentation issues. Other examples (e.g. GRE) are tunnels where there may be more state. There is no discussion about whether there are assumptions about packet ordering/reordering, duplication, losses, corruption, etc. It isn't clear why the particular encapsulations discussed have been chosen rather than UDP or TCP-based options. There should probably be more discussion about what types of network paths NSH is suitable for and that the choice of an encapsulation for NSH needs to be appropriate to the underlying path between service entities. Some encapsulations will need to be tuned for the combination of path and offered load of traffic. Some can provide much more feedback to the NSH "layer" than others that are mainly open-loop. Propagation of errors through a service function chain or signaling of errors backwards on a chain seems like it bears further discussion.
- [sfc] Tsvart last call review of draft-ietf-sfc-n… Wesley Eddy
- Re: [sfc] Tsvart last call review of draft-ietf-s… Joe Touch
- Re: [sfc] Tsvart last call review of draft-ietf-s… Carlos Pignataro (cpignata)