Re: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation
Jeff Tantsura <jefftant.ietf@gmail.com> Mon, 09 November 2020 22:43 UTC
Return-Path: <jefftant.ietf@gmail.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 891563A14B3; Mon, 9 Nov 2020 14:43:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 DNqOn4IlxZZZ; Mon, 9 Nov 2020 14:43:13 -0800 (PST)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 3C0FE3A14B4; Mon, 9 Nov 2020 14:43:13 -0800 (PST)
Received: by mail-pf1-x42d.google.com with SMTP id c66so3838871pfa.4; Mon, 09 Nov 2020 14:43:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=tPYMwCyszOiqqO9SadWXnDrby52JVgMmhqXw5kUL7eA=; b=LHvo+0RY6zNzll51S6WjCw/GImWw8K6qSYWzUZG+ZrZ0ijWM94Y01CSOrbEeMyE+DS EjkEyDNDL1A4SUh3hKBsJC4JI1WfngT44tTeoynDtpWai6HdgiuqHDD03LPVOZtB5bW4 so4R5mvYqhal4VmRCZWFZTqMB40YtXmfLX6kCY+NLWJHgyxYrIfa57FWx59XtcAPosVv vDGpLvopOjXPdgFjwlVqAI9sdEZit9akt8O3iPFdSK8cq+qnKTPtXLohuGE/wKjwKZQd PONTv0mE9+ZEwo63PDR1n3wcLN/jrF3El8Xn1IQToMhXMtmfpVuAzRitRbMdxFNFLoxk qA+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=tPYMwCyszOiqqO9SadWXnDrby52JVgMmhqXw5kUL7eA=; b=cfVuyj7yYMi2o025R/1VN20Ijpsd5P1Wf5O8QsxWe8xyksRsLTxth3xNRNt8LkHIj5 DC+ffd1wPDsPTzsWgBZlT8cQcf2inDGndTrzoSIrceoWcU2tEtHMTMzm3vXB570ZFnZp 0KZlnSHHlTXi1aT7HrVREueNMN9kzv1DpoNlFKBk746kNp149S+04mI8UzTq3vT3IpmI S6OC57KgaKneWjQ/yr34qhsvNiY9hNkh9M/vAdzWPlldOhowOxKEYgVsehFhFXQSs2X8 1yfUMqtVEZxCALxy8fpvQCrG1OlWSFxC1dJgoKJp55UO6tmAfJHNxWMmCCcOz2KbfBBA aXfA==
X-Gm-Message-State: AOAM530es1j2c0GxeMIwgT1tXAyBlXeAg/0skTGYfWGp1FvN5ToqQagb M+U8y5k+jMfYDZZGFIwsyKpFWAx5fN8=
X-Google-Smtp-Source: ABdhPJwQIICfPPzID7RWcONSI1DBKu+iFlEMqVcWdYho1oLxIFd7v0+0S/1Y7BQ5MmxgXqJMhDb18w==
X-Received: by 2002:a63:ff1c:: with SMTP id k28mr14894957pgi.47.1604961792496; Mon, 09 Nov 2020 14:43:12 -0800 (PST)
Received: from [192.168.1.7] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id 7sm493482pjt.54.2020.11.09.14.43.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2020 14:43:11 -0800 (PST)
Date: Mon, 09 Nov 2020 14:43:02 -0800
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: adrian@olddog.co.uk, teas@ietf.org, "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: draft-nsdt-teas-ietf-network-slice-definition@ietf.org
Message-ID: <13178999-9168-46fb-8455-36d4d5683a2e@Spark>
In-Reply-To: <9e8170c6-399b-e954-2abb-5e5f425f172a@joelhalpern.com>
References: <059e01d6b6ce$0f74a830$2e5df890$@olddog.co.uk> <9e8170c6-399b-e954-2abb-5e5f425f172a@joelhalpern.com>
X-Readdle-Message-ID: 13178999-9168-46fb-8455-36d4d5683a2e@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5fa9c5fd_6b68079a_6e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/-LeIG7HcBwbhcrESocC2x1237PA>
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: Mon, 09 Nov 2020 22:43:16 -0000
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