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

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>; 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,

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

DetNet Service sub-layer

DetNet Forwarding sub-layer

TSN sub-network

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”.

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

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.

> 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
>