Re: [Tsv-art] Tsvart last call review of draft-ietf-sfc-nsh-19

Joe Touch <> Wed, 23 August 2017 03:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25767132376; Tue, 22 Aug 2017 20:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MqMWJDnJKJVy; Tue, 22 Aug 2017 20:27:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14AB71328D9; Tue, 22 Aug 2017 20:27:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=a505qSeO/ciUDkKwwEI3RFOrhbVekcBHLK4gMuQsqsU=; b=Ir0JMIE8xyj6nlKe8tUthlp83m Hkmul9UZdF5YeBTGIAjHrRb8eSjayd1jnajseRYBYIFwo0dTSkywFyXkHZi/LWCW0cggzchCkScHp LMZ6g8Q/CGrgKe0jm+QIFgnE8lSJzHXzH+F/pby+WZjvITHud0cxvuk652OuosMXr3pXeWt0dKCCo 6NeGns7OZDV2J4F0mfQmbiwO5dKNp2WozoHuYcJdMmgK+fNfFQVQPeUefHGFZX2CxYS0+jiS5zxQ9 iHT8W3XcGxPtmxpQ2aZPmykAYQA1wSR/lYMkCLWZ6k9KszdtfdCkfwbVYkKEctHb5XVib0G5bNztK PUoX/usg==;
Received: from ([]:58380 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <>) id 1dkMKI-003wY3-4k; Tue, 22 Aug 2017 23:27:33 -0400
To: Wesley Eddy <>,
References: <>
From: Joe Touch <>
Message-ID: <>
Date: Tue, 22 Aug 2017 20:27:28 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-sfc-nsh-19
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Aug 2017 03:27:36 -0000

FWIW, this doc would benefit from consideration of the terminology
developed for draft-ietf-intarea-tunnels

In particular, the issue of the differences between the MTU of a hop,
path, and edge-to-edge (e.g., the last including receiver reassembly).


On 8/22/2017 11:41 AM, Wesley Eddy wrote:
> 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.