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

[[e-mail]]

Hello Mach,






I understand your concern, it's valid, so I've asked for guidance from the IPPM WG chairs during my presentation.


Furthermore, I've provided my personal suggestion when replied to Frank, hope it's acceptable to you.






Best Regards,


Xiao Min



原始邮件



发件人：MachChen
收件人：Frank Brockners (fbrockne);Tommy Pauly;IETF IPPM WG ([e-mail]);
抄送人：IPPM Chairs;
日 期 ：2020年11月16日 15:51
主 题 ：Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state


_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm



Hi all,


 


As mentioned on the mic, I shared the similar concern on the second point. Given the draft is going to define extensions to ICMP, MPLS echo/Request, IMHO those parts should be defined
 in those relevant WGs (e.g, 6man, MPLS WG), at least those WGs should be involved in this discussion.


 


Best regards,


Mach


 




From: ippm [mailto:[e-mail]]On Behalf Of Frank Brockners (fbrockne)
Sent: Monday, November 16, 2020 3:13 PM
To: Tommy Pauly <tpauly=[e-mail]>; IETF IPPM WG ([e-mail]) <[e-mail]>
Cc: IPPM Chairs <[e-mail]>
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 <[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