Re: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation
Joel Halpern Direct <jmh.direct@joelhalpern.com> Tue, 10 November 2020 00:01 UTC
Return-Path: <jmh.direct@joelhalpern.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 0CD013A1507; Mon, 9 Nov 2020 16:01:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 ATwghcflPBor; Mon, 9 Nov 2020 16:01:36 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 26D653A1503; Mon, 9 Nov 2020 16:01:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4CVShJ0LWcz1nsT0; Mon, 9 Nov 2020 16:01:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1604966496; bh=0tLObAI5dda2jHrS2STmGd6z0xae+/XUIg2t5qwkbjQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=a2i7VaRVlLDOPzuEvcb8GjQA+ffTgsMTSku6wfhnz2kxzuXbOakxJjBCM93TTmMhs KZYR0bsCYgIjjvEbNoNvFC2tNG2XgUrWQ5xRKDXjBsZgs72MvudZnBNM8CC7g0sNlk J50RG85khzfkai3gUSAwfIYRJoDj1yibw5BWZDek=
X-Quarantine-ID: <B_7_JPmaKoDf>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4CVShH33lvz1nsSy; Mon, 9 Nov 2020 16:01:35 -0800 (PST)
To: Jeff Tantsura <jefftant.ietf@gmail.com>, teas@ietf.org
Cc: draft-nsdt-teas-ietf-network-slice-definition@ietf.org
References: <059e01d6b6ce$0f74a830$2e5df890$@olddog.co.uk> <9e8170c6-399b-e954-2abb-5e5f425f172a@joelhalpern.com> <13178999-9168-46fb-8455-36d4d5683a2e@Spark> <62c127a5-9230-d105-04b7-4b061fdd43c1@joelhalpern.com> <a9d968ed-90af-4889-8cc8-bc57b76edbf3@Spark>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Message-ID: <e63a5189-533f-61da-e13b-6572dfd72142@joelhalpern.com>
Date: Mon, 09 Nov 2020 19:01:34 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1
MIME-Version: 1.0
In-Reply-To: <a9d968ed-90af-4889-8cc8-bc57b76edbf3@Spark>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/ssYCsKZ95iNH-qaEgTY3T413NfU>
Subject: Re: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation
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: Tue, 10 Nov 2020 00:01:38 -0000
You raised the dedicated fiber question. If one has an end-to-end system with multiple components, there are many places where there simply will not be dedicated fiber. More importantly, I see no way to meaningfully express "the customer wants as much dedication as possible" in the interface we are discussing. Such a declaration will be dealt with in different ways by different people / systems / adminstrations, meaning that it gives no reliable behavior to the customer. I agree that Isolation is not an SLO. But if it is not an SLO, I do not know how it fits with the rest of what the definitions draft lays out. Yours, Joel On 11/9/2020 6:37 PM, Jeff Tantsura wrote: > Joel, > > There’s no buying of any fibers, a slice is a service provided by a > provider to a consumer. A fiber between point A and point B is a valid > example of a slice, as much as an LSP, lambda, or any other technology. > We are talking about defintions (terminology) applicable. > > Would the following definitions work for you? > dedicated infra (in any way or form) - for example some vendors allow > you to have a dedicated NPU on router. > disjointed infra, where backup path is isolated (non fate sharing) from > primary, e.g. SRLGs, common devices, etc > > I don’t think mixing performance objectives with isolation is a great > idea though, > an SLA doesn’t change because there’s someone else sharing > infrastructure with you, it is well understood that any changes within > other customers should not affect you. > > Joel - my last objective in the world would be to have you to object the > same draft again, please bear with us in preparing for the adoption. > > Cheers, > Jeff > On Nov 9, 2020, 2:47 PM -0800, Joel Halpern Direct > <jmh.direct@joelhalpern.com>, wrote: >> If your security policy requires dedicated fiber, buy dedicated fiber. >> If you are going through shared routers, shared roadMs, etc. then >> dedicating the fiber seems to me to completely miss the point. >> >> And none of the definitions I have seen for what "Isolation" could mean >> go to the requisite level of detail. If it means "the entire >> infrastructure must be dedicated", then I do not think it belongs in the >> IETF. If it means "dedicate something, please", then it is not an SLO. >> >> The definitions and framework draft are explicit that they are >> technology agnostic. So it is really hard to see how you can express >> any meaningful and useful isolation, assuming that there is such a thing. >> >> More importantly, I would want to see an actual definition of what is to >> be described if we are to include it. >> >> I am not asking that the placeholders be removed. There may be a >> definition that is useful. But what is there isn't it. Saying that >> there may be some as yet undefined SLO that relates to som as yet >> undefined meaning of Isolation does not cut it for me. >> >> And yes, I am getting tired of refighting the same discussion. We >> agreed on leaving placeholders in the document. I was hoping and >> expecting that we could get the result of that adopted. I do not like >> having to object to the same draft again. >> >> Yours, >> Joel >> >> On 11/9/2020 5:43 PM, Jeff Tantsura wrote: >>> Joel, >>> >>> Thanks for your comments. >>> I respectively disagree with you, if my security policies require use of >>> dedicated infrastructure (fiber is a common one), it is a valid service >>> objective. >>> >>> Cheers, >>> Jeff >>> On Nov 9, 2020, 1:45 PM -0800, Joel M. Halpern <jmh@joelhalpern.com>, >>> wrote: >>>> Thank you Adrian. I mostly agree with what you say (retained below.) >>>> >>>> The only point where I disagree is that the proposed text fro 9.1 still >>>> keeps the notion that there may be an Isolation SLO. >>>> As far as I can tell, Isolation is a mechanism. It is one of many >>>> mechanisms that can be used to meet the SLOs. I have no idea what an >>>> Isolation SLO element would be, or why a customer would ask for it. >>>> So I would be inclined to go a step further and just get rid of 9.1. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/9/2020 2:25 PM, Adrian Farrel wrote: >>>>> Hi, >>>>> >>>>> I'm not sure where the right place to discuss this document is. >>>>> Since it >>>>> replaces the previous terminology document, and since that was >>>>> proposed for >>>>> adoption on the TEAS list, I think this is probably the right place >>>>> (feel >>>>> free to redirect me). >>>>> >>>>> I'd like to focus this email just on Section 9 - the text on >>>>> isolation. I >>>>> suspect that this is the largest remaining obstacle to WG adoption. >>>>> >>>>> Firstly, we have to recall that this is a terminology document, not a >>>>> broader architecture. Therefore we should aim to reduce the text to >>>>> clear >>>>> and simple definitions: further text belongs in some other document >>>>> such as >>>>> the framework draft or a focus-specific document that describes some >>>>> facet >>>>> in detail. So I guess I agree with the Editor's statement at the top of >>>>> Section 9... >>>>>> Editor's note: This content is a work in progress. The section on >>>>>> isolation is too descriptive. >>>>> >>>>> A way to reduce this would be... >>>>> >>>>> == Section 9 == >>>>> >>>>> OLD >>>>> An IETF Network Slice consumer may request, that the IETF Network >>>>> Slice delivered to them is isolated from any other network slices of >>>>> services delivered to any other customers. It is expected that the >>>>> changes to the other network slices of services do not have any >>>>> negative impact on the delivery of the IETF Network Slice. In a more >>>>> general sense, isolation can be classified in the following ways: >>>>> >>>>> Traffic Separation: Traffic of one network slice should not be >>>>> subjected to policies and forwarding rules of other network >>>>> slices. >>>>> >>>>> Interference Avoidance: Changes in other network slices should not >>>>> impact to the SLOs of the network slice. Here the changes in >>>>> other network slice may include the changes in connectivity, >>>>> traffic volume, traffic pattern, etc. >>>>> >>>>> Service Assurance: In case service degradation is unacceptable due >>>>> to unpredictable network situations producing service degradation >>>>> (e.g., major congestion events, etc.), explicit reservation of >>>>> resources in the network maybe requested for a reduces set IETF >>>>> network slices. >>>>> NEW >>>>> An IETF Network Slice consumer may request, that the IETF Network >>>>> Slice delivered to them is isolated from any other network slices of >>>>> services delivered to any other customers. It is expected that the >>>>> changes to the other network slices of services do not have any >>>>> negative impact on the delivery of the IETF Network Slice. >>>>> END >>>>> >>>>> In making this change I'd note that while these three principles are an >>>>> important part of the discussion of isolation they are out of context >>>>> here. >>>>> Traffic separation is a feature of how isolation may be achieved, but >>>>> it is >>>>> not something that a consumer can or should specifically ask for: >>>>> they have >>>>> no way of measuring it and, indeed, since they don't know the >>>>> purpose of >>>>> policies and forwarding rules within an operator's network they >>>>> shouldn't >>>>> ask for control over them. Interference avoidance is a fine goal for a >>>>> consumer to ask for, but you already have this captured in the >>>>> preceding >>>>> paragraph. Service assurance seems to capture two things: that the >>>>> consumer >>>>> may wish for protection of their service in the event of network >>>>> failure >>>>> (that's not really an isolation thing) and that a way to protect >>>>> against >>>>> failure situations is to reserve resources (that's not necessarily an >>>>> isolation thing, and is certainly a question of realisation). >>>>> >>>>> == Section 9.1 == >>>>> >>>>> I think that this section is a little over-stated. Maybe: >>>>> OLD >>>>> Isolation is an important requirement of IETF network slices for >>>>> services like critical services, emergencies, etc. A consumer may >>>>> express this request through the description of SLOs. >>>>> NEW >>>>> Isolation may be an important requirement of IETF network slices >>>>> for some critical services. A consumer may express this request as >>>>> an SLO. >>>>> END >>>>> >>>>> == Section 9.2 == >>>>> >>>>> While I think there is value in having this section to note that >>>>> there is a >>>>> concept of isolation in the realisation of a network slice, I don't >>>>> think >>>>> you should get into details with examples etc. If you want to talk >>>>> about how >>>>> realisation of network slices works, that should be in another >>>>> document. >>>>> >>>>> Thus, I think you could drop the whole of the fist paragraph: it just >>>>> duplicates some of the ideas in the second paragraph which says it more >>>>> clearly. >>>>> >>>>> Furthermore, the final paragraph in the section seems to be all about >>>>> realisation. I think you should drop it partly because it is >>>>> technically >>>>> suspect (an L3VPN does not achieve traffic separation in the network, >>>>> that >>>>> is exactly the point of an L3VPN), but mainly because it is a >>>>> discussion of >>>>> the details and technologies of realisation. >>>>> >>>>> == Section 9.3 == >>>>> >>>>> I tend to think that there will be value in a full and careful >>>>> discussion of >>>>> how IETF network slices meet the requirements of 3GPP transport >>>>> slices, but >>>>> I don't think it should be in this document. Thus, I agree with the >>>>> editor's >>>>> note that the section should be removed. Maybe interested parties could >>>>> start a new document "Applicability of IETF Network Slices to 3GPP >>>>> Transport >>>>> Slices." >>>>> >>>>> >>>>> Thanks, >>>>> Adrian >>>>> >>>>> _______________________________________________ >>>>> Teas mailing list >>>>> Teas@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/teas >>>>>
- [Teas] Thoughts about draft-nsdt-teas-ietf-networ… Adrian Farrel
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Joel M. Halpern
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Adrian Farrel
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Jeff Tantsura
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Jeff Tantsura
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Joel Halpern Direct
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Jeff Tantsura
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Joel Halpern Direct
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Jari Arkko
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Stewart Bryant
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Joel Halpern Direct
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Stewart Bryant
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Joel M. Halpern
- Re: [Teas] Thoughts about draft-nsdt-teas-ietf-ne… Stewart Bryant