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

[Lou Berger <[e-mail]>]

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)" 
<[e-mail]> 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.
> However, I think maybe I could get your point finally. If I get this right:
> [cid:image002.jpg@01D53117.296632B0]
> 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
>
>
>
> From: detnet [mailto:[e-mail]] On Behalf Of Lou Berger
> Sent: Tuesday, July 02, 2019 7:50 PM
> To: Gengxuesong (Geng Xuesong) <[e-mail]>; [e-mail]
> Cc: 유연철 <[e-mail]>; Mach Chen <[e-mail]>
> Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt
>
>
> 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:
> 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:[e-mail]] On Behalf Of Lou Berger
> Sent: Monday, July 01, 2019 10:07 PM
> To: Gengxuesong (Geng Xuesong) 
> <[e-mail]><mailto:[e-mail]>; 
> [e-mail]<mailto:[e-mail]>
> Cc: 유연철 <[e-mail]><mailto:[e-mail]>; Mach Chen 
> <[e-mail]><mailto:[e-mail]>
> 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:[e-mail]]
> Sent: Sunday, June 30, 2019 11:14 PM
> To: Gengxuesong (Geng Xuesong) 
> <[e-mail]><mailto:[e-mail]>; 
> [e-mail]<mailto:[e-mail]>
> Cc: 유연철 <[e-mail]><mailto:[e-mail]>; Mach Chen 
> <[e-mail]><mailto:[e-mail]>
> 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
>
> why wouldn't it, that's what how *all* the other documents refer to this case.
>
>
>
> 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)" 
> <[e-mail]<mailto:[e-mail]>> 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 architecture and other documents refer to it as an app-flow.
>
>
>
>
>
>
>
> 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.
>
> 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
>
>> 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:[e-mail]] On Behalf Of
>>
>>>[e-mail]<mailto:[e-mail]>
>>
>>>Sent: Tuesday, March 26, 2019 12:47 AM
>>
>>>To: [e-mail]<mailto:[e-mail]>
>>
>>>Cc: [e-mail]<mailto:[e-mail]>
>>
>>>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
>>
>>>[e-mail]<mailto:[e-mail]>
>>
>>>https://www.ietf.org/mailman/listinfo/detnet
>>
>>
>> ----------
>> _______________________________________________
>> detnet mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/detnet
>>
>
>
>
> This body part will be downloaded on demand.