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

Joe Touch <touch@strayalpha.com> Wed, 23 August 2017 03:27 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25767132376; Tue, 22 Aug 2017 20:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqMWJDnJKJVy; Tue, 22 Aug 2017 20:27:34 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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; d=strayalpha.com; 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 cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:58380 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <touch@strayalpha.com>) id 1dkMKI-003wY3-4k; Tue, 22 Aug 2017 23:27:33 -0400
To: Wesley Eddy <wes@mti-systems.com>, tsv-art@ietf.org
Cc: ietf@ietf.org, sfc@ietf.org, draft-ietf-sfc-nsh.all@ietf.org
References: <150342731718.6066.9872092086965343963@ietfa.amsl.com>
From: Joe Touch <touch@strayalpha.com>
Message-ID: <59162f72-fc2a-8303-e0d4-cf88f92704a1@strayalpha.com>
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: <150342731718.6066.9872092086965343963@ietfa.amsl.com>
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 - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/CsdWwR9B5_AB64D0eFl-KIE7_NA>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-sfc-nsh-19
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: 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).

Joe


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