Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition
Igor Bryskin <i_bryskin@yahoo.com> Fri, 04 September 2020 17:34 UTC
Return-Path: <i_bryskin@yahoo.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C37E3A0C47 for <teas@ietfa.amsl.com>; Fri, 4 Sep 2020 10:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=yahoo.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 GfSUYLrqPHD8 for <teas@ietfa.amsl.com>; Fri, 4 Sep 2020 10:34:33 -0700 (PDT)
Received: from sonic308-9.consmr.mail.ne1.yahoo.com (sonic308-9.consmr.mail.ne1.yahoo.com [66.163.187.32]) (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 DE2503A0C43 for <teas@ietf.org>; Fri, 4 Sep 2020 10:34:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1599240872; bh=G7J7Lhc0PYb33zFZNfUGxXAWDlh9Y03qoXo43eq44oE=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=hexdy4wNO1pZ5cQjs64Sq0GQr03V87oKnz8bMhy9QbVJ53oTl2Z98TTlBxKoN3191eSEQue4CrVFMpCYQX/FK+gTfZBFYN1yHsU1dmB5YYH3A+F/f2gCslS1DwYy7Bd7n9MovHRgUBvWcRIQi4fXzojMiQMNdKu790fYBGZqMCGDGoDLCXf/ss6cIydNgq2E0jPBizs8GciUUeeVje3V5HWqYY5xPJ0YRYTi3KM1wO8lKaVMLDlqHeHc++X3WhYVxHULh2RltpQ+YqrmhIva7Jj9RHsq69AW/ZX9a2DWre9f1gH3DOTdtvTM1P3nsk7DQXZ1kH300QCJANtpOn7vYQ==
X-YMail-OSG: eCaOhccVM1kY3VA6wafCT6W5OI2gBz5u_OKp857bO5dNykdypIQMjJVH8w.Pftw vcr8x_spd0pom0FV48Tm.0863qsFfpI3R_._awjNE1uBJtRyioyMrVgY50zYWehkMZSpnId2RECh E6oZPIyz0JLu8QQ6ACdTJlAiP.gbMbQP2vf3ONQLJOUuoau6p9_TrqH3IKMgwl2eL0S4uRywvNa5 cBT1hg1ic6TBTTmfVNImwWKSmXIt2Ujwiwj2PS5i4CZnu6OXkLsMkGOnK5GKnSw855LDkHT8Amc8 VZvyg0uTYNinLA6DwCewLT7_Vjhz9lUDrLyspc_rsDem3BtHJrAnSn1ws93qVjsSHcfi6a1baeaP xgofeUk.0RVjMg9TctHh6iTC3yZ8wpza0H.e3sT161dYw3a0g7DQ8mWe5SIH_B3D9frdYC4JsCQD Euzv2DTKdGTWmiKbMEj.UejXODrafNnD.jit4gHbQ2AS.oCmyzZCT.BfeTb865uj8PYbfcg0lYBk uMDWb13vPdPZaf_P5cqZNQEL_OUyDIeJ64MRy6vGlsEfv.wMQrbiBdHpthll9ojt_vEpoFG0B3gw ADOLyjSnuFl1PEc7OfQorp7GQIu0zf9ePwgiuiKzQSKjVIZl8PybQGf3acZWOhFm4LaBzZczU7H7 9rM.uUqGKvmRTr2vmVz3zC93nm1oir2NEiQ.b_V7ASktEoUjQVwmYedC2c.cDP6ZQFvlH9IAaYv4 VejTQc.nQHPZDn_.Lfa9CTL6Mrg9zxRSE8oKyYEwxbeMuoQLlH3kJjLE29e1Vvj1x4P0D3mG1oY2 TwhVgokKk.8_KzRk1PsWAhpO_m6gbDCbhFBBziiwvk4Rxz0NUs_hXk61CGmYqjnDTrNC2jlwwleY HUcgXbCwFim2qQjUBrfAC.UReB7hmozMyObTSIdw4oqFr9XaNeKE4xO6Yd0S4E.nK4dW2OfMTt8G 5696Osr6CJkPj7i8WEx1ZMNrUQD957qljhriD_Kib154dbsfV1IzY9kqH.1tD_qePfv3UOqfnC7g BhxRBrY7OebczU19dwXLjxO1dKr2ymhj3MngvE5p9dS7xrqRH7G.CGxrIc8KeG8Az77K4zFho4eQ YGvQ80eSDxnsL1VneKKEWyk.D6k3WH93Xc._Oc.g2LqCq25Mp5fMqToAUtdymkxca0rerUpNvZSi SuNL_9_2X445p3wPYp7KbdsxwNsMxOBDH1ROGoqSiD.s1MJrn.bhb2gc5kfInrL8mL9yPkEan.K0 aE4fp.Feps2x2x2q4u8cGDNWjCzR7i6D.ReVG4vMc40udlXEafbn3R2dwQLVb8UmPN.x7sOsZvrR fGloV_lKG5U3lzn2rMiJNelp2lqs.pO_94msssAyhibBp6b4_n.1SB2aA_SayJd1wZTA0PXzM8.R LbSr1ovLWACsWhRp42Wp7WyyWqlVgRsoHO88xfVmhFnvWhXRA1QS2EcaDTRwpxe2N0ndo_QR7Wfr toqXMzA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Fri, 4 Sep 2020 17:34:32 +0000
Date: Fri, 04 Sep 2020 17:33:46 +0000
From: Igor Bryskin <i_bryskin@yahoo.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Shunsuke Homma <s.homma0718@gmail.com>
Cc: "BRUNGARD, DEBORAH A" <db3546@att.com>, TEAS WG Chairs <teas-chairs@ietf.org>, TEAS WG <teas@ietf.org>, Eric Gray <ewgray2k@gmail.com>, Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>, Vishnu Pavan Beeram <vishnupavan@gmail.com>, "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>
Message-ID: <1150278594.310107.1599240826553@mail.yahoo.com>
In-Reply-To: <CAGU6MPdM6zLubGO1iyQJq2t8A=d=XabXBg8_nY1C2NKjsz=M+Q@mail.gmail.com>
References: <CA+YzgTvnv5nUZ6OYx9GkFUxDHxAFNvYsx5LrFfho3860_MLfZA@mail.gmail.com> <009001d680a7$eee86630$ccb93290$@olddog.co.uk> <160740632.2137384.1599059672316@mail.yahoo.com> <E4EA54FD-D1BD-43B0-BD75-B4C443082B64@nokia.com> <478F43F1-8335-482A-A90B-A07F02CDEF02@gmail.com> <008801d68215$859580e0$90c082a0$@olddog.co.uk> <CAGU6MPdM6zLubGO1iyQJq2t8A=d=XabXBg8_nY1C2NKjsz=M+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_310104_903997631.1599240826534"
X-Mailer: WebService/1.1.16565 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/DQ_MVy3fI54Gzyvz5JifGFpAwXU>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2020 17:34:38 -0000
H9 Reza, One important thing to understand about TEAS TE Topology model is that it should have been called TE *aware* Topology model instead. It is perfectly legal, for example, to drop all TE related attributes for all topology nodes and links and, thus, configure/control/describe generic ( not necessarily TE) network topology. Even without TE related attributes the model provides a rich set of systematic that would be valuable in the context of network slicing, specifically:- means for controlling/describing horizontal network hierarchies via open-ended access and inter-domain links and inter-domain locks;- means for controlling/describing vertical (multi-layer) network hierarchies via transitional links or inter-layer locks;- means for controlling/describing overlay/underlay relationships and topology stacks supporting each of nodes/links via source/supporting node/link objects;- topology element coordinates in space via GPS attribute;-etc. Igor On Friday, September 4, 2020, 9:48:51 AM EDT, Shunsuke Homma <s.homma0718@gmail.com> wrote: I think the definition you referred to in TS23.501 came from ITU-T (ITU-T Y.3100) . And, I assume that the ambiguous definition brought this confusion (i.e., the ambiguity allows readers to create their own interpretations). # It's obvious that definitions of IETF documents are consistent with it, because everyone would refer to it. 3GPP has their more concrete concept of network slicing on the basis of the above definition in TS28.530. I think we also need to break down the definition from IETF perspective and clarify our concrete scope. Regarding slicing on non-TE networks, for example, a network can be logically separated with OSPF multi-instance or IGP Flex-Algo. Or, in some cases, operators may lend whole physical links. Of course, in many cases, it is better to use TE technologies. But we need not to limit the target to TE networks, I think. Regards, Shunsuke 2020年9月4日(金) 2:13 Adrian Farrel <adrian@olddog.co.uk>: Thank you Eric for what is the clearest email to date on how we got to where we are. It helps me understand a lot better the questions we should be asking. I’m sure many of these questions were debated at length in the design team, but “we thought about it and came to a conclusion” is never the strongest argument to present to a working group, so we may have to unpack some of the compromises that were made in order to bring everyone along with the ideas. (I also hope that the compromise wasn’t reached on the basis of most of the team saying they didn’t like it and a few people digging in. But that will come out if the members of the team speak up on the list to say what they do or don’t like.) I appreciate the desire to be consistent with the terminology used in other bodies. There is no reason not to do that where that terminology is clear and where it is not in conflict with terminology already in use in the IETF. On the other hand, where the IETF is already using terminology we have to be more careful. It looks to me that the 3GPP has some nice core definitions in TS 23.501 (I’m looking at v16.2.0). For example: Network Slice: A logical network that provides specific network capabilities and network characteristics. That definition looks pretty much consistent with every definition I have seen in use in the IETF. The problem seems to come as we move from the abstract/generic to the specific. I believe it will always be the case that the concept of “transport” is a relative term. Any network that can carry traffic for an application or another network is (by definition of “transport” meaning to carry) a transport network. If you build IP networks then any sub-IP network is a transport network. If you build radio networks then you may see an IP network as a transport network. If you run IP over radio, then you probably see the radio network as transport. As a concept, then, “transport” adds value when it describes the relationship between network layers. But I think we find that the 3GPP definition of “network slice” embraces the wider and more general concept that we also need. That is, we need to describe the creation and management of logical networks that provides specific network capabilities and network characteristics. I don’t think we want to be limited to when those logical networks are specifically intended to carry traffic for client networks that are themselves network slices. If, as some people seem to argue, there is a need to constrain the description to be limited to just a specific use case of a network slice, then I suggest that is exactly what should be done. That is: define a network slice and get comfortable with that definition; specify the use case; describe how the generic network slice is used in that case; set out any limitations or additions needed to the generic definition. Two other small points: - Igor noted how ACTN was renamed from “transport” to “TE” to ensure it was applicable to all network types for which the IETF (and specifically TEAS) could apply the technology. I agreed with that change and I think it applies here, too. - There may be a desire to apply the concept of network slicing to non-TE networks (but still considering IETF technologies). I would be intrigued to understand how that works without some form of ‘reservation’ of network resources and ‘steering’ of traffic. It may be that: - The advocates of this idea should read (and contribute to) draft-ietf-teas-rfc3272bis - We should all think hard about where such work should be done given the scope of TEAS Best, Adrian From: Eric Gray <ewgray2k@gmail.com> Sent: 03 September 2020 16:20 To: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com> Cc: Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>; Vishnu Pavan Beeram <vishnupavan@gmail.com>; TEAS WG <teas@ietf.org>; Adrian Farrel <adrian@olddog.co.uk>; TEAS WG Chairs <teas-chairs@ietf.org>; BRUNGARD, DEBORAH A <db3546@att.com> Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition Reza, It’s tempting to say that I agree with whatever it is that you said below. :-) However, you’ve dived directly into a details-based explanation - where it is possible (or even quite likely) that your details-based explanation has a Ouroboros-like circularity that depends on how you’ve defined the details. Instead, I suggest summarizing the process by which we decided to compromise in using “transport slice” (or “transport slicing”). I personally thought (and - to some extent - still think) we should be using “transport network slices” - for at least the case where we are using packet-based (or other IETF supported methodologies for) connectivity services to support RAN and Packet Core applications in mobile networks - mostly to be consistent with 3GPP terminology. That was at least my starting position. But we (the IETF) are already (and arguably have been for some time) using the phrase “network slicing” to refer to mostly technology (and layer) agnostic network virtualization. That obviously applies very nicely in cases where we are talking only of IETF defined/maintained technologies. For example: in DC networking. But using “network slicing” in the mobile networking application clashes badly with other uses that apply in the same space. For example: 3GPP defines "network slices" as originating on a UE, and terminating on a UPF (and vice-versa) and these “network slices” have to be carried (i.e. - "transported”) over the slices provided for that purpose by what 3GPP consistently refers to as a “Transport Network.” It is possible that 3GPP (or mobile operators) may extend usage to include “network slices” that extend from one or more UEs to one or more other UEs, through one or more (essentially concatenated) UPFs - but dealing with this case is not essential (or arguably even useful) to understanding requirements of the mobile network application in general. On top of that, in the mobile networking application, there is no presumption that a “transport network” will be anything that the IETF defines or maintains. Microwave technology is - for instance - a technology that many mobile operators go to first (or at least most often) in providing “transport” for a mobile operator’s RAN traffic (including network slices), and obviously these services have previously been (and will for some time be) provided using some form of synchronous optical networking (which is a driver for some of the interest in TDM-like “transport services”). So there are multiple dimensions to this naming choice, and I don’t think anyone will be completely satisfied with any name we select. To the extent possible, we should try to define a northbound interface generic enough to support any technology - including largely those that are defined/maintained by the IETF - while trying to avoid naming ambiguity to the extent possible. And we should try to include sufficient flexibility to support “carrying” (i.e. - “transport”) of "network slices" as we have defined them in the IETF. We cannot actually use the phrase “network slices” (or “network slicing”) for all of the cases, as that will be far too ambiguous and will lead to the need to “qualify” every usage to remove the inherent ambiguity we would be creating. Hence the compromise of using “transport slice.” I don’t like it, and I am not alone in that - but that is pretty much the definition of what a “compromise” is. — Eric On Sep 3, 2020, at 10:35 AM, Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com> wrote: Hi Deborah, >>>>> Why are you excluding RAN? RAW is already doing IP solutions, SG15 has RAN transport solutions for IP. IP is already in the RAN. We are not excluding the RAN. This is the explanation. RAN NEs has two logical components, Radio and Transport. When I mentioned in my previous email that a “5G network slice has RAN Slice, Transport Slice and Core slice, I refer to the Radio portion of the RAN. The transport portion of the RAN can be consider as part of the transport slice. This is clearly pointed out in the draft with definition of Transport Slice Endpoint (TSE). Please see picture below where for example the TSE could be the endpoint inside the Transport portion of the RAN. <image001.png> Hi Igor, >>>> I agree with Deborah and Adrian that at least some terms defined in this work could have been borrowed from other TEAS WG work. You have a valid point of using the exiting IETF terms as much as we can. And this was the intention of the draft authors. Having said that, It is important to consider that the operator can realize a “Transport Slice” in a TE or NON-TE network. They can even realize a transport slice in NON-IP/MPLS network (like PON). The point is that the transport slice is not necessarily associated to a TE network. As pointed out in the draft, the realize of a transport slice can be in TE network and any IETF models/works can be utilized for realization. Cheers, Reza From: Teas <teas-bounces@ietf.org> on behalf of Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org> Date: Wednesday, September 2, 2020 at 11:14 AM To: 'Vishnu Pavan Beeram' <vishnupavan@gmail.com>, 'TEAS WG' <teas@ietf.org>, Adrian Farrel <adrian@olddog.co.uk> Cc: 'TEAS WG Chairs' <teas-chairs@ietf.org> Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition Hi, I agree with Deborah and Adrian that at least some terms defined in this work could have been borrowed from other TEAS WG work. For example, I may have missed some discussions, but I still do not see much difference between transport slice as defined and an abstract network topology defined/configured by a client and provided as a service by the server as defined in network topology model family. If we could agree that the two are at least close cousins, the life would get much simpler IMHO. Igor On Tuesday, September 1, 2020, 5:36:39 PM EDT, Adrian Farrel <adrian@olddog.co.uk> wrote: Hi, I've reviewed this document as part of the adoption poll. My review has been partially overtaken by threads on the list. Sorry about that, but it is a lengthy review. I'd like to start by thanking the design team for tackling the thorny subject of terminology, and the authors of this draft for pulling together the various opinions of the team so that we, the working group, can do the easier task of reviewing the material. I'm aware that the conditions for WG adoption specifically do not include that the document should be perfect. But it is important that the work is clear enough and sufficiently on message that we can work out what it is for and why we might adopt it. In my review, below, I raise a number of points that I think are quite serious and need to be addressed before we can look at the document properly and decide whether or not to adopt it. These points call into question what is actually being defined. That is, I am reserving judgement and not saying "adopt once these issues are fixed." Above all, I see no benefit to a document that defines a term that seems to have no particular benefit or use. We know that underlay networks carry traffic for overlay networks. We know that virtualisation can be done at different technology levels and that networks can be arranged hierarchically or stitched together with abstraction and adaptation. We know that an underlay network can be sliced. What additional benefit is the definition of the term "Transport Slice" bring? It looks that the composed end-to-end transport slice is another term for a virtual network, where at the lowest level a transport slide seems to be a network slice. This question has to be answered before I can support adoption. Finally, I want to say that we often decide to adopt a document on the understanding that we can fix it up later. But in this case I am very concerned that adopting this document would be interpreted as the acceptance of the concept of a transport slice without agreement on what it is or why we want it. That would surely lead us into a very difficult place where debate about the document would be hard to progress. Thanks, Adrian === I brought up my concern about the use of the term "Transport" around IETF-106 and it still bothers me. The Abstract says "...the definition of a slice in the transport networks" but since that term is not common in the IETF (or rather, it has two very specific meanings neither of which is intended here) the Abstract fails in its goal "to bring clarity". A more accurate Abstract might be: This document provides a definition of the term "Transport Slice" for use within the IETF and specifically within other IETF documents that describe aspects of network slicing. The document also describes the characteristics of a transport slice, describes related terms and their meanings, and explains how transport slices can be used in combination with end to end network slices or independent of them. Section 3 goes on to reference RFC 5921 to give basis for use of the word "transport". In view of this, it might be interesting to examine how any network slice can be anything other than a transport slice. That will lead to a discussion about why this document needs to be separate from the slicing framework draft. The answers to these questions would usefully be placed in the document. --- Section 1 A number of use cases benefit from establishing network connectivity providing transport and assurance of a specific set of network resources. I cannot understand this sentence. What does it mean to "provide transport"? Transport of what? And, is there a punctuation issue or does the text mean "transport of network resources"? What does "assurance of network resources" mean? --- Section 1 In this document, as detailed in the subsequent sections, we refer to this connectivity and resource commitment as the transport slice. It is unhelpful to include this text here. Is this the normative definition of a transport slice or just a passing comment? --- Section 1 Services that might benefit from the transport slices include but not limited to: Since this assertion is unsubstantiated and expressed as a speculation it reads like marketing! I suspect we don't need it or the list of bullets, but maybe you could insert forward references to the sections that describe the use cases and how a transport slice might be beneficial in those cases (those would be sections yet to be written). If, as you seem to imply, the reason for this document is to describe a term for a concept that has value in certain deployments, I think it is incumbent on you to describe those cases. I would recommend throwing out the whole of Section 1 as currently written and replacing it with an Introduction that expands upon the Abstract as well as describing what the document will do. You would still want to add the use case descriptions. --- Section 1.1 This section launches into a discussion of why we want a transport slice, but it does so before defining (section 3) what a transport slice actually is. The later paragraphs of this section are descriptive about transport slices, but are presumably not normative definitions. You may find it helpful to re-write this section in abstract terms. What behaviors are needed from the network? How is the network operated? How does this compare with "traditional" VPNs? In other words, don't mention Transport Slice in this section at all, but use this section to establish the need. --- Section 1.1 Transport slice is described as a construct that specifies connectivity requirements, emphasizing on assurance of those requirements. Transport slice is unaware of the underlying infrastructure connectivity (hence, the term "transport"). Firstly, please avoid using passive voice. I think you are defining (in this not document) not running a commentary on the fact that someone somewhere describes "transport slice" in a particular way. More important, however, is what is going on here. It appears that you are describing a "transport slice as a service". This would be really helpful to state up front. That is, you are not describing how the transport slice is delivered by the network, nor any visibility that the client has of that network. Hence, "[the] transport slice if unaware of the underlying infrastructure connectivity". But this view as a "service" seems at odds with the quote in Section 3 where you state that "A transport slice is a logical network topology connecting a number of endpoints with a set of shared or dedicated network resources, that are used to satisfy specific Service Level Objectives (SLOs)". ...If the transport slice is unaware of the underlying infrastructure connectivity, how can the slice be a set of shared or dedicated network resources? I don't understand how you get to 'hence the term "transport"' from the lack of awareness of underlying infrastructure. --- Section 1.1 Relation to Enhanced VPN. As you know, VPN+ is adopted TEAS work. I see that you have an Informative reference to draft-ietf-teas-enhanced-vpn, but I also see that you never make use of this reference until the appendix. I think you need to discuss VPN+ in Section 1.1 to provide sufficient contrast and to explain why you need your new concept. --- Section 1.1. The final paragraph in this section says "Transport slices relate to a more general topic of network slicing." It is hard to evaluate this without a more detailed description of network slicing than is provided in the single next sentence. In particular, we need to understand why you need the term "transport slice" instead of simply "network slice." I'd say you could go one of three ways: 1. Provide a more detailed description of network slicing in this document 2. Make a normative reference to some other document that defines a network slice 3. Remove this paragraph and clean the document so that the focus is entirely on the definition of "transport slice" and no mention is made of "network slicing". --- Section 2 Trying to not nit-pick this section (it can be worked on later), but the terms SLI, SLO, and SLA seem to be fairly important within this document. These three brief paragraphs are not very much information for such key terms. You probably either need a section to go into more details of these definitions or you need external references to where these concepts are defined. --- Section 3 Why is the definition of a transport slice in quotes? Is it a definition taken from somewhere else? --- Section 3 "Slice" refers to a set of characteristics that separate one type of user-traffic from other types. Is "separation" a different term from "isolation"? They are often used as synonyms. If you mean them to be the same, it may help to use only one term in this document, but if you mean them to be different, it may help to provide some statement of contrast. --- Section 4 The following subsections describe the characteristics needed for support of transport slices. "Characteristics" of what? "Needed" by whom? --- Section 4.1 (and elsewhere) The use of the term "end user" may not convey the message you intend. (Or maybe it does!) An end user is usually conceived to be a person or machine that it the ultimate source or sink of packet data. Do you define that the consumer/customer/client of a transport slice is such an individual person/component? Or is a transport slice provided as a service to support another network (like a pseudowire, VLAN, VPN, etc.)? If you plan to continue using "end user" you might include it in Section 5.1. --- Section 4.1 If for example the range of latencies a network can provide is 50ms-100ms, then this would be the range of values the end user should be able to request, it would be as low as 50ms or as high as 100ms or anything in between. Is this just a bad example, or is there something I am not seeing? Surely no one request a latency. They may indicate that they can tolerate a latency: that is, they may request an upper bound to the latency they will receive. If so, just because the network "can provide" latency of 50-100ms, does not restrict the user from giving a higher value. There is also some question of who asks and who provides. As you have it phrased, the network must tell the end user what is available, and the end user can then select. Is that really how it works? Doesn't latency in a network depend on many factors (including where the sources and destinations are, and what other service parameters are being delivered)? If so, wouldn't the end user make a request with a set of SLIs and the network would respond yes/no/negotiate? --- Section 4.1.1 I'm not sure what this paragraph is doing here. If it were illustrative it might be acceptable but currently it has: This document defines a minimal set of SLOs and later systems or standards could extend this set and define more SLOs. For example, we included Guaranteed bandwidth which is the minimum requested bandwidth for the transport slice. The later standard might define other SLOs related to bandwidth if needed. This document is not positioned as Standards Track, so this text looks very out of place. I do understand that is a transport slice is to be viewed as a service then it is important to qualify the service parameters. Is this the same list of service requirements as we find in section 3 of draft-ietf-teas-enhanced-vpn? Are any differences the clue to understanding the difference between an enhanced VPN and a transport slice? --- Section 4.1.1 o Availability: is defined as the ratio of uptime to total_time(uptime+downtime), where uptime is the time the transport slice is available in accordance with the SLOs associated with it. There is some circuitous definition here since an SLO is "A target value or range of values for a service level that is measured by an SLI." You also need to indicate what you mean by "the transport slice is available"? Does the disconnection of one TSE from a slice mean the slice is not available, or just downgraded? (This may be a comment too far! It is probably off in the details that the WG might discuss if/when the document is adopted.) --- Section 4.1.1 Security : really? draft-ietf-teas-enhanced-vpn has: While an enhanced VPN service may be sold as offering encryption and other security features as part of the service, customers would be well advised to take responsibility for their own security requirements themselves possibly by encrypting traffic before handing it off to the service provider. Do you really believe that "encrypted connectivity" is likely to be an SLI of a transport slice? --- Section 4.1.2 With these objectives incorporated, a customer sees transport slice as a dedicated network for its exclusive use. Do you mean like a VPN? A sort of VPN with enhanced attributes? Like a sort of enhanced VPN? --- Sections 4.2 and 4.3 I didn't really understand how/why we need another decomposition of network services, network virtualisation, and hierarchical networks that is essentially functionally the same as many of the ones we have worked n before but which has a different set of names for things. Is there really a big difference between this and work we have done before? --- Section 5.1 I'm a bit confused by your statement (in the TSC definition) that there are different types of orchestrators and different types of TSC. There is no explanation of this and the definitions appear to be generic. If it is OK to have "slice operator for short" why is it not OK to have "slice" for short? --- The only mention of the "e2e network slice orchestrator" is in Section 5.2. This seems to be related to some text in 5.1 A user may either directly manage its service by interfacing with the transport slice controller or indirectly through an orchestrator. Orchestrator: An orchestrator is an entity that composes different services, resource and network requirements. It interfaces with the transport slice controllers. ...which is slightly in conflict with text in 5. A transport slice is requested from an entity (such as an orchestrator or a system-wide controller) performing broader service or application specific functions. There is probably some unspoken meaning to these differences, but it is hard to guess. --- I consider the distinction in Section 6 between "end-to-end slice", "other slice", and "transport slice" to be somewhat bogus. The customer of an end-to-end slice might be directly using the "transport network". The IETF only deals with IETF technologies. --- Section 7 will need to filled in at some stage. At the least, you have a suggestion that security is an SLI. But probably, there are plenty of security and privacy concerns with all aspects of network slicing. From: Teas <teas-bounces@ietf.org> On Behalf Of Vishnu Pavan Beeram Sent: 19 August 2020 16:50 To: TEAS WG <teas@ietf.org> Cc: TEAS WG Chairs <teas-chairs@ietf.org> Subject: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition All, This is start of a *three* week poll on making draft-nsdt-teas-transport-slice-definition-03 a TEAS working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The poll ends September 9th (extra week to account for vacation season). Thanks, Pavan and Lou _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Daniele Ceccarelli
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Dongjie (Jimmy)
- [Teas] WG adoption - draft-nsdt-teas-transport-sl… Vishnu Pavan Beeram
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel M. Halpern
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Kiran Makhijani
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel Halpern Direct
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Kiran Makhijani
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel M. Halpern
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel Halpern Direct
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Dongjie (Jimmy)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel Halpern Direct
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Dongjie (Jimmy)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Luis M. Contreras
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… David Sinicrope
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel M. Halpern
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… BRUNGARD, DEBORAH A
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Greg Mirsky
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Kiran Makhijani
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Greg Mirsky
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Kiran Makhijani
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel Halpern Direct
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Greg Mirsky
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Dongjie (Jimmy)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… BRUNGARD, DEBORAH A
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Luis M. Contreras
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Luis M. Contreras
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Luis M. Contreras
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… BRUNGARD, DEBORAH A
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Vishnu Pavan Beeram
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gengxuesong (Geng Xuesong)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… David Sinicrope
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… David Sinicrope
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Jari Arkko
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Jeff Tantsura
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Young Lee
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Uma Chunduri
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gengxuesong (Geng Xuesong)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gengxuesong (Geng Xuesong)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… mohamed.boucadair
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel M. Halpern
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Eric Gray
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… mohamed.boucadair
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Adrian Farrel
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gyan Mishra
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gyan Mishra
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Greg Mirsky
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gyan Mishra
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gengxuesong (Geng Xuesong)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel M. Halpern
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gengxuesong (Geng Xuesong)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Joel M. Halpern
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Gengxuesong (Geng Xuesong)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… John E Drake
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Adrian Farrel
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Igor Bryskin
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Shunsuke Homma
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… BRUNGARD, DEBORAH A
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Adrian Farrel
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Jeff Tantsura
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Shunsuke Homma
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Shunsuke Homma
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Dongjie (Jimmy)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Kiran Makhijani
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Eric Gray
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… John E Drake
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Adrian Farrel
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Kiran Makhijani
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Shunsuke Homma
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Igor Bryskin
- Re: [Teas] WG adoption - draft-nsdt-teas-transpor… Vishnu Pavan Beeram