Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN)
draft-ietf-detnet-mpls-over-tsn-07

This document is "MPLS over IEEE 802.1 Time-Sensitive Networking".  Also on this telechat: "IEEE 802.1 Time Sensitive Networking over MPLS".  I wonder if one is just the inverse of the other.

I concur with Alvaro's statement about the IEEE references being normative.

In Section 2.2, "CW" is defined, but the term used in the document is actually "d-CW".  The terms "DF", "LSR", "PE", "S-PE", and "T-PE" are defined but not used anywhere.

In Section 4, I can't parse this sentence: "All these functions have to identify flows those require TSN treatment (i.e., applying TSN functions during forwarding)."

Section 6 says: "Therefore, it is important that the interface between DetNet nodes and TSN sub-network are subject to authorization, authentication, and encryption."  Would references to documents describing those specific TSN capabilities be useful here?  I'm not sure if those are covered by the referenced TSN documents.

Thank you to Yoav Nir for the SECDIR review.

As noted in the abstract, “[t]his document does not define new procedures or processes.”  Since Sections 1 – 5 appears to rely heavily on TSN references, I was surprised that the Security Considerations did not follow the same pattern.  I would have expected pointers into the underlying IEEE TSN specifications on security considerations.  The text appears to be generic, and beyond a single sentence, identical to draft-ietf-detnet-ip-over-tsn.

Thank you for the work put into this document. 

Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated), and some nits.

Special thanks to Tim for his INT directorate review as well to Balázs for his answer:
- INT directorate: Tim Chown https://datatracker.ietf.org/doc/review-ietf-detnet-mpls-over-tsn-05-intdir-telechat-chown-2021-02-14/

I am trusting Tim's review for my ballot and I am sure that they helped to improve the document,

Regards,

-éric

I agree with Alvaro's ballot points. I think IEEEP8021CBcv should also be a normative reference.

= Abstract =

"Whenever this document makes
   requirements statements or recommendations, these are taken from
   normative text in the referenced RFCs."
   
I found the use of "requirements statements" a little misleading since this document contains no normative language.

= Section 4 =

"The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
   Working Group have defined (and are defining) a number of amendments
   to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and
   bounded latency in bridged networks."

Since this is going into an immutable RFC, starting with "At the time of this writing" or some such would be helpful.

The following references should be Normative: I-D.ietf-detnet-security, IEEE8021Q, and RFC8655.

These references describe TSN, an understanding which is required, the architecture, and security considerations for DetNet -- note that other data plane documents use them normatively as well.


====

For the record (no need to reply)

I'm having a hard time convincing myself that this document has archival value as an RFC, given that the procedures are already specified in the IEEE documents.  I had a similar concern (related to the contributions made in the document) about draft-ietf-detnet-ip-over-mpls (which is on the Standards Track).  As with the MPLS document, I am making this a non-blocking comment and not opposing the publication.

Roman's comment is a good one.

Section 3

   and process d-CWs, S-Labels and F-labels as needed.  MPLS DetNet
   nodes and transit nodes include DetNet forwarding sub-layer
   functions, support for notably explicit routes, and resources
   allocation to eliminate (or reduce) congestion loss and jitter.

Akin to my remarks on draft-ietf-detnet-tsn-vpn-over-mpls, I'd suggest
"notably support for explicit routes, and resource allocation to
eliminate (or reduce) congestion loss and jitter".

Section 4.2

   A TSN-aware MPLS (DetNet) node implementation must support the
   Sequencing function and the Sequence encode/decode function as
   defined in Clause 7.4 and 7.6 of IEEE 802.1CB [IEEE8021CB] if FRER is
   used inside the TSN sub-network.
   [...]
   A TSN-aware MPLS (DetNet) node implementation must support the Stream
   splitting function and the Individual recovery function as defined in
   Clause 7.7 and 7.5 of IEEE 802.1CB [IEEE8021CB] when the node is a
   replication or elimination point for FRER.

(nit) I suggest phrasing these as "in order for FRIR to be used inside
the TSN sub-network" and "in order for that node to be a replication or
elimination point for FRER".  The current phrasing implies some
surprising causality, as if changing the network's configuration
spontaneously imposes a requirement on the node.

Section 4.4

   Implementations of this document shall use management and control
   information to map a DetNet flow to a TSN Stream.  N:1 mapping
   (aggregating DetNet flows in a single TSN Stream) shall be supported.

I note that in draft-ietf-detnet-tsn-vpn-over-mpls this was a normative
"SHALL be supported" (which was itself the strongest criterion I could
find for that document being standards-track).  Is there a simple
description for what's different between these documents?

Section 5

   requirements.  Note that, as the TSN sub-network is just a portion of
   the end2end DetNet path (i.e., single hop from MPLS perspective),

nit: please write out "end-to-end".

   In some case it may be challenging to determine some TSN Stream
   related information.  [...]

nit: "In some cases".