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

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Mon, 1 Jul 2019 09:32:01 +0000

Hi Lou,

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

Best Regards
Xuesong

From: Lou Berger [mailto:[email-masked]]
Sent: Sunday, June 30, 2019 11:14 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: 유연철 <[email-masked]>; Mach Chen <[email-masked]>
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)" <[email-masked]<mailto:[email-masked]>> 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:
>
> 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:
>

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:
>
>
> 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:[email-masked]] On Behalf Of
>
>>[email-masked]<mailto:[email-masked]>
>
>>Sent: Tuesday, March 26, 2019 12:47 AM
>
>>To: [email-masked]<mailto:[email-masked]>
>
>>Cc: [email-masked]<mailto:[email-masked]>
>
>>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
>
>>[email-masked]<mailto:[email-masked]>
>
>>https://www.ietf.org/mailman/listinfo/detnet
>
>
> ----------
> _______________________________________________
> detnet mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/detnet
>

---

From: Lou Berger <[email-masked]>
Date: Mon, 1 Jul 2019 10:06:38 -0400

Hi,

Thank you for the response. Please see my comments in-line below.

On 7/1/2019 5:32 AM, Gengxuesong (Geng Xuesong) wrote:
> *From:*Lou Berger [mailto:[email-masked]]
> *Sent:* Sunday, June 30, 2019 11:14 PM
> *To:* Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
> *Cc:* 유연철<[email-masked]>; Mach Chen <[email-masked]>
> *Subject:* Re: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt
>
> Hi,
>
> I think our yang modeling should follow the architecture, the flow 
> information model and the data plane solution documents.
>
> 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"
> DetNet Forwarding sub-layer
I don't think "TSN" is the only option here, so should be dropped.

> 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.
>
> On May 27, 2019 2:36:31 AM "Gengxuesong (Geng Xuesong)" 
> <[email-masked] <mailto:[email-masked]>> 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:
> >
> > 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:
> >
>
> 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.

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

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

Thanks!

Lou

> > 2. There are four elements in every configuration instance: 
> operations, in-segment, out-segment, as discussed in IETF 104.
> >
> > 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)
>
>
> >
> >>[email-masked] <mailto:[email-masked]>
> >
> >>To: [email-masked] <mailto:[email-masked]>
> >
> >>Cc: [email-masked] <mailto:[email-masked]>
> >
> >>[email-masked] <mailto:[email-masked]>
> >
> > [email-masked] <mailto:[email-masked]>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 2 Jul 2019 02:13:31 +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:[email-masked]] On Behalf Of Lou Berger
Sent: Monday, July 01, 2019 10:07 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: 유연철 <[email-masked]>; Mach Chen <[email-masked]>
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt

Hi,

Best Regards
Xuesong

From: Lou Berger [mailto:[email-masked]]
Sent: Sunday, June 30, 2019 11:14 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: 유연철 <[email-masked]><mailto:[email-masked]>; Mach Chen <[email-masked]><mailto:[email-masked]>
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt

Hi,

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

DetNet 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

TSN sub-network

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

name

in-segments

out-segments

operations

----------

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”

   Name: XX

   In-segment: app flow

<Xuesong>  Great!

   Name : XX

<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

Lou
(As contributor)

---

From: Lou Berger <[email-masked]>
Date: Tue, 2 Jul 2019 07:49:53 -0400

Hi Xuesong,

You might want to look at the updated data plane docs published 
yesterday 
(https://tools.ietf.org/wg/detnet/index.pyht?sort=3&reverse=1). In 
particular the sections labeled "Flow Identification Management and 
Control Information" - each basically summarizes the information that 
will need to be covered in the yang models.

see bellow for specific responses.

On 7/1/2019 10:13 PM, Gengxuesong (Geng Xuesong) wrote:
> 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:[email-masked]] *On Behalf Of *Lou Berger
> *Sent:* Monday, July 01, 2019 10:07 PM
>     *To:* Gengxuesong (Geng Xuesong) <[email-masked]>
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     *Cc:* 유연철<[email-masked]> <mailto:[email-masked]>; Mach
>     Chen <[email-masked]> <mailto:[email-masked]>
>     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
>
> <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
>
why wouldn't it, that's what how *all* the other documents refer to this 
case.

>     detnet abstract elements, but also allows for technology
>     specifics”. However, if you have better idea of the design, please
>     let us know.
>
>     > 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:
>     >
>     > 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:
>     >
>
>     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”.
>
> <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 architecture and other documents refer to it as an app-flow.
>     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
>
>     only thing that should be included. So we think “DetNet proxy” may
>     be more suitable here.
>
> <Xuesong>  Yes…the disagreement here is just the name.
>
for me it is about cross document consistency and having the modeling 
line up with the rest of the DetNet concepts.  A proxy is a node type 
that maps app-flows to detent flows according to the architecture doc. 
It also says App-flows are what sit above DetNet and is what detnet 
provides services for.  I don't think the models should be inventing new 
architecture or other concepts, but rather represent what is defined 
elsewhere.

> 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).
>
Which case? a proxy?  I thought you agreed that you/we don't expect 
specific node types to be explicitly called out in the yang models.  
Perhaps I misunderstood.

Thank you!

Lou

>     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)
>
>
>     >
> This body part will be downloaded on demand.

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 2 Jul 2019 12:46:05 +0000

Hi Lou,

Thank you for reminding the updated text. I believe this could provide a reasonable base for DetNet YANG model. I will read them carefully. However, I’m afraid the time is not enough for us to make the YANG Model in accordance with all the updated data plane drafts strictly before IETF 105. We will check whether the new structure of the YANG Model is general enough to carry all the  “Management and Control Information”.

About the previous discussion, I agree that all the names used in YANG Model should refer to the names that have been defined in architecture. I just try to make sure that the name that has been defined is able to cover all the possible situations and easy to understand.
However, I think maybe I could get your point finally. If I get this right:
You mean that, as showed in the figure above, from the view of the proxy, the “DetNet Flow from another domain” is handled similarly just as an “App flow”. So , we could call it an “app flow instance”.
If this is right, I could change the name in the YANG Model ☺

Best Regards
Xuesong

Sent: Tuesday, July 02, 2019 7:50 PM

Hi Xuesong,

You might want to look at the updated data plane docs published yesterday (https://tools.ietf.org/wg/detnet/index.pyht?sort=3&reverse=1). In particular the sections labeled "Flow Identification Management and Control Information" - each basically summarizes the information that will need to be covered in the yang models.

Best Regards
Xuesong

Hi,

Best Regards
Xuesong

Hi,

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

DetNet Proxy

why wouldn't it, that's what how *all* the other documents refer to this case.

DetNet Service sub-layer

TSN sub-network

name

in-segments

out-segments

operations

----------

   Name: XX

   In-segment: app flow

<Xuesong>  Great!

   Name : XX

for me it is about cross document consistency and having the modeling line up with the rest of the DetNet concepts.  A proxy is a node type that maps app-flows to detent flows according to the architecture doc. It also says App-flows are what sit above DetNet and is what detnet provides services for.  I don't think the models should be inventing new architecture or other concepts, but rather represent what is defined elsewhere.

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

Which case? a proxy?  I thought you agreed that you/we don't expect specific node types to be explicitly called out in the yang models.  Perhaps I misunderstood.

Thank you!

Lou

Thanks!

Lou

Lou
(As contributor)

---

From: Lou Berger <[email-masked]>
Date: Tue, 02 Jul 2019 09:09:16 -0400

Hi Xuesong,

I'm saying that the general case covered in the architecture is that app 
flows are carried over (i.e., receive service from) a detnet and this is 
true no matter what node type is present at the edge, or between service 
instances.  So I think this is the right concept to focus on, rather than 
have a top/main level element in our model that is node type-specific. so 
from a modeling perspective, I would drop the proxy in your figure below.

Cheers,

Lou

----------
On July 2, 2019 8:46:37 AM "Gengxuesong (Geng Xuesong)" 
<[email-masked]> wrote:

> Hi Lou,
>
> Thank you for reminding the updated text. I believe this could provide a 
> reasonable base for DetNet YANG model. I will read them carefully. However, 
> I’m afraid the time is not enough for us to make the YANG Model in 
> accordance with all the updated data plane drafts strictly before IETF 105. 
> We will check whether the new structure of the YANG Model is general enough 
> to carry all the  “Management and Control Information”.
>
> About the previous discussion, I agree that all the names used in YANG 
> Model should refer to the names that have been defined in architecture. I 
> just try to make sure that the name that has been defined is able to cover 
> all the possible situations and easy to understand.
> You mean that, as showed in the figure above, from the view of the proxy, 
> the “DetNet Flow from another domain” is handled similarly just as an “App 
> flow”. So , we could call it an “app flow instance”.
> You might want to look at the updated data plane docs published yesterday 
> particular the sections labeled "Flow Identification Management and Control 
> Information" - each basically summarizes the information that will need to 
> be covered in the yang models.
>
> 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
>
> To: Gengxuesong (Geng Xuesong) 
> <[email-masked]><mailto:[email-masked]>; 
> Cc: 유연철 <[email-masked]><mailto:[email-masked]>; Mach Chen 
> <[email-masked]><mailto:[email-masked]>
> To: Gengxuesong (Geng Xuesong) 
> <[email-masked]><mailto:[email-masked]>; 
> Cc: 유연철 <[email-masked]><mailto:[email-masked]>; Mach Chen 
> <[email-masked]><mailto:[email-masked]>
> 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 
> <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
> <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
>
> 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.
>
> <[email-masked]<mailto:[email-masked]>> 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:
>>
>> 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:
>>
>
> 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 
> <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”.
>
> 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”
> 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
>
> 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.
>
>
>
> for me it is about cross document consistency and having the modeling line 
> up with the rest of the DetNet concepts.  A proxy is a node type that maps 
> app-flows to detent flows according to the architecture doc. It also says 
> App-flows are what sit above DetNet and is what detnet provides services 
> for.  I don't think the models should be inventing new architecture or 
> other concepts, but rather represent what is defined elsewhere.
>
> 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).
>
>> 2. There are four elements in every configuration instance: operations, 
>> in-segment, out-segment, as discussed in IETF 104.
>>
> 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)
>
>>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 3 Jul 2019 01:58:58 +0000

