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

"Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com> Mon, 27 April 2020 16:33 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 4656B3A0EEE for <teas@ietfa.amsl.com>; Mon, 27 Apr 2020 09:33:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 R9kcL_CNKvy8 for <teas@ietfa.amsl.com>; Mon, 27 Apr 2020 09:33:09 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750122.outbound.protection.outlook.com [40.107.75.122]) (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 9FA303A0EEA for <teas@ietf.org>; Mon, 27 Apr 2020 09:33:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DpHNxLn/XFAImu2wh6chK1swjt/ElF7fc6i3UBrwX2ck2OEkaZCpl+hCPH3cnaxkwPatJpGpFv6KPNAQB5M8R4hR5Cf9ayJP3QxB/XCbPckBnzCiMVN1MWSejDfCF993F0oJNwvKlqMi86xlTVjUqQesd0D+vUhYT8COGr216Jy2XNItXgoOyLSjLoD/3BNzegfgYVM3MtRWN0S6ExVI4xjWaFB4hxOrUdoqg9koYrtu/nm+U//btNY7t0yFAUjIlrdU3fRervWAWAWzlZPmBZ1GgFSRBHX54Xxvij4Kh1NLUTskcnc0pQaF4D4UPWfsDlqP8xrKELbjxhj6/na9mw==
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=CfjbmFG1G+DWQKbkGgEMLeDBIyr1Cphzk6sFnOmm23w=; b=hGbC/SQhV6NuE9O60G7cxLebSoEMHjSqWF1f/G+UKk1Xlfassnx+nSjCfDmUf/PNtF05lJpcredHsuNokn+dsKQ2jHi6Pbijgr6iNHm6fTWcq0p05LukXq6SXygcvKuDkolb9HYSSRVuIWicWXMcMC0P+w4iqtvSnMRnCtLt3/9iU9Vjc56NEBtIX1/M0VL22RfLVSBaHUqccZMQBq/Qtta7Pi39RH1w2o2WK6xKjWsHhqTGZgeu1tQCZlwFNiJHr0xbpymbvHrvZ6ghLCQ1BxB0nCNME6NHl4en5rpSdbuKmNj+KzQOS36aErtxpodHgFCii449bB8flWDsy8X5HA==
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=CfjbmFG1G+DWQKbkGgEMLeDBIyr1Cphzk6sFnOmm23w=; b=kb9zjJOc97A62hTmeLWsBZEUgvLU5KrpwGkONSFUILS7Mf+8k9doZvssZpN7Fsb1x+PwUJl6m+J2RpKj/4WZl/ypq/UfiGfxcLu7RlYRoss7U+2OOoZpUbp3yqc91Zx2DiZngovpBtL7YXIR6BinLl3WwgN6UE4E6e39zL2V0Eo=
Received: from DM6PR08MB6331.namprd08.prod.outlook.com (2603:10b6:5:1ee::8) by DM6PR08MB5785.namprd08.prod.outlook.com (2603:10b6:5:17d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Mon, 27 Apr 2020 16:33:05 +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 16:33:05 +0000
From: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, 'TEAS WG' <teas@ietf.org>
Thread-Topic: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question
Thread-Index: AQHWHLGHoujrJCnW0EGXx8lNgBGapw==
Date: Mon, 27 Apr 2020 16:33:05 +0000
Message-ID: <2D05FDB1-E023-4E9B-91D0-8C0A67A8FFA6@nokia.com>
References: <0a36dbf4fee9468cae14390bff6287ae@huawei.com> <E61B7668-6A2A-4F3A-90B2-5165B7E63896@nokia.com> <62a5f1b8-24e2-01c8-046e-ab8f75e03a13@joelhalpern.com> <FE52192B-33EA-4FDF-BBC8-050EE6243924@nokia.com> <e207d172-cad3-b23f-f7fa-f1112f3208c8@joelhalpern.com>
In-Reply-To: <e207d172-cad3-b23f-f7fa-f1112f3208c8@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
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: 6afcbdaf-b890-4cbf-089d-08d7eac8a9a6
x-ms-traffictypediagnostic: DM6PR08MB5785:
x-microsoft-antispam-prvs: <DM6PR08MB5785C55379E675A14369AF229FAF0@DM6PR08MB5785.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)(136003)(376002)(346002)(366004)(39860400002)(81156014)(6486002)(71200400001)(8676002)(26005)(2616005)(30864003)(8936002)(33656002)(6512007)(36756003)(2906002)(76116006)(91956017)(66556008)(110136005)(478600001)(66946007)(86362001)(5660300002)(966005)(66446008)(316002)(6506007)(186003)(66476007)(53546011)(64756008)(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: zyOWjgUOQBda/T3gxrmA039up/qrVpQFzBMT71Bm0anQlFCM1K2YkBS46inpxnqGS+25VfyqKH15JRCMdWHtiyWPdwl1OyYpRlZkDPfWWUWr/T2Zz/GpCR9dPttZzcQlAOLyb1rbDJipYamJgZHgROhACPK7kNabqK0YluYtVGmh0d8V636Qs+0HEn1ASp9F8SVyOioM5pzpUWYwlRvDvpTx2i9hycmWHaCJq/snYmtl+LXosqVpL9tYI9ixshCDtlyy5KymcB4byeoqj4p1KROAcWF7nlWXz05a5PuAKdu6IG5azr9N7NJen4+HGFAwYXWQwDNw2kO+QnhJ/voNtn4R0uud9DqtZcIRPgpR9vu+OzaDQ7DbKV2G/wMri2T9RXEicJtQNWu+MT5G7pr3ZK/YA0tKyJwzKLDngnUtrruI0P/Oo0EQzMbBkPFz5kFpGEHUerrDTctdkiLYagEmoGZAKgEQKj90QqIbCOpXLOHaHQkiWFptcjEm3k5R9BrzaFosWT4PY6uTTdtxQ66S7w==
x-ms-exchange-antispam-messagedata: koF8/o7DffUNOJWL6RgVlyGOsX3C5fmkPrTV4GShYiutesdD+sVP7JKG8qlYw8tFVh09IWU4/o3Q0ENxlM2rx8ySu1E8dAI1RMyZSEg8/UnKfK79dy5M5ZnRnN8nl2bnUHDEvjshdwrVitqXYeBb8AaeDzW9JGwT1Z4o0zCUu/cT1S4Mj7pkuvWjHwfQGUnIBB8V9HpkJq4nBkzDBE9yxt2skTqvfTxVLajm4SIaBi4WNW+KgawkwQMN9vUvFMzWsphnWZbcvszhgxc15jAGGuLKw30oUWeqg2HkMzEyEnJSbI9kN24DgAin5jmOZQowZoSKiPON7qKEu2QyubTecrZHTGfp6wtBZnSCBAVy/W/dCgt1xaW7+QISBq52qwD45pr7njSZKGH/O2mn1bhfmMQYgdwG8UJ02j3elQJQhOaYQXaNvlh/ozp7vZSXsxYrwZioL7xaeM7eX/fch7NDoUK8ONZfdSHiuANuAQBFjh/qETzcCZEBlQBzJlhmyrdPNJ94rrwegCLr/rurG5Hb3RPbhtTNVsWUhXICwxYOB/JLUNl8yXXkMkB6f3KZ3KJsKKMExmtBMoDgFZ/e2FEvsn/f62k+/FWPPK48WC03Bd5/NWezCFffjq8+45T3aaaFRC1YwXHVTrqq/wMIIHlnz7oCKRjFLsY4loZtuqSOsQ3pJQXztnXSVx5HlpF9y51TU8Lz0P7bTCblfHFmfuoJwKYeSknQY3XZUD97iNbD12F1sGP8U2tWBOQ5wZaLSGx+pzRIb+BTejpEtIsOAwtS/6jZEUNJluYzAWDNCmVOSbQ=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <7F79A19DF38A5E49833FF8A9FCDE3670@namprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6afcbdaf-b890-4cbf-089d-08d7eac8a9a6
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 16:33:05.5041 (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: 5hAIrqw2DZwylM0ILrnYUePVP+rK8xhJUu20KVG11qFJ6hWHhkd90vMEvHxCneKWlj3TdzYmfNl4VnHEgUrpJg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5785
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/ZoR6G3qSy1FeXG_QSob_hemeM7s>
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 16:33:14 -0000

OK great.
Reza



On 2020-04-27, 9:27 AM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:

    What you describe here seems aligned with what I understand.
    When I read your response to Sue, it seemed to say something different. 
    Sorry I misunderstood you.

    Yours,
    Joel

    On 4/27/2020 8:43 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
    > Joel,
    > 
    > If assume with “customer”, you mean the owner of the transport slice.
    > 
    > Let me clarify. Transport slice is meaningful in context of an e2e 
    > network slice. The e2e network slice has an owner which requested the 
    > creation of the e2e network slice.
    > 
    > For example, customer Uber asks the operator for an e2e network slice 
    > for service “autonomous driving”. In addition of creating Other Slices 
    > (OS), the Operator eventually creates one or many Transport Slices to 
    > satisfy the original e2e network slice.
    > 
    > In this case, customer Uber is the owner of the e2e network slice (which 
    > in turn means he is the owner of the many transport slices) in the network.
    > 
    > E2E network Slice Orchestrator and Transpot slice Controller provide the 
    > full automation on both e2e network slice and transport slices.
    > 
    > I think the above clarification is aligned with you comment.
    > 
    > Cheers,
    > 
    > Reza
    > 
    > On 2020-04-26, 12:54 AM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:
    > 
    >      Reza, I am pretty sure that the custoemr of the Transport Network 
    > Slice
    > 
    >      is not actually the orchestrator.  Yes, the orchestrator gave the
    > 
    >      orders.  But those orders were to meet someone else needs for the 
    > slice.
    > 
    >        Pretending that the end-to-end slice is the customer of the 
    > transport
    > 
    >      slice seems to be counter-productive.
    > 
    >      Yours,
    > 
    >      Joel
    > 
    >      On 4/26/2020 12:36 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
    > 
    >      > 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.
    > 
    >      >
    > 
    >      > 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.
    > 
    >      >
    > 
    >      > 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.
    > 
    >      >
    > 
    >      > 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
    > 
    >      >
    > 
    >      > 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.
    > 
    >      >
    > 
    >      > /[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.
    > 
    >      >
    > 
    >      > +------+
    > 
    >      >
    > 
    >      > |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.
    > 
    >      >
    > 
    >      > 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
    > 
    >      >
    > 
    >      >
    > 
    >      > _______________________________________________
    > 
    >      > Teas mailing list
    > 
    >      > Teas@ietf.org
    > 
    >      > https://www.ietf.org/mailman/listinfo/teas
    > 
    >      >
    >