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. > >
- [Tsv-art] Tsvart last call review of draft-ietf-s… Wesley Eddy
- Re: [Tsv-art] Tsvart last call review of draft-ie… Joe Touch
- Re: [Tsv-art] Tsvart last call review of draft-ie… Carlos Pignataro (cpignata)
- Re: [Tsv-art] Tsvart last call review of draft-ie… Mirja Kühlewind