Subject: [Detnet] I-D Action: draft-ietf-detnet-flow-information-model-05.txt

From: [email-masked]
Date: Thu, 12 Sep 2019 06:55:09 -0700

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           : DetNet Flow Information Model
        Authors         : János Farkas
                          Balázs Varga
                          Rodney Cummings
                          Yuanlong Jiang
                          Don Fedyk
	Filename        : draft-ietf-detnet-flow-information-model-05.txt
	Pages           : 22
	Date            : 2019-09-12

Abstract:
   This document describes flow and service information model for
   Deterministic Networking (DetNet).  These models are defined for IP
   and MPLS DetNet data planes

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-detnet-flow-information-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-05
https://datatracker.ietf.org/doc/html/draft-ietf-detnet-flow-information-model-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-flow-information-model-05

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/

---

From: Balázs Varga A <[email-masked]>
Date: Thu, 12 Sep 2019 13:59:25 +0000

Hi,

Some editorial clean up were made on this draft.
Any comments from the group are welcome.

Do we have any missing attribute(s)?

Cheers
Bala'zs

-----Original Message-----
From: detnet <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, September 12, 2019 3:55 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Detnet] I-D Action: draft-ietf-detnet-flow-information-model-05.txt

Abstract:

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.

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Fri, 20 Sep 2019 09:00:48 +0000

Hi Bala'zs,

Here are some comments for DetNet information Model 

1. The definition of DetNet flow and DetNet Service :
1) In Section 3.2 "Reference Points Used in Modeling":
"From service design perspective a fundamental question is the location of the service/flow endpoints, i.e., where the service/flowstarts and ends."
It seems like that the DetNet service and DetNet flow are the same thing, or at least share the same end point.

2) In Section 3.3 "Information Elements": 
there is definition of DetNet Flow and DetNet Service 
"   o  DetNet flow related parameters: these describe the DetNet flow
      characteristics (e.g., identification, format, traffic
      specification, endpoints, rank, etc.).
   o  DetNet service related parameters: these describe the expected
      service characteristics (e.g., delivery type, connectivity delay/
      loss, status, rank, etc.)."
N:1 Mapping is also allowed for DetNet flow and DetNet service
It seems like that the DetNet service is the "expected service" and DetNet flow is the "real detnet flow"

3) In Section 5 "DetNet Flow Related Parameters " and Section 6"DetNet Service Related Parameters"
There are a lot of same parameters both defined in DetNet flow and DetNet Service, 
for example the parameter of "Requirements of the DetNet Flow " are the same as the "Delivery Profile of the DetNet Service"
for example the parameter of "Format of the DetNet Flow" and "Delivery Type of the DetNet service";

This makes me very confused. If the values of these parameters are the same, why they should be defined twice? If they are different,
which should be the real characteristics for a DetNet flow/service?

I think the structure of the information model is not clear for me, especially the relationship between detnet service and detnet flow(In DetNet architecture draft, there is no definition for "detnet service" either). At least more explanation is needed here.

2. The interface between DetNet information model and DetNet YANG model :
1) In the picture shows in Section 1, 

      User                  Network Operator
              flow/service
       /\      info model    +---+
      /  \    <--------------->   | X |    management/control
      ----                   +-+-+       plane entity
                             ^
                             |   configuration
                             |     info model
                        +------------+
                        v     |     |
                       +-+     |     v  Network
                       +-+     v    +-+  nodes
                              +-+   +-+
                              +-+
I think we both agree that , this picture shows there is no direct interface between DetNet information model and DetNet Configuration model. But some parameters should go along with each other.

2) What has been done in the current stage and what is missing
In Section 4 and Section 5 App flow Identification and DetNet flow Identification are defined. DetNet YANG Model refer to DetNet information model about these parameters.
Do you think this is enough? What should also be included? It will be highly appreciated if you could give some suggestions and we could also discuss this in the mailing list.

Best Regards
Xuesong

>From: detnet [mailto:[email-masked]] On Behalf Of Balázs Varga A
>Sent: Thursday, September 12, 2019 9:59 PM
>To: [email-masked]
>Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-flow-information-model-05.txt
>
>Hi,
>

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 23 Sep 2019 07:39:48 +0000

