Reviewer: Bernard Aboba Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. ------------------------------------------------------------- The abstract of the document says: " This document defines the principles for using Operations, Administration, and Maintenance protocols and mechanisms in the Deterministic Networking networks with the IP data plane." On the other hand, the first sentence of Section 6 (Security Considerations) says: " This document describes the applicability of the existing Fault Management and Performance Monitoring IP OAM protocols. " Overall, the document's purpose seems closer to the description in Section 6, than to the goal described in the Abstract. Given the Abstract, I was surprised that the document doesn't define much in the way of principles, other than "fate sharing", which is defined in an odd manner (e.g. with respect to network treatment, ICMP does not "share fate" with UDP). Rather, the document seems more like a summary of previous work relating to DetNet OAM, as noted in Section 6. The other issue is that the document needs a grammar edit beyond what can be expected of the RFC Editor. Below I suggest alternative wording where possible. Sometimes it is difficult to figure out what the author is trying to say, so I can't be sure that the suggested re-wording captures the intended meaning. ------------------ Detailed comments ------------------ 1. Introduction [RFC8655] introduces and explains Deterministic Networks (DetNet) architecture. Operations, Administration and Maintenance (OAM) protocols are used to detect, localize defects in the network, and monitor network performance. Some OAM functions, e.g., failure detection, work in the network proactively, while others, e.g., defect localization, usually performed on-demand. These tasks achieved by a combination of active and hybrid, as defined in [RFC7799], OAM methods. [BA] Rewrite as: "Operations, Administration and Maintenance (OAM) protocols are used to detect and localize defects in the network as well as to monitor network performance. Some OAM functions (e.g., failure detection), work in the network proactively, while others (e.g., defect localization) are usually performed on-demand. These tasks are achieved by a combination of active and hybrid OAM methods, as defined in [RFC7799]." [I-D.ietf-detnet-oam-framework] lists the functional requirements toward OAM for DetNet domain. The list can further be used for gap analysis of available OAM tools to identify possible enhancements of existing or whether new OAM tools are required to support proactive and on-demand path monitoring and service validation. Also, the document defines the OAM use principals for the DetNet networks with the IP data plane. [BA] Rewrite as: "[I-D.ietf-detnet-oam-framework] lists the OAM functional requirements for DetNet, and defines the principles for OAM use within DetNet networks utilizing the IP data plane. The functional requirements can be compared against current OAM tools to identify gaps and potential enhancements required to enable proactive and on-demand path monitoring and service validation." 2.1. Terminology The term "DetNet OAM" used in this document interchangeably with longer version "set of OAM protocols, methods and tools for Deterministic Networks". DetNet Deterministic Networks DiffServ Differentiated Services OAM: Operations, Administration, and Maintenance PREF Packet Replication and Elimination Function POF Packet Ordering Function RDI Remote Defect Indication ICMP Internet Control Message Protocol ACH Associated Channel Header Underlay Network or Underlay Layer: The network that provides connectivity between the DetNet nodes. MPLS network providing LSP connectivity between DetNet nodes is an example of the underlay layer. DetNet Node - a node that is an actor in the DetNet domain. DetNet domain edge node and node that performs PREF within the domain are examples of DetNet node. [BA] Rewrite as: " Underlay Network or Underlay Layer: The network that provides connectivity between DetNet nodes. MPLS networks providing LSP connectivity between DetNet nodes are an example of the underlay layer. DetNet Node - a node that is an actor in the DetNet domain. DetNet domain edge nodes and nodes that perform PREF within the domain are examples of a DetNet node." 3. Active OAM for DetNet Networks with the IP Data Plane OAM protocols and mechanisms act within the data plane of the particular networking layer. And thus it is critical that the data plane encapsulation supports OAM mechanisms in such a way that DetNet OAM packets are in-band with a DetNet flow being monitored, i.e., DetNet OAM test packets follow precisely the same path as DetNet data plane traffic both for unidirectional and bi-directional DetNet paths. The DetNet data plane encapsulation in a transport network with IP encapsulations specified in Section 6 of [RFC8939]. [BA] Rewrite as: " DetNet OAM packets are sent along with the DetNet flow being monitored, and follow the same path as the DetNet data plane traffic for both unidirectional and bi-directional DetNet paths. [RFC8939] Section 6 specifies the DetNet data plane encapsulation in an IP transport network." For the IP underlay network, DetNet flows are identified by the ordered match to the provisioned information set that, among other elements, includes the IP protocol, source port number, destination port number. Active IP OAM protocols like Bidirectional Forwarding Detection (BFD) [RFC5880] or Simple Two-way Active Measurement Protocol (STAMP) [RFC8762], use UDP transport and the well-known UDP port numbers as the destination port. [BA] This sentence is confusing to me. BFD and STAMP are different. STAMP uses the well-known UDP port number allocated for the OWAMP-Test/TWAMP-Test Receiver Port, whereas BFD can run at multiple layers, not just over UDP, and when run over UDP is not restricted to a single well-known UDP destination port. Can you rephrase this in a more clear way? Thus a DetNet node must be able to associate an IP DetNet flow with the particular test session to ensure that test packets experience the same treatment as the DetNet flow packets. For example, that can be achieved with a 3-tuple (destination and source IP addresses in combination with DSCP value) used to identify the IP DetNet flow. In such a scenario, an IP OAM session between the same pair of IP nodes would share the network treatment with the monitored IP DetNet flow regardless of whether ICMP, BFD, or STAMP protocol is used. Most of on-demand failure detection and localization in IP networks is being done by using the Internet Control Message Protocol (ICMP) Echo Request, Echo Reply and the set of defined error messages, e.g., Destination Unreachable, with the more detailed information provided through code points. [RFC0792] and [RFC4443] define the ICMP for IPv4 and IPv6 networks, respectively. Because ICMP is another IP protocol like, for example, UDP, a DetNet node must able to associate an ICMP packet generated by the specified IP DetNet node and addressed to the another IP DetnNet node with an IP DetNet flow between this pair of endpoints. [BA] Associating an ICMP packet with a DetNet flow is useful, but since ICMP will not necessarily experience the same network treatment as UDP (due to filtering, for example), I am not sure how this provides the guarantees that you claim. 3.1. Mapping Active OAM and IP DetNet flows IP OAM protocols are used to detect failures (e.g., BFD [RFC5880]) and performance degradation (e.g., STAMP [RFC8762]) that affect an IP DetNet flow. When the UDP destination port number used by the OAM protocol is one of the assigned by IANA, then the UDP source port can be used to achieve co-routedness of OAM, and the monitored IP DetNet flow in the multipath environments, e.g., Link Aggregation Group or Equal Cost Multipath. (That also applies to encapsulation techniques described in Section 3.2 and Section 3.3.) To ensure the accuracy of [BA] Can you explain how the UDP source port can be used to achieve co-routedness and the role played by assignment of a destination port by IANA? Are you trying to say that traffic utilizing the same UDP source and destination ports + DSCP values is assumed to be treated similarly by network devices? 6. Security Considerations This document describes the applicability of the existing Fault Management and Performance Monitoring IP OAM protocols. It does not raise any security concerns or issues in addition to ones common to networking or already documented in [RFC0792], [RFC4443], [RFC5880], and [RFC8762] for the referenced DetNet and OAM protocols. [BA] The first sentence of this paragraph seems like a more accurate description of the document than the abstract. Maybe it should be copied there? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
