Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

"Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com> Mon, 27 April 2020 12:28 UTC

Return-Path: <reza.rokui@nokia.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 848F63A083D; Mon, 27 Apr 2020 05:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=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 0kjy-sxQ7_yY; Mon, 27 Apr 2020 05:28:19 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2098.outbound.protection.outlook.com [40.107.244.98]) (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 EDF473A0835; Mon, 27 Apr 2020 05:28:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bIYf9tIet7FGZH68PRf1mXlRPGmno2iExvZfaTJxkkSKhzgbpqxgIwEYIqYXbeXzi9UJzsVcC/HprdvpntWB2eKl2Dog+XwVtO7yXXzpfz1VaVoyuegTExzERQ/dzJCZeFzxsDMk8nBTquTLLmBdlCe/Yc0eO/LY3XawcQIxznHY7eVPVZYDh2EH/8+cvdX+09mGxU5mhaU9ysOceLWdlqUtNvLYfhscefYeqDskrqkWcvEJxHUmUkX11MWN1bz88WbkoYjVFh8LzTSNnGMqMG4Y7oFJPH7HG3MoSikt7TbYB+WjvzcnWVALb6s63yKQExuveP+UdszzxDU87V6+Lw==
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=elXXqhE0xHRJ7cf6jmv+H041Xi0d/txJkRuL1IkunkQ=; b=JaSK3cfrn/c/rJppkQxETOTe+d6YPzRzyAcdRr6ZQ6kWaxS0zq7OKX024X2zFWPOGG8sJxSBUjHXsXMFhwYqm3dIzyOcqZkOnrLp4N/UF5zbZV8nfV1gGysLyRoMi4VMeDWKEZxXU0kbA/2KO4Tbeh8JrrJHkdBv/hpxsyfW77O2NzEfT/Unv+1oS30jJsnDeiMc7xGezKrsMpbsIvuc7EQ6hwOUynO6bPZIvZV+U0DS4PT2zSIGk1q84bDS2DjvhCCv0NOlC3KCjf6ZuCWwnx/FhFqb9ZAodY1W54tXPMYKjl3NeyXlZotMSJjSGTCibhm6NopBePQ6pe+7Pv7rXA==
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=elXXqhE0xHRJ7cf6jmv+H041Xi0d/txJkRuL1IkunkQ=; b=IA0WhAB/HZ3HXm2n3i87xaAeWQf7N7oVzvq599rN0j0xpyEGGWHljnf1liz6ETQXmQCcntuSmAHWwR6kCYbEZphy9Y3NhA4sdy+BWX8YHoAO7s8f/wZdmRPs/TdqMUGk0KAl3vLZU/xkXfUU60dGPzhSDXzagECgDFkZAUGAW+0=
Received: from DM6PR08MB6331.namprd08.prod.outlook.com (2603:10b6:5:1ee::8) by DM6PR08MB6313.namprd08.prod.outlook.com (2603:10b6:5:1ea::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Mon, 27 Apr 2020 12:28:14 +0000
Received: from DM6PR08MB6331.namprd08.prod.outlook.com ([fe80::88e:916a:f169:9c1a]) by DM6PR08MB6331.namprd08.prod.outlook.com ([fe80::88e:916a:f169:9c1a%7]) with mapi id 15.20.2937.023; Mon, 27 Apr 2020 12:28:14 +0000
From: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>
To: Susan Hares <shares@ndzh.com>, "'Wubo (lana)'" <lana.wubo@huawei.com>, 'Dhruv Dhody' <dhruv.ietf@gmail.com>, 'Teas-ns-dt' <teas-ns-dt-bounces@ietf.org>, 'TEAS WG' <teas@ietf.org>
CC: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>
Thread-Topic: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question
Thread-Index: AQHWHI9StL59uJEkiECYjBWg6QI8Yg==
Date: Mon, 27 Apr 2020 12:28:14 +0000
Message-ID: <099953C6-7127-4142-A4EE-E628D730992B@nokia.com>
References: <0a36dbf4fee9468cae14390bff6287ae@huawei.com> <E61B7668-6A2A-4F3A-90B2-5165B7E63896@nokia.com> <003a01d61be3$88257290$987057b0$@ndzh.com>
In-Reply-To: <003a01d61be3$88257290$987057b0$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
authentication-results: spf=none (sender IP is ) smtp.mailfrom=reza.rokui@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: c50f1c06-6b07-4a65-cc49-08d7eaa674e2
x-ms-traffictypediagnostic: DM6PR08MB6313:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM6PR08MB63139E1C3C6798EA0998078A9FAF0@DM6PR08MB6313.namprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0386B406AA
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; SFTY:; SFS:(4636009)(396003)(346002)(39850400004)(136003)(366004)(376002)(36756003)(6512007)(186003)(8676002)(8936002)(99936003)(2906002)(66616009)(66476007)(66556008)(64756008)(66446008)(478600001)(91956017)(76116006)(6486002)(81156014)(26005)(66946007)(316002)(110136005)(53546011)(5660300002)(966005)(6506007)(33656002)(107886003)(71200400001)(30864003)(2616005)(4326008)(86362001)(579004)(559001); DIR:OUT; SFP:1102;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: dwmt04t3L9tRG9REXekYwbsM8c68sXAUjXXenysQpn7MwMscT5NFZul3upGEw7jHW7J6xkKSQP/PAxOxsxivw8N6WQGIiBc+CLz+sb+ryuvmEvz8r1Yn5nL1K0VbYzA4JaROwPRwCejWao6616tFE7OON8QAevsFUoYmoTKljiDXIvBEBk9Q1AGynnQgfJdKwZX28goWGzx4RqSL5poYFWU4dVUFYBuZv9VTk506eG+Dp+7NYzsweEijthG7OleCMfvIaBXsEApBmUD4SgLZydGj0pNdRC2T4zfH6fPkSs/o3I8r9sdEMqCCff9I+mlcvlehbvHhpOlzicZGj2yxBhMjkewemzCh7iqfRGcR6mINhq22Cy/85MlYhdnU7SQl8cFyLN0lFZq5giJjPB19xffRU1ipcu41Au/F5ztnISHf2LyFlXnUxtH8SYkJrXzEkVxCth6NWmYn1f/qVoHsC51/iCTGZJ8D6bYrMY5VhsQ8+NJ27X1Q39RHN6YzpxFZ1AQhnRMQuM3eUc5x+3+lCQ==
x-ms-exchange-antispam-messagedata: nbOg6ZKCM9zIW6yRV5vxwmw3Pc02o0m+tCFeVsSmQclqDBeU3bdavu+yGTbLVl+9gAymDHzh6rm+qchma+1CEXh2dfymM54wyRGMt8j5aAbI8RfYArU43wGAUFPTaZ6KrLlTCh3u8tFLyjbux6gbxe+nmT4iha+UlbkyZl4cF0LsUxD3C4ZBVzLT45IWYKhofv7ScRw5OZh4xPBvC5kGY8lZNugCEHqj+eCl4+iOHiMySqRBsa8aUE7tK2SgK8hG9ay0hIlTEAs3FxmnnBJMLDIESyJ1ylO92sgqxF0Hjr9IRPaj4RoQaW9qkKA6IdEvRFg12ZxXqQxspav44fN5rTPib17WmRoE+dqw/5XLy7AIM+xBFf2ybFMgcN8vVLKbIwiTrC57DuOkONRS9YT+4t8JCCSX5xwKAFN8IbgJD/du9HsFU4r7sjBJAOYUGB9LB/Rpd4PtBTUshzuJRrkxHXKVDno0YKPiORns/cfN9EphUygz3aARMrSrh602fG9K9slKiT+Z8WQGwJSoHwSADRb3o3maMQjQYe6c9WINjrM2gGlY8Q8EMuefCOngkn/dwimfNc8SrracbRG7C8hNc7ajVRwNvFvs1U2IMQf521yKy7iDChhrkh/TJQm7MXwd3pVevKgJ5OFoSF6hIGxxilbvp7MWQki4lz/OiFsccnI8xBK81f9nDmYwzoT7ek2uwEAlszpaFV3odrjrBkx7tM1yherkwV/AW+eOtHfCBbtBSwgKH5XYIeU32jh+YuYm2tvBo+sPvHlDoXu+LpT2oQk5kcu2AD8TtEEzZaZGhp0=
Content-Type: multipart/related; boundary="_004_099953C671274142A4EEE628D730992Bnokiacom_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c50f1c06-6b07-4a65-cc49-08d7eaa674e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 12:28:14.0983 (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: 3KpCLLDswOW1YQZeiIx4K7oqySJ2Q0m+0ShW1rW2on4heFee37uktbElJlni8WJDlwQXsx/DTlJBHWx7JzXR3Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6313
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/kc6m8a-uQGCAxG4tASoiGj36vqM>
Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question
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, 27 Apr 2020 12:28:23 -0000

Sue,
Please see inline.

Reza

From: Susan Hares <shares@ndzh.com>
Date: Sunday, April 26, 2020 at 11:58 AM
To: Reza Rokui <reza.rokui@nokia.com>om>, "'Wubo (lana)'" <lana.wubo@huawei.com>om>, 'Dhruv Dhody' <dhruv.ietf@gmail.com>om>, 'Teas-ns-dt' <teas-ns-dt-bounces@ietf.org>rg>, 'TEAS WG' <teas@ietf.org>
Subject: RE: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Reza:

Please  see my comments below – inline.   Here’s the important part from of all your responses.


[Reza] Endpoints of Transport slice are the abstract entities.

They could be the application software for example or  a physical node, the logical node or interface or any other  component which needs connectivity. To realize the transport slice you can use for example  L2SM or L3SM between multiple Sites. For example if you want to create a Transport Slice between a  VNF and application, you can realize it using L2SM or L3SM across IP network between multiple Sites which might be different from Transport Slice Endpoints.



Here you describe using l2SM and L3SM as a customer at a high layer.

It is fine to build layers of customer or transport models, just define the interactions.

In defining RFC8345 – the authors knew the customer layer might take refining.
If this is what you are doing, then please define it  carefully and cleanly.
 [Reza] Please elaborate on this.
In summary as shown in following slide, augmenting RFC 8345 is a potential option to define TSC NBI. However, the authors feel that it is not a good option. The reasons are also shown below.

[cid:image001.png@01D61C6D.C95A0020]

If you are defining layers within RFC8345 customer layer, please define what you are doing.

Joel and I are commenting on this work because we wish to see you succeed.
[Reza] Great to hear this.

Sue




From: Rokui, Reza (Nokia - CA/Ottawa) [mailto:reza.rokui@nokia.com]
Sent: Sunday, April 26, 2020 12:36 AM
To: Wubo (lana); Susan Hares; 'Dhruv Dhody'; 'Teas-ns-dt'; 'TEAS WG'
Cc: Rokui, Reza (Nokia - CA/Ottawa)
Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Hi Sue,

In addition of Bo’s answers, see my comments in line.

Reza



From: "Wubo (lana)" <lana.wubo@huawei.com>
Date: Friday, April 24, 2020 at 5:32 AM
To: Susan Hares <shares@ndzh.com>om>, Reza Rokui <reza.rokui@nokia.com>om>, 'Dhruv Dhody' <dhruv.ietf@gmail.com>om>, 'Teas-ns-dt' <teas-ns-dt-bounces@ietf.org>rg>, 'TEAS WG' <teas@ietf.org>
Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question


Hi Sue,



Many thanks for the detailed comments.

Let me answer first and see if my co-author has anything to add.

Please see inline below.



Thanks,

Bo

-----邮件原件-----
发件人: Teas [mailto:teas-bounces@ietf.org] 代表 Susan Hares
发送时间: 2020年4月24日 2:02
收件人: 'Rokui, Reza (Nokia - CA/Ottawa)' <reza.rokui@nokia.com>om>; 'Dhruv Dhody' <dhruv.ietf@gmail.com>om>; 'Teas-ns-dt' <teas-ns-dt-bounces@ietf.org>rg>; 'TEAS WG' <teas@ietf.org>
主题: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question



Reza:



Your answer to my request for clarification of your slides seems to have skipped a step.

 I asked for clarification, and you stated you prepared a clear set of slides

(smile)

A clarification question indicates your slides were unclear to me.

Perhaps you would kindly explain a few things to me.



Sue

----------------



Question 1)  Your slides stated



Customer level

    |

Higher level systems

  |  (your model is here)

Transport slide controller

|

Network controllers

[Bo] This figure is from the Transport slice definition draft, where the customer is the user who uses the slice.



On slide 2,

a) who is the customer?

