Re: [Teas-ns-dt] Definitions draft review
Xufeng Liu <xufeng.liu.ietf@gmail.com> Thu, 06 February 2020 02:45 UTC
Return-Path: <xufeng.liu.ietf@gmail.com>
X-Original-To: teas-ns-dt@ietfa.amsl.com
Delivered-To: teas-ns-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 88669120127
for <teas-ns-dt@ietfa.amsl.com>; Wed, 5 Feb 2020 18:45:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
URIBL_BLOCKED=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 jcCfDCk4KFlU for <teas-ns-dt@ietfa.amsl.com>;
Wed, 5 Feb 2020 18:45:06 -0800 (PST)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com
[IPv6:2607:f8b0:4864:20::d2a])
(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 68976120072
for <teas-ns-dt@ietf.org>; Wed, 5 Feb 2020 18:45:06 -0800 (PST)
Received: by mail-io1-xd2a.google.com with SMTP id k24so4636031ioc.4
for <teas-ns-dt@ietf.org>; Wed, 05 Feb 2020 18:45:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=n3i6yBuSDCsn5fsJSf05TuJJpyty/M5hlCe/yWxHes4=;
b=Z0g3SmHtlY0e9CgePo9AGpThG8dIjVRqVSD1cTkFMkcehRoq8yvU9MupWOo0apkHn+
KHTfqTFhuDeCFv5txYGv9W9ns1qEA8LvbGkSlbk5Xe7KOfEnYogAyt3nkzdHaR2j3bwf
s9llEY2aFU40z+Klmr81Z2yRhQDUEz9EQIMK+O7Auq9jmEFVG76VKop7CwH2zJzSbw4R
DKnKJ45XkrsHf5z34rsPyQfHb/RghjFfOO1H1u39ysiZkZZP+mA7IEx/FTB2dxRqqfZA
XrgrFMV3ZYrNAvh5KAv1zjM03fzVyrinqGQ8rqoYITAde8Hd7BpECJSPjs8J2RpWjaKr
gXQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=n3i6yBuSDCsn5fsJSf05TuJJpyty/M5hlCe/yWxHes4=;
b=L7+Vt7Xdery+hbH5nrI7p30FvUnd5xob1LrUBG73JzHWkj2qMUbSly5hf8oTMxpaso
vOUU9gS5QLgbAA7hsgCO2CqcxE/0o22zkCVE+IlCIcdQe4EedHBJSqCn/r9QIk/ZT4rC
8dkSmlFDKdEheRWgU1pklNaU/kZsNiTr74I83Kf5B4SMHkRD/bcCkJ0+2DysI5JG4/F+
OlxXnKGMNNrgYqa8cGVHxvq7qUzVMJz2eD7ND6rOFU2f1GCsJE71h3UEY0zAqnaheTHS
4tClTRlnppev14DXr0uAoqjAdCSjhwE8talvMtRqfWGmwMpaSQz2ydbQ1KhwWRsWs+Dr
E+1w==
X-Gm-Message-State: APjAAAV7MIcMj8rNF6vRQulylZ2nqtlwA75qD0avYvXyse0Rs3z4X51m
C07Jm4EL/fu/cVPwrFr+vUlnYqYpYiNLAvSaDJbMwEqCkOM=
X-Google-Smtp-Source: APXvYqzlv3iidmf46pdMitJedFtR4Z9MbaJNAjSSbWzTIv6CYjEvIsiIaD4eL2dqV5pA94h0P2R7uTYo74N5/21LFR8=
X-Received: by 2002:a5e:8a03:: with SMTP id d3mr31343066iok.269.1580957105596;
Wed, 05 Feb 2020 18:45:05 -0800 (PST)
MIME-Version: 1.0
References: <0D8BB404-3988-424D-82A9-2F5EAD203B9E@ericsson.com>
<CAGU6MPe6FOpxz_0xf5N+UTpnO-7zn6-C4yFfYiSTXa5Kt7a1rw@mail.gmail.com>
<9698b55c9ccb4aa78557e637ae5ff11d@huawei.com>
<CAGU6MPfHrM3AGPq4nKkrmrXS1JBTWtpJVRdfCH4R+4QqpJuHQA@mail.gmail.com>
In-Reply-To: <CAGU6MPfHrM3AGPq4nKkrmrXS1JBTWtpJVRdfCH4R+4QqpJuHQA@mail.gmail.com>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Wed, 5 Feb 2020 21:44:54 -0500
Message-ID: <CAEz6PPQmj92sQpy5ZtTWinS-y3xMW4wPb=K5X+UAsjd7p3cjgg@mail.gmail.com>
To: Shunsuke Homma <s.homma0718@gmail.com>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>,
Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org>,
"teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000af2d9c059ddf42d8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/AVaq3pRfp9mtWFT7GRy47BL80S8>
Subject: Re: [Teas-ns-dt] Definitions draft review
X-BeenThere: teas-ns-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TEAS Network Slicing Design Team <teas-ns-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas-ns-dt>,
<mailto:teas-ns-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas-ns-dt/>
List-Post: <mailto:teas-ns-dt@ietf.org>
List-Help: <mailto:teas-ns-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas-ns-dt>,
<mailto:teas-ns-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2020 02:45:10 -0000
Hi Shunsuke and all, On Tue, Jan 28, 2020 at 11:57 PM Shunsuke Homma <s.homma0718@gmail.com> wrote: > Hi Jie, all, > > Thank you for your useful comments. Please see inline. (My responses are > tagged with [SH2]) > > Also, I attached the current status (work in progress) and diffs from the > previous version. I hope it covers your points. > > Regards, > > Shunsuke > > > > > On Wed, Jan 29, 2020 at 1:08 AM Dongjie (Jimmy) <jie.dong@huawei.com> > wrote: > >> Hi Shunsuke and Jari, >> >> >> >> Please see some comments inline with [Jie], thanks. >> >> >> >> Best regards, >> >> Jie >> >> >> >> *From:* Teas-ns-dt [mailto:teas-ns-dt-bounces@ietf.org] *On Behalf Of *Shunsuke >> Homma >> *Sent:* Tuesday, January 28, 2020 12:23 AM >> *To:* Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org> >> *Cc:* teas-ns-dt@ietf.org >> *Subject:* Re: [Teas-ns-dt] Definitions draft review >> >> >> >> Hi Jari, >> >> >> >> I appreciate for your kind review and feedback. Please see inline. >> >> >> >> Regards, >> >> >> >> Shunsuke >> >> >> >> 2020年1月27日(月) 23:05 Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org >> >: >> >> I did a review of the definitions draft. We're off to a good start but I >> wanted to convey some smaller and larger comments, the latter mostly with >> the intent to scope the document down to a very specific goal, with the >> intent that it can be specified and approved as an IETF RFC easily and >> without extended discussions. >> >> > the definition of transport slice in IETF >> >> I wonder if the organization matters or rather the substance. Maybe “in >> IP networks” instead of “in IETF”. Or equivalent. What tech are you >> specifying? You should speak about that, not the standards org. >> >> [SH] "in IP network" seems better, and I'll change the term. >> >> >> >> [Jie] Please see my previous mail to the list, which suggested to use >> “transport network” with some clarification about the scope of “transport >> network”. >> >> [SH2] As Jeff also pointed, I used "transport network" instead of "IP > network" or "Packet-Switched Network". > [Xufeng]: Agree on using the "transport network". > > >> >> >> > Network Slicing is considered very useful because there >> > is a need to generalize control, operations and management of diverse >> > set of services and related resource requirements that can then be >> > applied to any number or type of proposed, implemented and/or >> > deployed technologies and associated devices. Some key applications >> > which might benefit from the use of network slicing include: >> >> I think there's two separate benefits here. First, why does one need >> slicing, partitioning, etc? And secondly, if one needs it, why does one >> need to generalise it? >> >> [SH] We'll consider replacing the text for emphasizing the two points: >> allowing diverse devices/applications which have different requirements on >> communication to coexist on the same network efficiently, and enabling >> tenants to deploy slices across multiple domains. >> >> >> >> [Jie] Agree the benefit of network slicing and generalization need to be stated separately. The first is to meet the diverse services/applications’ requirement in the same network, while the second IMO is to ease the management of network slices across multiple domains or multiple technologies. >> >> ” >> >> [SH2] Please check the new text in the attached file. > [Xufeng]: The new text is now: Network slicing is a methodology to generically describe the logical partitioning of network resources associated with a service or an application. Network slicing is expected to enable diverse devices/ applications which have different requirements on communication to coexist on the same network efficiently. Also, a network slice sometimes traverses multiple domains, and generalized interfaces, operations, and managements would be important. The later parts of the paragraph try to answer Jary's second question "why does one need to generalise it". However, there still are no supporting statements to answer Jary's first question "why does one need slicing, partitioning, etc?" > > >> >> >> > Transport slices are a >> > part of network slice that fulfills connection requirements, which >> > are created and managed within the scope of transport networks (e.g. >> > IP, MPLS, GMPLS). >> >> Since the word endpoint is introduced above, maybe use it here too. >> Perhaps: >> >> ... connection requirements between endpoints. Transport slices are >> created ... >> >> [SH] Agree. I'll modify it. >> >> >> >> > This document provides a definition of 'transport slices' in IETF, >> > and describes considerations for their realization. >> >> I wonder if this should be in this document or elsewhere. E.g., the >> framework or a separate use cases document. >> >> [SH] Yes, I also think that considerations for realization should be >> moved to the framework document. >> >> >> >> [Jie] This is also what I suggested in previous review comments: the >> scenarios described in section 6 could be moved to a separate document, >> some summarized considerations for realization may be moved to the >> framework document. >> >> >> > [SH2] I assume some essences related to realization are described in > hierarchical concept in section 5, and I removed section 6 from definition > draft. > > >> > o UPF: User Plane Function >> > o gNB: Next Generation Node B >> >> Many terms and definitions... how much of this is necessary? Will this >> extra detail clutter what one tries to achieve with the definition? The >> crisper definition you have, the less you need to talk about mobile >> networks or other use cases. Considering writing another draft with use >> cases if that's necessary. >> >> [SH] Sure. We'll filter the list to only essentials. >> >> >> >> > 3. High Level Architecture of End-to-End Network Slicing >> >> This section is interesting and well written, but I wonder if it belongs >> to this document. We're not specifying the full slicing architecture. We >> should specify transport slices. >> >> How about defining transport slices *without* having to refer to >> end-to-end slice? >> >> (It would be ok to have a small note like the one about sub-slice terms >> in Section 4.1) >> >> [SH] IMHO, some description about relationship between E2E slice and >> transport slice would be important, because transport slice won't >> necessarily provide e2e connectivity. However, the current description may >> includes too much information, and we'll reconsider and polish the >> description. >> >> >> >> [Jie] In my understanding transport slice may be used as a component in >> end-to-end network slice, and may also be used as a mechanism to fulfil >> some service requirement in general cases. That said, it is useful to >> briefly describe the relationship of transport slice and end-to-end slice, >> then more focusing on transport network slice itself. Some text in the >> introduction section of VPN+ framework may be helpful. >> >> >> > [SH2] Thanks. I'll refer the introduction VPN+. > [Xufeng]: Are we trying to define "end-to-end (E2E) network slice" here? If yes, it is not clear which statement is the definition. If not, it is also not clear where the definition is from and referenced. > > >> > "A transport slice is an abstract network topology connecting a >> > number of endpoints, with expected objectives specified through a set >> > of service level objectives (SLO)". >> >> Seems fine... but one has to fill in the definition of endpoints (maybe >> forward ref to Section 5.2), the SLO in more detail (maybe forward ref to >> section 5), and also specify what "connecting" means. >> >> [SH] We need more elaboration with referring other I-Ds and RFCs. >> >> >> >> [Jie] Agreed to clarify the definition by referencing and coordinating >> with other relevant drafts and RFCs mentioned on the conference call (VPN+, >> ACTN, RFC 7926, etc.). >> >> >> >> > 4.2. Overview of Transport Slice Structure >> >> This is good material and generic. >> >> [SH] Thanks. >> >> >> >> [Jie] One comment I previously raised on this section was the >> description: “an E2E network slice might have one or more of "Transport >> Slices" and one or more of "Other Slices"”. If we consider the architecture >> of ACTN, a transport network with multiple domains could be abstracted >> using the MDSC and exposed to the client as one virtual network, thus with >> abstraction, could the multiple transport slices be seen as one abstracted >> transport slice by the end-to-end slice tenant? This could be discussed >> further on the conference calls. >> >> [SH2] I think this point is covered in the section 5.3. IMHO, > "abstraction level" (i.e., whether multiple transport slices should be > exposed as one transport slice or not) will vary depending on service > providing form. > [Xufeng]: In Figure 2, the three dots between "Network-1" and "Network-p" can be reconsidered. It initially looked like a connection link to me, then I realized that you want to say that there could be multiple networks "Network-2", "Network-3", etc. In addition, in the text, it is not clear what "Network-1" and "Network-p" are, and what is their relationship with the above "Transport Slice" in the diagram. > > >> >> >> Another comment is about the sentence: “the structure of a transport >> slice involves both definition and its realization.” It sounds a little >> strange that the definition is part of the structure. Maybe it wants say >> that the “the structure of a transport slice involves both the abstracted >> slice management and its realization”? >> >> >> > [SH2] This sentence is added by other authors and I'm not sure whether my > understanding is correct, but I assume that the points here are following > two points: > - Transport slice is provided and managed as abstracted network (i.e., the > definitions is technology agnostic) > - It will be realized with specific technologies (i.e., realization is > tied to specific technologies) > > Certainly, this may be confusing and I'll consider to modify the text. > > > 4.2.2. Transport Slice Controller Interfaces >> >> Potentially fodder for removal, isn't this something that the framework >> document should talk about? >> >> [SH] OK. We can move this subsection to the framework doc. Btw, should >> stakeholders section be moved as well? >> > [Xufeng]: In favor of moving parts of these two sections. 1) For "Transport Slice Controller Interfaces", I'd like to use "Transport Slice User Interfaces", to describe general interface based on Figure 2, without imposing any architecture concepts or components like "controller". Figure 3 is structured like a layered SDN architecture, which may not be the only architecture for a generic transport network system. 2) For section "Stakeholders", "Customer or User" is generic and relevant here, but "Orchestrator", "Transport Slice Controller" and "Transport Network Controller" are imposing SDN architecture again. In addition, we can add "Transport Network Service Provider" to complete the relationship with "Customer or User". > >> >> > 5.1. Service Level Objectives on Transport Slice >> > >> > A transport slice is defined in terms of several quantifiable >> > objectives or SLOs. These objectives define a set of network >> > resource parameters or values necessary to provide a service a given >> > transport slice. A non-exhaustive list of characteristics types for >> > transport slice is described below: >> > >> > o Guaranteed Bandwidth >> > o Guaranteed Delay >> > o Prevention of Jitter >> > o High Reliability (i.e., low packet loss rate) >> > o High Availability (i.e., MTBF, MTTR) >> > o Secure network >> > o etc. >> >> I'd prefer to see a more complete and fully defined set of criteria >> (including references to definitions) which then can of course be extended >> by future docs. >> >> [SH] Sure. Let's continue the clarification. >> >> >> >> [Jie] Agree that more explanation and references about these >> characteristics are needed. Some text and references can be found in >> section 2 of VPN+ framework. >> >> >> > [SH2] Thanks. I'll refer the section. > [Xufeng]: The last paragraph reads: Isolation discussion: SLO sufficiently specifies a transport slice. For example, an SLO need not explicitly ask for isolation since it is implied by guarantees of network resources. In fact a number of isolation technologies (TE, RSVP, VPN, VXLAN, IntServ etc.) are means to realize transport slices in the underlay networks. It is also implied that the forwarding, policy and address spaces are local with in a transport slice and instantiation of one slice does not conflict with another slice. This can be enforced as hard or soft level of resource allocations. The appropriate level is selected based on the specified SLOs. I'd not agree with the text here. 1) Why "isolation is implied by guarantees of network resources"? The allocated resources can be shared. The isolation can have different levels. At the most un-restrict isolation level, every resource can be shared. 2) Most of the listed technologies are not "isolation technologies". TE is for traffic performance; RSVP is for signaling; VPN is for address space separation; etc. 3) Saying that "the forwarding, policy and address spaces are local" may not be alway true. > > 5.3. Vertical Transport Slice >> >> This is ok, as is 5.4. >> >> [SH] Thanks. >> >> >> >> > 6. Realization of Transport slice >> >> Maybe the realisiation part is something that one should consider moving >> somewhere else. Potentially also the other parts, because while the first >> example for instance is quite good, it has a number of details that aren't >> core to the definition of a slice. Do we need a use case doc? >> >> [SH] I agree with that this section should be moved to other document. >> For example, can we describe these in an appendix of the framework doc? (It >> will take long time to make a new draft and reach our consensus. ) >> > [Xufeng]: Agree with moving. > >> >> Thanks again. >> >> >> >> Jari >> >> >> -- >> Teas-ns-dt mailing list >> Teas-ns-dt@ietf.org >> https://www.ietf.org/mailman/listinfo/teas-ns-dt >> >> -- > Teas-ns-dt mailing list > Teas-ns-dt@ietf.org > https://www.ietf.org/mailman/listinfo/teas-ns-dt >
- [Teas-ns-dt] Definitions draft review Jari Arkko
- Re: [Teas-ns-dt] Definitions draft review Jeff Tantsura
- Re: [Teas-ns-dt] Definitions draft review Shunsuke Homma
- Re: [Teas-ns-dt] Definitions draft review Jeff Tantsura
- Re: [Teas-ns-dt] Definitions draft review Dongjie (Jimmy)
- Re: [Teas-ns-dt] Definitions draft review Dongjie (Jimmy)
- Re: [Teas-ns-dt] Definitions draft review Shunsuke Homma
- Re: [Teas-ns-dt] Definitions draft review Greg Mirsky
- Re: [Teas-ns-dt] Definitions draft review Shunsuke Homma
- Re: [Teas-ns-dt] Definitions draft review Kiran Makhijani
- Re: [Teas-ns-dt] Definitions draft review Shunsuke Homma
- Re: [Teas-ns-dt] Definitions draft review Wubo (lana)
- Re: [Teas-ns-dt] Definitions draft review Kiran Makhijani
- Re: [Teas-ns-dt] Definitions draft review Xufeng Liu
- Re: [Teas-ns-dt] Definitions draft review Shunsuke Homma