Re: [ippm] Quick comment on draft-ietf-ippm-ioam-data-11

xiao.min2@zte.com.cn Thu, 07 January 2021 03:34 UTC

Return-Path: <xiao.min2@zte.com.cn>
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 E1E303A14AA for <ippm@ietfa.amsl.com>; Wed, 6 Jan 2021 19:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 r5HUDG77Yv2q for <ippm@ietfa.amsl.com>; Wed, 6 Jan 2021 19:33:59 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 C52CE3A14A8 for <ippm@ietf.org>; Wed, 6 Jan 2021 19:33:58 -0800 (PST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id D3A5EBBF2CBB4486F783; Thu, 7 Jan 2021 11:33:56 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl1.zte.com.cn with SMTP id 1073XhQJ051271; Thu, 7 Jan 2021 11:33:43 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid201; Thu, 7 Jan 2021 11:33:43 +0800 (CST)
Date: Thu, 07 Jan 2021 11:33:43 +0800
X-Zmail-TransId: 2afc5ff68117c943f56b
X-Mailer: Zmail v1.0
Message-ID: <202101071133436017787@zte.com.cn>
In-Reply-To: <BYAPR11MB2584DC77FF0225466C424804DAD00@BYAPR11MB2584.namprd11.prod.outlook.com>
References: 202101051034258505599@zte.com.cn, BYAPR11MB2584DC77FF0225466C424804DAD00@BYAPR11MB2584.namprd11.prod.outlook.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: fbrockne@cisco.com
Cc: ippm@ietf.org, shwetha.bhandari@gmail.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 1073XhQJ051271
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/J3OQvx8JkAhgGATNU6mJ8AThscc>
Subject: Re: [ippm] Quick comment on draft-ietf-ippm-ioam-data-11
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, 07 Jan 2021 03:34:01 -0000

Hi Frank and Shwetha,

Thank you for the clear explanation.
Considering the IOAM-Data draft is the IOAM base document referenced by many other drafts, it would be nice if you can add some text to explain it, otherwise I suspect that the question shall be brought up again sometime.

Best Regards,
Xiao Min









原始邮件



发件人:FrankBrockners(fbrockne)
收件人:肖敏10093570;ippm@ietf.org;
抄送人:shwetha.bhandari@gmail.com;
日 期 :2021年01月07日 01:14
主 题 :RE: [ippm] Quick comment on draft-ietf-ippm-ioam-data-11






Hi Xiao Min,


 


the 7-bit wide registry for IOAM-Option-Types is because some protocols, like e.g. Geneve, only offer room for 7 bits.
 See https://tools.ietf.org/html/draft-brockners-ippm-ioam-geneve-05#section-3
 “   Type:  8-bit field defining the IOAM Option type, as defined in


      Section 7.2 of [I-D.ietf-ippm-ioam-data].  The 'C' bit MUST be set


      to zero.”


 


This requirement drove the change from 8 to 7 bits – back in March 2018, see:


https://github.com/inband-oam/ietf/commit/22b33b12863fa62dd80d47a00b859bce82b69e60
 “IOAM-Type code point reduced from 256 -> 128 to handle encaps like Geneve where top bit in type reserved.”


(Thanks to Shwetha for digging up the reference).


 


Cheers, Frank


 




From: ippm <ippm-bounces@ietf.org> On Behalf Of xiao.min2@zte.com.cn
 Sent: Dienstag, 5. Januar 2021 03:34
 To: ippm@ietf.org
 Subject: [ippm] Quick comment on draft-ietf-ippm-ioam-data-11




 

Hi authors,
 
 While updating "IOAM over BIER" draft, I noticed that in Section 8.1 of IOAM-Data draft 128 code points are defined for IOAM Option-Type Registry, nevertheless in whether draft-ietf-ippm-ioam-ipv6-options or draft-ietf-sfc-ioam-nsh, IOAM Type is an 8-bit field, could 256 code points instead of 128 code points be defined?
 
 Best Regards,
 Xiao Min