Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

xiao.min2@zte.com.cn Tue, 17 November 2020 07:52 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 C5F1F3A1196; Mon, 16 Nov 2020 23:52:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 KEBriOh5kowM; Mon, 16 Nov 2020 23:52:24 -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 52A6F3A119B; Mon, 16 Nov 2020 23:52:24 -0800 (PST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 570877A4C2634EF4F0D0; Tue, 17 Nov 2020 15:52:22 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl1.zte.com.cn with SMTP id 0AH7qB3j071143; Tue, 17 Nov 2020 15:52:11 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid201; Tue, 17 Nov 2020 15:52:11 +0800 (CST)
Date: Tue, 17 Nov 2020 15:52:11 +0800 (CST)
X-Zmail-TransId: 2afc5fb3812b562fe095
X-Mailer: Zmail v1.0
Message-ID: <202011171552114583186@zte.com.cn>
In-Reply-To: <C7C2E1C43D652C4E9E49FE7517C236CB02CBD214@dggeml529-mbx.china.huawei.com>
References: 5E408E0E-862E-480B-88FD-890098340EBC@apple.com, BYAPR11MB25847ACE60112CE82761253CDAE30@BYAPR11MB2584.namprd11.prod.outlook.com, C7C2E1C43D652C4E9E49FE7517C236CB02CBD214@dggeml529-mbx.china.huawei.com
Mime-Version: 1.0
From: <xiao.min2@zte.com.cn>
To: <c.l@huawei.com>
Cc: <fbrockne=40cisco.com@dmarc.ietf.org>, <tpauly=40apple.com@dmarc.ietf.org>, <ippm@ietf.org>, <ippm-chairs@ietf.org>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 0AH7qB3j071143
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/43gAaynj82O5ske3eLc9hXBsYec>
Subject: Re: [ippm] =?utf-8?q?Call_for_adoption=3A_draft-xiao-ippm-ioam-conf-?= =?utf-8?q?state?=
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: Tue, 17 Nov 2020 07:52:27 -0000

Hello Cheng,






I noticed that Frank has submitted an In-situ OAM deployment draft within OPSAWG, in section 3 of that draft it says:



"

IOAM is a network domain specific feature, with "network domain"
 being a set of network devices or entities within a single
 administration. IOAM is not targeted for a deployment on the global
 Internet. The part of the network which employs IOAM is referred to
 as the "IOAM-Domain".
"



To my understanding, the IOAM data is collected only within a trusted domain, of course, Frank can correct me if I'm wrong.



For your convenience, the link for this quoted draft is provided as below.


https://tools.ietf.org/html/draft-brockners-opsawg-ioam-deployment 






Best Regards,


Xiao Min



原始邮件



发件人:Chengli(ChengLi)
收件人:Frank Brockners (fbrockne);Tommy Pauly;IETF IPPM WG (ippm@ietf.org);
抄送人:IPPM Chairs;
日 期 :2020年11月16日 17:28
主 题 :Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state


_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm



I have one simple question like I mentioned in the meeting: Is it secure to discover the non-routing capabilities info from the data plane?


 


For instance, a packet may travel several network domains, and the trusted scope is only within each domain. When we use ICMP Ping, we can get the non-routing info from other domains. Is it OK to do it?  I think
 we should consider more about security and privacy.


 


Furthermore, can we collect the IOAM data in multiple domain scenarios? Or only within a trusted domain?


 


Thanks,


Cheng


 


 


 


 


 


 


 



From: ippm [mailto:ippm-bounces@ietf.org] On Behalf OfFrank Brockners (fbrockne)
Sent: Monday, November 16, 2020 3:13 PM
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>rg>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
Cc: IPPM Chairs <ippm-chairs@ietf.org>
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state




 


Hello IPPM,


 


per what I mentioned during the IPPM WG meeting today, I don’t think we should adopt the document before we have a couple of key questions resolved:


 


* Why can’t we use Netconf/YANG (with the existing capabilities discovery process – a la RFC 6241) to retrieve the IOAM capabilities of IOAM nodes? E.g. the encapsulating node (as a NC client) could retrieve the IOAM capabilities from other
 IOAM nodes  (acting as a NC server). Plus there is already a YANG model in flight for IOAM (draft-zhou-ippm-ioam-yang-08). At a minimum I would have expected that the draft discusses why NC/YANG is not suitable for the scenario that the authors have in mind.
 The slides (https://datatracker.ietf.org/meeting/109/materials/slides-109-ippm-echo-requestreply-for-enabled-ioam-capabilities-00)
 that were presented in the IPPM WG meeting today, mention “Changed from “IOAM Configuration Data” to “Enabled IOAM Capabilities” since the former is too associated with NETCONF/YANG.” IMHO we need a bit more than just wordsmithing.


 


* While the draft uses IOAM capabilities discovery as the use-case, in more general terms, it proposes to add management/ops capabilities to echo-request/reply protocols like ICMP, which is a much broader topic. The TLV structures which
 are proposed to be added to echo-requests and echo-replies could obviously be leveraged for other use-cases. Does the work really fit the scope of the IPPM WG?


 


Thanks, Frank


 




From: ippm <ippm-bounces@ietf.org>On Behalf Of Tommy Pauly
Sent: Freitag, 30. Oktober 2020 19:46
To: IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
Cc: IPPM Chairs <ippm-chairs@ietf.org>
Subject: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state




 


Hello IPPM,




This email starts a Working Group call for adoption for draft-xiao-ippm-ioam-conf-state. This document has been presented several times and discussed within the working group in the context of our overall IOAM work.

The document can be found here:

https://tools.ietf.org/html/draft-xiao-ippm-ioam-conf-state-07

Please provide your feedback on these document, and state whether or not you believe the IPPM WG should adopt this work by replying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, November 16.

Best,
Tommy & Ian