[Bo]The customer here refers to the Higher level systems.

[Reza] The customer of the “Transport slices” is whoever wants to create the connectivity

across transport network as part of e2e network slice. As an example, in 5G, the customer

is called “5G network slice Orchestrator”.

Or for use-case of NFV connectivity between data centers, the higher level system

might be the OSS system or a customer portal.



RFC8345 provides an architecture that allows many types

of service models above the network layer.  As far as I

can tell, you are defining a model that uses the

services of network controllers.   Theory behind the model

is to provide clean service points based on a common model.



To state  ACTN could do this but it is only one model

Implies that you are building a model that combines with other

Models.  If so, your definitions need to clearly state:

1) who uses each level

2) how the level above connects to the level below

3) how you interact with existing models



b) who is running the higher level systems?

[Reza] It depends on the Transport Slice use-case.

In 5G network slicing, the high system is orchestrator

runs by network slice operator (or customer himself).

It all depends of the use-case. The details is out of scope of our draft.



You need to have enough details to define the characteristics

of each layer of the model.



Saying the “details” are out of  scope is insufficient for

Building a model that is going to combine other models.

You are proposing an alternative to RFC8345 – then

You must come up to its standard.



c) who is running transport slide controller

[Bo] As defined in the definition draft, it is quite possible that the higher level systems and the TSC are not in the same management domain.

