[RTG-DIR] Rtgdir early review of draft-ietf-detnet-mpls-over-ip-preof-02

[Bruno Decraene via Datatracker <[e-mail]>]

Reviewer: Bruno Decraene
Review result: Has Issues

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.