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

[Bernard Aboba <[e-mail]>]

The changes look good.  Thank you for your quick response!

On Mon, Feb 5, 2024 at 6:19 AM Greg Mirsky <[e-mail]> wrote:

> 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?
>>
>>
>>
>>