[Reza] Note that “Transport Slice Controller” is a FUNCTIONAL block.

Depends on the use-case and operator’s desire,  It might be part

of “Network Controller”. It might also be a separate box owns by

network operator.  It is possible that the owner of the

“Transport Slice Controller” and “Network Controllers” as

not the same network operator.



I am assuming by your slides and by your response that

Your yang data model is for the Transport slice controller.

All data models have profiles for implementation:

(MUST implement, May implement, etc).



If the connection to your yang model exists across a

Administrative boundary, the access permissions in the

Data model need to be defined with that in mind.

The basic NETCONF/RESTCONF data models will take

care of access permissions.



Are you saying additional work needs to be done here?



Your text says in section 3, page

  "The intention of the transport slice model is to allow the consumers,

   e.g.  A higher level management system, to request and monitor

   transport slices.  In particular, the model allows consumers to

   operate in an abstract, technology-agnostic manner, with

   implementation details hidden. "



Is the end-customer directly running the system?

[Reza]  Referring to Figure-4 of the definition draft below,

the end-customer is the whoever owns the “E2E Network slice”.



We call him the Customer (or Tenant).

For example in 5G network slicing, an E2E network slice is

created for customer “Uber” for service type “Autonomous Driving.”

In this case the end-customer is “Uber” which can run and manage its own e2e network slice

