Re: [Detnet] AD Review of draft-ietf-detnet-mpls-over-ip-preof-07

Hi Roman,

Many thanks for your detailed review and good suggestions. 
Please, find replies and resolutions as follows:

1, Section 4.2, Encapsulation clarifications.
Right, there are many references used to define the encapsulation. We intended to avoid repeating text from those RFCs.
The concept is based on UDP tunnels between nodes implementing DetNet service sub-layer functionalities (=PREOF). 
Within the UDP tunnel DetNet MPLS PseudoWire encapsulation is used. So the UDP payload starts with a standard 
"MPLS label stack". (32 bits label(s) followed by a d-CW followed by a payload). You know the UDP payload format 
from the UDP destination port (=6635). As defined in RFC7510: UDP destination port number (6635) indicating MPLS. 
It has been allocated by IANA.

2, Section 4.4, Aggregation
OK, PREOF requires per DetNet flow state information. In order cope with scalability aggregation was introduced, where 
state for PREOF is needed only for the aggregate. Nodes doing aggregation/de-aggregation know the "aggregation flavor"
from their configuration.  
-- How do I know the header in UDP is “S-Label + dCW” vs. “A-Label + dCW + S-Label + dCW”?
This is known from explicit configuration of the node. Clarification added as follows:

NEW TEXT (added to the end of the section)
   The option used for aggregation is known by configuration of the aggregation/de-aggregation nodes. 
END

3, Section 5. Specifying App-flow identification information.
-- How do I specify that?
-- *  PREOF + related Service-ID(s). Does that mean to have PREOF “information” for configuration? Does that mean choosing the algorithms?
Right, all these information are specified by the configuration of the node. PREOF functionality is configured 
in detail (flow parameters, function parameters, algorithms, etc.)
I intend to add reference to "RFC9016: DetNet Flow and Service Information Model".

NEW TEXT (added to the end of the section)
   These parameters are defined in the DetNet Flow and Service information model [RFC9016] 
   and the DetNet YANG model.
END

4, Section 6., Please cite by reference which security considerations apply.
OK, Security consideration of DetNet MPLS [RFC8964] and DetNet MPLS over UDP/IP [RFC9025] applies.

OLD TEXT
   There are no new DetNet related security considerations introduced by
   this solution.
NEW TEXT
   There are no new DetNet related security considerations introduced by
   this solution. Security considerations of DetNet MPLS [RFC8964] and 
   DetNet MPLS over UDP/IP [RFC9025] apply.
END

5, Idnits reports: unused references.
OK, they are removed.

Above changes will be posted in v08 (today).
Please, let us know if You think further changes are needed.

Thanks
Bala’zs

-----Original Message-----
From: detnet <detnet-bounces@ietf.org> On Behalf Of Roman Danyliw
Sent: Friday, October 27, 2023 11:05 PM
To: detnet@ietf.org
Subject: [Detnet] AD Review of draft-ietf-detnet-mpls-over-ip-preof-07

Hi!

I performed an AD review of draft-ietf-detnet-mpls-over-ip-preof-07 stepping in as the responsible AD to help load-balance the PubReq queue.  Thanks for the document.

Begging your patience not being a RTG AD, I have difficulty understanding the basic encapsulation semantics being proposed.  I tried following the references, but wasn’t able to understand how to construct the basic encapsulation.  See below:

** Section 4.2.  Figure 3 is describing an encapsulation header built on fields and processes based on [RFC8964] and [RFC9025].  The UDP payload appears to be an S-Label + dCW + Detnet payload.  Section 4.2.1 of RFC8964 describes the d-CW format and semantics. Section 4.2.2 of RFC8964 has significant text describing S-Labels, but where is the very basic description: how many bits is it?  What are the semantics?

** Section 4.4. 
-- No objection to this text.  However, this behavior seems like an expansion of the PREOF scope I understand the document be.  Is there narrative text that can bridge how aggregation is a building block for replication, elimination and ordering?  I could perhaps speculate on replication and elimination. Less so on ordering.

-- I’m missing a basic understanding of layering.  How do I know the header in UDP is “S-Label + dCW” vs. “A-Label + dCW + S-Label + dCW”?

** Section 5.
   The minimum set of information for the configuration of the DetNet
   service sub-layer is summarized as follows:

   *  App-flow identification information.

How do I specify that?

...
   *  PREOF + related Service-ID(s).

Does that mean to have PREOF “information” for configuration?  Does that mean choosing the algorithms?

** Section 6.
   There are no new DetNet related security considerations introduced by
   this solution.

Please cite by reference which security considerations apply.

** Idnits reports:

  == Unused Reference: 'RFC2119' is defined on line 427, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC8174' is defined on line 432, but no explicit
     reference was found in the text

Regards,
Roman
_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet