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

[[e-mail]]

The datatracker seems to have slightly edited my layout so I'm resending below my original text which I believe is easier to parse.

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 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 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 mean RFC 8964?
----

Introduction
"The DetNet MPLS data plane [RFC8939]" 
8939 seems to be DetNet over IP. Did you mean 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....
- 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."


Orange Restricted

-----
§ 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.

-----Original Message-----
From: rtg-dir <[e-mail]> On Behalf Of Bruno Decraene via Datatracker
Sent: Wednesday, April 5, 2023 6:48 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: [RTG-DIR] Rtgdir early review of draft-ietf-detnet-mpls-over-ip-preof-02

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.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.