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

[[e-mail]]

Hi Frank,






Please see inline my comments with <XM2>.





Thanks,


Xiao Min



原始邮件



发件人：FrankBrockners(fbrockne)
收件人：肖敏10093570;
抄送人：[e-mail];tpauly=[e-mail];[e-mail];
日 期 ：2020年11月18日 00:36
主 题 ：RE: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state




Hi Xiao Min,


 


Please see inline… (“..FB”)


 




From: ippm <[e-mail]> On Behalf Of [e-mail]
Sent: Dienstag, 17. November 2020 08:31
To: fbrockne=[e-mail]
Cc: [e-mail]; tpauly=[e-mail]; [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]);



抄送人：IPPM Chairs;



日期：2020年11月16日
 15:13



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




_______________________________________________
ippm mailing list
[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.

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

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

<XM2> If I understand it correctly, you prefer to use Netconf/Yang, rather than Echo Request/Reply, to resolve the problem raised in this draft. If that's the case, then at least we converge on the problem raised in this draft. When Netconf/Yang is used here, I see several issues. Firstly, each IOAM encapsulating node (including the host when it takes the role of an IOAM encapsulating node) needs to implement a Netconf Client, which is not easy in my view. Secondly, each IOAM encapsulating node needs to establish netconf connection with each IOAM transit node and IOAM decapsulating node, the scalability can be an issue. Thirdly, Netconf/Yang is designed for communication between the NMS and the NE, if it's used for communication between NEs, just for capabilities discovery, then most of its functions are redundant.


 


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


<XM2> I'm not sure I'm wrong or you're missing something, I believe in this draft we do provide references of ICMPv6 RFCs to support TLV-like extension objects. To my understanding, ICMPv6 supports new TLV definition, of course, IOAM Capabilities are a bit different with the currently defined ones, but I don't think it's an abnormal one.

Cheers, Frank


 


Thanks, Frank


 




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

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