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

[wangyali <[e-mail]>]

Hi Frank,

I agree with you that NC/YANG is an alternate way to retrieve the IOAM decapsulation capability.
And from the side of IGP/BGP, we also proposed extensions to IGP/BGP for IOAM/Alternate Marking transit node/decapsulation node capability in https://tools.ietf.org/html/draft-wang-lsr-igp-extensions-ifit-01 and https://tools.ietf.org/html/draft-wang-idr-bgp-ifit-capabilities-01 .

Please see the details of proposed extensions for IOAM transit/decapsulating node capability for two scenarios with and without the centralized controller in line [Yali].

Any questions and comments are welcome.

Best,
Yali

From: ippm [mailto:[e-mail]] On Behalf Of Frank Brockners (fbrockne)
Sent: Wednesday, November 18, 2020 12:36 AM
To: [e-mail]
Cc: [e-mail]; tpauly=[e-mail]; [e-mail]
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Xiao Min,

Please see inline… (“..FB”)

From: ippm <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Dienstag, 17. November 2020 08:31
To: fbrockne=[e-mail]<mailto:fbrockne=[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; tpauly=[e-mail]<mailto:tpauly=[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: 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 ([e-mail]<mailto:[e-mail]>);
抄送人：IPPM Chairs;
日 期 ：2020年11月16日 15:13
主 题 ：Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state
_______________________________________________
ippm mailing list
[e-mail]<mailto:[e-mail]>
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.
 [Yali] For this scenario having a centralized controller, since BGP-LS defines a way to advertise topology and associated attributes and capabilities of the nodes in that topology to a centralized controller [RFC7752]. And typically, BGP-LS is configured on a small number of nodes that do not necessarily act as head-ends. Thus, in order for BGP-LS to signal IFIT node capabilities for all the IOAM transit node, the IOAM transit node capability should be advertised by every IGP router in the network. Therefore, draft https://tools.ietf.org/html/draft-wang-lsr-igp-extensions-ifit-01 extends Node and Link Attribute TLVs to IGP.

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

[Yali] For this scenario without centralized controller and only considering the requirement that the IOAM encapsulation node query the IOAM decapsulation node capability, draft https://tools.ietf.org/html/draft-wang-idr-bgp-ifit-capabilities-01 proposes two methods to extend to BGP, i.e., Option 1 is extension to BGP Extended Community and Option 2 is extension to BGP Next-Hop Capability.

…FB: Hmm – I still don’t follow what the use-case you have in mind would be. Most routers already implement a Netconf server. Any node can take the role of a Netconf client – as you note yourself above. And with the YANG model for IOAM becoming finalized, we have all the ingredients already available. Plus Netconf is built as a protocol for management operations – thus you also have the security part figured out if you use NC/Y (see the related discussion on the IPPM mailer). Why would anyone spend the effort to reimplement everything that is available with NC/Y into e.g. ICMPv6?
* 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.
…FB: IMHO there are no real circular dependencies: Your approach requires that ICMPv6 would be able to carry TLVs in echo request and reply messages. Once that capability would be there, you could use those TLVs to carry the particular IOAM capability data. This means you’d need to evolve ICMPv6 first. If and only if TLVs would already exist in ICMPv6 echo request/reply messages, then one could assume that you’d specify code-points for specific types (like the “Type = IOAM Capabilities” that you have in your draft), so that it would be worthwhile to focus on defining data types etc. So IMHO you’re really taking the second step before the first one.

Cheers, Frank

Thanks, Frank

From: ippm <[e-mail]<mailto:[e-mail]>> On Behalf Of Tommy Pauly
Sent: Freitag, 30. Oktober 2020 19:46
To: IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Cc: IPPM Chairs <[e-mail]<mailto:[e-mail]>>
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