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

From an email exchange:

"""
There is always a similar interworking pair at the other end of the Stream and it restores the packet to its original destination MAC address and VLAN.

Therefore, there is no impact to IP and IP-related traffic that might carry MAC addresses, like ARP or NDP.
"""

I also concur with Alvaro's observations.

As noted in the abstract, “[t]his document does not define new procedures or processes.”  Since Sections 1 – 5 appears to be primarily annotated references to TSN citations, 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-mpls-over-tsn.

Thank you for the work put into this document. 

Special thanks to Niklas and Tim for their directorates reviews as well to Balázs for his answer:
- IoT directorate: Niklas Widell https://datatracker.ietf.org/doc/review-ietf-detnet-ip-over-tsn-06-iotdir-telechat-widell-2021-02-15/
- INT directorate: Tim Chown https://datatracker.ietf.org/doc/review-ietf-detnet-ip-over-tsn-05-intdir-telechat-chown-2021-02-14/

I only did a quick review of the document as I am trusting those two reviews 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.
   
= Section 5 =

	"Mapping between DetNet IP flow(s) (as flow identification defined
      in [RFC8939], it is summarized in Section 5.1 of that document,
      and includes all wildcards, port ranges and the ability to ignore
      specific IP fields) and TSN Stream(s) (as stream identification
      information defined in [IEEE8021CB] and [IEEEP8021CBdb])."

This is wordy and therefore hard to parse in the context of the bulleted list. It would be clearer if it were broken up into multiple sentences.

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

Some of these references describe TSN, an understanding which is required.  Others represent 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 1

                         As described in [RFC8939] no DetNet specific
   headers are added to support DetNet IP flows, only the forwarding
   sub-layer functions are supported inside the DetNet domain.  [...]

nit: I suggest "so only the forwarding sub-layer functions can be
supported inside the DetNet domain".

Section 4.2

   A TSN-aware IP (DetNet) node implementations must support the Stream

nit: singular/plural mismatch "A TSN-aware IP"/"implementations"

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 9.2

I agree with the other ADs that (most of?) the IEEE references should be
classified as normative.

Thank you for documenting some of the concerns and considerations related to mapping management information between the Detnet and TSN management models.

Rob