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

[Balázs Varga A <[e-mail]>]

Hi Bruno,

Many thanks for your review. 

Yes, this informational draft builds upon the technology specified by RFC9025.  Nonetheless, 
this draft describes in detail a specific network scenario. Right, the draft has its own story line 
as well. 

DetNet WG has defined two data planes: (1) IP, (2) MPLS. In order to minimize data plane 
impact of DetNet technology to existing hardware, a "simplified" IP data plane was defined 
in RFC8939. Simplified means that no new IP headers were defined to include the meta-data 
needed for PREOF functionalities (i.e., sequence number). 

DetNet WG defined in dedicated documents how to use different sub-network technologies 
to interconnect DetNet nodes, one of them is RFC9025. It is not the task of a sub-network nodes 
to participate in PREOF, therefore RFC9025 defined only the encapsulation aspects of the 
IP sub-network scenario.

However, draft-ietf-detnet-mpls-over-ip-preof describes the scenario how to achieve PREOF 
support in a DetNet IP network with minimal effort and re-using the existing DetNet RFCs.
It is a very important characteristics of this document that it only allows for zero F labels and 
uses the PW encapsulation just to carry the "sequence number" information, without 
implementing a full-blown MPLS protocol stack on the DetNet IP node. 

As a summary, RFC9025 defines a "sub-network" scenario (interconnection of DetNet MPLS 
nodes), whereas this draft defines how to implement a "PREOF capable DetNet IP node/network".

Please note that the intended status is "informational". This is to reflect that this draft does not 
specify new technology, but describes a very specific use of other RFCs for DetNet scenarios as 
described above. In other words,  this draft puts the pieces of the puzzle together, which - based 
on various off-line discussions - is not that trivial.

Also thanks for the minor/nit comments, we have updated the draft accordingly, except 
comments on §4.2 and §4.5, where the differences are intentionally to RFC9025 and results from 
the zero F-labels.

Many thanks

Bala'zs (& János & Andy)

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Wednesday, April 5, 2023 6:53 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: [RTG-DIR] Rtgdir early review of draft-ietf-detnet-mpls-over-ip-preof-02

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.