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

Hello Frank,

Please see inline my response tagged with <XM>.

Best Regards,

Xiao Min

原始邮件

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

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

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:

<XM> Considering you're the key proponent of In-situ OAM, I believe your concerns if any must be addressed, and that's why I had a face to face discussion with you on -01 version of this draft about two years ago. I thought I've convinced you of the intention of this draft, by some major updates, however it seems it's still not that case, hope we can converge through the on-list discussion.

* 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.

<XM> Although it's a little bit unusual to compare Echo Request/Reply with Netconf/Yang, I'd like to share my thoughts with you and seek your understanding. In my mind, there are several different methods for the IOAM encapsulating node to know the enabled IOAM capabilities of the IOAM transit nodes/decapsulating node as follows.

* In the deployment scenario there is a centralized Controller/NMS, the IOAM transit nodes/decapsulating node can report their enabled IOAM capabilities directly to the centralized Controller/NMS, and then the IOAM encapsulating node can get these capabilites via configuration by the centralized Controller/NMS, or by means of querying the centralized Controller/NMS for these capabilities. In this scenario, Netconf/Yang is not the only candidate, PCEP or BGP can also be used here.

* In the deployment scenario there is no centralized Controller/NMS, the IOAM encapsulating node can query the IOAM transit nodes/decapsulating node for their enabled IOAM capabilities. In this draft in question, Echo Request/Reply is proposed as the query mechanism because it's a native on-path traceroute method. In this scenario, I agree as you mentioned that Netconf/Yang can also be used, actually PCEP or BGP can be used too. Nevertheless, whether Netconf/Yang, PCEP or BGP are not native on-path traceroute method, further considering that the IOAM encapsulating node can be a host too, so using Netconf/Yang, PCEP or BGP as the IOAM capabilities discovery mechanism is not proposed in this draft.

* 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?

<XM> During this presentation, I've asked for guidance from the IPPM WG chairs on this question. My personal suggestion is to separate the IOAM capabilities definition and the extensions on ICMPv6, LSP-Ping and SFC-Ping, just like to separate IOAM-Data from IOAM-over-IPv6, IOAM-over-NSH, IOAM-over-MPLS, because it's possible to fall into egg-chicken loops if we bind them together. After rough consensus is reached on the IOAM capabilities definition in IPPM WG, respective proposals can be brought up in the WGs that are in charge of ICMPv6, LSP-Ping and SFC-Ping, and if the WGs are not interested to take up these IOAM related protocol extensions, which can be pushed back to the IPPM WG with their authorizations.

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