Re: [Detnet] Tsvart last call review of draft-ietf-detnet-ip-oam-10

[Greg Mirsky <[e-mail]>]

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 been
successfully submitted by Greg Mirsky and posted to the
IETF repository.


Name:     draft-ietf-detnet-ip-oam
Revision: 11
Title:    Operations, Administration and Maintenance (OAM) for
Deterministic Networks (DetNet) with IP Data Plane
Date:     2024-02-05
Group:    detnet
Pages:    9
URL:      https://www.ietf.org/archive/id/draft-ietf-detnet-ip-oam-11.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-oam/
HTML:     https://www.ietf.org/archive/id/draft-ietf-detnet-ip-oam-11.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-detnet-ip-oam
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-detnet-ip-oam-11


Abstract:


   This document discusses the use of existing IP Operations,
   Administration, and Maintenance protocols and mechanisms in
   Deterministic Networking networks that use the IP data plane.

Please let us know whether these updates adequately address your comments.
Our sincere thanks for your help in improving this document.

Regards,
Greg (on behalf of the authors)

On Tue, Jan 30, 2024 at 6:01 PM Bernard Aboba via Datatracker <
[e-mail]> 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
> [e-mail] 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?
>
>
>
>