if they have agreement with network slice and transport slice operators.



           <======================= E2E NS ======================>
           <-OS1-> <-TS1-> <-TS2-> <-OS2->   ...   <-TSn-> <-OSm->
          |------------------------------------------------------|
          |    .--.             .--.                .--.         |
          |   (    )--.        (    )--.           (    )--.     |
          |   .'         '     .'         '        .'        '   |
   [EU-x] |  (  Network-1  )  (  Network-2  ) ... (  Network-p ) |[EU-y]
          |   `-----------'    `-----------'       `----------'  |
          |                                                      |
          |                      Operator-z                      |
          |------------------------------------------------------|
   Legend:
     E2E NS: End-to-end network slice
     TSn: Transport Slice n
     OSm: Other Slice m
     EU-x: End User-x
     EU-y: End User-y

I realize you believe your Uber drive scenario is very different than
the VPN case.  Your argument simply points out more layered
VPNs with different means of setting these VPNs up.
Building a new type of VPN is fine, but your comparison
fail to delve into the complexities of the L2SM and L3SM.



Is this directly linked to the certified paying customer?

Or is the customer really the person on the inside of the 5G provider configuring it.

[Reza] Referring to the example above, if with “paying customer” you means customer “Uber”,

the answer is YES. But since Uber can sell the usage of this network slice to hundreds of drivers, if