Hi Lou,

OK, I agree. I would change the name.

Best Regards
Xuesong

From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, July 02, 2019 9:09 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: 유연철 <[email-masked]>; Mach Chen <[email-masked]>
Subject: RE: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt

Hi Xuesong,

I'm saying that the general case covered in the architecture is that app flows are carried over (i.e., receive service from) a detnet and this is true no matter what node type is present at the edge, or between service instances.  So I think this is the right concept to focus on, rather than have a top/main level element in our model that is node type-specific. so from a modeling perspective, I would drop the proxy in your figure below.

Cheers,

Lou

________________________________

On July 2, 2019 8:46:37 AM "Gengxuesong (Geng Xuesong)" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lou,

Best Regards
Xuesong

From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, July 02, 2019 7:50 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: 유연철 <[email-masked]<mailto:[email-masked]>>; Mach Chen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt

Hi Xuesong,

Best Regards
Xuesong

Hi,

Best Regards
Xuesong

Hi,

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

DetNet Proxy

DetNet Service sub-layer

TSN sub-network

name

in-segments

out-segments

operations

----------

•   Name: XX

•   In-segment: app flow

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

•   Operation: sequence number generation

<Xuesong>  Great!

•   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

Thank you!

Lou

Thanks!

Lou

Lou
(As contributor)

---

From: "Black, David" <[email-masked]>
Date: Wed, 17 Jul 2019 18:43:28 +0000

Minor, but important, comment – I see several occurrences of “dscp-bitmask” in this draft.   That’s not a good idea, because it is not consistent with this paragraph in RFC 2474, Section 3 (https://tools.ietf.org/html/rfc2474#section-3):

   Implementors should note that the DSCP field is six bits wide.  DS-
   compliant nodes MUST select PHBs by matching against the entire 6-bit
   DSCP field, e.g., by treating the value of the field as a table index
   which is used to select a particular packet handling mechanism which
   has been implemented in that device.  The value of the CU field MUST
   be ignored by PHB selection.  The DSCP field is defined as an
   unstructured field to facilitate the definition of future per-hop
   behaviors.

The best approach is to use a list of individual DSCPs.

Thanks, --David

From: detnet <[email-masked]> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Monday, July 1, 2019 10:14 PM
To: Lou Berger; [email-masked]
Cc: 유연철; Mach Chen
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt

[EXTERNAL EMAIL]
Hi Lou,

Best Regards
Xuesong

Hi,

Best Regards
Xuesong

Hi,

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

DetNet Proxy

DetNet Service sub-layer

TSN sub-network

name

in-segments

out-segments

operations

----------

   Name: XX

   In-segment: app flow

<Xuesong>  Great!

   Name : XX

Thanks!

Lou

Lou
(As contributor)

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Thu, 18 Jul 2019 03:16:19 +0000

Thank you David for reviewing the draft and giving comments.
Your suggestion is very reasonable for me.
If there is no other consideration from other authors, I think we would update this in the next version.

Best Regards
Xuesong

From: Black, David [mailto:[email-masked]]
Sent: Thursday, July 18, 2019 2:43 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; Lou Berger <[email-masked]>; [email-masked]
Cc: 유연철 <[email-masked]>; Mach Chen <[email-masked]>
Subject: RE: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt

Thanks, --David

From: detnet <[email-masked]<mailto:[email-masked]>> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Monday, July 1, 2019 10:14 PM
To: Lou Berger; [email-masked]<mailto:[email-masked]>
Cc: 유연철; Mach Chen
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt

[EXTERNAL EMAIL]
Hi Lou,

Best Regards
Xuesong

Hi,

Best Regards
Xuesong

Hi,

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

DetNet Proxy

DetNet Service sub-layer

TSN sub-network

name

in-segments

out-segments

operations

----------

   Name: XX

   In-segment: app flow

<Xuesong>  Great!

   Name : XX

Thanks!

Lou

Lou
(As contributor)