Hi Bernard,
thank you for your thoughtful comments and helpful suggestions. The authors discussed them and updated the draft to address your concerns. I uploaded the new version:
A new version of Internet-Draft draft-ietf-detnet-ip-oam-11.txt has beensuccessfully submitted by Greg Mirsky and posted to theIETF repository.
Name: draft-ietf-detnet-ip-oamRevision: 11Title: Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data PlaneDate: 2024-02-05Group: detnetPages: 9
Abstract:
Please let us know whether these updates adequately address your comments. Our sincere thanks for your help in improving this document.This document discusses the use of existing IP Operations,Administration, and Maintenance protocols and mechanisms inDeterministic Networking networks that use the IP data plane.
Regards,
Greg (on behalf of the authors)
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.
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
