Re: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang

Tianran Zhou <zhoutianran@huawei.com> Thu, 19 November 2020 05:06 UTC

Return-Path: <zhoutianran@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 14E9B3A0D05; Wed, 18 Nov 2020 21:06:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 xXQZlAHM49pM; Wed, 18 Nov 2020 21:06:52 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C073A0D02; Wed, 18 Nov 2020 21:06:52 -0800 (PST)
Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Cc70B1qq8z67DTh; Thu, 19 Nov 2020 13:04:58 +0800 (CST)
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 19 Nov 2020 06:06:50 +0100
Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 19 Nov 2020 13:06:48 +0800
Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Thu, 19 Nov 2020 13:06:48 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>
CC: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, IPPM Chairs <ippm-chairs@ietf.org>, "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>
Thread-Topic: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang
Thread-Index: AQHWruxHXkttMybmSkWN4dSd7Dk7lanEEcWAgAYPvACAAYb6gIADW8PQ
Date: Thu, 19 Nov 2020 05:06:47 +0000
Message-ID: <c07a61d071ec4eada1622db6dc3d3834@huawei.com>
References: <43DADFB5-FE8A-49A1-BF39-1ECC10594211@apple.com> <CAB75xn4NP8T_P-icT1qz+Nvxra6f2of8zZew1Ymvgzr2Hjb1Kg@mail.gmail.com> <1ea39389889347bfb0e16fea668a9f59@huawei.com> <CAB75xn6X+SDeNNVcUOR_NyNQuhbDaz-wC_w-p-DHFJts+hW1Aw@mail.gmail.com>
In-Reply-To: <CAB75xn6X+SDeNNVcUOR_NyNQuhbDaz-wC_w-p-DHFJts+hW1Aw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.128]
Content-Type: multipart/alternative; boundary="_000_c07a61d071ec4eada1622db6dc3d3834huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/-Y37agAyV6Kpbu-UbrL7R1VJMRc>
Subject: Re: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
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, 19 Nov 2020 05:06:54 -0000

Hi Dhruv,

Indeed, I cannot give you the use case when the pre-allocated tracing and incremental tracing option present at the same time.
I think the IOAM data draft should be clear about this.
On the other hand, whether the management interface should be so strict?
Maybe here we can be somehow flexible, so that some use case comes out.

Best,
Tianran

From: Dhruv Dhody [mailto:dhruv.ietf@gmail.com]
Sent: Tuesday, November 17, 2020 5:44 PM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>; IPPM Chairs <ippm-chairs@ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
Subject: Re: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang

Hi Tianran,

<snip>

- Currently all 5 profiles can be configured at the same time in a single ioam-profile (as each of them have a separate container of their own). Is that intentional?
ZTR> Yes, we want to allow a packet to apply different IOAM at the same time.


[Dhruv]: That is true for some combinations, but it may not be the case for others.
What would be the YANG best practice here - to me adding a must condition in the YANG makes sense, something like when Incremental Tracing Option is enabled, we check that the Pre-allocated Tracing Option is not already enabled (provided you agree that they should not be enabled at the same time)?

Thanks,
Dhruv