From nobody Thu Aug 18 05:47:09 2022 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3409C15271C; Thu, 18 Aug 2022 05:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_BLOCKED=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 QbI7nGDAKjRY; Thu, 18 Aug 2022 05:47:05 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 1F475C152718; Thu, 18 Aug 2022 05:47:05 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id t11-20020a17090a510b00b001fac77e9d1fso1936309pjh.5; Thu, 18 Aug 2022 05:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=akXLswOYyxvxiLs2AdTirXjA5WCuIbcJJaxEEcN8eaw=; b=YtE/OMkAnyx4mowkLp55E6S6IJdKBs7P5O4Uumk4qaAR98TAXD5Ccroy/d03JYXrE9 K9vX+GXHqUFCPfviELiUczp0Y84o5y1C3w6Q8R1stppSb4KqJ6T3StP1WSowEa8/8mml 2De05OdFEMFVF7tTIjZzUgMB8y5QYcVxFex5jSVelJ+4kfpb4UOypUVq7HjDUaf2P7or GvTipzycIBe81bUSxjMpi2rWzWdplSLzALp+0xpgF3QHSbdmUPkDsVQhsPRJq/ZNvXOq w85liyDhWj1h6afkFs4DOF09WvZNb2DW9WIhTThmvkaJVlxN8EKBig7NBO79pkTX6xUE fxrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=akXLswOYyxvxiLs2AdTirXjA5WCuIbcJJaxEEcN8eaw=; b=2Xi3ES2IN/dcyZMDP09a79MofZQ+BhUr/8k3Rp/peaCeYhbJfkJMZ+7hKsdi/hzDLJ j/U3zJ1eoLrpddIcNRJmn46XyLXQeIeRzwn0AE2Ft2YCo10WTjKnBERNnl1x4S1RwVxc KbKeLVVAWX27cGtaVQ3pevo6mybDK6QWmRglEl/ccU+517oCquqUbkT92balYpOTn+Y+ v1WvuxIE0Qxlrh8/GbIwoV5EFMEbrtpm23SxLKBEyF2DSBkhQ69UKi0JAF63FZHEoO0Q 1UM9tbPhUDS3HmNC9ejX6vH4Y0JZ03Z+sUZoUdUulvwBOzuxm63LwYlOeLdzHQB2oi6/ 3u4A== X-Gm-Message-State: ACgBeo3ZDDx8ymPaK3G0ZRLgZnwU/Uy5/ey97I+6XdfO/zINuJFTudmk ggYZIThKSkoNWcnUvzA/3O8PPPNPpUMw2o7QOn0= X-Google-Smtp-Source: AA6agR7ZNy+AsEsPZcfgjngE3BjVY6BzD7hTuj01j92ZifaHB9PPNjBe/Wi//IBQDsvVAAqDeGxMEl/hgxCJWwEJXZI= X-Received: by 2002:a17:903:244b:b0:16f:1ca5:b29f with SMTP id l11-20020a170903244b00b0016f1ca5b29fmr2542871pls.44.1660826824538; Thu, 18 Aug 2022 05:47:04 -0700 (PDT) MIME-Version: 1.0 References: <165652459525.26132.7128833852572523790@ietfa.amsl.com> In-Reply-To: <165652459525.26132.7128833852572523790@ietfa.amsl.com> From: Tal Mizrahi Date: Thu, 18 Aug 2022 15:46:50 +0300 Message-ID: To: John Scudder Cc: The IESG , draft-ietf-ippm-ioam-flags@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, tpauly@apple.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] John Scudder's Discuss on draft-ietf-ippm-ioam-flags-09: (with DISCUSS and COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2022 12:47:07 -0000 Dear John, Many thanks for the comments. We have uploaded an updated version that hopefully addresses the DISCUSS comments. https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags Please see my responses below, marked [TM]. Please let us know if there are further comments. Cheers, Tal. On Wed, Jun 29, 2022 at 8:43 PM John Scudder via Datatracker wrote: > > John Scudder has entered the following ballot position for > draft-ietf-ippm-ioam-flags-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/about/groups/iesg/statements/handlin= g-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for this document. I have one issue I'd like to be sure we clear u= p. > > 1. In =C2=A74.1.1, > > The loopback flag MUST NOT be set if it is not guaranteed that there > is a return path from each of the IOAM transit and IOAM decapsulating > nodes, > > This is heartwarming but I can=E2=80=99t see how you could guarantee this= property at > all times in any network using dynamic routing or even subject to dynamic > conditions (and that would be all networks), and for that matter I=E2=80= =99m not sure > how to write code to even determine this in any general way. Is it your > intention that this MUST NOT is directed to the operator and not to the c= ode > implementor? Or perhaps is it for very small values of =E2=80=9Cguarantee= =E2=80=9D? That is, is > this an aspirational MUST and not a MUST MUST? > > In general it's a little problematic when we use RFC 2119 keywords in a > protocol document, to express desires about how a protocol's operator sho= uld > deploy it. They are at their best when used to express requirements for h= ow a > coder should implement the protocol. Please consider creating an operatio= nal > considerations section, and grouping operational requirements and advice = there, > at least in that case it becomes clear to whom the RFC 2119 keywords are > speaking. > > Alternately, please qualify the keywords appropriately in-line, e.g. in t= he > above text you could say something like > > The domain MUST be configured such that there is expected to be a retu= rn > path from each of the IOAM transit and IOAM decapsulating nodes; if th= is > expectation does not apply then configuration MUST NOT enable the loop= back > flag to be set, [TM] The point is well taken. We have adopted the text you suggested with minor changes. > > To me it seems as though it might be less painful to group these into an > operational considerations section, but whatever works for you, as long a= s it's > clear. > > I did a cursory check over the document with this in mind, the other plac= e I > identified what looks like operational guidance to me is also in =C2=A74.= 1.1, the > paragraph about how you "SHOULD NOT exceed 1/N of the interface capacity"= . At > first blush that looks like something that could be computed automaticall= y by > inspection of the router's hardware, but by the time we get to the end of= the > paragraph we see that "prior knowledge about the network topology or size= " is > needed, so it must really be operational guidance. (Possibly this applies= to > the 1/N paragraphs in =C2=A74.2 and =C2=A75 also, although it's less clea= rly the case.) [TM] This paragraph was rephrased to emphasize the operational aspect. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 2. The document cites RFCs 7014 and 5475 normatively. They don't seem nor= mative > to me, they seem informative. [TM] Fixed. > > 3. In =C2=A74.2, > > The L-bit MUST be cleared > in the copy of the packet that a node sends back towards the source. > > This makes me wonder, does the looped back packet inherit the IP TTL/hop = limit > of the parent packet? The description of it as a =E2=80=9Ccopy=E2=80=9D m= akes me think it does. > Should this be explicit? [TM] Generally speaking, we made an effort to keep the current document as encapsulation-independent as possible. For example, the IPv6 Hop Limit is specific to the IPv6 encapsulation of IOAM. However, we added the following comment: NEW: Creating the copy that is looped back, and specifically the truncation, may require some encapsulation-specific updates in the encapsulation header. > > NITS: > > 4. In =C2=A75, > > This draft focuses on three possible use cases of active measurement > > Should be "this document focuses". [TM] Fixed. > > 5. Again in =C2=A75, > > A selected > data packet that is replicated, and its (possibly truncated) copy > is forwarded with one or more IOAM options, while the original > packet is forwarded normally, without IOAM options. > > I think you need to delete the "that" from the first clause? > [TM] Fixed. > 6. And once again in =C2=A75, > > o IOAM active measurement using replicated data packets: probe > packets are created by the encapsulating node by selecting some or > all of the en route data packets and replicating them. > > The 1/N requirement calls into question "or all" above, unless N=3D1, som= ething > you strongly discourage. Although you don't technically *forbid* N=3D1, I= think > the inclusion of "or all" creates confusion and you could and should leav= e it > out while still not technically forbidding N=3D1. > [TM] The 1/N is a rate limiting recommendation is an upper bound. For example, when the traffic rate is generally low, the "or all" is possible without violating the 1/N recommendation. Therefore, there does not seem to be a conflict between the two paragraphs. > 7. In =C2=A78, > > The attacker can > potentially leverage the Loopback flag for a Distributed Denial of > Service (DDoS) attack, as multiple devices send looped-back copies > of a packet to a single source. > > The use of "source" is odd here. By the nature of an attack, the looped-b= ack > copies wouldn't be targeted at the actual source of the packets. Possibly > "target" or even "victim"? [TM] Fixed. > > >