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

"Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com> Fri, 25 September 2020 15:05 UTC

Return-Path: <reza.rokui@nokia.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 7490B3A0E3E for <teas-ns-dt@ietfa.amsl.com>; Fri, 25 Sep 2020 08:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.595
X-Spam-Level:
X-Spam-Status: No, score=-3.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 jPIPPygJe3wA for <teas-ns-dt@ietfa.amsl.com>; Fri, 25 Sep 2020 08:05:10 -0700 (PDT)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2090.outbound.protection.outlook.com [40.107.243.90]) (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 BD71B3A0D3C for <teas-ns-dt@ietf.org>; Fri, 25 Sep 2020 08:05:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m4u+Dnix1gBtm6QRvb84Dnq+b04EHgq2dzNvHSdrhKkPlpJCdF/DWDLu2YdU4UoKpXm3SiVLy6CXrqVhyLD+kS17Ig99fpxSQ3i9waCXkOYohACg8h3vnXzT0exwHi6FVp3gm3fGUdXJbpkSaOii6MPgdXZOCOx80acs7El3lPMf0lvUeFKNLWv0TJg+3mAO9DCZel00wMNTUklGeYWJxLt1Zhtp5FZgVrtY/3ghn6qKvNJTv6ydosnmsWEV6TdxEDfedQ5Np4YqlgWdxnWcrVnbuCPm4GOqv3ozN9w2ABTni2ljxCkSGW/ZBxBjDZs3nL8uIQph9BU5WfHd2dl2rQ==
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=V1fbrmoMVKNsKwMAGAYCVFmV1T2R4900EvEa7TAJZGw=; b=Rqu2iXTxlLhvMz+DE84Ttw/pcs+lUZ22aPfDPzbyMLfaQpsbWcZnHNIrSA1pgPrZxCcCRj9CDojiWxtwyCoyNlUvOdLmhcefMZcmXx+XQn8LqcY08WO6eXNSZkv2leJ37wMgx2ZWMz5p122qvqhca+6LjhzqWUZuOxKGVgq7302vy8Qzhr7dbgNIZBQ7+XLl9yxSD0D7b7sVsGXYmgh305kOEmQNNHOH4Xpbno03B3k9oM2Qjr/f3+LPZ60DlDrM7PGyZLdVSvjgZDXkPUprm2oQLlZch6pk1iCHsspbKJWsbsJIIzPbEEvy2S81DRNFh3UImr66RUlbC+CA3KDBCQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V1fbrmoMVKNsKwMAGAYCVFmV1T2R4900EvEa7TAJZGw=; b=cDq+eu+OIa5O4wx0DbgtOJJ8+fMJvL17lnBSgJvhTpDpjAId2YzsDF3RA0Le7lgX7PwPsIKtD5Xz9V4VO3nKcAimN8DGCxnERY7DltS4G1Au3+GIg3liMqXtJi5AtPXcN++bPoB9vajJ6Jcbk+/8CPu98Mw4jdHNWWZ2mJiCneo=
Received: from DM6PR08MB6331.namprd08.prod.outlook.com (2603:10b6:5:1ee::8) by DM5PR0801MB3670.namprd08.prod.outlook.com (2603:10b6:4:7a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.26; Fri, 25 Sep 2020 15:04:57 +0000
Received: from DM6PR08MB6331.namprd08.prod.outlook.com ([fe80::8d69:2e65:578c:54af]) by DM6PR08MB6331.namprd08.prod.outlook.com ([fe80::8d69:2e65:578c:54af%6]) with mapi id 15.20.3412.022; Fri, 25 Sep 2020 15:04:57 +0000
From: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>
To: "BRUNGARD, DEBORAH A" <db3546@att.com>
CC: Lou Berger <lberger@labn.net>, Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, Vishnu Pavan Beeram <vbeeram=40juniper.net@dmarc.ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>, "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>
Thread-Topic: [Teas-ns-dt] Brief meeting notes
Thread-Index: AQHWk007XoODSDqBvUik//fyekBPZw==
Date: Fri, 25 Sep 2020 15:04:56 +0000
Message-ID: <203E6439-3BB2-481E-A686-89E365941E84@nokia.com>
References: <1A1D96DA-199E-43CC-ADEC-B86D69E7F7CC@nokia.com> <0FE617D3-7483-499E-9CCC-C9CDC05238FC@att.com>
In-Reply-To: <0FE617D3-7483-499E-9CCC-C9CDC05238FC@att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.41.20091302
authentication-results: att.com; dkim=none (message not signed) header.d=none;att.com; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [24.246.4.36]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 196fcb17-db66-459b-1c71-08d861645dce
x-ms-traffictypediagnostic: DM5PR0801MB3670:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM5PR0801MB36701F5EEAD18C38E9439E609F360@DM5PR0801MB3670.namprd08.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: 7qTdfVlJ1Q8e3i3BrmCAX2zKDN7L6k0/GC+U4jRpe173NKBUJ64/iV7LOkuJdINVc5CeguGFhZvnXNLbJqPZ9TjEr0F1zJurbbdS6bwmw+ZmTlkXuzEd8XwiLohuSRaoSAbjEQjSXqbPKWrPRjp7MSBj/nBpdqqhB/+Hg6JiVyI2hSxZgIk53f3k+rerXa3w9zGYCjHeYIC2S7new48vDkvYinRtQYsR9iLzwvnH0y2N5km3x71Y8mIoxoMberAvyeORx6lEzUBG+qoidpCyipc2oTl+hs03m5Vr7MCCo459OexGyzS5t7PXPCgZ+3u3pQn7juvPtIiJEO3bl+VRUb4P/Mwou8r3nDT0vidT+a1OI2Eet940AJ4WglmWIAgg
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB6331.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(366004)(39860400002)(396003)(376002)(186003)(6486002)(53546011)(36756003)(316002)(6506007)(2616005)(8676002)(71200400001)(26005)(9326002)(86362001)(91956017)(107886003)(478600001)(99936003)(66446008)(5660300002)(66946007)(66616009)(76116006)(2906002)(66556008)(6512007)(66476007)(64756008)(4326008)(54906003)(8936002)(6916009)(33656002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 2uxCEc8tXqm3U5haFlCtU23wQSIOkIn2w+dFiw5Zn2kWqu919P0RcP1iuJ/sc7EKXSTPl4bvLNjcsT5Ilqy/xFLDJy1a3ojUyq783Lq8PoJn1b3Ywoix2eRLe9zbI3b9MksZD8cxh/DzGQwivGcNUWtMwXeXdskuf2E9IFt4N2YQ4Xg0XcNigvs4zzJ1nUDpyze1vPzQ2RLlXrnl1mbmgiJs3gaxFJTadkJq3JT051Tgj2fi98zECHRgG3biOswwhNqEfD7fJPWaiS+ZOl7S2aBgpqIOva2wCApbyruZuviWTszZ1KMzjzvQsk2L0Lhq/YxjdEZtBWq8eFppRdQFoVZ+6xndTwD4Bh02n0xyCOJZmfhmaGK8HywePfyZownSBFha7CiPQhD4YH4LW3SkUzJkXuhqvccW5PNRGSJ8o5q58sHMZ1H0NF5k6pmzhLcHtldhynftfcIAHRhfVWGKH32ncGbhR29zg1ZG4HheBOWcRcgmViV0j7OCJeiQDm8KQPGdGfnGgLE0aI9F7KCnKAxCuOcKls7jXkHjwUvgX9mbMn0fbybJgwUrqIonRLVcmQAsGHi6BeqdFxejvAi7sPI6hj+S4syF6CtiX/0IuHxmrFHsAWsKTi+mV7pMIr18TMb/DYKu7JngIAqM30aFJQ==
Content-Type: multipart/related; boundary="_004_203E64393BB2481EA68689E365941E84nokiacom_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB6331.namprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 196fcb17-db66-459b-1c71-08d861645dce
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2020 15:04:56.9993 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MF4+mzy/Kz+5JoWtbP+nsNWfaQ40KsctyyURQ7dPl6wyX4MI4PtSgUDYpAg1UWHdlEBHizDTDBJIOUHFJsUl5Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0801MB3670
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/8ebqDggqkPreLy6SQX2HI48N0qM>
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 15:05:13 -0000

Hi Deborah,

Thanks for your email. Before answering your email, I have one question for you.
Please clarify the phrase “E2E slice”; are you referring  to“E2E network slice” or “Connections” in picture below? Or something else?

Cheers,
Reza

[cid:image001.png@01D6932B.B3354D60]


From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org> on behalf of "BRUNGARD, DEBORAH A" <db3546@att.com>
Date: Friday, September 25, 2020 at 10:01 AM
To: Reza Rokui <reza.rokui@nokia.com>
Cc: Lou Berger <lberger@labn.net>, Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, Vishnu Pavan Beeram <vbeeram=40juniper.net@dmarc.ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
Subject: Re: [Teas-ns-dt] Brief meeting notes

Hi Reza,

<AD hat off>

It’s good to see not stuck on using a 3GPP term.

As I think both Adrian and I noted before, I think we are approaching this with a different end model in mind. It depends how one wants to view this operationally. I’d say some basic operational requirements are:
- ability for the E2E slice to traverse multiple domains
- ability for each domain to efficiently provide the E2E slice the appropriate parameters - and this includes the ability to combine multiple E2E slices for supporting over the domain.
- ability for the E2E slice to be identified and each domain needs to have the ability to identify the slice and the mapping in its domain
- critical - it must not be assumed there is a one to one mapping between control/service entities and physical entities. As an operator, why I am so sensitive on the term transport, because it infers physical entities. Both ITU and IETF operators no longer look at our world as 1:1 “transport” pipes, it is a “network”, and that is critical for our operations to be intelligent.

In ccamp and teas, we’ve modeled this in the past using the same term for the different domains (and ITU and ETSI do also) - this is why we are questioning why need now a different term within a domain. It complicates operationally.

RFC4726 describes an E2E LSP and the multiple ways to support it across a domain. Each domain still uses the same term, LSP. And there are many models for supporting.

As you were wondering on proprietary domains (an earlier thread), one could also use the ASON model, RFC4139. The E2E is a “call”. Each domain is a “call segment”, including the proprietary domain. Operationally, all domains know exactly the reference.

Here, can use the term E2E network slice segments for the “connections” in the domain. Don’t forget in each domain, they will be supported by other network slices - hierarchical slices. So what you are referring to as connections may be a “network slice”. There needs to be an independence between control and realization in the network.

Thanks,
Deborah

Sent from my iPhone


On Sep 25, 2020, at 8:28 AM, Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com> wrote:
John,

                >>>> Reza said that we couldn’t use the term ‘network slice’ because 3GPP uses the term ‘E2E network slice’.

This is not correct and this is not what has been said. It has nothing to do with 3GPP.
Whatever I mentioned was that an ‘E2E Network Slice” Is a concept between multiple users and for an operator to create it, it need to create one or more artifacts for various “Connections”.
Calling these Connections “Network Slice” is not accurate as they are part of the “E2E Network Slice”

Reza


From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org> on behalf of John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
Date: Thursday, September 24, 2020 at 3:41 PM
To: 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>
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’.
  2.  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’
  3.  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).
  4.  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?
  5.  Kiran said that the NBI was not a service definition.  I think this is nonsense – otherwise, why do we have ‘service level objectives’?

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.

Yours Irrespectively,

John



Juniper Business Use Only
From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org> On Behalf Of Jari Arkko
Sent: Thursday, September 24, 2020 12:34 PM
To: teas-ns-dt@ietf.org
Subject: [Teas-ns-dt] Brief meeting notes

[External Email. Be cautious of content]

Situation:
- Documents not adopted as is

Process:
- we need to revise based on feedback and ask again
- wait on framework until definitions agreed
- interim on Oct 19

Main changes:
1/ need to use a different term
- Perhaps more about the name itself than its definition – but also have to worry about the latter. Maybe easier to discuss once the name is not objectionable?
- We all recognize the feedback, and agree not to use transport network slice term
- IETF network slice one contender, some resistance
2/ isolation
- Need acceptable content, not just a placeholder
- Need to understand which approach to use, though (Jari recommended explaining how the term relates to this work, perhaps some breakdown of the term as well)

Next steps:
- For each issue/change, a small team to look at it, provide some options, and analysis of the implications and tradeoffs in those options
- Post early to main TEAS WG list, keep discussion ongoing
- Jari can arrange a weekly call starting next week (again, posted to main list) for those who want to discuss in real-time. But useful only after the above two steps are done first.
- Responsible people: on the name issue, the author team; on isolation Luis, Jie, and Jeff will work on it
- Everyone else to stay active on list + comment and make counter proposals and additional analysis