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

[Lou Berger <[e-mail]>]

Balazs,

can you drop lines 138-144, and push a new rev?

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-detnet-mpls-over-ip-preof-06.txt

Thank you,
Lou
On 7/25/2023 10:11 AM, Balázs Varga A wrote:
> Hi Bruno, great, thanks. Version 06 was uploaded with these changes. Cheers Bala'zs
>
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Tuesday, July 25, 2023 3:28 PM
> To: Balázs Varga A <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Lou Berger <[e-mail]>
> Subject: RE: [RTG-DIR] Rtgdir early review of draft-ietf-detnet-mpls-over-ip-preof-02
>
> Hi Balázs,
>
> Thanks.
> Change looks good to me.
>
> Regards,
> --Bruno
>
>
> Orange Restricted
>
> -----Original Message-----
> From: Balázs Varga A <[e-mail]>
> Sent: Tuesday, July 25, 2023 2:40 PM
> To: DECRAENE Bruno INNOV/NET <[e-mail]>; Lou Berger <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [RTG-DIR] Rtgdir early review of draft-ietf-detnet-mpls-over-ip-preof-02
>
> Hi Bruno,
>
> Many thanks for your efforts to improve the document. Based on the further feedbacks we intend to do the following changes (including your proposed one as well). Please, let us know if these changes are able to mitigate your concerns.
>
> OLD:
> "This document describes a DetNet IP encapsulation that includes sequencing information based on the DetNet MPLS over UDP/IP data plane [RFC9025], i.e., leveraging the MPLS-over-UDP technology."
> NEW:
> "This documents provides sequencing information to DetNet IP nodes by re-using the DetNet MPLS over UDP/IP data plane [RFC9025] with the restriction of using zero F-labels."
> END.
>
> OLD:
> " 4.5. PREOF Procedures"
> NEW:
> " 4.5. PREOF Processing"
> END.
>
> OLD:
> "To support outgoing PREOF capable DetNet IP encapsulation, an implementation supports the provisioning of UDP and IP header information."
> NEW:
> "The outgoing PREOF encapsulation and processing can be implemented via the provisioning of UDP and IP header information."
> END.
>
> OLD:
> "To support the receive processing, an implementation also supports the provisioning of received Service-ID, UDP and IP header information."
> NEW:
> "The incoming PREOF processing can be implemented via the provisioning of received Service-ID, UDP and IP header information."
> END.
>
> OLD:
> " An implementation supports ordering of the set of information used to identify an individual DetNet flow. This can, for example, be used ..."
> NEW:
> "Ordering of the set of information used to identify an individual DetNet flow can, for example, be used ..."
> END.
>
> Many thanks
> Bala'zs (& the co-authors)
>
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Monday, July 24, 2023 4:25 PM
> To: Lou Berger <[e-mail]>
> Cc: [e-mail]; Balázs Varga A <[e-mail]>; [e-mail]; [e-mail]
> Subject: RE: [RTG-DIR] Rtgdir early review of draft-ietf-detnet-mpls-over-ip-preof-02
>
> Authors, thanks for the new versions -03 & 04.
>
> Lou,
>
> Thanks for the follow up.
> My minor comments and nits have been addressed.
>
> I was originally concerned that some sentences could be seen as respecifying the behaviors defined in previous STD track RFC. I can see some improvements, in particular thanks to the removal of the "MUST" clauses.
> There are still some sentences which could be seen as defining what the implementation should do and which could may be rephrased. E.g.
> -"To support outgoing PREOF capable DetNet IP encapsulation, an implementation supports the provisioning of UDP and IP header information."
> - "To support the receive processing, an implementation also supports the provisioning of received Service-ID, UDP and IP header information."
> -" An implementation supports ordering of the set of information used to identify an individual DetNet flow."
> - " 4.5. PREOF Procedures"
> - "This document describes a DetNet IP encapsulation"
>
> I'll leave this to the authors/WG/shepherd/AD.
>
> As for the last bullet, may be a proposal below:
> OLD: This document describes a DetNet IP encapsulation that includes sequencing information based on the DetNet MPLS over UDP/IP data plane [RFC9025], i.e., leveraging the MPLS-over-UDP technology.
> NEW: This documents provides sequencing information to DetNet IP nodes by re-using the DetNet MPLS over UDP/IP data plane [RFC9025] with the restriction of using zero F-labels.
>
> (Main comment is about changing "describe" into "re-use". )
>
> --Bruno
> Orange Restricted
>
>> -----Original Message-----
>> From: Lou Berger <[e-mail]>
>> Sent: Sunday, July 23, 2023 10:49 PM
>> To: DECRAENE Bruno INNOV/NET <[e-mail]>
>> Cc: [e-mail]; Balázs Varga A <[e-mail]>;
>> [e-mail]; [e-mail]
>> Subject: Re: [RTG-DIR] Rtgdir early review of
>> draft-ietf-detnet-mpls-over-ip-preof-02
>>
>> Bruno,
>>
>> Can you take a look at the current version (-04) and identify any
>> issues you think have NOT been addressed in your review?
>>
>> Thank you!
>>
>> Lou
>>
>> On 4/26/2023 3:43 AM, Balázs Varga A wrote:
>>> 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.
>>>
>
>
>> -----Original Message-----
>> From: Lou Berger <[e-mail]>
>> Sent: Sunday, July 23, 2023 10:49 PM
>> To: DECRAENE Bruno INNOV/NET <[e-mail]>
>> Cc: [e-mail]; Balázs Varga A <[e-mail]>;
>> [e-mail]; [e-mail]
>> Subject: Re: [RTG-DIR] Rtgdir early review of
>> draft-ietf-detnet-mpls-over-ip-preof-02
>>
>> Bruno,
>>
>> Can you take a look at the current version (-04) and identify any
>> issues you think have NOT been addressed in your review?
>>
>> Thank you!
>>
>> Lou
>>
>> On 4/26/2023 3:43 AM, Balázs Varga A wrote:
>>> 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.
>>>
> ____________________________________________________________________________________________________________
> 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.
> ____________________________________________________________________________________________________________
> 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.