Re: [Detnet] Some Comments about the information model

["Gengxuesong (Geng Xuesong)" <[e-mail]>]

Hi Bala'zs,

Thank you for your detailed response.

1. DetNet Identification in the encapsulation sounds good to me.
But I am a little confused with the "aggregate of DetNet flows" part, even after rereading the architecture draft. I cannot figure what kind of condition will make it necessary to aggregate flows or dedicate an LSP to more than 1 DetNet flows?
(BTW the quote is in chapter 4.7 of the architecture draft,  in case anyone else want to check the context)

2. "calculated" is great, thanks.

Best Regards,

Xuesong

From: detnet [mailto:[e-mail]] On Behalf Of Balázs Varga A
Sent: Tuesday, April 25, 2017 3:44 PM
To: Gengxuesong (Geng Xuesong); [e-mail]
Cc: [e-mail]
Subject: Re: [Detnet] Some Comments about the information model

Hi Xuesong,
thanks for your feedback.

- chapter6.1, Identification of flows:
Good point, maybe worth to put all the pieces together here. We have related text in three drafts (architecture, data-plane, flow-info).
You are correct, intermediate nodes have to recognize DetNet flows for proper forwarding (e.g., selecting queues, using the allocated
resources, etc.). So it is intended to works as follows (example below is with non-detnet-aware end systems):
1, Source:
encapsulates data of the application (that requires detnet treatment in the network). The flow can be recognized based on L2
and/or L3 fields as defined in the info model.
2,a, Edge node:
the info model specifies the identification at the edge. For ingress it is the same as used by the source.
2,b, Edge node:
also has the task to adapt the format of the transported DetNet flow (i.e., by additional encapsulation) for the forwarding
paradigm of the DetNet domain. This encapsulation is described in the dataplane-solution draft (still under discussion) and
intended to ensure that intermediate nodes in the DetNet domain can easily recognize and serve DetNet flows.
3, Intermediate node:
recognizes detnet flows based on the fields in the encapsulation created by edge nodes.

One more thing worth to add here: the DetNet domain may be configured to serve aggregate flows. In such a case intermediate nodes are not
able to recognize each individual DetNet flows. Intermediate nodes do recognize only the aggregates (for example an LSP dedicated to transport the
aggregate of DetNet flows, etc.).
See also https://tools.ietf.org/html/draft-ietf-detnet-architecture-01 in chapter 4.9
" it is possible that an existing DetNet flow can be used as a carrier for multiple DetNet sub-flows ...
Of course, this requires that the aggregate DetNet flow be provisioned properly to carry the sub-flows."

- chapter10, Status:
Yes, You are correct. Agree, the "measured" should be replaced with "calculated" or similar.

Cheers
Bala'zs

From: Gengxuesong (Geng Xuesong) [mailto:[e-mail]]
Sent: 2017. április 24. 15:42
To: [e-mail]<mailto:[e-mail]>; Balázs Varga A <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Some Comments about the information model


Hi Bala'zs


I have read "draft-farkas-detnet-flow-information-model-00". Thank you for offering the whole picture of DetNet information model, combining L2 and L3.

Here are some comments and questions after reading the draft:

6.1. Identification and Specification of Flows
"Identification options for TSN flows are specified by [IEEE8021CB], which also includes IP flow identification"

So I find the relative contents in [IEEE8021CB] as follows:
" The IP Stream identification is a passive Stream identification function that operates at the transport layer and Internet Protocol interface layer."

That is to say, the information of this part can only be recognized by the end station or other "DetNet edge node", which contain the transport layer(It is different from the transport layer in draft-finn-detnet-architecture-08. It is the transport layer in IP/TCP I think). However, the intermediate node which will forward the DetNet flow should also have the ability to separate DetNet flows from other flows, and send them to a special queue or make them go through queuing scheduler, in order to limit the delay in this node. So whether you have considered DetNet identification in every intermediate node as described above?


10. Status
"AccumulatedLatency is specified as an integer number of nanoseconds. Latency is measured using the time at which the data frame's message timestamp point passes the reference plane marking the boundary between the network media and PHY. The message timestamp point is specified by IEEE Std 802.1AS [IEEE8021AS] for various media. For a successful Status, the network returns a value less than or equal to the MaxLatency of the UserToNetworkRequirements (Section 9.3)."

If AccumulatedLatency of a particular path is MEASURED, even when it is less than the MaxLatency, it can not been proved that all the flows going through the path will experience latency which is less than their requirements. Because MEASUREMENT is only a special case. Maybe AccumulatedLatency should be defined as a value independent of the Internet conditions, such as a calculated value by the theory or other methods?





Best Regards,

Xuesong