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

[Greg Mirsky <[e-mail]>]

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 <
[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.

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
<https://www.rfc-editor.org/rfc/rfc7799>) 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.