Re: [Detnet] review DetNet OAM framework draft

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear authors and all

I do support this document but do not see that in its present shape it is ready for WGLC. Please find some review comments below.

- Sadly RFC 8655 does not define either "latency" or "delay". Reading this draft, I now see it as an oversight. I'd suggest that we define them in the terminology section. it is my sense that RFC 8655 uses "delay"  with the meaning of incremental flight duration, and uses "latency" for the total time end-to-end time across the network, IOW, minimal_latency + delay <= bounded_latency.



- Their work -> that work ?



- the abstract and the introduction indicate that the document is a problem statement / functional requirement draft, and indeed the text reads like a requirement document. But the title says framework. Which is it?



- same question about the intended status (std track). Is that really what we want here?



- "It is critical for the

      quality of information obtained using an active method that

      generated test packets are in-band with the monitored data flow.

". this duplicates text in 3.3 and does not belong in a terminology. Remove?



- "                                                                                                         OAM represents the

   essential elements of the network operation and necessary for OAM

   resources that need to be accounted for to maintain the network

   operational.

" does not parse too well



- "information about the state of the network being

   collected

" is being? Maybe remove that text ? it seems to repeat the first sentence of the paragraph.



- "   Also, we can characterize methods of transporting OAM information

   relative to the path of data.  For instance, OAM information may be

   transported out-of-band or in-band with the data flow.

" this deserves its own subsection with some more explanation and possibly some references to relevant IETF work



"   Similarly, the destination does not receive packets from different

   flows through its interface.

" sorry I do not get the intended meaning



- section 3.3 -"It is worth noting that the test and data packets MUST follow the

   same path, i.e., the connectivity verification has to be conducted

   in-band without impacting the data traffic."

 there appears to be a tension between the bandwidth that is reserved for the flow and the extra bandwidth that the OAM needs .

Do we need to know in advance how much OAM there will be? Must that be included in the reservation?





- section 3.4. What do we do for PREOF?



- "The network has isolated and identified the cause of the fault."

Again I fail to understand the intention.



-"                                  One of the advantages of the use of

   AMM in a DetNet domain with the IP data plane is that the marking is

   applied to a data flow, thus ensuring that measured metrics are

   directly applicable to the DetNet flow.

" isn't this the case for IPPM in general? Isn't the benefit of AMM more related to conciseness?



- Maybe we should discuss the tension between RFC 8939 and the capability to use separate packets for OAM, since the flow is routed on the 5/6 tuple. Does that mean that only in-situ is feasible with RFC 8939 (ref draft-ietf-ippm-ioam-ipv6-options)?



Section 4. This section needs more thoughts. For instance there are packets like PTP packets for which it is important to know the transit duration in each hop. Isn't that true for DetNet as well? Radio links have numerous metrics that can be reported (think RFC 8175), we need to know that information per hop as opposed to per path/circuit. We need to know if the hop does store-and-forward or passthrough - e.g., in the former case using smaller frames / packets / segments / fragments and/or network coding may improve the latency. Maybe we could dump the WG collective mind with a dedicated thread?



- "   DetNet needs to implement a self-healing and self-optimization

   approach."

Though I agree with the intention and the next sentences, I'm not sure this is the best wording. Those words are classical for routing protocols that (re)compute a path, which is disruptive or consecutive to a disruption. We do not want disruptions in DetNet. There must be enough PREOF to ensure the SLO without repairing. The RAW problem is actually NOT to use all the redundancy at all times in order to save battery and spectrum. I'd rather say that

" in the face of events that impact the network operation (e.g., link up/down, node crash/reboot, flows starting and ending) the DetNet Controller need to perform repair and re-optimization actions in order to permanently ensure the SLO of all active flows with minimal waste of resources".



- section 5.2: Is it the intention to include the repair action in OAM work?



- section 6. Why only MPLS data plane? It seems that the requirement are not dependent on the underlying technology.



- I'm not sure about requirement 5, 6, 10, 11, and of the use of "excellent" in 16.



- I read requirement 16 as the only service assurance requirement. A very important requirement in my view, and I think we want more. We also want to ensure that a scheduled transmission happens as scheduled/when, that the guaranteed resources like buffers are available per reservation..



Many thanks to the authors for all the great work!



Pascal



From: detnet <[e-mail]> On Behalf Of Janos Farkas
Sent: jeudi 29 avril 2021 0:28
To: [e-mail]
Subject: [Detnet] review DetNet OAM framework draft

WG,

Please review the DetNet OAM framework draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-oam-framework/.

The authors consider the draft in a pretty good shape, do not see any major piece missing.

WG review and comments would be great in order to develop the draft towards WG Last Call.

Please send your comments to the list before the next informal OAM discussion on May 11 or bring it to the informal meeting: https://ietf.webex.com/ietf/j.php?MTID=m27bb8ee31f025670e4071bfdfcd47432. (More details on the OAM informal meetings: https://mailarchive.ietf.org/arch/msg/detnet/4ik3tI-E3uhOFNaKhpkZiWwyiZc/.)

Regards,
Janos