Re: [Netslices] COMS: What next?

"Dongjie (Jimmy)" <jie.dong@huawei.com> Wed, 09 May 2018 07:29 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: netslices@ietfa.amsl.com
Delivered-To: netslices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAD512D87F; Wed, 9 May 2018 00:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 ME0c7wqq5D_6; Wed, 9 May 2018 00:29:01 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 73B27126DCA; Wed, 9 May 2018 00:29:00 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DDF384970D9FC; Wed, 9 May 2018 08:28:55 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 9 May 2018 08:28:57 +0100
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.29]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0382.000; Wed, 9 May 2018 15:28:49 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Alex Galis <a.galis@ucl.ac.uk>
CC: Adrian Farrel <adrian@olddog.co.uk>, Stewart Bryant <stewart.bryant@gmail.com>, "ops-ads@ietf.org" <ops-ads@ietf.org>, "netslices@ietf.org" <netslices@ietf.org>, "netslicing-chairs@ietf.org" <netslicing-chairs@ietf.org>
Thread-Topic: [Netslices] COMS: What next?
Thread-Index: AdPlILgAX/KKfPLpSf+RkPW5V/OfRwAJkBIAAEa1VgAAATmFAAAHVpeAAAGiIIAANdxegA==
Date: Wed, 09 May 2018 07:28:49 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C9279844EF14@NKGEML515-MBS.china.huawei.com>
References: <DB3PR03MB0969078FA60DD302A2D35E2E9D840@DB3PR03MB0969.eurprd03.prod.outlook.com> <003601d3e58a$07fdfdd0$17f9f970$@olddog.co.uk> <DB5PR0301MB1909011B75FBF439E36FF16F9D9A0@DB5PR0301MB1909.eurprd03.prod.outlook.com> <007001d3e6a9$c3dc1bc0$4b945340$@olddog.co.uk> <504803DE-7EBC-4EC4-8290-CC38E9D8E2F8@ucl.ac.uk> <DB5PR0301MB19095471BB00DBB6BA3AC7649D9A0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
In-Reply-To: <DB5PR0301MB19095471BB00DBB6BA3AC7649D9A0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.151.75]
Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C9279844EF14NKGEML515MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netslices/aCiA8JrbyPRq-mvvqHyMUwSKcLg>
Subject: Re: [Netslices] COMS: What next?
X-BeenThere: netslices@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This list is intended for discussion and review of network slicing at IETF." <netslices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netslices>, <mailto:netslices-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netslices/>
List-Post: <mailto:netslices@ietf.org>
List-Help: <mailto:netslices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netslices>, <mailto:netslices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 May 2018 07:29:04 -0000

Hi Sasha,

Yes some aspects of network slicing are currently handled by existing IETF WGs. The enhanced VPN draft you mentioned aims to provide a layered framework and the candidate technology components. Based on the discussion in RTGWG on last IETF meeting, this draft will be moved to TEAS WG to move forward.

And I totally agree that segment routing in SPRING WG is relevant due to the advantages you mentioned, while some enhancement may be needed to achieve the required isolation between network slices. Currently there is another draft which describes the mechanism of using SR for enhanced VPNs: https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-00

Best regards,
Jie

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Tuesday, May 08, 2018 9:08 PM
To: Alex Galis <a.galis@ucl.ac.uk>
Cc: Adrian Farrel <adrian@olddog.co.uk>; Stewart Bryant <stewart.bryant@gmail.com>; ops-ads@ietf.org; netslices@ietf.org; netslicing-chairs@ietf.org
Subject: Re: [Netslices] COMS: What next?


Alex,

Lots of thanks for a prompt response.



I would like to clarify my position regarding network slicing:



1.       I am not sure if L2/L3VPN are "primitive" network slices.

a.       Rather, I see network slices as both services (provided by the Slice Provider to a Slice Tenant) and virtual networks in their own right  (that could be used by the Slice Tenants to provide L2/L3VPN services to their customers).

b.      I think that this matches (more or less and notwithstanding some terminology differences) the approach to network virtualization taken by ITU-T in Recommendations Y.3011 and Y.1312

c.       Calling a L2/L3VPN service instance a “primitive” slice on top of which exactly one service is instantiated looks an exaggeration to me.

2.       The dualistic approach to network slices  mentioned above affects many aspects of networking:

a.       Some of these aspects are already handled (to some extent) by various IETF WGs. E.g., I think that SPRING WG work on Segment Routing (SR) may be highly relevant for network slicing because it facilitates setup of intra-slice traffic-engineered paths by the Slice Tenants without adding CP and DP state for these paths in transit nodes crossed by these paths and without any per-TE path interaction with the Slice Provider. I believe that this matches the approach presented in the Enhanced VPN<https://tools.ietf.org/html/draft-bryant-rtgwg-enhanced-vpn-02> draft

b.      Some of these aspects are not, to the best of my knowledge, handled by the existing IETF WGs.

                                                                  i.      One of these is the YANG data model for Network Slice as a Service I have mentioned as a reasonable objective for a yet-to-be-created WG

                                                                 ii.      Such a model could reuse some elements of the L2/L3VPN service data models, e.g., the some of the parameters that describe interconnection between the “slice tenant edge” devices and edge devices of its customers

3.       There are also some aspects of network slicing that should be left out of scope of the IETF work.



Not sure if this helps.



Regards,

Sasha



Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>





