Re: [ippm] Opsdir last call review of draft-ietf-ippm-ioam-ipv6-options-08

Shwetha Bhandari <> Sun, 25 September 2022 02:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5536CC14CE2B for <>; Sat, 24 Sep 2022 19:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Status: No, score=-7.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NRGuRGvm8gb9 for <>; Sat, 24 Sep 2022 19:27:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7ABAAC1522D0 for <>; Sat, 24 Sep 2022 19:27:13 -0700 (PDT)
Received: from pps.filterd ( []) by ( with ESMTP id 28ONahI6028557 for <>; Sat, 24 Sep 2022 19:16:19 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=proofpoint; bh=4Xs1DU+NRQ/cBR81XP/zLqG2OrhZY7jenxSeehnoyGU=; b=K70hVUjZydkCLJ7hLRzZp8Yl0o+0fpwsVp637IzdR/622BnrLQfeARO+spEqTrJ/+mtN apmiX7H+JZHKzVVONoYqBbl2QPKfxgF923BHEYnGhoTO0VTyDgujZzM55b8kAbKEpXdX +MgtceBxYvdZXjGtjN30y7YrmHCl2cY10Xml9OKhiEnhRIsrifBrxrFvL5XMpsjEwyev AVZKiVLWPrBP5Rfz3rX9yAs7ZOYE9ls4aLGuwywHICE3RngsVHsSFwfRh3egpuf2QVh4 FOG++AbUJUS3REruyqy5OF64YgwfFVYKwOIk1vCqa3P9zpfOf8AUCA/ghCWfxBLFi6P/ vw==
Received: from ( []) by (PPS) with ESMTPS id 3jt1cksacg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <>; Sat, 24 Sep 2022 19:16:19 -0700
Received: by with SMTP id x7-20020a056512130700b00492c545b3cfso1234513lfu.11 for <>; Sat, 24 Sep 2022 19:16:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=4Xs1DU+NRQ/cBR81XP/zLqG2OrhZY7jenxSeehnoyGU=; b=Qz761mnsvtFHjs3AKFdKTqEsJOc+uTpyyTrsLpqLfBYGXwmQzfq9A0u/A418IxDi1+ GxXG7C/Qln2e1lqhRmw9/d5Jo7KKJBggB0DS+ZuU/x5MJ30kTOypG0gH3928k9qv5LN/ eIMXdIv/voXUpAC1K93AVBidaGM0ZlzyirvqTDUDGLGNLII+POKjLZ607Yk05ezLyHNj vM/ITMAfGPBUaLqHRViZbG3+5jGwk7WaF4Iy+WpX1hI5SlVWTBtwT81dMdWsOJhSxZ7I XT8QpkkGXktuqWTEpf8OQXTr1jW6A0fqPwIYYwl5FM/nXI15uEXi7j3KkDbeMpX4/Wyq OLKQ==
X-Gm-Message-State: ACrzQf0bTlQ51pExymYOAc311oZpYV2ojMICYSeH1DuukMkNpqZQLvRS J/i3KPn4oanvltJio7MHw1S0XGx2zHffZ5IdMLa7fjSHgIXrBX8vC1zU3ZjkLhhgOYkVYE/wFSK hN6uOBWUDQxLIwxYTS0an
X-Received: by 2002:a05:6512:138e:b0:47f:77cc:327a with SMTP id p14-20020a056512138e00b0047f77cc327amr6453999lfa.277.1664072177582; Sat, 24 Sep 2022 19:16:17 -0700 (PDT)
X-Google-Smtp-Source: AMsMyM5oU44+islFIf1sLoBOOORbb5guf8cOZ4m3f946Mc3Jaof9Ju6pVtFhFbSFygfZfzQekWU9PvWB7bReaELDkU4=
X-Received: by 2002:a05:6512:138e:b0:47f:77cc:327a with SMTP id p14-20020a056512138e00b0047f77cc327amr6453994lfa.277.1664072177356; Sat, 24 Sep 2022 19:16:17 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Shwetha Bhandari <>
Date: Sun, 25 Sep 2022 07:46:06 +0530
Message-ID: <>
To: Tianran Zhou <>
Content-Type: multipart/alternative; boundary="000000000000032fbc05e976ffb6"
X-Proofpoint-GUID: adi3EjMwxg12V6aL1r-JYMWz3R3m2KfP
X-Proofpoint-ORIG-GUID: adi3EjMwxg12V6aL1r-JYMWz3R3m2KfP
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib: definitions=2022-09-24_14,2022-09-22_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 mlxlogscore=999 impostorscore=0 mlxscore=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 bulkscore=5 adultscore=0 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209250014
Archived-At: <>
Subject: Re: [ippm] Opsdir last call review of draft-ietf-ippm-ioam-ipv6-options-08
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: Sun, 25 Sep 2022 02:27:20 -0000

Hello Tianran,

Thank you for your review and feedback. Sorry for the late response. I am
revising the draft based on this, gen-art, sec-dir feedback.

Regarding your concern on the Increment Tracing option, it has a RemainingLen
field to restrict the length the option data can grow to.
This is elaborated in RFC 9197.
Will a new deployment consideration with the following text address your

C7       The IOAM Incremental Trace Option-Type expands the
            option length that may affect the processing of extension
            headers and options that follow IOAM options.
            Hence when IOAM Incremental Trace Option-Type is
            used in the deployment the RemainingLen field of the option
            must follow the guidance in RFC9197 and must
            be computed and set appropriately.


On Wed, Jul 13, 2022 at 12:39 PM Tianran Zhou via Datatracker <> wrote:

> Reviewer: Tianran Zhou
> Review result: Has Issues
> I have reviewed this document as part of the Operational directorate's
> ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written with the intent of improving the operational aspects
> of
> the IETF drafts. Comments that are not addressed in last call may be
> included
> in AD reviews during the IESG review.  Document editors and WG chairs
> should
> treat these comments just like any other last call comments.
> It is good to describe the deployment consideration in section 5. However,
> I
> think there is an issue that the increamental tracing option will impact
> other
> IPv6 extension header processing, e.g. SRH. This is similar to the
> consideration about PMTU, which has many ways to detect. But it is
> different.
> The increamental option is encapsulated in HbH which is the first EH. As
> the
> option length expands, the intermedate node may not be able to process
> other
> EHs. Typically, SRH is used for TE. This will break the network service.
> Best,
> Tianran