Re: [Teas-ns-dt] issue discussion: NF resource

Kiran Makhijani <kiranm@futurewei.com> Mon, 01 June 2020 19:30 UTC

Return-Path: <kiranm@futurewei.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 12C0B3A1497 for <teas-ns-dt@ietfa.amsl.com>; Mon, 1 Jun 2020 12:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 TruK1lsUp5R4 for <teas-ns-dt@ietfa.amsl.com>; Mon, 1 Jun 2020 12:30:09 -0700 (PDT)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2106.outbound.protection.outlook.com [40.107.223.106]) (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 ED7633A1286 for <teas-ns-dt@ietf.org>; Mon, 1 Jun 2020 12:30:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OX5+YBYuRb5ARbmdn7eyfO2oDo1Vhq0wRrxdWufadjDNXjgXLBi40GsI2RNDqZ7RvJNbT6hO9rHkuYT+9aT/oIxTLRM/xPLsoxnGp0MGoKW4IQ2tdm72Z3yUH9ZUd0oR72n75w4FGSZqW33oEFmpJa2BZsZbC2JzvtFLun01ifC0btsm72ZQrx4DjSPRqwL6hWywAzrPLL+GBkNBvo0EzJPaXXK7PlVtygzHq8JI8Mc9vFTgI5m2PuIA+J21/aOgGsPPrjIDE6vkludJYOJrc7RuCgr7SGdspHKwHvUe5Pj2OoBhU9wJbvDZiXUGnSHGbBGru6zJ5jCR9Cd2ZpIUNw==
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=r2H6G1UTUWcUBwZ3vPtW3bCcdBx4fINcLOMQAtUTrjg=; b=YfBsfa/PybQ4Kgg0Z09u0cL87sPn+0VR/OUT5MKdKFezYW16Z0xwPjOtCzK2nAFc3+PQKB199QldUSmEuZbZlzWDTKC12qXvaiKCVSnmzaW0twyqHynWjNyX/Q5jlUGp9OFQ2Jo18KwhRYUxmYkde9pHq+vHr5jIwCKUpQ2Fhr2BMMO/n2EcyWhKsXyoLLAT9dD/yaQ8sq3IMziofIQLm2DtNOphsbBZFPVwKK54h8qqvuz3dkuVxx0ZD2HMZ4IvBgoLWjLY3YUFGQu8GDV011JdlLHt6CcrbCEAAm5HHgsZ3LjCIp5/p1QTtSAJYAAdLY9vNl7DVvWExs2gI6TAxA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r2H6G1UTUWcUBwZ3vPtW3bCcdBx4fINcLOMQAtUTrjg=; b=jia7FQm69qWg2wj6OnFxcDnO/4kMsfhoSNcp2SR3VLxXi7/SG7qYjaH4nTqXqVFFlZk1/X42EoVuXBC+TklVPxKCS3JVOzLHP4unvFEdpRpSmGeBxTvT2VYcUkR2iZuqMOhjby0lPzkcy5VFcyNOpDN/lEJZDITq1UDFAhUIK/A=
Received: from BYAPR13MB2437.namprd13.prod.outlook.com (2603:10b6:a02:cb::23) by BYAPR13MB2726.namprd13.prod.outlook.com (2603:10b6:a03:f9::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.7; Mon, 1 Jun 2020 19:30:06 +0000
Received: from BYAPR13MB2437.namprd13.prod.outlook.com ([fe80::8c6a:9bdd:5a1d:fd6e]) by BYAPR13MB2437.namprd13.prod.outlook.com ([fe80::8c6a:9bdd:5a1d:fd6e%4]) with mapi id 15.20.3066.014; Mon, 1 Jun 2020 19:30:05 +0000
From: Kiran Makhijani <kiranm@futurewei.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
Thread-Topic: [Teas-ns-dt] issue discussion: NF resource
Thread-Index: AdY1Ix0SreAxhV/TS9uVsZhhZuI53gAGlXGAAAKRtYAABHcZAAC7RIgA
Date: Mon, 1 Jun 2020 19:30:05 +0000
Message-ID: <BYAPR13MB243743825A4E6AF08BDCFCF3D98A0@BYAPR13MB2437.namprd13.prod.outlook.com>
References: <BYAPR13MB243703FF3232B71DEB810033D98E0@BYAPR13MB2437.namprd13.prod.outlook.com> <CA+RyBmUwMJRFKMRA-rpcZ=Zc3orgjUbQKt0xztWT0MZE2Vq-hg@mail.gmail.com> <BYAPR13MB24370CD6260226A84ED26E82D98E0@BYAPR13MB2437.namprd13.prod.outlook.com> <CA+RyBmVEO9t4M-na7+f_Y+1CMQG=SY9vvbU=EmMbOep1sEbcRw@mail.gmail.com>
In-Reply-To: <CA+RyBmVEO9t4M-na7+f_Y+1CMQG=SY9vvbU=EmMbOep1sEbcRw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [67.188.27.49]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 03f063cd-7494-4c1c-bfe9-08d806623044
x-ms-traffictypediagnostic: BYAPR13MB2726:
x-microsoft-antispam-prvs: <BYAPR13MB2726FDD285828D6A7588F37DD98A0@BYAPR13MB2726.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0421BF7135
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: odwkdA1ZikllMA1Lo/x2IALypWG+zdux1ZmWgQQMNCOlz3wwqfSAH8tRE1TiIdX6LbVnyLgVh7K/m971JQIi07NHmPObwAmUtXAQywTy4uH8IVJJlTl5F0vmo9L+uN9SttBrCeuPjAe0WBQweZaVcVp9+ST1M4gJ9LP9tKznQ9DIO687va8E5iyjiwCLCjNgvhhh3paQDHqdoW+gdzR31GSRXORWpzAUc28zxnrstoMQTVUuO2XPLjX8T6rDk3nZ6q4BhPqM6/9ilmCz2YtU6uH3zH/Afk9rIK4fKE/k7i5Ve4GhJXQ+2ftUSWjrSRrbwms6KZ2kLkk/AhcHZto8WmmuwuDo9VAnDpPwcaqp6AiNS89Zl7bicodwA7Qi0u6sXOY2gCYqHWTwo1NDcu+olQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR13MB2437.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39850400004)(136003)(346002)(376002)(396003)(366004)(8936002)(33656002)(186003)(52536014)(71200400001)(83380400001)(9686003)(9326002)(316002)(26005)(5660300002)(66476007)(478600001)(66446008)(64756008)(66556008)(4326008)(7696005)(66946007)(86362001)(2906002)(55016002)(8676002)(166002)(6916009)(6506007)(53546011)(76116006)(966005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: a7rJI1w80+06vhyQVmQuoSxE3Cc9W6quGiYnEUesXwHrZqowaYHTK90bQpxAtIrzTzB1FbCAAwRMRETsvfJyU4oUr6mNLlQaJg0HdZ6udpebw5vqQFW5ATEq5tUpAhLf3RVLYDuqeany/BkUioNBbKzzgOaJ/6kzVF6FJC3cZZroPPyWI/VqVdCzB58+H4BLfXyLsX55RWMF6o9EgMvQrqTGGPvYRTrPAFtWwBKvQKa1giSvoJP1axawpXEnfk22CGmog0gqfy/0arZbmV46zIn0RMJek/6e1sCyUtNjEm6lrzK6JEHqZl71AyhiHG8hicKAhcpecyppvosFeFx73SKkKUZTVy6f+tnkEhejOWnE9o/cj0UDLdpf8rak9bdqOsRoiLy6Haz0UQo2fmPrzruM0kMlR2YMJoz+B7EA8SjoNJ6wFWEsh6IljY/8AY6Hls3qDipskxYo32KWZXjqKv77Eb1AIuIhIim9YH3HufQ=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR13MB243743825A4E6AF08BDCFCF3D98A0BYAPR13MB2437namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 03f063cd-7494-4c1c-bfe9-08d806623044
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2020 19:30:05.7829 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: CDy4OSFvDdsCTIQX598bHIUhinIds2qjkEWRWLln3J+lTRWKxa8uwD0h0UAimrOnAxheVhZKXopBL/hTZwUAjQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2726
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/PIPjWGZiGq6P_mHDdumEcM0jj3Y>
Subject: Re: [Teas-ns-dt] issue discussion: NF resource
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: Mon, 01 Jun 2020 19:30:11 -0000

Hi Greg,
In order to resolve the issue:
Since the section is “Minimum SLOs”, I agree to “move it outside the minimal”.

My actual reply would put us back in the loop: If an operator gave less cpu and firewall runs slow then the user is not happy. Shouldn’t they be able to provide some criteria to get their ideal performance? How do you meet that objective upfront?
-Kiran

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Thursday, May 28, 2020 6:37 PM
To: Kiran Makhijani <kiranm@futurewei.com>
Cc: teas-ns-dt@ietf.org
Subject: Re: [Teas-ns-dt] issue discussion: NF resource

Hi Kiran,
thank you for your kind consideration of my comments. If we agree that a customer of a TS may specify a certain TS behavior that is externally observable on data packets, then I don't find where elements like "memory", "computing power" fit. I think that these are important to an operator when choosing the most economical and efficient method to realize the TS according to the specific LSO.
What do you think?

Regards,
Greg

On Thu, May 28, 2020 at 4:56 PM Kiran Makhijani <kiranm@futurewei.com<mailto:kiranm@futurewei.com>> wrote:
Hi Greg,
You are right. I should not have used term ‘virtual’ – I was visualizing a NF container in NBI data model. A user of transport slice just asks for a NF and associated properties. Whether it’s V- or P- is a realization time decision.

I see NFs adding a lot of value from higher-layer perspective, without getting bogged down about network details users can attach app specific firewalls, IDS, and caching type of functions on the endpoints. These are all good examples for use of NFs in slices. Secondly you will be able to express your requirement from a single place instead of dealing with different interfaces.

<your quote>
the TS does not specify which NFs should compose the TS but only what is the functional behavior and performance provided by the TS.
^^^
I hope you agree that there’s a need for some “functional behavior”. If user can leverage provider network for that behavior, then why not?
-Kiran


From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Sent: Thursday, May 28, 2020 3:15 PM
To: Kiran Makhijani <kiranm@futurewei.com<mailto:kiranm@futurewei.com>>
Cc: teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>
Subject: Re: [Teas-ns-dt] issue discussion: NF resource

Hi Kiran,
I think that an NF can be realized as a physical device or a VM. Would you agree? If that is the case, then, in my opinion, we cannot consider only the VNF case but add the PNF case as well.
Also, I don't see the real benefit to have NF, in all their variety now and more in the future, as part of a TS. I think that NF is either part of the TS implementation and thus is selected by an operator based on the SLO. Or part of a service that uses the TS. In the model I have in mind, a client of the TS does not specify which NFs should compose the TS but only what is the functional behavior and performance provided by the TS.

On Thu, May 28, 2020 at 12:06 PM Kiran Makhijani <kiranm@futurewei.com<mailto:kiranm@futurewei.com>> wrote:
Hi All,
To kick off discussion on this topic.

During earlier discussions several of us asked for network functions should be part of the slices. For me the value of doing this is to be able to express different nuances of a service through single set of objectives. Then in NBI and implementation there is one controller to monitor the performance.

At the entry and exit of transport slices, these NF can be supplied to enforce access control, policies, etc. on transport slice traffic. It is also safe to assume that they will be virtual.

The objective is to apply those function on  traffic flows.
2 examples are  (1) use of firewall at entry point with the rules described by the user of transport slice. (2) Caching or DPI function on exit endpoints.


Regards
Kiran

--
Teas-ns-dt mailing list
Teas-ns-dt@ietf.org<mailto:Teas-ns-dt@ietf.org>
https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt&data=02%7C01%7Ckiranm%40futurewei.com%7Cf693a0401cb94a59ee0708d80370c0f7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263130100769061&sdata=ppr3yiBDq1%2BAZbFsYnhwGugLb27aVuEoBtBY45kXOdc%3D&reserved=0>