[Netslices] Some comments on draft-qiang-netslices-gap-analysis
Lou Berger <lberger@labn.net> Sun, 09 July 2017 19:08 UTC
Return-Path: <lberger@labn.net>
X-Original-To: netslices@ietfa.amsl.com
Delivered-To: netslices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52920129AA8 for <netslices@ietfa.amsl.com>; Sun, 9 Jul 2017 12:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level:
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 3CFreDAM1rFc for <netslices@ietfa.amsl.com>; Sun, 9 Jul 2017 12:08:18 -0700 (PDT)
Received: from gproxy9.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 1F9F6127869 for <netslices@ietf.org>; Sun, 9 Jul 2017 12:08:18 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 7B71A1E3918 for <netslices@ietf.org>; Sun, 9 Jul 2017 13:08:14 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id ij8A1v01A2SSUrH01j8Da9; Sun, 09 Jul 2017 13:08:14 -0600
X-Authority-Analysis: v=2.2 cv=eYdNR/MH c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=G3gG6ho9WtcA:10 a=GVf_a5JbartjgoGaiQ8A:9 a=tyIOtGQSBomoE-1j:21 a=1v1FbXoJxbTLr-7P:21 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:To:Subject:From:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4GHcv3DnL6FRV/0WiKs+mS2ZQDFstBykY5klxS44O2I=; b=H4j23NTb/iKYErUE9Bv8Mfp1dm RzLP6gcVk3uu2pLinkdjsFO2KW49rDbW0EUIMfnsIxp6mLU1qiP8IjjmgRMV+cbH2xhJ2hyvHW2Xj colYLw9ZZO3CJsl5Tz9hwF3dc;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:54476 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1dUHYw-002qRO-OU for netslices@ietf.org; Sun, 09 Jul 2017 13:08:10 -0600
From: Lou Berger <lberger@labn.net>
To: netslices@ietf.org
Message-ID: <abda1f7d-a27c-7324-bcea-ad66b9fcf0d8@labn.net>
Date: Sun, 09 Jul 2017 15:08:05 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dUHYw-002qRO-OU
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:54476
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/netslices/FnZRxxPQVqLLIi1YrN3vGhc0Kt0>
Subject: [Netslices] Some comments on draft-qiang-netslices-gap-analysis
X-BeenThere: netslices@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This list is intended for discussion and review of network slicing at IETF." <netslices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netslices>, <mailto:netslices-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netslices/>
List-Post: <mailto:netslices@ietf.org>
List-Help: <mailto:netslices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netslices>, <mailto:netslices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Jul 2017 19:08:19 -0000
Hi, With all they "excitement" on slicing I'm sure there is work to be done on the topic, but I think it would be good for such work to build on (and at worst, understand) the IETF technology/RFCs. In reading this draft, I really felt like the authors were not familiar with the substantive work that has been on TE networks over the years, notably: - Section 5.2 cross domain coordination There are many years of work and related RFCs in this area in IETF TE that are missing from the 'gap analysis' . I suggest reading RFC7926 as a good primer on existing RFCs as well as some background that predates the current TEAS ACTN work. - WRT Section 6.2.1 and 2.3 MPLS-TE solutions are broader than just signaling, i.e., routing is just as important. RCF7926 has sufficient pointers to good references for this. On a more specific note, this section is missing the intersection of VPNs and RSVP-TE and L3VPNs, see RFC 6882. Even more notably, the section is missing that TE LSPs can support the Guaranteed Quality of Service defined by RFC2212 (even if some vendors choose not to implement it), GS is defined as: Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queueing delays. This service makes it possible to provide a service that guarantees both delay and bandwidth. - Also, separately and in the context of Section 6.2.5 I think the 1st paragraph of correctly states that DetNet is concerned with "low packet loss rates, low packet delay variation (jitter) and assured maximum end-to-end delivery latency." (leveraging existing RFCs to the maximum extent possible.) But much of the rest of the section contradicts this and I really can't seem to parse the 2nd paragraph in any way that makes sense in the context of detnet or delivering low loss, low jitter and deterministic latency. Also, I suggest referencing 802.1TSN in the context or DetNet or independently. FWIW there is an 802.1 TSN tutorial scheduled for Sunday (1345-1445 in Congress Hall III) and we'll be spending some time in the DetNet WG session on understanding 802.1 TSN's flow requirements/capabilities and how to they might be leveraged (and support) by DetNet. - finally, WRT timing I'd think mentioned 1588 and other related time sync work in IETF could be relevant. Lou
- [Netslices] Some comments on draft-qiang-netslice… Lou Berger
- Re: [Netslices] Some comments on draft-qiang-nets… Daniele Ceccarelli
- Re: [Netslices] Some comments on draft-qiang-nets… Alex Galis
- Re: [Netslices] Some comments on draft-qiang-nets… Stewart Bryant
- Re: [Netslices] Some comments on draft-qiang-nets… Lou Berger
- Re: [Netslices] Some comments on draft-qiang-nets… Lou Berger
- Re: [Netslices] Some comments on draft-qiang-nets… Stewart Bryant
- Re: [Netslices] Some comments on draft-qiang-nets… Lou Berger
- Re: [Netslices] Some comments on draft-qiang-nets… Kiran.Makhijani
- Re: [Netslices] Some comments on draft-qiang-nets… qiangli (D)
- Re: [Netslices] Some comments on draft-qiang-nets… qiangli (D)
- Re: [Netslices] Some comments on draft-qiang-nets… Daniele Ceccarelli
- Re: [Netslices] Some comments on draft-qiang-nets… Daniele Ceccarelli