From nobody Sun May 23 00:48:05 2021 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 2B5F33A31FC; Sun, 23 May 2021 00:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1vjMG3Ol9sO; Sun, 23 May 2021 00:47:56 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A6C3A31FA; Sun, 23 May 2021 00:47:55 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id z85-20020a1c7e580000b029017a76f3afbaso6815800wmc.2; Sun, 23 May 2021 00:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=us6q1Kz1r17K5fmE7DT3no2bG576Z7sK9Jgi8xnxJp4=; b=eBjDbJ4+b+7tJT8nBF0MazROKsmS9Ftlatm7BpIEWsIoyiU0jC/yPKontuQKnWghMQ ystRF8bLx59uNJf+VRD8PvdZ9RICzKivBO+kMprIt6Pv+217rCUJ04dk/krSQeL6TjUt NHtJUUZiL1YP+GYiGe86P0SpyGb2kEWFqKxlbOH/uhMVEreykijG57LCCQOfrU5gWIdr ie13YqgYoUtghfAfKOtPQIx+5fMM7LorOlekZdJERj9Mo2UQ/+yaiOrQXOZcjsZK7fjr Ut6kqG2DZoWFLXGaeJK1KgoSH2zBa7A5pYPFq0C0WrVCrj/s1zy3W/PO6UtnAo190bVE 4P8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=us6q1Kz1r17K5fmE7DT3no2bG576Z7sK9Jgi8xnxJp4=; b=CRQw4BYooE0lrYSVqEB5yxSWvtACBikxKz9zFUZJzIB59fP2AmPtDiuXxkiANFFj1Y GxQqEQOOxZPpmMSnr+02UgXCdM5Z+xzXmXEKoTAEEDUk7HQhaaQc52qKAmEiJlx7U5ba ZOQ79B2Ck+9dzmYp62HNqjT2HYh/USTHhlZeDE9LxvGguGmmK3XgbXZYswXUVEpd8xii DbRcEkqs1rQNHhKwOE5rWwqi2qVIu4j5OX2SCjvv5PZVVz5b07vS5+XOTl6cNJPlvgGh jp6nydRETETJ6VKi+gQOKRAcgWAG3GCTfF4ooMQsA4I0Z2qu7alIE3uupVF77ek3wyzL Cy8w== X-Gm-Message-State: AOAM533T/HRnHensSJeYBSR+tn4xxrVUyZv65Q6F2ATWkwMG68XAKpVd rbYVc+AVUdUES33I+RNyNAlRku2AMCfppnWW5/Q= X-Google-Smtp-Source: ABdhPJwLKV83leJn/WdSocutdRoI7udQYmSXkX8sWEMZAptv41TZZEM6QWqeV6gUlUyl8GxMV1VmZ/tFBwyX4TU1ryI= X-Received: by 2002:a7b:c923:: with SMTP id h3mr5203203wml.67.1621756072751; Sun, 23 May 2021 00:47:52 -0700 (PDT) MIME-Version: 1.0 References: <161666128644.21877.3692355580933620496@ietfa.amsl.com> In-Reply-To: <161666128644.21877.3692355580933620496@ietfa.amsl.com> From: Tal Mizrahi Date: Sun, 23 May 2021 10:47:39 +0300 Message-ID: To: =?UTF-8?B?w4lyaWMgVnluY2tl?= Cc: The IESG , draft-ietf-ippm-ioam-data@ietf.org, IPPM Chairs , IETF IPPM WG , Al Morton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-ippm-ioam-data-12=3A_=28with_COMMENT=29?= X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 07:47:59 -0000 Hi =C3=89ric, Many thanks for the comments. We are currently working on an updated version of the draft that will accommodate the comments. Please see our responses and proposed changes below. Please let us know if there are further comments. Thanks, Tal. On Thu, Mar 25, 2021 at 10:34 AM =C3=89ric Vyncke via Datatracker wrote: > > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-ippm-ioam-data-12: No Objection > > 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document and thank you for acknowled= ging > my comments and advices (as they were minor, I am not recusing myself). > Sometimes the text is difficult to read as paragraphs and sentences are l= ong > and somehow repetitive. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated), and some nits. Like Alvaro, I was hesitating to ballot a DI= SCUSS > on one point about section 4 (insertion/deletion of data on the flight). > > I hope that this helps to improve the document, > > Regards, > > -=C3=A9ric > > =3D=3D COMMENTS =3D=3D > > -- Abstract -- > "a path between two points in the network" does this mean that this docum= ent > cannot be used with a multicast destination address ? > Proposed text update: OLD: traverses a path between two points in the network NEW: traverses a path in the network > -- Section 2 -- > Is the list about 'contributors' (as in the section title) or 'co-authors= ' (as > in the text) ? > After a bit of discussion with the WG chairs, this was the text that was recommended for this section. > -- Section 3 -- > Please use the BCP14 boilerplate > Right. Will be fixed. > Please note that Geneve is now RFC 8926. > Right. Will be fixed. > -- Section 4 -- > Should the 'deployment domain' include a reference to RFC 8799 ? > > I was about to ballot a DISCUSS on this one: While the actual encapsulati= on is > out of scope, the definition of "IOAM control points" alludes to nodes at= the > edge and in the core being able to add/remove data fields. This behavior = will > obviously have some impacts on the PMTU discovery and possibly on the han= dling > of ICMP. Did the authors think of writing a generic section in this docum= ent on > how this can be done in a correct way? > Right. This was also pointed out by other IESG members, and we plan to clarify this text, including a reference to RFC 8799. > What is "live user traffic" ? I guess that this is not about end-user rea= l-time > video ;-) but a better wording would be welcome. > Right. s/live / / > I am afraid that "ships in the night" does not apply here as all ships ar= e > usually on the same layer ;-) (planes do flight at different flight level= s) > But, this is not that important. No need to reply. > > -- Section 5.1 -- > Is it expected to have additional IOAM data types than the 4 in this docu= ment? > Text should clarify this. > Right. We will add the following text to section 5.1: NEW: Future IOAM-Option-Types can be allocated by IANA, as described in Section = 8.1. > -- Section 5.2 -- > "A transit node MUST NOT add new IOAM-Option-Types" seems to contradict t= he > "IOAM control points" definition of section 4. > Section 4 says: "Devices which form an IOAM-Domain can add, update or remove IOAM-Data-Fields." Specifically, transit nodes can add data fields, but not option types. This is clearly specified in Section 5.2, as well as the difference between an encapsulating node and a transit node. > -- Section 5.3 -- > If 0x0000 is already reserved, then I would suggest to make it part of th= e IANA > range (i.e., making IANA range 0x0000 t 0x7FFF). > Right. This value is already defined in the IANA section as reserved. The text just explicitly states what the meaning of value 0 is: "0: default namespace (known to all IOAM nodes)" > -- Section 5.4.2.5 -- > Should there be a precise definition (or reference) of "time in nanosecon= ds the > packet spent in the transit node"? E.g., between first bit received and l= ast > bit sent ? > We tried to avoid explicitly specifying this, in order to avoid mandating a specific hardware/software architecture. We plan to add a general note to Section 5.4 that discusses the fact that some of the node data fields have implementation specific semantics: NEW: It should be noted that the semantics of some of the node data fields that are defined below, such as the queue depth and buffer occupancy, are implementation specific. This approach is intended to allow IOAM nodes with various different architectures. > -- Section 5.4.2.7 -- > Is there a reason why the queue depth is expressed in buffers and not in > packets? (Both metrics have useful values imho) > Right, again this goes back to the note about implementation specific semantics. We hope the note we are adding to Section 5.4 addresses this. > -- Section 5.5 -- > In "Random: Unique identifier for the packet" how are collisions resolved= ? Do > they matter at all ? > Good point, and we will add some text about this to the PoT draft. The current draft only defines the fields. The detailed functionality is specified in the PoT draft. > How can a transit/decaps node can handle the PoT (and also the E2E of sec= tion > 5.6) as the length is not specified in the header ? > The length of the PoT option is constant, and thus a node that detects the presence of a PoT option knows its length. For the E2E option, a node that parses the IOAM-E2E-Type field knows the length of the option. > =3D=3D NITS =3D=3D > > Usually "e.g." is enclosed between commas. > > The sentence "The definition of how IOAM-Data-Fields are encapsulated int= o > other protocols is outside the scope of this document." or a minor variat= ion of > it occurs multiple times in the document. Please consider avoiding those > repetitions. > > >