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

"Chengli (Cheng Li)" <c.l@huawei.com> Wed, 18 November 2020 08:56 UTC

Return-Path: <c.l@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 6869F3A16B6; Wed, 18 Nov 2020 00:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 dl35BnjKIbq9; Wed, 18 Nov 2020 00:56:09 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D3F3A16B1; Wed, 18 Nov 2020 00:56:09 -0800 (PST)
Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Cbc7S24ptz67Dfp; Wed, 18 Nov 2020 16:54:28 +0800 (CST)
Received: from fraeml795-chm.china.huawei.com (10.206.15.16) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 18 Nov 2020 09:56:02 +0100
Received: from fraeml795-chm.china.huawei.com (10.206.15.16) by fraeml795-chm.china.huawei.com (10.206.15.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 18 Nov 2020 09:56:01 +0100
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by fraeml795-chm.china.huawei.com (10.206.15.16) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 18 Nov 2020 09:56:01 +0100
Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.220]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Wed, 18 Nov 2020 16:55:57 +0800
From: "Chengli (Cheng Li)" <c.l@huawei.com>
To: "xiao.min2@zte.com.cn" <xiao.min2@zte.com.cn>
CC: "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "fbrockne=40cisco.com@dmarc.ietf.org" <fbrockne=40cisco.com@dmarc.ietf.org>, "tpauly=40apple.com@dmarc.ietf.org" <tpauly=40apple.com@dmarc.ietf.org>
Thread-Topic: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state
Thread-Index: AQHWvLkTkAn5jFR/UE+awxVQkZJh3KnMFSgwgADsJgCAAJKtMA==
Date: Wed, 18 Nov 2020 08:55:56 +0000
Message-ID: <C7C2E1C43D652C4E9E49FE7517C236CB02CBFDF2@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, 202011171552114583186@zte.com.cn, C7C2E1C43D652C4E9E49FE7517C236CB02CBE91A@dggeml529-mbx.china.huawei.com, C7C2E1C43D652C4E9E49FE7517C236CB02CBEA49@dggeml529-mbx.china.huawei.com <202011181557167521943@zte.com.cn>
In-Reply-To: <202011181557167521943@zte.com.cn>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.130]
Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB02CBFDF2dggeml529mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/u-ukPZ7dRhdGsot0YeUeIbk8CJU>
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-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: Wed, 18 Nov 2020 08:56:12 -0000

Hi Min,

Thanks for your reply.

Simple example, Domain A is an IOAM domain, Domain B is another IOAM domain. Logically, the IOAM capabilities info of nodes in domain B MUST NOT be leaked out side the domain, therefore, the node 1 in domain A should not get the info of nodes in domain B.

In your solution, I guess we can use the ICMPv6 to request the capabilities info within the IOAM domain or outside the domain, if I understand it correctly.
Nothing to stop anyone to get the IOAM capability info of any node from any corner in the world. Right?

The solution of preventing information leaking needs to be considered. That is my concern.

IGP/BGP/BGP-LS solution may have other issues like you mentioned, but they can be controlled within the trusted domain.
Also, I see many capabilities are advertised via these protocols.  But this is another topic.

Best,
Cheng


From: xiao.min2@zte.com.cn [mailto:xiao.min2@zte.com.cn]
Sent: Wednesday, November 18, 2020 3:57 PM
To: Chengli (Cheng Li) <c.l@huawei.com>
Cc: Chengli (Cheng Li) <c.l@huawei.com>om>; ippm-chairs@ietf.org; ippm@ietf.org; fbrockne=40cisco.com@dmarc.ietf.org; tpauly=40apple.com@dmarc.ietf.org
Subject: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state


Hi Cheng,



I don't really understand your concern.

ICMPv6 is a mature protocol mechanism, and IOAM function is limited in a trusted domain, then using ICMPv6 to discover IOAM capabilities wouldn't introduce any big challenge on security and privacy.

I don't think IGP is better than ICMPv6 in this case. Firstly, flooding IOAM capabilities throughout the IGP domain is too heavy and unnecessary in my view. Secondly, IGP domain and IOAM domain don't always have the same coverage, one example is that when the IOAM encapsulating node is a host IGP flooding doesn't work for it.



Best Regards,

Xiao Min
原始邮件
发件人:Chengli(ChengLi)
收件人:Chengli (Cheng Li);肖敏10093570;
抄送人:ippm-chairs@ietf.org;ippm@ietf.org;fbrockne=40cisco.com@dmarc.ietf.org;tpauly=40apple.com@dmarc.ietf.org<mailto:ippm-chairs@ietf.org;ippm@ietf.org;fbrockne=40cisco.com@dmarc.ietf.org;tpauly=40apple.com@dmarc.ietf.org>;
日 期 :2020年11月17日 17:53
主 题 :RE: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state
I meantI don’t think we can detect the (Non Routing ) capabilities of a node in another domain. Sorry for the typo.

From: ippm [mailto:ippm-bounces@ietf.org]On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, November 17, 2020 4:09 PM
To: xiao.min2@zte.com.cn<mailto:xiao.min2@zte.com.cn>
Cc: ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>; ippm@ietf.org<mailto:ippm@ietf.org>; fbrockne=40cisco.com@dmarc.ietf.org<mailto:fbrockne=40cisco.com@dmarc.ietf.org>; tpauly=40apple.com@dmarc.ietf.org<mailto:tpauly=40apple.com@dmarc.ietf.org>
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Min,

That is also my understanding. IOAM is limited in a trusted domain.

But ICMP can be used in the global Internet? I don’t think we can detect the capabilities of a node in another node. Privacy and security will be a big challenge.

So personally I prefer IGP/BGP/BGP-LS or NETCONF/YANG way.

Thanks,
Cheng



From:xiao.min2@zte.com.cn<mailto:xiao.min2@zte.com.cn> [mailto:xiao.min2@zte.com.cn]
Sent: Tuesday, November 17, 2020 3:52 PM
To: Chengli (Cheng Li) <c.l@huawei.com<mailto:c.l@huawei.com>>
Cc: fbrockne=40cisco.com@dmarc.ietf.org<mailto:fbrockne=40cisco.com@dmarc.ietf.org>;tpauly=40apple.com@dmarc.ietf.org<mailto:tpauly=40apple.com@dmarc.ietf.org>;ippm@ietf.org<mailto:ippm@ietf.org>; ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>
Subject: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state


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<mailto: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<mailto: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<mailto:tpauly=40apple.com@dmarc.ietf.org>>; IETF IPPM WG (ippm@ietf.org<mailto:ippm@ietf.org>) <ippm@ietf.org<mailto:ippm@ietf.org>>
Cc: IPPM Chairs <ippm-chairs@ietf.org<mailto: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<mailto:ippm-bounces@ietf.org>>On Behalf OfTommy Pauly
Sent: Freitag, 30. Oktober 2020 19:46
To: IETF IPPM WG (ippm@ietf.org<mailto:ippm@ietf.org>) <ippm@ietf.org<mailto:ippm@ietf.org>>
Cc: IPPM Chairs <ippm-chairs@ietf.org<mailto: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<https://tools.ietf.org/html/draft-zhou-ippm-ioam-yang-08>

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