Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)
RFC 9023
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
Alvaro Retana No Objection
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.
Erik Kline (was Discuss) No Objection
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. """
Martin Duke No Objection
Murray Kucherawy No Objection
I also concur with Alvaro's observations.
Robert Wilton No Objection
Thank you for documenting some of the concerns and considerations related to mapping management information between the Detnet and TSN management models. Rob
Roman Danyliw No Objection
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.
Éric Vyncke No Objection
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
(Deborah Brungard; former steering group member) Yes
(Alissa Cooper; former steering group member) No Objection
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.
(Barry Leiba; former steering group member) No Objection
(Benjamin Kaduk; former steering group member) No Objection
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.
(Magnus Westerlund; former steering group member) No Objection