comment on draft-ietf-6man-ipv6-alt-mark

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Tue, 28 July 2020 13:38 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0863A0C54; Tue, 28 Jul 2020 06:38:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYQx8H1Dh4OJ; Tue, 28 Jul 2020 06:38:40 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69863A0C34; Tue, 28 Jul 2020 06:38:40 -0700 (PDT)
Received: from lhreml714-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 1E183D8AF125ADE24234; Tue, 28 Jul 2020 14:38:37 +0100 (IST)
Received: from fraeml711-chm.china.huawei.com (10.206.15.60) by lhreml714-chm.china.huawei.com (10.201.108.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 28 Jul 2020 14:38:36 +0100
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 28 Jul 2020 15:38:36 +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.1913.007; Tue, 28 Jul 2020 15:38:36 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: "Lubashev, Igor" <ilubashe@akamai.com>, "6man@ietf.org" <6man@ietf.org>
CC: "draft-ietf-6man-ipv6-alt-mark@ietf.org" <draft-ietf-6man-ipv6-alt-mark@ietf.org>
Subject: comment on draft-ietf-6man-ipv6-alt-mark
Thread-Topic: comment on draft-ietf-6man-ipv6-alt-mark
Thread-Index: AdZk1iyhoTPCqSsHTDGNVLCAAJZMgA==
Date: Tue, 28 Jul 2020 13:38:36 +0000
Message-ID: <f01e140dff464dd39132874a4cfe24e4@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.222.83]
Content-Type: multipart/alternative; boundary="_000_f01e140dff464dd39132874a4cfe24e4huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/we7fcLd48rX1OvR165USft3OkvM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 13:38:43 -0000

Dear Igor, All,
Thanks for your comment during the 6MAN session of today.
This is just to share with 6MAN WG my reply and our offline discussion after the presentation.
I know your draft: https://tools.ietf.org/html/draft-ferrieuxhamchaoui-tsvwg-lossbits-02

Firstly, it is worth highlighting that the scope of draft-ietf-6man-ipv6-alt-mark is very simple: it applies RFC8321 (and draft-ietf-ippm-multipoint-alt-mark) to IPv6 data plane in order to provide an OAM performance measurement tool to enable network level monitoring (like RFC6374 for MPLS or Y.1731 for Ethernet and so on). This is to cover an OAM requirement since IPv6 lacks of a passive/hybrid performance measurement method.

The proposal in your draft (draft-ferrieuxhamchaoui-tsvwg-lossbits-02) is interesting but it aims to cover a different scenario since it is applicable to an encrypted client-server protocol such as QUIC or TCP. I'm also working on a similar problem (draft-cfb-ippm-spinbit-measurements). Anyway these methodologies are applicable to Client-Server protocol at transport level on top of the network level and the flow under monitoring is managed by the higher-level protocol.
So the main difference is that draft-ferrieuxhamchaoui-tsvwg-lossbits is applicable to QUIC/TCP while draft-ietf-6man-ipv6-alt-mark is dedicated to IPv6.

In summary, the two methodologies are used separately since each layer needs its own OAM tools but they can also be used in combination to get richer information related to the lower/higher-layer protocol.

I think we may evaluate to add some considerations on that in a future version of our draft.

Regards,

Giuseppe