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

[Lou Berger <[e-mail]>]

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]>; [e-mail]
> *Cc:* 유연철<[e-mail]>; Mach Chen <[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.