Re: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt

"Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com> Tue, 02 July 2019 02:13 UTC

Return-Path: <gengxuesong@huawei.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082AE12018B for <detnet@ietfa.amsl.com>; Mon, 1 Jul 2019 19:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level:
X-Spam-Status: No, score=-4.189 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, 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 ER6759YGu3vm for <detnet@ietfa.amsl.com>; Mon, 1 Jul 2019 19:13:36 -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 31A331200D7 for <detnet@ietf.org>; Mon, 1 Jul 2019 19:13:36 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7E6D9BAC1E9FD51503BB for <detnet@ietf.org>; Tue, 2 Jul 2019 03:13:34 +0100 (IST)
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 2 Jul 2019 03:13:33 +0100
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme752-chm.china.huawei.com (10.3.19.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Tue, 2 Jul 2019 10:13:31 +0800
Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1591.008; Tue, 2 Jul 2019 10:13:31 +0800
From: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
To: Lou Berger <lberger@labn.net>, "detnet@ietf.org" <detnet@ietf.org>
CC: 유연철 <dbduscjf@etri.re.kr>, Mach Chen <mach.chen@huawei.com>
Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt
Thread-Index: AQHU4yp5IP/WsEhQf0SBxRa/pLw8F6Z+4YjAgDV+zoCAAa1dcP//0kEAgAFNGLA=
Date: Tue, 02 Jul 2019 02:13:31 +0000
Message-ID: <c8ca68a8d04e4a92884b23d7faeec57f@huawei.com>
References: <155353240678.28988.18080552674175846436@ietfa.amsl.com> <1be0f2c21bc04ffcb5934f36c1ff14b7@huawei.com> <16ba8f2dce8.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <6150ff5968b44b9193f48448cc0dde20@huawei.com> <a094129d-161f-62b0-218d-bed6814ca393@labn.net>
In-Reply-To: <a094129d-161f-62b0-218d-bed6814ca393@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.169.123]
Content-Type: multipart/alternative; boundary="_000_c8ca68a8d04e4a92884b23d7faeec57fhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/ZYBJKKJQo30UZEev8zFwTQ9bUEw>
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jul 2019 02:13:40 -0000

Hi Lou,

Thank you for your comments and please see the response below.
By the way, we will update the draft based on this discussions soon, if anybody has further comments, please let us know.

Best Regards
Xuesong

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Lou Berger
Sent: Monday, July 01, 2019 10:07 PM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>; detnet@ietf.org
Cc: 유연철 <dbduscjf@etri.re.kr>; Mach Chen <mach.chen@huawei.com>
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt


Hi,

Thank you for the response. Please see my comments in-line below.
On 7/1/2019 5:32 AM, Gengxuesong (Geng Xuesong) wrote:
Hi Lou,

Thank you for reviewing the new structure and giving comments. Please find the feedback below.

Best Regards
Xuesong

From: Lou Berger [mailto:lberger@labn.net]
Sent: Sunday, June 30, 2019 11:14 PM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com><mailto:gengxuesong@huawei.com>; detnet@ietf.org<mailto:detnet@ietf.org>
Cc: 유연철 <dbduscjf@etri.re.kr><mailto:dbduscjf@etri.re.kr>; Mach Chen <mach.chen@huawei.com><mailto:mach.chen@huawei.com>
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt


Hi,

I was hoping others would comment on this first, but I guess I'll jump in.

I think our yang modeling should follow the architecture, the flow information model and the data plane solution documents.

I think this means that are four basic elements are

(App flow)
Service sub-layer
Forwarding sub-layer
(Sub-network)

The two sublayers are part of detnet and should be fully described in the models. The said the data plane solutions allows for different technologies to realize each sub-layer and we are currently defining two different technologies.  I think this means that the Subway or is need a general structure that covers detnet abstract elements, but also allows for technology specifics. I suggest ensuring that the structure covers both the current IP and mpls data plane definitions, and the elements identified in those documents that require configuration.

The same concepts largely apply for the app flow subnetwork portions, i.e., there should be a general structure that allows for technology specifics. Hereto, I suggested  that the structure covers both the current IP over mpls and mpls over UDP definitions, and the elements identified in those documents that require configuration.

<Xuesong> “ An abstract structure that allows for technology specifics “ is a very good point, and that is also what we want to achieve in the new structure. As showed in the structure picture below, there are four instances  ( I call it “instance” rather than “element” here, because there have been “elements” in every instance in the structure below. However, the name is still under discussion. We could decide which one is better afterwards) in the YANG model, they are:

DetNet Proxy
I think app-flow better matches the other documents than "Proxy"

<Xuesong> Actually, the name doesn’t bother me that much, when the contents are the same. “App-flow” is not bad. But What I am thinking is that when we do mapping between DetNet services from different domains, just like the example below, whether the name of “APP-flow” still works

DetNet Service sub-layer

DetNet Forwarding sub-layer

TSN sub-network

I don't think "TSN" is the only option here, so should be dropped.

<Xuesong> I agree, “sub-network” works for me.



And in each instance, there are elements:

name

in-segments

out-segments

operations

These elements are different when the technologies used for the specific instance is different.

We believe that this structure can meet the requirement of “covers detnet abstract elements, but also allows for technology specifics”. However, if you have better idea of the design, please let us know.

See below for more specific comments.

----------
On May 27, 2019 2:36:31 AM "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>> wrote:

