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

[Lou Berger <[e-mail]>]

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

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

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


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