-----Original Message-----
From: Alex Galis [mailto:a.galis@ucl.ac.uk]
Sent: Tuesday, May 8, 2018 3:22 PM
To: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Cc: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>; ops-ads@ietf.org<mailto:ops-ads@ietf.org>; netslices@ietf.org<mailto:netslices@ietf.org>; netslicing-chairs@ietf.org<mailto:netslicing-chairs@ietf.org>
Subject: Re: [Netslices] COMS: What next?



Hi Adrian



On one hand you statement that L2SM, L3SM and ACTN are "primitive" forms of slicing may be correct if you define what a primitive is and how could be used and managed.



On the other hand  L2SM, L3SM and ACTN/ virtual nets would be consider as slices or slice enablers if they can provide dynamic resource partition supporting a very large variety of service requirements per partition ( i.e. range from low latency service to high bandwidth service to defined QoS based services to ...)



In my view L2SM, L3SM, ACTN  and other L2/L3 technologies (i.e. VPN, IPV6 segment routing, etc) would be useful technology in the activation in a domain of a network slice but they are not necessarily ‘slices’.



As presented in London the COMS related work activities cannot be just reduced to L2SM, L3SM, ACTN or to operations  (i.e. operations on IPV6) on existing networking systems.



I support Sasha’s statement that "network slices as service (NSaaS) therefore looks like a reasonable objective for a dedicated IETF WG”



Best Regrards

Alex







> On 8 May 2018, at 9:51 AM, Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> wrote:

>

> Yes, and without pretending to speak for the whole room in London,

> there were some observations made that L2SM and L3SM were "primitive"

> forms of slicing, and that ACTN (see TEAS WG) constructs virtual

> networks over underlying transport networks and is also slicing.

>

> Some people, thus, are in agreement with you. Other,  I think, believe

> that the problem space is larger and more complex.

>

> A

>

>> -----Original Message-----

>> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]

>> Sent: 08 May 2018 09:16

>> To: adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>

>> Cc: ops-ads@ietf.org<mailto:ops-ads@ietf.org>; netslices@ietf.org<mailto:netslices@ietf.org>; netslicing-chairs@ietf.org<mailto:netslicing-chairs@ietf.org>

>> Subject: RE: [Netslices] COMS: What next?

>>

>> Adrian,

>> Lots of thanks for a prompt response and sincere apologies for

>> sending out an incomplete email.

>>

>> The completion of the sentence that has puzzled you should be something like:

>>

>> " My personal impression from reading the drafts and looking at the

>> presentation at the session is that there is certain similarity

>> between the

> Service

>> Delivery Interface (SDI) mentioned there and the YANG data models for

>> L3/L2VPN services. Developing a YANG data model for network slices as

>> services

>> (NSaaS) therefore looks like a reasonable objective for a dedicated

>> IETF WG to me".

>>

>> Hopefully this clarifies my original question.

>>

>> Regards,

>> Sasha

>>

>> Office: +972-39266302

>> Cell:      +972-549266302

>> Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>

>>

>> -----Original Message-----

>> From: Adrian Farrel [mailto:adrian@olddog.co.uk]

>> Sent: Monday, May 7, 2018 1:32 AM

>> To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>;

>> netslicing- chairs@ietf.org<mailto:chairs@ietf.org>

>> Cc: ops-ads@ietf.org<mailto:ops-ads@ietf.org>; netslices@ietf.org<mailto:netslices@ietf.org>

>> Subject: RE: [Netslices] COMS: What next?

>>

>> Hi Sasha,

>>

>>> My colleagues and I wonder what (if any) are the expected next steps

>>> of the COMS BOF.

>>> The status of this BOF at IETF-101 was Non-WG-forming.

>>

>> Right. The objectives were to get more focus and find answers to the

>> questions that the ADs had posed.

>>

>>> My personal impression from reading the drafts and looking at the

>>> presentation at the session is that there is

>>

>> Oooh, you do know how to tantalise your audience, don't you?

>>

>> Or possibly this is a competition and you will be awarding prizes for

>> the best completion of you sentence. ;-)

>>

>>> Are there any plans to hold yet another session at IETF-102 in Montreal?

>>> To progress this BOF to a WG? Or simply to pass this subject to some

>>> other SDO?

>>

>> You're asking the question on the right mailing list. But I have

>> heard no

> plans and

>> have not seen anything recent in the IETF that seems like progress.

>>

>> Maybe others will have something to say.

>>

>> Cheers,

>> Adrian

>> --

>> Support an author and your imagination Tales from the Wood - Eighteen

>> new fairy tales More Tales from the Wood - Eighteen MORE new fairy

>> tales Tales from Beyond the Wood - A bumper collection of twenty-two

>> new tales

>> http://webdefence.global.blackspider.com/urlwrap/?q=AXicHcqxDcIwEAXQ3

>> 1Gz iG2RKAQq6GhoQ0Fl4otiybGj8wmHPVgIiRmYB0H93nqF6wd4vgEOD9PeVOa7mqw

>> PfYrCKag-TSh1c-

>> 7kcjLVZldtcQy02OiIVWd9zKOQjwfqvVCg_x9F5rzXupSiBiJnmaz7iZ45DT5Q1m1jag1

>> geQFflGksFQ&Z

>> http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924

>> Or buy from me direct.

>>

>>

>>

>> ______________________________________________________________

>> _____________

>>

>> This e-mail message is intended for the recipient only and contains

> information

>> which is

>> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have

>> received this transmission in error, please inform us by e-mail,

>> phone or fax, and then

> delete

>> the original

>> and all copies thereof.

>> ______________________________________________________________

>> _____________

>

> _______________________________________________

> Netslices mailing list

> Netslices@ietf.org<mailto:Netslices@ietf.org>

> https://www.ietf.org/mailman/listinfo/netslices



___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________