> Dear WG,
>
>
>
> After several discussions with other authors and chairs, we decided to update the YANG Model, which aligns with the new serious of Data Plane drafts, as follows:
>
> [cid:image001.png@01D51499.6EF5EC20]1. There are four configuration instances, including "DetNet Proxy Instance", "Service Sub-layer Instance", "Forwarding Sub-layer Instance", "TSN Sub-network Instance". When the device is configured, these instances are used following the order of the layer stack defined in the architecture:
>
> [cid:image003.png@01D51499.6EF5EC20]

I don't really understand how proxy fits in the middle of a detnet.

I'd say the four elements and the overall model match what we have in the architecture, and what I have listed above: app flow, service and forwarding sublayers, and (technology agnostic) sub-layer.

<Xuesong> Perhaps the only disagreement here is about the name of the first instance: “App flow” or “DetNet Proxy”. I believe what really matters here is the content included in the “DetNet Proxy instance”.

And I'm not sure how proxy maps to the general case.  Proxy's are a specific node type.  App-flow is the general concept from the architecture and data plane documents.

<Xuesong>  If “proxy” is the name of a node, maybe there should be a new name for the “sub-layer” on the top of the “service sub-layer”





The functions of “DetNet Proxy instance” here compose:

1.  Mapping App flow to a DetNet service, in this case:

Ÿ   Name: XX

Ÿ   In-segment: app flow

Ÿ   Out-segment: mapping to a DetNet service sub-layer

Ÿ   Operation: sequence number generation

I agree with this, if this was called app-flow.

<Xuesong>  Great!

2.  Mapping DetNet service from one DetNet domain to another DetNet domain, for example from an MPLS DetNet domain to IP DetNet domain, where the encapsulation of a DetNet flow may be changed. In this case:

Ÿ   Name : XX

Ÿ   In-segment: flow identification of detnet flow from MPLS domain

Ÿ   Out-segment: mapping to a DetNet service sub-layer from IP domain

Ÿ   Operation: sequence number generation

We could find that, “app flow” is included here, but it is not the only thing that should be included. So we think “DetNet proxy” may be more suitable here.



I guess we just disagree on the importance of "proxies"

<Xuesong>  Yes…the disagreement here is just the name. Do you think the case of mapping between services from different DetNet Domains should be included here or not? If not, I think “APP flow” is absolutely good. But we have to remove this case and find somewhere else to put it in ( maybe service sub-layer).



Thanks!

Lou

> 2. There are four elements in every configuration instance: operations, in-segment, out-segment, as discussed in IETF 104.
>
> The overall structure is like:
>
> [cid:image006.png@01D51499.6EF5EC20]
>
> If the WG agrees with the structure, we will work on update the draft and publish 03 version as soon as possible.
>
>

The different node rolls identified in the architecture, need to covered in the overall model, but need not be explicitly identified. For example some nodes, will be service aware while others only support the forwarding sub layer. I'd like to see the update resulting from my comment above before making more detail comments though.

<Xuesong> Yes, I agree that the role of the node should be decoupled here. So there is no node role in the new structure. We just list all the instances, and each node will contain the instance that should be there to support the function.

Lou
(As contributor)

>
> Any comments or suggests are welcome.
>
>
>
> Best Regards
> Xuesong
>
>
>
>>-----Original Message-----
>
>>From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of
>
>>internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
>
>>Sent: Tuesday, March 26, 2019 12:47 AM
>
>>To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
>
>>Cc: detnet@ietf.org<mailto:detnet@ietf.org>
>
>>Subject: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt
>
>>
>
>>
>
>>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>>This draft is a work item of the Deterministic Networking WG of the IETF.
>
>>
>
>>        Title           : Deterministic Networking (DetNet) Configuration
>
>>YANG Model
>
>>        Authors         : Xuesong Geng
>
>>                          Mach(Guoyi) Chen
>
>>                          Zhenqiang Li
>
>>                          Reshad Rahman
>
>>       Filename        : draft-ietf-detnet-yang-02.txt
>
>>       Pages           : 46
>
>>       Date            : 2019-03-25
>
>>
>
>>Abstract:
>
>>   This document contains the specification for Deterministic Networking
>
>>   flow configuration YANG Model.  The model allows for provisioning of
>
>>   end-to-end DetNet service along the path without dependency on any
>
>>   signaling protocol.
>
>>
>
>>   The YANG module defined in this document conforms to the Network
>
>>   Management Datastore Architecture (NMDA).
>
>>
>
>>
>
>>
>
>>The IETF datatracker status page for this draft is:
>
>>https://datatracker.ietf.org/doc/draft-ietf-detnet-yang/
>
>>
>
>>There are also htmlized versions available at:
>
>>https://tools.ietf.org/html/draft-ietf-detnet-yang-02
>
>>https://datatracker.ietf.org/doc/html/draft-ietf-detnet-yang-02
>
>>
>
>>A diff from the previous version is available at:
>
>>https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-yang-02
>
>>
>
>>
>
>>Please note that it may take a couple of minutes from the time of submission
>
>>until the htmlized version and diff are available at tools.ietf.org.
>
>>
>
>>Internet-Drafts are also available by anonymous FTP at:
>
>>ftp://ftp.ietf.org/internet-drafts/
>
>>
>
>>_______________________________________________
>
>>detnet mailing list
>
>>detnet@ietf.org<mailto:detnet@ietf.org>
>
>>https://www.ietf.org/mailman/listinfo/detnet
>
>
> ----------
> _______________________________________________
> detnet mailing list
> detnet@ietf.org<mailto:detnet@ietf.org>
> https://www.ietf.org/mailman/listinfo/detnet
>