Hi Xuesong,

Thanks for your review on the flow information model. 

Please, find below my clarifications regarding your topics:
- DetNet flow vs. DetNet Service:
They are defining different but related things, that may have caused your confusion.
We are using the terminology of draft-architecture. The DetNet service is provided
for the packets of a DetNet flow (see definition in Sec2.1 of draft-flow-info). 
DetNet flow requirements are based on end-user App-flow requirements, what
the User "wants" from the Operator across its network.
DetNet service parameters are determined and used by the Network Operator 
(see Fig2). They are used as input to create configuration for the nodes in the 
Operator's Network.
For each flow requirements attribute there must be a matching service delivery
attribute. Maybe an example on delay can clarify: DnFlowRequirements.MaxLatency 
defines what is the maximum latency a DetNet flow can tolerate.
DnServiceDeliveryProfile.MaxLatency defines what is the maximum latency provided 
by the the DetNet service. The flow requirements are fulfilled if
DnFlowRequirements.MaxLatency >= DnServiceDeliveryProfile.MaxLatency

- Structure of attributes
Slide 6 (and also 7 and 8) were created to visualize the structure of the attributes:
https://datatracker.ietf.org/meeting/105/materials/slides-105-detnet-sessa-detnet-flow-info-model-ietf-105-00.pdf
App-flow related attributes describe the characteristics and requirements of
the App-flow. At the edge of the DetNet domain when the DetNet flow is 
"created" the attributes of one or more App-flow(s) are used. (e.g., when 
multiple App-flows are served by a single DetNet flow (i.e., aggregation)).
Inside the DetNet domain a "DetNet service instance" may serve multiple
DetNet flows, therefore DetNet service related attributes are determined 
by considering attributes of all served DetNet flows.

- Identification in YANG:
I think referring to DetNet information model about identification attributes
is fine. Additionally, You need a configuration related parameter, that describes
the mapping of App-flow(s) to DetNet flow ( FlowID(s) -- > DnFlowID). 
And similarly the mapping of DetNet flow(s) to DetNet service instance 
(DnFlowID(s) -- > DnServiceID).

Let me know whether the above clarifies your concerns.

Thanks & Cheers
Bala'zs

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]> 
Sent: Friday, September 20, 2019 11:01 AM
To: Balázs Varga A <[email-masked]>
Cc: [email-masked]
Subject: RE: [Detnet] I-D Action: draft-ietf-detnet-flow-information-model-05.txt

Hi Bala'zs,

N:1 Mapping is also allowed for DetNet flow and DetNet service It seems like that the DetNet service is the "expected service" and DetNet flow is the "real detnet flow"

3) In Section 5 "DetNet Flow Related Parameters " and Section 6"DetNet Service Related Parameters"
There are a lot of same parameters both defined in DetNet flow and DetNet Service, for example the parameter of "Requirements of the DetNet Flow " are the same as the "Delivery Profile of the DetNet Service"
for example the parameter of "Format of the DetNet Flow" and "Delivery Type of the DetNet service";

This makes me very confused. If the values of these parameters are the same, why they should be defined twice? If they are different, which should be the real characteristics for a DetNet flow/service?

      User                  Network Operator
              flow/service
       /\      info model    +---+

2) What has been done in the current stage and what is missing In Section 4 and Section 5 App flow Identification and DetNet flow Identification are defined. DetNet YANG Model refer to DetNet information model about these parameters.
Do you think this is enough? What should also be included? It will be highly appreciated if you could give some suggestions and we could also discuss this in the mailing list.

Best Regards
Xuesong

>Subject: Re: [Detnet] I-D Action: 
>draft-ietf-detnet-flow-information-model-05.txt
>
>Hi,
>
>Subject: [Detnet] I-D Action: 
>draft-ietf-detnet-flow-information-model-05.txt
>
>
>https://datatracker.ietf.org/doc/html/draft-ietf-detnet-flow-informatio
>n-model-
>05
>
>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.
>