Reviewer: Bruno Decraene Review result: Has Issues I have been selected to do a routing directorate “early” review of this draft. Disclaimer: I had no knowledge of DETNET before this review. So please excuse the my lack of DETNET knowledge. Summary: It's not really crystal clear to me what this document brings in addition to RFC9025. However I've limited knowledge of DetNet and the misunderstanding may likely comes from me. Yet this document seems to duplicate at best or re-specify at worst a some part of RC9025. I have some minor comments and nits on the text. Comments: Major: It's not clear to me what this document brings in addition to RFC9025. My understanding is that RFC9025 provides "full functionality at the DetNet layer over an IP network". So this seems to (already) include DetNet PREOF at the service sub-layer. At minimum, it seems that RFC9025 already provides the bits on the wire required for PREOF. The only change that I could see is that RFC9025 allows for zero or more F-labels while this document only allows for zero F labels. If this is the only difference, probably this document could be made much shorter. ====================== Minor: Abstract: " built on the existing MPLS PREOF solution [RFC8939]" 8939 seems to be DetNet over IP. Did you meant RFC 8964? ---- Introduction "The DetNet MPLS data plane [RFC8939]" 8939 seems to be DetNet over IP. Did you meant RFC 8964? ----- 3. Requirements "The described solution practically gains from MPLS header fields without adding MPLS protocol stack complexity to the nodal requirements." - I'm not sure that MPLS data plane is "complex" compared to the DetNet data plane, at least from a network processor standpoint... - The proposed solution carries a S-label which is an MPLS label hence MPLS... IMO this sentence could be removed or simplified. e.g. "The described solution practically gains from MPLS header fields without requiring the support of the MPLS forwarding plane". ----- 4.3. Packet Processing "Note, that Service-IDs provide identification at the downstream DetNet service sub-layer receiver, not the sender." - I would propose to indicate what is been authenticated. (I would assume the DetNet flow). - I don't understand what you mean by "not the sender". My best guess would be "Note, that Service-IDs is a local ID on the receiver side providing identification of the DetNet flow (or service sub-layer ?) at the downstream DetNet service sub-layer receiver." ----- OLD: In the first case, the different DetNet PWs use the same UDP tunnel, so they are treated as a single (aggregated) flow on all transit nodes. That seems to be also the case for the second case so it's not clear to me that this sentence is the best way to characterize the first case. I would propose NEW: 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. OLD: For the second option, an additional Service-ID and d-CW tuple is added to the encapsulation. I would propose NEW: For the second option, an additional hierarchy is created thanks to an additional Service-ID and d-CW tuple added to the encapsulation. ----- §4.2 " DetNet flows are identified at the receiving DetNet service sub-layer processing node via the S-Label and/or the UDP/IP header information." Well, actually RFC9025 seems to say something different: "identify incoming app flows based on the combination of S-Label and incoming encapsulation header information." And why does this document re-describe/specifies what is already defined in RFC 9025. ( same comment for §4.5 "The provisioned information MUST be used to identify incoming app-flows based on the combination of Service-ID and/or incoming encapsulation header information." ----- § 5. Control and Management Plane Parameters RC8939 also allows the use of the IPv6 Flow Label. Is there a reason not to also include it in this section? ====================== Nits: Introduction OLD: The DetNet Working Group has defined packet replication (PRF), packet elimination (PEF) and packet ordering (POF) functions may be NEW: The DetNet Working Group has defined Packet Replication (PRF), Packet Rlimination (PEF) and Packet Ordering (POF) functions ----- §5 "this draft envisions" :s/draft/document Not sure "envision" is the best term for an RFC, but it's really up to you.