Re: [Last-Call] Tsvart last call review of draft-ietf-detnet-ip-oam-10
Bernard Aboba <bernard.aboba@gmail.com> Mon, 05 February 2024 20:07 UTC
Return-Path: <bernard.aboba@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0726FC14F61F; Mon, 5 Feb 2024 12:07:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s38HfOhyTStS; Mon, 5 Feb 2024 12:07:14 -0800 (PST)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E91C14F61D; Mon, 5 Feb 2024 12:07:14 -0800 (PST)
Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-5d8df2edd29so3818650a12.2; Mon, 05 Feb 2024 12:07:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707163633; x=1707768433; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HoWWkyv+Rw6NwFd4dCbGGSOWC6gfHfp4HPLj2POhhCU=; b=HFela+YU62WKDj9ypgV6Xs8iMT7/HBNdkKhLuyvtXOn2/P5MkrCe0LKpxKzZ1Ypd9Y eL7w5EE51MCrBcTFS/w2ny7WGwSCaJq1FfOT2gVU+bDlf8f+h5hL7sAe7+FieaebW/tv KkBC7kIpryDInrdIBRklyB+k3eYNmBde2PdGwMXaXDLdxKmBF0N4cm/IgOmvgEFv8yMQ QqO2IRya+pCN6CKKiU+WQ5RlkllRxbIZ1qHuGW0y24pROr0qJUmGFCNeG4L0e+KcoGsg YiuxoYr43Uot1AtuVh+EsOyNGLIXLkTloCwx7enxTYpOFcZIBJOWh/n1W8Hks5XrWNp5 e6uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707163633; x=1707768433; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HoWWkyv+Rw6NwFd4dCbGGSOWC6gfHfp4HPLj2POhhCU=; b=neoiIkEGPuv+F+DhaPakzmHQ/jl2MZr0p1zee8Ztq9EN6ZEGp3aoQi+6nCUY52klq7 F+JD8bJyfMYsO2TKa7Szny38QU88iVpFAYtm2unkwqU0dh5OxacLnA/vqO8b+a3Oo84b 23Qi4AbuKMgBwUkbVGMqDd8rMv+vOfdM3LtPT0/Tr5BTR9yzFVyXuQnxUXtaWH1Xy1PD wnOLwQUbY9/Bdi4dVBsIkbR3qFBuHrZ8kYBTi3Sl/T706tWu6pc5TQRrh5kVD6vCxLMd diKL8gUd2ZS8fZaLpfJbS/nzGcSOZhZ/sySIBiiyevbLQyj66uLNOdoL2zbes81h77CA VINg==
X-Gm-Message-State: AOJu0YxhlQakZk/qrPmJt5uyrvtZFfqYk1t5FmLiOtiD2HE4/CuU3t+z QPLXUS0S2i3s8oBN8qM1yObSFJOqs6Dw+OFKIyGiOU/Sgy8PyKri8X+DWPgH60dRRk32RcAnbI1 XSK2sqSamBUq1h5LTUO09UbQ2ffL9J/YKJyM=
X-Google-Smtp-Source: AGHT+IF1ZyxI2tzWFmB8gUJV+EdHX9bGRWBWgqxYU30DPE/tUDwsx0UBBxDeZ9p16ID3SpOTNfLLnBUYqAZiBzCU3YA=
X-Received: by 2002:a05:6a20:268f:b0:19c:8a24:82e1 with SMTP id h15-20020a056a20268f00b0019c8a2482e1mr557299pze.17.1707163633190; Mon, 05 Feb 2024 12:07:13 -0800 (PST)
MIME-Version: 1.0
References: <170666646597.61715.14079948386246766282@ietfa.amsl.com> <CA+RyBmUtipudb8XrnVgZ4tSHvpEmL7YYX6s3emPskf4OX_hW0g@mail.gmail.com>
In-Reply-To: <CA+RyBmUtipudb8XrnVgZ4tSHvpEmL7YYX6s3emPskf4OX_hW0g@mail.gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 05 Feb 2024 12:07:01 -0800
Message-ID: <CAOW+2dsUizutpwtPTBdEXOXFBgu0FWKdFEf4V8Z6+NViqTebmg@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: tsv-art@ietf.org, detnet@ietf.org, draft-ietf-detnet-ip-oam.all@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ee0c5a0610a8016d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/AE6bStBHcEwjuTBmYmRee5a6g0E>
Subject: Re: [Last-Call] Tsvart last call review of draft-ietf-detnet-ip-oam-10
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Feb 2024 20:07:18 -0000
The changes look good. Thank you for your quick response! On Mon, Feb 5, 2024 at 6:19 AM Greg Mirsky <gregimirsky@gmail.com> 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 < > noreply@ietf.org> 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@ietf.org 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] Tsvart last call review of draft-ietf… Bernard Aboba via Datatracker
- Re: [Last-Call] Tsvart last call review of draft-… Greg Mirsky
- Re: [Last-Call] Tsvart last call review of draft-… Greg Mirsky
- Re: [Last-Call] Tsvart last call review of draft-… Bernard Aboba