Re: [Teas-ns-dt] Brief meeting notes

Eric Gray <eric.gray@ericsson.com> Fri, 25 September 2020 14:25 UTC

Return-Path: <eric.gray@ericsson.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 1937B3A0AA6 for <teas-ns-dt@ietfa.amsl.com>; Fri, 25 Sep 2020 07:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.794
X-Spam-Level:
X-Spam-Status: No, score=-3.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=ericsson.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 NhYpPiW_l-Zf for <teas-ns-dt@ietfa.amsl.com>; Fri, 25 Sep 2020 07:25:48 -0700 (PDT)
Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam08on2059.outbound.protection.outlook.com [40.107.100.59]) (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 CC1383A0A8E for <teas-ns-dt@ietf.org>; Fri, 25 Sep 2020 07:25:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fjQD3zwzPdPN3BVuXuNy8VtXo3IitgqIQGrftTyU9H9AoyZNhAMNh5KbIbuOXL3V6Umetlt36lQIy/yWgNb4qDD9DOC+lzpa9qboZ9DaoYcn0OIjOmZhfwVWm2NodgyuQ8nqnfAkQsNoWNSaazetuoA7qW4QjIHTeqfS4incb+eosvyjBG94XjOuo6i/yQWLmdfyYmLu71lp7eDqr4V+IC6O23r4jQN9/klLqApIzVorb3E7CtgmkYwz55VTJmFpVn9ZnL3wDiWEpU1MouoCEnMVrSToDShvm5R0X5WGMABeRSc7adRONh6fu3l1l0WTKqow3+TX5mHAr+9RX7zSOw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oq9BGkmZGV1GlTR1hRUKdt31O9BQf2Qd3hCvS/lb1KM=; b=ivspBzGW7RCcFjBeKIxzRd/DO60aiDp/onFiVblUxbnuRJWL/TWpmX+E5G3EG8taxXkHg7CWbo46X69vMSXRtlhsbd2CEUOp7kGHP1EepZyme2aIkKVaMOUCeEBFtVKrX2YiOo1rnPdOFDBXXW73xhRX4h9J7rUa6DhTg16YX0eFliSrNDSzhcDjyhj1/Z8r8c1zP5cAcK75D0KVl7EA0gweYM+pPaye1uKBzmajQzV9oL5MP+h0jI797VCNTjaP/S6FoUqfgKjHw3P5hVdBT+oVNuyp2aa5e9Pq8Bj9jmIL7hrMC2t+92EEd7aE0LtM3skALUsxQJ4ouHFLhYJ1BQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oq9BGkmZGV1GlTR1hRUKdt31O9BQf2Qd3hCvS/lb1KM=; b=pweAUL0YCt5F7pcXS7wb5/QeWK8UFMaLjXEuG7cWcpOGMfO48tHQ/wvfhZ46IOGURqFiJDUhG3p0jMgXnJF3Deg86phbhfvso9ecg6BVSoW1/wUEWn1AdAwpL/N+VPGyWElf+ZDry9xABiiS3gnwDIuXnA11yoQrEdPgvLtkLI4=
Received: from MN2PR15MB3103.namprd15.prod.outlook.com (2603:10b6:208:f9::10) by MN2PR15MB2541.namprd15.prod.outlook.com (2603:10b6:208:122::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.22; Fri, 25 Sep 2020 14:25:41 +0000
Received: from MN2PR15MB3103.namprd15.prod.outlook.com ([fe80::e59a:ce0a:60d:9257]) by MN2PR15MB3103.namprd15.prod.outlook.com ([fe80::e59a:ce0a:60d:9257%7]) with mapi id 15.20.3412.024; Fri, 25 Sep 2020 14:25:41 +0000
From: Eric Gray <eric.gray@ericsson.com>
To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org>, "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
CC: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Lou Berger <lberger@labn.net>, "'BRUNGARD, DEBORAH A'" <db3546@att.com>, Vishnu Pavan Beeram <vbeeram=40juniper.net@dmarc.ietf.org>
Thread-Topic: Brief meeting notes
Thread-Index: AQHWkpB0qRU6hCn3nkSOh3i8Q715Jal4J//QgAANuPA=
Date: Fri, 25 Sep 2020 14:25:41 +0000
Message-ID: <MN2PR15MB3103126C9F7A524CE72CC5D597360@MN2PR15MB3103.namprd15.prod.outlook.com>
References: <2FD2FD24-3C5D-4C79-90CB-41F958D4218E@ericsson.com> <DM5PR05MB338852A1FD0231671F8C4BB5C7390@DM5PR05MB3388.namprd05.prod.outlook.com>
In-Reply-To: <DM5PR05MB338852A1FD0231671F8C4BB5C7390@DM5PR05MB3388.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-09-24T19:41:35Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=31e408c3-4ff2-4e59-826f-96526eb207f0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [73.248.143.71]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b96ca10c-751e-457b-77c0-08d8615ee1b2
x-ms-traffictypediagnostic: MN2PR15MB2541:
x-microsoft-antispam-prvs: <MN2PR15MB2541531BEF220B89CD6C909697360@MN2PR15MB2541.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: PI6o+NJm6RPP/RlBox4lMYg1lzZYMVyfTOYvqQ0RySHHgtmriU9sa/1qiz2j9dq6J2ti5fUyJRjai8i6HgiMCH8eQahGFzxeOuRYDupzd9J0ItVWMMeb034M5Bh+nVVkPoNHkAXpi7djCGWR2fSgCVC4uWk0VZylMcVYRGOvn3L/qjST272J5Ru3xaz/J/SpE8WAroh5XyQc+vTPY0nxLJ23m7ivsMDvOkCWr9iN3mj0nZy3ffkz9bm7gttREFEciw1qJasG/qFbxj9WWkrLmxOYmQ5n86Zp66pzI2lfu6tyTnU1BlVW8vAcyW1OU3SjXPjWz/tUryrRvcK6ykjfWRA7dm/kW9h8kQhDj43BM8ZjeITnaYH5RYjGzk8/6Wrn
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR15MB3103.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(39860400002)(346002)(396003)(366004)(54906003)(9686003)(110136005)(8676002)(71200400001)(83380400001)(86362001)(52536014)(478600001)(7116003)(3480700007)(55016002)(64756008)(66476007)(5660300002)(66946007)(8936002)(66556008)(66446008)(76116006)(316002)(4326008)(53546011)(186003)(26005)(44832011)(33656002)(6506007)(2906002)(7696005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: B+YrGcayKLVJqZBca9AwL3LyT06fZoQHu0bcgkIo+N+vjZRqAia42iqpdyi7Bx9DzjvV4onGIcwWsIN3+TuZLUYV2RyYRi55szMy7um0+h/nmLkcvPW/f5+HydC0GcDH4ix/9i36w6bQhVZSvUwbJ7n5RG9FBU21HgWA3Wz9cpalgP4OeTn+T2kLHYgQKQUxhX7yH/KRPl0DiT94wEh88rnFU7GnJwGfoSt7eZV17U6RhPBtsG12Z7E87J6iPQhkp79rkdWY26G4f3MwITjV3dObWrCjhGvXTUz61q27IyX9cHSdGOgPRYqY7RDawYXvM9rOxKV8pgtyoG1/b1pCKepxtlRwDzMZEBvaoZFRWOwKF5mIwjXbP0hCMjDPgKQnmehAKXT6Gj6m1sTv2qyr6gdqTpik2takKKmQIE7RU0lIF8xKBou4zhlIbo89G2qACMjCuuqMz/wvyXQsoqZ8SiaJpVw4xL/vn6PzcKbYDJ5eVroytqfT7irKhSUbCzL1HOhcpMVo2l6/Pi3/NIHOGNsKVyvtfoSztY6iyzBE5SOHvXy1kA0QtWhPL36VvO8NAiuc7niD1+OL0Fiice9pf3iPd2z6aJqx9IhuG+JMhCV3N7psb5TJXoI58DuI9+ZWLzWOOXXkDKmrGRu+DU4jFQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR15MB3103126C9F7A524CE72CC5D597360MN2PR15MB3103namp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR15MB3103.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b96ca10c-751e-457b-77c0-08d8615ee1b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2020 14:25:41.2605 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Vo2wT22UOTdsRixhuQhGl6nETl8RQjxDuwxeAuDxFt++Fs0TRFElo+lCE6dJS/sSdmlPWokstJIoyUUP++7xgA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR15MB2541
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/tIZ5XBe9onVn60a4bYOTjUMRxSw>
Subject: Re: [Teas-ns-dt] Brief meeting notes
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: Fri, 25 Sep 2020 14:25:50 -0000

I’ve added further to the points John made in his mail, below…

--
Eric

From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org> On Behalf Of John E Drake
Sent: Thursday, September 24, 2020 3:42 PM
To: Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org>; teas-ns-dt@ietf.org
Cc: adrian@olddog.co.uk; Lou Berger <lberger@labn.net>; 'BRUNGARD, DEBORAH A' <db3546@att.com>; Vishnu Pavan Beeram <vbeeram=40juniper.net@dmarc.ietf.org>
Subject: Re: [Teas-ns-dt] Brief meeting notes

Hi,

I just wanted to comment on some of the statements that were made during the conference call today.  I think it’s important that we have a written record rather than trying to respond during the conference call.


  1.  Reza said that we couldn’t use the term ‘network slice’ because 3GPP uses the term ‘E2E network slice’.  Obviously, ‘network slice’ is a different term than ‘E2E network slice’ so this is nonsense.  Further, the definition of the term ‘E2E network slice’ would appear to be the concatenation of two or more ‘network slices’.

There is some confusion in this part of the discussion.  The concern (from the perspective of folks who deal with more than one other SDO, besides the IETF) is that a reader may be confused by the use of the term/phrase also used in another context, being used in a different way in an IETF context.  Nobody can reasonably argue that the IETF – generally – cannot use the phrase “network slice” because there is ample evidence to support the conclusion that we do use it and have been using it for a considerable period of time.

One thing we have learned repeatedly in the IETF – and, in my personal experience at least, in other SDOs – is that the phrase “end to end” is a fundamentally useless qualifier without significant context information.  Since we do not need this concept in order to describe support requirements for IETF Network Slices (or Slice Services) in a single domain, we can (and should) avoid spending much time in discussing it.

In order to avoid the concerns about potential confusion, however, we need only provide a brief explanation of how an “IETF Network Slice” would be used (or what it might be known as) in other groups or organizations.  The hardest part about doing this is deciding where to do it – which is a key reason for sticking to providing a few relevant term/phrase definitions in the current definition draft and delegating the task of explaining the applicability of IETF Network Slices to other contexts to a section added explicitly for that purpose to the Framework draft, or a separate “Applicability Draft.”


  1.  Kiran said that the network slicing was introducing an entirely new concept to the IETF.  The last time I checked, there were roughly 20-30 drafts or RFCs on the topic of network slicing, all of which pre-date anything the NSDT has published and all of which use the term ‘network slicing’

I’m not sure if Kiran actually said this, but it is a common enough belief.  I doubt anyone can claim certain knowledge of who used the phrase first, but it is fairly obvious that a number of distinct standards organizations have been using “network slice/slices/slicing” for quite a while.


  1.  Kiran said that ‘transport network’ was a common term in the IETF.  This is incorrect.  ‘Transport Network’ is an ITU term and the only time it is used in the IETF is in support of the ITU’s use of MPLS.  This is MPLS-TP (transport profile).

If you look a little into the structure and history of the IETF, you will see quite quickly why it is that the term “Transport” is used with considerable reluctance in the IETF to mean anything other than the “Transport” layer originally included in the (now more than a little archaic) OSI seven-layer model.  The many ways that layering is done now can be confusing enough, without referring to any of the bottom three layers as “Transport” as well.

As an SDO, while we want to make an effort to avoid confusing the industry, our first responsibility is to avoid confusing ourselves.  😊


  1.  Kiran said that term ‘IETF network slice’ is not generic.  Why is it important that the term we use be generic and why is this term not generic?

Again, I am not sure I heard Kiran say this, precisely, but someone may have and many may have interpreted what was said as meaning this.  In fact, it may look like there are a number of possibly distinct network slice concepts in the IETF.  But this is mostly because of the work in different drafts having a focus on how to use some specific subset of one or more technologies to support what has become an increasingly stable concept of a network slice in an IETF context (hence, an “IETF Network Slice”).

In order to make an IETF Network Slice generic, we have to abstract the means for creating an IETF Network Slice from what the result looks like to a consumer.

This is what the industry as a whole typically refers to as a service model – i.e. – how we define a service in terms of things that a consumer can actually determine as service objectives that the service is meeting.


  1.  Kiran said that the NBI was not a service definition.  I think this is nonsense – otherwise, why do we have ‘service level objectives’?

And this is the clincher.  If we are modeling whatever it is that we are providing using “service (level) objectives,” then what we are defining is a service model.

Further, any discussion of isolation should be in terms of the variation of an SLO parameter’s value, since this is the only thing a customer can measure as the instantiation of its ‘service’.  E.g., absolute isolation would mean that a given SLO parameter’s value is invariant.

Personally, I think that “isolation” us a topic best discussed separately.

Yours Irrespectively,

John


- - - [SNIP] - - -