Scope of strict SLA in network slicing

Greg Mirsky <gregimirsky@gmail.com> Thu, 16 November 2017 06:52 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC88F1294E8 for <rtgwg@ietfa.amsl.com>; Wed, 15 Nov 2017 22:52:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VJ2pRLSUoehs for <rtgwg@ietfa.amsl.com>; Wed, 15 Nov 2017 22:52:34 -0800 (PST)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452601293E0 for <rtgwg@ietf.org>; Wed, 15 Nov 2017 22:52:34 -0800 (PST)
Received: by mail-lf0-x236.google.com with SMTP id m1so12942665lfj.9 for <rtgwg@ietf.org>; Wed, 15 Nov 2017 22:52:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YhtSxWy33Lu8UPEBXwTMRvzxxUFjl6N/5QY4unqr+hk=; b=U2h5Losyk7qZhxGnRnKUPQw3BChezTGsOeVvwt1JIn2HMtO6YMwE9SQQ/uW2misktB 8FiesNDB0ISjmmjntdEAJj4Rs61WtSuEuCV3C4wBSnfcbtDCDrd+EBhAYDhX5tPFrxPP M2u6VpFTNHnaeEsXOKngR6j6VttzojbdeH7GnfIeW50+QzY7kE4ovP/dUTrnJmDp6pEZ zZKK9eMIM0rRbrR0T7nzbhDCct/gI73mdhzbic2zGmRW425y3FG1hRlnrGaHgR0de25b ueLp/gbGCm3x2AhGGPtV3tj9ctnl/mi/S2WHaZwBoRN9JNuZ5ado6C8Jx2EYjk5mF8aA BdyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YhtSxWy33Lu8UPEBXwTMRvzxxUFjl6N/5QY4unqr+hk=; b=F3epfFrZr0UPJ45tY46S4t46vKqvoUCO94yq3+yQBiYEHU8wwYH1eEge6vuOgYib0o G+E8iiAAlfBU3Aai6n8s3NxF2bDe3ZJZZooQZv0KiXk1FzyJMBjWGCSbhVDyTwsmBpwB Nmb+hedup/gYG4/OTWqUqPf6Dq7ZCfCApy1dRXKW7AVkosse8xTLy8nrR9YLA6m8+vsx OjrQVLQkw3xuxRMqsLvEKwDpsYDGQt48iQcF3/fWFzhg4A8ENIC3A9XrcM5oGYLZkrMi ygCeHgCVmlA2shD2e/4IhC4przg054hJLUd0Dw4cBfumh0Vn3dxX0bOeUWwl0QFQqqo4 Ltbg==
X-Gm-Message-State: AJaThX5jSFT5pp8rtDGOa4vLDz/Y/Hy+4FwPgRwanWyuLHUBsUFtI++b +fjsWgf3nqnfzGOzq8W8je/CZNsL030dENgcTNos2A==
X-Google-Smtp-Source: AGs4zMbidpNj7vdwFwRWVqWPl+YmW2jgoZb9H6l+coTcE8uavSmOilVKguJYLH2OPQLX+jKuElvRfUWo6jHTjHQTJEo=
X-Received: by 10.25.159.71 with SMTP id i68mr169612lfe.37.1510815152278; Wed, 15 Nov 2017 22:52:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.32.136 with HTTP; Wed, 15 Nov 2017 22:52:31 -0800 (PST)
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 16 Nov 2017 14:52:31 +0800
Message-ID: <CA+RyBmX7zgp3WgeMpov2=vbThWwDXs_XJJiGeyiaSKgrPpo0RA@mail.gmail.com>
Subject: Scope of strict SLA in network slicing
To: "rtgwg@ietf.org" <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="001a11401f6a791145055e141039"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/t2oaqPHFJqHnDNBd4wkjcDfaYzY>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2017 06:52:37 -0000

Dear All,
I'd like to stress what I've said at the mike. Two of three network slicing
scenarios, enhanced mobile broadband and massive IoT, that have been
defined by 3GPP do not set forth too strict latency/jitter/packet loss
constraints. But netslices to support ultra-reliable and low latency
communications (URLLC) are expected to have very stringent
latency/jitter/packet loss constraints e2e. But, in my opinion, there's no
requirement that URLLC slices must share physical resources. One of
solutions may use, for example, FlexE to deliver CBR guaranteed services.

Regards,
Greg