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

Hi Frank,
many thank for your comments at the mike and the continued discussion on
the list.
I would point to RFC 4884 that defined Multi-part message as the mechanism
to extend ICMP functionality. To this day several RFCs that use that
mechanism equipped ICMP with capabilities to respond with various objects,
e.g., MPLS Label stack, a piece of interface information that includes its
IP address, name, and MTU. So, I think that the proposed mechanism to
extend ICMP for IAOM capability discovery is in line with RFC 4884.

Regards,
Greg

On Sun, Nov 15, 2020 at 11:12 PM Frank Brockners (fbrockne) <fbrockne=
40cisco.com@dmarc.ietf.org> wrote:

> 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> *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
> <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
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>