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

<xiao.min2@zte.com.cn> Wed, 20 November 2019 02:39 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 4CFEC1201EF for <ippm@ietfa.amsl.com>; Tue, 19 Nov 2019 18:39:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 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, 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 uLVhJoGqlZqp for <ippm@ietfa.amsl.com>; Tue, 19 Nov 2019 18:39:23 -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 B43D81201E0 for <ippm@ietf.org>; Tue, 19 Nov 2019 18:39:22 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id B7C25403909209895335 for <ippm@ietf.org>; Wed, 20 Nov 2019 10:39:15 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 90BD1C6D96530F613E99; Wed, 20 Nov 2019 10:39:15 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl2.zte.com.cn with SMTP id xAK2d0P3093132; Wed, 20 Nov 2019 10:39:00 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Wed, 20 Nov 2019 10:38:56 +0800 (CST)
Date: Wed, 20 Nov 2019 10:38:56 +0800
X-Zmail-TransId: 2afa5dd4a7406bbecd13
X-Mailer: Zmail v1.0
Message-ID: <201911201038562696122@zte.com.cn>
In-Reply-To: <BYAPR11MB2584C26544D5CC6DEE766FC7DA4C0@BYAPR11MB2584.namprd11.prod.outlook.com>
References: 201911181318081812271@zte.com.cn, BYAPR11MB2584C26544D5CC6DEE766FC7DA4C0@BYAPR11MB2584.namprd11.prod.outlook.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: fbrockne@cisco.com
Cc: ippm@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn xAK2d0P3093132
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/dh-LALyOFquBbb6Y-l2rLOOdjYc>
Subject: Re: [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: Wed, 20 Nov 2019 02:39:27 -0000

Hi Frank,






Now I understand the intention behind the text, you might need to rephrase the text, when it says "a router MUST drop packets..." it really means "an IOAM capable router MUST drop packets...".


BTW, I didn't see it as a bug from the beginning, I just raised it as an inconsistency between the two drafts for you to clarify.






Best Regards,


Xiao Min



原始邮件



发件人:FrankBrockners(fbrockne) <fbrockne@cisco.com>
收件人:肖敏10093570;ippm@ietf.org <ippm@ietf.org>;
日 期 :2019年11月19日 11:47
主 题 :RE: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00




Hi Xiao,


 


thanks for following up. Apparently the behavior described in draft-ietf-ippm-ioam-ipv6-options-00 isn’t a bug – as we speculated in the IPPM WG meeting yesterday, but the desired behavior that we arrived at after WG discussions in 6man
 and with several IPv6 experts.  See https://github.com/inband-oam/ietf/commit/48175cf89de6369a4d01017ec80c07b34f57f17c#diff-803b63dbe26303f504708318e255d884 (“Don't forward an IOAM packet unless configured to do so.”)


This behavior for IPv6 is to ensure that packets with IOAM do not accidentally leak from a domain that employs IPv6.


This also means for IPv6, things are more constrained than what is stated in the more generic draft-ietf-ippm-ioam-data-08.


 


Cheers, Frank


 


 


 




From: ippm <ippm-bounces@ietf.org> On Behalf Of xiao.min2@zte.com.cn
Sent: Montag, 18. November 2019 13:18
To: ippm@ietf.org
Subject: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00




 

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