From nobody Thu Aug 18 05:50:28 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 4F3C0C15271F; Thu, 18 Aug 2022 05:50:25 -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 xv01aui5ggJP; Thu, 18 Aug 2022 05:50:23 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 75061C15271D; Thu, 18 Aug 2022 05:50:23 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id f65so1204435pgc.12; Thu, 18 Aug 2022 05:50:23 -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=r+e5A5JJR8Vac49UQz88p6L7VKZLsDRCl7YNojr0v0c=; b=OYVRJmlBgNQ7K3AItZFi4o9ryuA6WJwyfgZZ2CkteX8oPyZAo/zOHiYxy54zw88CTB B09M3u/iEiyeCzIfQbE+0JwAhItEXz5YsswM3kJQ6ORJb92a5QK329dkQVRkYIwThywQ HevCe6Tw4TD+5zfcMJGjXkG3NHiqUSeNNfllT9ovcImxR8E5Fbf5L5+kbSFIOF/GKAc+ HrABbR+ixq3AVucDT9f5WVitpGJipfT14nZM4pT1AevYPFeSVIHL4LGyD5SRHYi0lKch eNWmS6upWCtfHl4f5QgqojUDrNTOKvdwG67ptSlNFi4jsnsbc50FN/Or0cfJOrd61+b3 BpUg== 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=r+e5A5JJR8Vac49UQz88p6L7VKZLsDRCl7YNojr0v0c=; b=aMTQDUG/VLKDqyLfNV2XIBIHdY4aeQdqVzaaop3w5jApLVSPrsKxpoZ4UTULZNrwqU wT2hxwtHiI0S/FfTdfbsk3By57161CMPLknRoNeeBiy720cQYiAxs/sDDx8PkhUF6xbW rzgEVjIdYDLHu2c2OfOo1Iy6P1S6beG3ECwNbIaC4wutitXDkeZ11Wit7kNVPYt0vHvu 4rc4ZFyN+IYSgYk/+oJbtI5Q2WKV1Gu1+dKjuXd9Vd82e7gbyV1o88D53VQlv9MX9vtI njgsq30JlYwk25V6e6igzCvLO+ic4vc33yjAwVGFqki/J9E2C5xfwjRHvLKO0BSQUbFp oL4g== X-Gm-Message-State: ACgBeo3Q0SejCI8FE1A1WNPmaDWMfmZuQmhOUCRkM17GyDKLi9WZKKje WLhhlDyZVIMT2K2rAO27ymKCIDNYqR+zcuAde+M= X-Google-Smtp-Source: AA6agR5rhwLU12O8A1raqV5xr9+lGm4BjGtKoESX7fUUjKPSO+9w7OseM1XeC2mWfJRLe9f4SZ1CAlVRBAFfNp1jpbo= X-Received: by 2002:a63:6941:0:b0:41c:9703:d2ea with SMTP id e62-20020a636941000000b0041c9703d2eamr2332713pgc.304.1660827022482; Thu, 18 Aug 2022 05:50:22 -0700 (PDT) MIME-Version: 1.0 References: <165648134156.26179.362559432030634930@ietfa.amsl.com> In-Reply-To: From: Tal Mizrahi Date: Thu, 18 Aug 2022 15:50:07 +0300 Message-ID: To: "Eric Vyncke (evyncke)" Cc: The IESG , "draft-ietf-ippm-ioam-flags@ietf.org" , IPPM Chairs , IETF IPPM WG , Tommy Pauly , "Pascal Thubert (pthubert)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-ippm?= =?utf-8?q?-ioam-flags-09=3A_=28with_DISCUSS_and_COMMENT=29?= 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:50:25 -0000 Dear Eric, Thanks again for the review and comments. We have uploaded an updated version that hopefully addresses the comments, and specifically the text related to the source address was rephrased, and a reference to RFC 6724 was added. The new version: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags Please let us know if there are further comments. Cheers, Tal. On Thu, Jun 30, 2022 at 4:50 PM Eric Vyncke (evyncke) w= rote: > > Dear Tal, > > Thank you for the quick reply, your proposed text is addressing my blocki= ng DISCUSS except for the source address in the 'echoed/looped back' packet= . Erik Kline has a similar comment and has suggested the use of RFC 6724 as= a reference. This reference would fix my issue as well. > > As soon as a revised I-D with those changes is uploaded, then I am cleari= ng my DISCUSS into a NO OBJECTION. > > Regards > > -=C3=A9ric > > =EF=BB=BFOn 29/06/2022, 14:40, "Tal Mizrahi" = wrote: > > Dear Eric, > > Many thanks for the feedback. > > Please see the responses to the DISCUSS issues below, marked [TM]. > > Cheers, > Tal. > > > On Wed, Jun 29, 2022 at 8:42 AM =C3=89ric Vyncke via Datatracker > wrote: > > > > =C3=89ric Vyncke 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 a= ll > > 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/h= andling-ballot-positions/ > > for more information about how to handle DISCUSS and COMMENT positi= ons. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ > > > > > > > > -------------------------------------------------------------------= --- > > DISCUSS: > > -------------------------------------------------------------------= --- > > > > # =C3=89ric Vyncke, INT AD, comments for draft-ietf-ippm-ioam-flags= -09 > > CC @evyncke > > > > Thank you for the work put into this document. > > > > Please find below some blocking DISCUSS points (easy to address as = it is about > > clarifications), some non-blocking COMMENT points (but replies woul= d be > > appreciated even if only for my own education), and some nits. > > > > Thanks to Pascal Thubert for his internet directorate review at: > > https://datatracker.ietf.org/doc/review-ietf-ippm-ioam-flags-09-int= dir-telechat-thubert-2022-06-28/ > > (please consider Pascal's comments as mine). > > > > Special thanks to Tommy Pauly for the shepherd's detailed write-up = including > > the WG consensus and the justification of the intended status. > > > > I hope that this helps to improve the document, > > > > Regards, > > > > -=C3=A9ric > > > > ## DISCUSS > > > > As noted in https://www.ietf.org/blog/handling-iesg-ballot-position= s/, a > > DISCUSS ballot is a request to have a discussion on the following t= opics: > > > > ### Section 4.2 which address > > > > `The address of the node performing the copy operation` is confusin= g in the > > case of multiple interfaces (typical for a transit device BTW)... W= hich address > > should be used ? If the packet was received through an interface wi= th a global > > address, then this should be the obvious choice or a loopback inter= face or ??? > > > > [TM] The current draft, much like RFC 9197, is intended to be > encapsulation-agnostic, while there are encapsulation-specific > documents, such as draft-ietf-ippm-ioam-ipv6-options, intended to > define how IOAM works over a specific encapsulation such as an IPv6 > option. > That said, I agree that the sentence you quoted might be > misunderstood, and I suggest to remove it, i.e. remove: > OLD: > The address of the node performing the copy operation is used as t= he > source address. > NEW: > ---NA > > > ### Section 4.2 just truncation ? > > > > ``` > > The copy is also truncated, i.e., any payload that > > resides after the IOAM option(s) is removed before transmitting = the > > looped back packet back towards the encapsulating node. > > ``` > > It is unclear what happens to the IPv6 Next header field... Should = the IP > > header length field be modified ? > > [TM] Specifically, in IOAM over IPv6 (which is not within the scope o= f > the current draft), the IOAM option resides in a hop-by-hop options > header or in a destination options header. Either way, the Next Heade= r > of this option header is available after the truncation. As a result > of the truncation there may be a need to modify some > encapsulation-specific fields, such as the IPv6 Payload Length. > > However, I agree that some clarification would help here. > I would suggest the following text update: > > OLD: > The copy is also truncated, i.e., any payload that > resides after the IOAM option(s) is removed before transmitting th= e > looped back packet back towards the encapsulating node. > NEW: > The copy is also truncated, i.e., any payload that > resides after the IOAM option(s) is removed before transmitting th= e > looped back packet back towards the encapsulating node. The trunca= tion > may require some encapsulation-specific updates in the encapsulati= on header. > > > > > > ### Section 4.2 forwarding ? > > > > It is unclear whether the packet is sent back to the source via the= received > > interface or whether the packet is forwarded based on the FIB. > > > > [TM] The draft mentions IOAM loopback as an alternative to Traceroute= . > Following this analogy, the question you raised would also arise when > a router sends an ICMP TTL Exceeded back to the source that runs > Traceroute. RFC 792 (ICMP) does not go into this issue, and I would > suggest avoiding this issue in the current draft as well, especially > since we are doing our best to be encapsulation agnostic. > > > ### IANA considerations conflicting text ? > > In section 4.1: > > ``` > > An IOAM trace option that has the Loopback flag set MUST have th= e > > value '1' in the most significant bit of IOAM-Trace-Type, and '0= ' in > > the rest of the bits of IOAM-Trace-Type. > > ``` > > but in section 6: > > ``` > > IANA is requested to allocate the following bits in the "IOAM Tr= ace > > Flags Registry" as follows: > > > > Bit 1 "Loopback" (L-bit) > > > > Bit 2 "Active" (A-bit) > > > > Note that bit 0 is the most significant bit in the Flags Registr= y. > > ``` > > > > Is it bit 0 or bit 1 ? > > [TM] The sentence from Section 4.1 refers to the IOAM-Trace-Type, > while the sentence from Section 6 refers to the IOAM Trace Flags. It > is a different field and a different registry, so there does not seem > to be a conflict. > Nevertheless, I suggest the following clarification: > > OLD: > Note that bit 0 is the most significant bit in the Flags Registry. > NEW: > Note that bit 0 is the most significant bit in the Flags Registry. > This bit was allocated by [RFC 9197] as the 'Overflow' bit. > > > > > > > > -------------------------------------------------------------------= --- > > COMMENT: > > -------------------------------------------------------------------= --- > > > > ## COMMENTS > > > > ### "loopback" > > > > No need to reply, but every time I read "loopback", I think of the = local > > "loopback interface". The use of "echo" would probably have made my= reading > > easier ;-) > > > > ### Section 4.1 > > > > ``` > > An IOAM trace option that has the Loopback flag set MUST have th= e > > value '1' in the most significant bit of IOAM-Trace-Type, and '0= ' in > > the rest of the bits of IOAM-Trace-Type. > > ``` > > Does it prevent further enhancements to Trace types ? > > > > ### Section 4.1.1 > > > > "SHOULD NOT exceed 1/N of the interface capacity" but this recommen= dation is > > only for the encapsulating node while there are nodes / links on th= e path that > > may have much more constrained capacity. I suggest to remove this p= art and > > replace it by text not refering to encapsulating node interface. > > > > ### Section 5 > > > > ``` > > The > > IOAM options are encapsulated in one of the IOAM encapsulation t= ypes, > > e.g., [I-D.ietf-sfc-ioam-nsh], or [I-D.ietf-ippm-ioam-ipv6-optio= ns]. > > ``` > > Should this text also appear in the section 4? > > > > ### Section 5 capacity > > > > In > > ``` > > Thus, the rate of the traffic that > > includes the Active flag rate SHOULD NOT exceed 1/N of the inter= face > > capacity on any of the IOAM node's interfaces. > > ``` > > Should thie be "IOAM nodes' interfaces" to take into account all IO= AM nodes > > (including transit). > > > > ## NITS > > > > ### Section 5 > > s/This draft focuses on three possible use cases/This document focu= ses on three > > possible use cases/ > > > > ## Notes > > > > This review is in the ["IETF Comments" Markdown format][ICMF], You = can use the > > [`ietf-comments` tool][ICT] to automatically convert this review in= to > > individual GitHub issues. > > > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > > [ICT]: https://github.com/mnot/ietf-comments > > > > > > >