with “paying customers” you means these drivers, the answer is NO.



Thank you for the clarification.



[Bo] No to the above questions, The TSC is unaware of slice customers.

And what I want to highlight is that the consumer in this draft refers

to the higher level management system.



Question-2)  If you are using the TS-Endpoint as an entry point (slide  4)

How is this conceptually different that the site endpoints defined by

RFC8466 (section 5.5), RFC8049 (section 6.5 and 6.6)?



In the L2SM and l3SM models, you sites with:

a) end-to-end p2p connectivity

b) ~logical LANs (multiple connections through a single transport)?

c) multiple VPNs (translated to multiple Transport slides connectivity)

[Bo]

In L2SM and L3SM, 'site' is defined to configure links between CE and PE.

In the context of transport slices, it is assumed that the connection

between the customer site and transport network has been established,

and multiple slices can share the connection.



Additionally, the higher level system may use different endpoints,

which may be the termination point on the CE side or the TP on the PE side.

[Reza] Endpoints of Transport slice are the abstract entities.

They could be the application software for example or  a physical node, the logical node or interface or any other  component which needs connectivity. To realize the transport slice you can use for example  L2SM or L3SM between multiple Sites. For example if you want to create a Transport Slice between a  VNF and application, you can realize it using L2SM or L3SM across IP network between multipole Sites which might be different from Transport Slice Endpoints.



This text is a very useful point.  You are combining L2SM and L3SM at a higher level.

 This is the answer I am seeking.



+------+

|CE  TS1EP--+

+------+      |

            |

            |   +--------------+

+------+      +-----+         |

|CE  TS2EP      |     PE  |

|    +----------------+         |

|    TS3EP      |         |

+------+          +-------------+



+------+

|CE  +--------+

+------+      |

            |

            |  +----------------+

+------+      +-TS1EP       |

|CE  |        TS2EP  PE   |

|    +----------+             |

|    |        TS3EP       |

+------+          +-------------- +



Question-3:  Slide 15 -  TS-NBI as Augmenting network model (RFC8345)



The slide makes it appear as you model TS-NBI as a network layer connection.

Is this correct?

[Bo] No, the authors prefer TS-NBI as a customer-view connection for Higher level systems.



If you are modeling as network connection, Why?

If you are modeling this as a customer level,  then why is this slide (which you claim is "clear") is modeling this as dependent on a link rather than connecting as a customer connection from an upper logical layer (connecting multiple connections) to one of possible links.



If you are modeling this as a customer level slides,  13 and 14 also seems to misaligned.  You are on top of these models utilizing what portions you wish.

[Bo] This draft has been discussed several times at DT. During the discussion, some members suggested to reuse the existing IETF topology definition since the definition draft defines TS as a logical topology connecting a number of endpoints.



