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
> >