Re: [ippm] In-situ OAM Data Type Extension

Tianran Zhou <zhoutianran@huawei.com> Wed, 25 September 2019 07:09 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 4B39A120100 for <ippm@ietfa.amsl.com>; Wed, 25 Sep 2019 00:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 EVNCmvloUxZu for <ippm@ietfa.amsl.com>; Wed, 25 Sep 2019 00:09:42 -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 D95981200FF for <ippm@ietf.org>; Wed, 25 Sep 2019 00:09:41 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1EE18A84B253B0038BB5 for <ippm@ietf.org>; Wed, 25 Sep 2019 08:09:40 +0100 (IST)
Received: from lhreml711-chm.china.huawei.com (10.201.108.62) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 25 Sep 2019 08:09:39 +0100
Received: from lhreml711-chm.china.huawei.com (10.201.108.62) by lhreml711-chm.china.huawei.com (10.201.108.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 25 Sep 2019 08:09:39 +0100
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml711-chm.china.huawei.com (10.201.108.62) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Wed, 25 Sep 2019 08:09:39 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0439.000; Wed, 25 Sep 2019 15:09:33 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>, Tom Herbert <tom@quantonium.net>
CC: "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: In-situ OAM Data Type Extension
Thread-Index: AdVzZ7Gfd6262M0xTaqtGX5AFwofPAABP3ewAAA7zyA=
Date: Wed, 25 Sep 2019 07:09:32 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F21BEFDFF08@NKGEML515-MBX.china.huawei.com>
References: <BBA82579FD347748BEADC4C445EA0F21BEFDFEDC@NKGEML515-MBX.china.huawei.com> <BYAPR11MB2584E9BB58F9B6736B526C5BDA870@BYAPR11MB2584.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB2584E9BB58F9B6736B526C5BDA870@BYAPR11MB2584.namprd11.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.156.116]
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/tFVKe0Bok8M0R3wmre3Z0QyIV0k>
Subject: Re: [ippm] In-situ OAM Data Type Extension
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: Wed, 25 Sep 2019 07:09:44 -0000

Hi Frank,

OK. 
IMHO, since you have ready reserved that bit for potential extension, why not define it?
The data type could be namespace specific. The IETF namespace now does not use up the bits, but other namespace may need to extend.

Tianran


> -----Original Message-----
> From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com]
> Sent: Wednesday, September 25, 2019 2:47 PM
> To: Tianran Zhou <zhoutianran@huawei.com>; Tom Herbert <tom@quantonium.net>
> Cc: ippm@ietf.org
> Subject: RE: In-situ OAM Data Type Extension
> 
> Hi Tianran,
> 
> Like what you state below: Per Tom's suggestion a reserved bit to ensure future
> extensibility was added in the most recent rev, i.e.
> draft-ietf-ippm-ioam-data-07.
> We can define the use of the bit and potential extension once we're in need
> of extending. For now we still have plenty of spare bits.
> 
> Regards, Frank
> 
> > -----Original Message-----
> > From: Tianran Zhou <zhoutianran@huawei.com>
> > Sent: Mittwoch, 25. September 2019 08:36
> > To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Tom Herbert
> > <tom@quantonium.net>
> > Cc: ippm@ietf.org
> > Subject: In-situ OAM Data Type Extension
> >
> > Hi Frank,
> >
> > I am revisiting the mailing list. And I am interesting about Tom's
> > discussion on IOAM Data Type Extension.
> > https://mailarchive.ietf.org/arch/msg/ippm/cp0E8-D0XbgTBy_3Bf6E21z00EA
> >
> > You had the following reply:
> > "* 24 bits Trace type
> > Per your suggestion, reserving a bit to allow for future scalability
> > makes sense - and bit 23 would be an obvious choice; which would in
> > turn mean that we'd need to assign a different bit for checksum
> > complement. If everyone else is fine with this change, we can include this
> change in -07."
> >
> > We also had a draft to address the same issue.
> > https://tools.ietf.org/html/draft-song-ippm-ioam-data-extension-01
> >
> > I see the latest draft-ietf-ippm-ioam-data-07 reserved the bit 23. Are
> > you going to define the usage of that bit or not?
> > Defer it to other draft or next version?
> >
> > Regards,
> > Tianran