IETF Logo Mail Archive

[ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00

<xiao.min2@zte.com.cn> Mon, 18 November 2019 05:18 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 9DFD412085E for <ippm@ietfa.amsl.com>; Sun, 17 Nov 2019 21:18:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 tb0f5lBs_QXz for <ippm@ietfa.amsl.com>; Sun, 17 Nov 2019 21:18:27 -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 B820B120837 for <ippm@ietf.org>; Sun, 17 Nov 2019 21:18:26 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id 6D7BCFEFFBC24BDAF6E9 for <ippm@ietf.org>; Mon, 18 Nov 2019 13:18:23 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 619EE4B41F7CB214555E for <ippm@ietf.org>; Mon, 18 Nov 2019 13:18:23 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl2.zte.com.cn with SMTP id xAI5I8JV073818 for <ippm@ietf.org>; Mon, 18 Nov 2019 13:18:08 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Mon, 18 Nov 2019 13:18:08 +0800 (CST)
Date: Mon, 18 Nov 2019 13:18:08 +0800
X-Zmail-TransId: 2afa5dd22990e1af7d5f
X-Mailer: Zmail v1.0
Message-ID: <201911181318081812271@zte.com.cn>
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: ippm@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn xAI5I8JV073818
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/AlEAbk0zd2nJFxrZ63aXiaZ3rRs>
Subject: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00
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: Mon, 18 Nov 2019 05:18:28 -0000

Hi Frank,




Repeat what I said on the mic this morning as below.




In section 3 of draft-ietf-ippm-ioam-ipv6-options-00 it says:

"Unless a particular interface is explicitly enabled (i.e. explicitly
   configured) for IOAM, a router MUST drop packets which contain extension headers carrying IOAM data-fields."

But in section 4.4 of draft-ietf-ippm-ioam-data-08 it says:

"If not all nodes within a domain are IOAM capable, IOAM tracing information (i.e., node data, see below) will only be collected on those nodes which are IOAM capable.  Nodes which are not IOAM capable will forward the packet without any changes to the IOAM-Data-Fields."

It seems they're not in alignment.




Best Regards,

Xiao Min

v2.23.0 | Report a Bug | By Email