[Tsv-art] 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: tsv-art@ietf.org
Delivered-To: tsv-art@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/tsv-art/tL6OjMCpe2p4cHFrmm2EdMWrvnE>
Subject: [Tsv-art] Tsvart last call review of draft-ietf-sfc-nsh-19
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-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.