Reviewer: Olivier Bonaventure Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. I reviewed the document from the transport viewpoint without being an expert in DetNet. As Bruno Decraene mentions in his review, the document seems to be a small modification to RFC9025 that already defines the encapsulation. Is it intended to informational while RFC9025 is standards track. In Section 5, my main concern is the handling of the FlowLabel field in the IPv6 header when several Detnet flows are aggregated together. Will these flows use packets with the same IPv6 flowLabel or different flowLabels (one per Detnet flow) ? This would have an impact on ECMP hash and thus influence the packet that different Detnet flows follow. If several Detnet flows are aggregated in a single UDP tunnel, do they all need to follow the same path in the network or not ? The handling of this FlowLabel must be clarified in a revision of this document. Details In Section 1 However, the DetNet IP data plane described in [RFC8939] does not specify how sequencing information can be encoded in the IP header. the end of the sentence (IP header) is misleading. The reader could think that you will change the IP header with an extension, which is clearly not the case. In 4.4, at the end of In the first case, the different DetNet PWs use the same UDP tunnel, so they are treated as a single (aggregated) flow at the forwarding sub-layer. At the service sub-layer, each flow uses a different Service ID. I would suggest to provide a reference to Figure 3 that describes this encapsulation. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
