[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