Re: [ippm] Robert Wilton's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS)

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Thu, 14 July 2022 09:20 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
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 28C1BC14F72A; Thu, 14 Jul 2022 02:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um5J7e-k0qqK; Thu, 14 Jul 2022 02:19:57 -0700 (PDT)
Received: from sinmsgout03.his.huawei.com (sinmsgout03.his.huawei.com [119.8.177.38]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A874C14F727; Thu, 14 Jul 2022 02:19:57 -0700 (PDT)
Received: from fraeml713-chm.china.huawei.com (unknown [172.18.156.207]) by sinmsgout03.his.huawei.com (SkyGuard) with ESMTP id 4Lk87B3xhNz9xGPv; Thu, 14 Jul 2022 17:18:46 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml713-chm.china.huawei.com (10.206.15.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 14 Jul 2022 11:19:47 +0200
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2375.024; Thu, 14 Jul 2022 11:19:47 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Robert Wilton <rwilton@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ippm-rfc8321bis@ietf.org" <draft-ietf-ippm-rfc8321bis@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "tpauly@apple.com" <tpauly@apple.com>
Thread-Topic: Robert Wilton's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS)
Thread-Index: AQHYl1kWrQ/Dx34SVEWFaYhx82d5g619hheQ
Date: Thu, 14 Jul 2022 09:19:46 +0000
Message-ID: <78800d39779c4922bc174844aa105a56@huawei.com>
References: <165778615318.64705.5126086585557202457@ietfa.amsl.com>
In-Reply-To: <165778615318.64705.5126086585557202457@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.214.207]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/FJ4WsJUk4XxfLeqgS7U5Bed0ApA>
Subject: Re: [ippm] Robert Wilton's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Thu, 14 Jul 2022 09:20:01 -0000

Hi Robert,
Thanks for your revision,
Please see my reply inline tagged as [GF].
I will address your comments in the next version.

Best Regards,

Giuseppe

-----Original Message-----
From: Robert Wilton via Datatracker <noreply@ietf.org> 
Sent: Thursday, July 14, 2022 10:09 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-rfc8321bis@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org; tpauly@apple.com; tpauly@apple.com
Subject: Robert Wilton's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS)

Robert Wilton has entered the following ballot position for
draft-ietf-ippm-rfc8321bis-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-rfc8321bis/



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

Sorry, another discuss, but hopefully a trivial one to resolve.

I found this text to be a unclear regarding passive vs hybrid:

   Therefore, the Alternate-Marking Method could be considered Hybrid or
   Passive, depending on the case.  In the case where the marking method
   is obtained by changing existing field values of the packets the
   technique is Hybrid.  In the case where the marking field is
   dedicated, reserved, and included in the protocol specification, the
   Alternate-Marking technique can be considered as Passive.

Please can you clarify the third sentence, to clarify that the marking is done
at source, or at least outside the controlled domain?  I.e., I presume that
even if there were some reserved bits in the protocol header for colouring
packets, that were then written at the edge of the controlled domain, then this
would be a active rather than passive measurement?

[GF]: I think it is better to further clarify this point. If you look at RFC7799:
"Passive Methods of Measurement are:

   o  based solely on observations of an undisturbed and unmodified
      packet stream of interest (in other words, the method of
      measurement MUST NOT add, change, or remove packets or fields or
      change field values anywhere along the path).

   o  dependent on the existence of one or more packet streams to supply
      the stream of interest.

   o  dependent on the presence of the packet stream of interest at one
      or more designated Observation Points."

By assuming that there are reserved bits in the protocol header, if the change in value of these marking bits at the domain edges (and not along the path) is still considered a modification to the packet stream, AltMark cannot be considered Passive.
Therefore, AltMark can be considered Hybrid Type I in any case. 
Note that, according to RFC7799, Hybrid Type I methods imply "Augmentation or modification of the stream of interest, or employment of methods that modify the treatment of the stream" 
I can eventually revise the text and state that Alternate-Marking Method can only be considered Hybrid.


Thanks,
Rob