[Reza] During multiple NSDT meetings, a few people asked why authors of NBI draft did not augment Network model yang (RFC 8345) . Slice 15 is included as completeness to outline the reasons and depict the potential augmentation. Note that authors desired is not to use this model. We stated the reason in Slide 15.



Your slide 15 was unclear and logically specious.



Question 4:  Are these models ephemeral?

[Bo] No, the slice model is an abstraction of resources that are dedicated allocated or shared in the Underlay layer. For example, a Transport slice could be the aggregation of interfaces, VPNs, and tunnels from entry to exit endpoint.



Again - thank you for answering these questions.







-----Original Message-----

From: Rokui, Reza (Nokia - CA/Ottawa) [mailto:reza.rokui@nokia.com]

Sent: Thursday, April 23, 2020 1:01 PM

To: Dhruv Dhody; Susan Hares; Teas-ns-dt; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>)

Cc: Rokui, Reza (Nokia - CA/Ottawa)

Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question



Thanks Sue for you comment and Dhruv for your response. We prepared a good set of slides to capture the rational behind our model and why we did not use VN or RFC 8345 models although we used the design concept from both yang models.

As Dhruv pointed out, we add them to appendix since they are very important aspects.



Cheers,

Reza





On 2020-04-23, 12:22 PM, "Teas on behalf of Dhruv Dhody" <teas-bounces@ietf.org on behalf of dhruv.ietf@gmail.com<mailto:teas-bounces@ietf.org%20on%20behalf%20of%20dhruv.ietf@gmail.com>> wrote:



    Hi Sue,



    Thanks for your email. Yes, our work for TS-NBI is closer to the

    customer service models and in fact uses the same design philosophy by

    creating an independent model with a customer view (of the slice)

    rather than the network view. The network view would be useful for the

    slice realization by the TS-controller as described in the framework

    draft.



    It would be good idea to capture this discussion in the Appendix of

    our I-D. Further, there are some technical challenges such as modeling

    TS-endoint as an augmentation of a termination point in RFC8345; our

    preference is to maintain TS-endpoint to be a logical identifier with

    either CE-side details or PE-side details or both.



    Thanks!

    Dhruv



    On Thu, Apr 23, 2020 at 9:16 PM Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> wrote:

    >

    > Bo Wu, Dhruv, Reza, and Liuyan:

    >

    >

    >

    > Thank you for your presentation in TEAS on the draft-wd-teas-transport-slice-yang-01.    I had hoped to ask this question on the mike:

    >

    >

    >

    > “Would you provide more details on why you felt the base model (RFC8345) was not appropriate to utilize? “

    >

    >

    >

    > It seems to me that you are proposing a customer level model  to monitor and set-up the traffic slicing?    RFC8345 provides a base model with a customer level.   The models L2SM and L3SM provided a customer level for general VPNs.   You seem to be providing the equivalent for a traffic slicing.

    >

    >

    >

    > If you are looking to utilize the base model then providing a customer level model is a good idea.  It is much cleaner than mixing it with the network layer.  When network slicing was starting its work, I prepared this suggestion as part of the first BOF.

    >

    >

    >

    > Would you do me a favor in your presentation of “customer level”,  would you careful distinguish between the following customer levels?

    >

    >

    >

    > End –customer ---

    >

    >         |

    >

    > VPN customer (person/tools configuring)

    >

    > Service

    >

    >     |

    >

    > VPN of network

    >

    >     |

    >

    > Base network

    >

    >

    >

    > Thank you!

    >

    >

    >

    > The I2RS WG (which chair) standardized RFC8345.   Your application was one of the ones that caused us to work through the model and the issues with yang.

    >

    >

    >

    > I’m excited to see your work in TEAS.

    >

    >

    >

    > Sue

    >

    >

    >

    >

    >

    >

    >

    > _______________________________________________

    > Teas mailing list

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

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



    _______________________________________________

    Teas mailing list

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

    https://www.ietf.org/mailman/listinfo/teas





_______________________________________________

Teas mailing list

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

https://www.ietf.org/mailman/listinfo/teas