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

Dhruv Dhody <dhruv.dhody@huawei.com> Fri, 24 April 2020 10:00 UTC

Return-Path: <dhruv.dhody@huawei.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 38B9B3A119A for <teas@ietfa.amsl.com>; Fri, 24 Apr 2020 03:00:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 zkbcNBRsChSo for <teas@ietfa.amsl.com>; Fri, 24 Apr 2020 03:00:16 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2A8383A118F for <teas@ietf.org>; Fri, 24 Apr 2020 03:00:16 -0700 (PDT)
Received: from lhreml727-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D641239FB1E13E977481; Fri, 24 Apr 2020 11:00:14 +0100 (IST)
Received: from lhreml727-chm.china.huawei.com (10.201.108.78) by lhreml727-chm.china.huawei.com (10.201.108.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 24 Apr 2020 11:00:14 +0100
Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml727-chm.china.huawei.com (10.201.108.78) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Fri, 24 Apr 2020 11:00:14 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.64]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0487.000; Fri, 24 Apr 2020 15:30:12 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: Susan Hares <shares@ndzh.com>, 'Dhruv Dhody' <dhruv.ietf@gmail.com>
CC: 'TEAS WG' <teas@ietf.org>
Thread-Topic: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question
Thread-Index: AdYZhkLc6QmnoHl8SwuPC330rphQdP//rhaAgAAY0oD//pr5kA==
Date: Fri, 24 Apr 2020 10:00:12 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8DE5D4CC@BLREML503-MBX.china.huawei.com>
References: <016d01d61986$4cf2a210$e6d7e630$@ndzh.com> <CAB75xn6hRMDoNCy7GX=f=XKb_rSfTb2y7X-=5CWa=1Oda33saw@mail.gmail.com> <01da01d61997$d18c7e90$74a57bb0$@ndzh.com>
In-Reply-To: <01da01d61997$d18c7e90$74a57bb0$@ndzh.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.149.39]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/GlMgJ2CLJyfSO3P8qog3jjfOW1I>
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: Fri, 24 Apr 2020 10:00:18 -0000

Hi Sue, 

I wanted to clear up that our approach in this I-D is an independent yang model. We wanted to include some slides that also show how the model *would* have looked if we took other approaches such as augmenting ietf-vn and ietf-network. More inline - 

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Susan Hares
> Sent: 23 April 2020 23:21
> To: 'Dhruv Dhody' <dhruv.ietf@gmail.com>
> Cc: 'TEAS WG' <teas@ietf.org>
> Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question
> 
> Dhruv:
> 
> Thanks for the quick response.     I'll consider your model as a customer
> model
> per RFC8345.
> 
> The L2SM Yang model (RFC8466) and the L3SM Yang Model  spend a great deal
> of time talking about connections to sites from different perspectives.
> See section 5.6 in RFC8466.
> See section 6.6 in section 8049.
> Your draft does not provide the same level of detail.
> 
> Perhaps this is coming.

[[Dhruv Dhody]]  Yes.


> 
> The issue I find unclear is exactly how the TS End point is indicated
> based on  RFC8345 (slide 15 your presentation)
> 
[[Dhruv Dhody]] Slide 13 and 15 is meant to show how the models would have looked, if we would have taken that route. We did not, our I-D is an independent model that does not augment RFC8345. In Slide 15 we note the issue if we were to augment termination point for TS-endpoint.  


> Your draft states in Section 5:
> 
>   "A TS End Point is a logical entity at an external Interface of the
>    transport network to a customer site. "
> 
> And section 5.1 you indicate this logical entity can be:
> distinct physical connection, L2 logical connection, tunnel
> 
> Then you state:   "Based on this, the end point
> in this model could represents the following options:"
> 
>    o  A slice interface of a customer site: the "node-id" and "tp-id"
>       under the "ts-endpoint" can be specified
> 
>    o  A slice interface of the transport network: the "node-id" and "tp-
>       id" under the "ts-endpoint" can be specified, and "site-access-
>       parameters" can be used to specify the attached customer site.
> 
>    o  The subset of traffic through the particular interface connected to
>       the transport network, either at the customer site or the
>       transport network: besides the "node-id" and "tp-id", the "ts-
>       traffic-criteria" is needed
> 
> If you are a customer model,  does this model that the end-point
> definition covers all these cases by providing more details depending to
> indicate the  logical connection underneath?
> 
[[Dhruv Dhody]] Yes. 


> Is this simply a way of stating you use RFC8345's logical links through to
> a different layer?
> (see figure 2 and 3 in RFC8345).
> 
[[Dhruv Dhody]] No. We do not use RFC 8345 in our model. 

Thanks! 
Dhruv 

> Thank you,  Susan Hares
> 
> 
> 
> -----Original Message-----
> From: Dhruv Dhody [mailto:dhruv.ietf@gmail.com]
> Sent: Thursday, April 23, 2020 12:23 PM
> To: Susan Hares
> Cc: TEAS WG (teas@ietf.org)
> Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question
> 
> 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> 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
> > https://www.ietf.org/mailman/listinfo/teas
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas