[ippm] Éric Vyncke's Discuss on draft-ietf-ippm-ioam-ipv6-options-09: (with DISCUSS and COMMENT)
Éric Vyncke via Datatracker <noreply@ietf.org> Tue, 29 November 2022 12:53 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ippm@ietf.org
Delivered-To: ippm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD2DC14F732; Tue, 29 Nov 2022 04:53:41 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-ioam-ipv6-options@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com, marcus.ihlar@ericsson.com, dthaler@microsoft.com
X-Test-IDTracker: no
X-IETF-IDTracker: 9.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <166972642189.22951.10409233355451977330@ietfa.amsl.com>
Date: Tue, 29 Nov 2022 04:53:41 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/iFh9vrAOZ-79nVqR3QF5kOEKUcM>
Subject: [ippm] Éric Vyncke's Discuss on draft-ietf-ippm-ioam-ipv6-options-09: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2022 12:53:41 -0000
Éric Vyncke has entered the following ballot position for draft-ietf-ippm-ioam-ipv6-options-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/handling-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-ipv6-options/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-ippm-ioam-ipv6-options-09 CC @evyncke Thank you for the work put into this document. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Marcus Ihlar for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. Please note that Dave Thaler is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Tim will complete the review (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/reviewrequest/16642/ I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Section 5.1 ``` Operators of an IOAM domain SHOULD ensure that the addition of OAM information does not lead to fragmentation of the packet, e.g., by configuring the MTU of transit routers and switches to a sufficiently high value. ``` Should it be a MUST as IPv6 routers are unable to fragment an IPv6 packet ? Should "e.g." be replaced by "i.e." ? Roman's DISCUSS points are also sensible. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS ### Encapsulation In the abstract and introduction, it is written that "IOAM options are encapsulated in IPv6". I am unsure whether this is the right wording as it is the original packet that is encapsulated and then IOAM options added. Suggest to simply use "IOAM option are transported in IPv6 packets". It also seems to prevent the use of IOAM by the source node, which appears to me as an important use case (e.g., video conferencing). ### Section 2 As written by others, the location of the contributors is at a weird location. ### Section 4 `IOAM data fields can be encapsulated in "option data" fields` is hard to parse even for an IPv6-aware person. Is it "option data" as in the diagram below ? Or is it the option fields of HbH & DO as defined in RFC 8200. Does every interface really need to be IOAM enabled ? It seems that not enabling on interface will only degrade the collected information but would still be useful. `a router MUST ignore IOAM Options` what about a host (i.e., not a router) receiving a packet with a destination option containing an IOAM option ? The Reserved field must be set to 0 on transmission, does it include also when it is received in HbH ? I.e., then re-transmitted to the next node ? Suggest to use "set to 0 by the source". ### Section 5.1 To be honest, I was about to mark those comments as blocking discuss points. In C1: ``` Implementations of IOAM SHOULD ensure that ECMP behavior for packets with and without IOAM data fields is the same. ``` What about non-IOAM-aware routers (or even not routers like LACP bundles)? Is it the reason why all routers need to support IOAM as specified in section 4 ? In C2: `which is intended to support hardware implementations of IOAM, ` seems weird. Is it about "which is intended to be used only by hardware-supported implementation" ? In C3, I am afraid that I cannot really parse this consideration. E.g., what is meant by "associated ICMP errors" ? Is it ICMP packet generated by an IOAM-domain router containing IOAM options (my guess) ? If the original packet is encapsulated (per the rest of this I-D), how could an ICMP sent back to the encapsulating node be sent further once decapsulated ? C4, does "data leak" means a "packet with IOAM data leaking outside of the IOAM domain" ? Unsure about the usefulness of C5. ### Section 5.2 The use of "encapsulation" and "decapsulation" appears weird in a host processing. ### Section 5.4 Should it be a sub-section of 5.3 ? (IOAM bounded by network devices) ### Section 5.4.1 Unsure whether there could be a real use case of using ULA just for IOAM... Suggest to remove this section. ### Section 5.4.2 Please add reference to VXLAN and Geneve. ## NITS ### Capitalized Extension header Some occurrence of `Extension header`, unsure whether "extension" should be capitalized though. ### IOAM or in-situ OAM Suggest to always use either "IOAM" or "in-situ OAM" and not the current mix. ### Section 5.1 s/that/than/ in `should follow the same path within the domain that an identical` ? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
- [ippm] Éric Vyncke's Discuss on draft-ietf-ippm-i… Éric Vyncke via Datatracker
- Re: [ippm] Éric Vyncke's Discuss on draft-ietf-ip… Frank Brockners (fbrockne)
- Re: [ippm] Éric Vyncke's Discuss on draft-ietf-ip… Eric Vyncke (evyncke)