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

Alvaro Retana via Datatracker <noreply@ietf.org> Mon, 11 July 2022 21:19 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 E1710C16ECC0; Mon, 11 Jul 2022 14:19:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-rfc8889bis@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, tpauly@apple.com
X-Test-IDTracker: no
X-IETF-IDTracker: 8.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <165757435591.4931.9146839768451175920@ietfa.amsl.com>
Date: Mon, 11 Jul 2022 14:19:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/rNtJL_ZgPz8ReRrSV-VsRNWYsM0>
Subject: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-rfc8889bis-02: (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: Mon, 11 Jul 2022 21:19:16 -0000

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 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-rfc8889bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

§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
      measurement.

These recommendations are good, as they are the result of experimentation.
However, they don't provide any deployment or operational guidelines of when
it is ok to follow them and when it isn't.  For example, for the one flag case,
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 indications
in the text above.  To clear this DISCUSS I expect deployment or operational
recommendations that can be used as implementation/deployment guidance.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Roman's DISCUSS position and have a related question about this text
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 able
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.]