Re: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-rfc8889bis-02: (with DISCUSS and COMMENT)

Alvaro Retana <> Tue, 02 August 2022 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F5FAC157B5C; Tue, 2 Aug 2022 13:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Status: No, score=-7.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8iHA4Js-F1tB; Tue, 2 Aug 2022 13:16:40 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::234]) (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 (Postfix) with ESMTPS id 3546CC157B35; Tue, 2 Aug 2022 13:16:40 -0700 (PDT)
Received: by with SMTP id v7so9158880ljh.5; Tue, 02 Aug 2022 13:16:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=0RTv5Ft4zncwWLOZheF3xDyqDQ1g6fovdHGdrYyKrsI=; b=b4XVOP3Kn8YgFemD7teMrU06dZgWYQ3J1iKQuwj+wvmzVy0U3mGkQkpGTrRed7CY6v CGkLJiGcZyny8VZv0SiQNeqKAAar5HNPpWmaoe8vB5r2VdvrYPa9lAsmUZS2wDLKy6Ez sq0NFjq2zM8uvCu3hVpa+YUoC+vIamdqxk2ZRkAuaQX1Mdp11Aozro6zGRou1dd+ZvTZ f92zLQfuwovNG8rJ5+wGgvqj2D51V5kqRpYC0jsgqsh26JYyRPLznbr5UQNHOjGj5uO+ quMUqg731NKnjMSJTQv2McqtTM4iHhhENSMEO2Zo4W3nrJSA8GQClDCp+bLJqIVo88Ir s2VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=0RTv5Ft4zncwWLOZheF3xDyqDQ1g6fovdHGdrYyKrsI=; b=NTaSdRSLuhQWm59y+iYyrknIkefdS8Ja6jGTCaRU/PslhvogTPQlxSfeyMhdayk294 iDYsSPT+FcwqTCnNrAna9vTSw0LKRgxZEMTEdIXUjS5dIu/t+lAxvH6CG6K8b4w+dXk7 rCDEIpb1JDukrhzvadMM5oqudxKlW0yo6etg6y9SApmSPxaqoXGZNHRWO8jgExBhriEH rYAUG/93RNUoPRpa3VOmBO5Bo8sEsza3E7rkYGbx2xPdyqn+8J4rXWVIS9FFXpSoHIJL PUu79jTrOqZ1j7JJ8wsWGE9J+QDZZRxMgO+XsN6rvt8hIwLUa/vnJSK4i/BkoW3Hdyii ytEQ==
X-Gm-Message-State: ACgBeo2iyk9bW7ydymvAaZq3MlbTSW9py4wu/2/3rUCXQWdk8Ci7e1tf 1sMyCTCfU2k1nRqSgRzHFYHNKatrfBxvsMgTWuDCstWu
X-Google-Smtp-Source: AA6agR5N4w8NGhycS/KXsZw216A5gPppZEVKDlj5nXZc+i2+HSea/gIWpw71ktS8PV645AIa12IVBodavjK97PvK+ic=
X-Received: by 2002:a2e:6f1c:0:b0:25e:4ded:68df with SMTP id k28-20020a2e6f1c000000b0025e4ded68dfmr3665265ljc.380.1659471398063; Tue, 02 Aug 2022 13:16:38 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Tue, 2 Aug 2022 13:16:37 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Tue, 2 Aug 2022 13:16:37 -0700
Message-ID: <>
To: The IESG <>, Giuseppe Fioccola <>
Cc: "" <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000032552705e547cb84"
Archived-At: <>
Subject: Re: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-rfc8889bis-02: (with DISCUSS and COMMENT)
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: Tue, 02 Aug 2022 20:16:41 -0000


I also reviewed the latest version of this draft and I’m clearing my



On July 12, 2022 at 12:00:17 PM, Giuseppe Fioccola ( wrote:

Hi Alvaro,
Thanks again for your review.
Please find my replies inline tagged as [GF].
I will publish a new version to address your comments.

Best Regards,


-----Original Message-----
From: Alvaro Retana via Datatracker <>
Sent: Monday, July 11, 2022 11:19 PM
To: The IESG <>
Subject: Alvaro Retana's Discuss on draft-ietf-ippm-rfc8889bis-02: (with

Alvaro Retana has entered the following ballot position for
draft-ietf-ippm-rfc8889bis-02: 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
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


§9 ("Results of the Multipoint Alternate Marking Experiment") makes several
recommendations about the use of one or two flag bits:

One flag: packet loss measurement SHOULD be done as described in
Section 6 by applying the network clustering partition described
in Section 5. While delay measurement MAY be done according to
the Mean delay calculation representative of the multipoint path,
as described in Section 7.1.1. Single-marking method based on the
first/last packet of the interval cannot be applied, as mentioned
in Section 7.2.1.

Two flags: packet loss measurement SHOULD be done as described in
Section 6 by applying the network clustering partition described
in Section 5. While delay measurement SHOULD be done on a single
packet basis according to double-marking method Section 7.2.1. In
this case the Mean delay calculation (Section 7.1.1) MAY also be
used as a representative value of a multipoint path.

One flag and hash-based selection: packet loss measurement SHOULD
be done as described in Section 6 by applying the network
clustering partition described in Section 5. Hash-based selection
methodologies, introduced in Section 7.2.2, MAY be used for delay

These recommendations are good, as they are the result of experimentation.
However, they don't provide any deployment or operational guidelines of
it is ok to follow them and when it isn't. For example, for the one flag
when it is ok to not measure packet loss as described in §6? Why is the use
of that mechanism only recommended and not required?

I have the same questions for all the recommendations and optional
in the text above. To clear this DISCUSS I expect deployment or operational
recommendations that can be used as implementation/deployment guidance.

[GF]: Similarly to RFC8321bis, I will surely add more details. Regarding
the packet loss measurement SHOULD can be replaced with MUST since it is
the only option for multipoint measurements. Regarding the delay
measurements, there are some considerations to take into account in order
to provide guidelines, such as the number of flags available, the kind of
information needed, the computational resources (e.g. to implement hashing


I support Roman's DISCUSS position and have a related question about this
in §9:

The Multipoint Alternate Marking Method is RECOMMENDED only for
controlled domains, as per [I-D.ietf-ippm-rfc8321bis].

When is it ok to use the Multipoint Alternate Marking Method in any other
deployment? IOW, given the definition of a controlled domain in rfc8321bis,
why is its use only recommended and not required?

Note that if this consideration depends entirely on rfc8321bis, you may be
to refer to it and eliminate the Normative language.

[I did not include this point as a DISCUSS because I expect it to be solved
when Roman's concern is addressed.]

[GF]: Yes it is similar to RFC8321bis. I will refer to it or just replace
that sentence with: "The Multipoint Alternate Marking Method MUST only be
applied to controlled domains."