Hi Bernard,
thank you for your comments and thoughtful suggestions. Please find my notes below tagged by GIM>>.
Regards,
Greg
On Tue, Jan 30, 2024 at 6:01 PM Bernard Aboba via Datatracker <noreply@xxxxxxxx> wrote:
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.
GIM>> Would the following update of Abstract make the two statements more consistent:
OLD TEXT:
This document defines the principles for using Operations,
Administration, and Maintenance protocols and mechanisms in the
Deterministic Networking networks with the IP data plane.
NEW TEXT:
This document defines the principles for using the existing IP
Operations, Administration, and Maintenance protocols and mechanisms
in the Deterministic Networking networks with the IP data plane.
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.
GIM>> For the active OAM (per the classification in RFC 7799) the fate-sharing between a test packet and the monitored data flow is an essential condition for maintaining the informational value of the collected OAM information. The document describes several approaches that, in the opinion of the DetNet WG, can be used to make this task more operationally friendly. And that also would allow for the fate-sharing between ICMP and a UDP-baset test protocol.
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.
GIM>> Thank you for your extensive and helpful suggestions. We will consider them with other editorial proposals that could be brought up in the course of the IETF Last Call.
------------------
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?
GIM>> All applications of BFD to dfferent network layers (e.g., MPLS) use IP/UDP encapsulation which includes the well-known UDP destination port number. Also, the scope of this document is explicitly on the use of the IP data plane. Thus, it seems like the current statement is technically accurate. Would you agree?
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.
GIM>> A DetNet domain is a different from the Internet and we expect that an operator will make special provisions for all IP OAM tools.
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?
GIM>> Co-routedness is only the topological part of the fate-sharing requirement for an active OAM. The seconde part is the same QoS treatment experienced by the monitored flow and injected in the network test packet. For the case of DetNet over IP, the key is the definition of the DetNet flow. DetNet IP OAM must be associated with the identifier of the DetNet in IP flow. In some cases, that would use the 3-tuple you mentioned. I can imagine that there could be scenario that would use the 5-tuple.
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?
GIM>> Please let me know if the proposed above text addresses your concern.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
