Re: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Haoyu,

Thanks for the update version.  I've looked at the latest version that you have published, and it doesn't change my fundamental view or previous comments on this document.

This document is focussed on a new different variant of on-path telemetry.  On-path telemetry is being working on in the IPPM WG, which is where this document would receive the necessary reviews to be able to progress.  This document needs to be taken there - it is not currently in charter for OPSAWG.

I cannot see how this work can progress without having discussions in IPPM first.

Regards,
Rob


-----Original Message-----
From: Haoyu Song <[e-mail]> 
Sent: 23 February 2022 01:27
To: Rob Wilton (rwilton) <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

Hi Rob,

Thank you for the comments and questions. We just uploaded an update version of the draft based on the latest review comments. https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/17/

We'd like to emphasize that this is  an architecture not a protocol solution. In fact, it pulls together the many existing and proposed protocol solutions to show how they fit together. The document itself doesn't propose any new techniques or protocols.  This is a kind of "cook book" to show why IETF solutions are important as part of a whole. Very often OAM solutions are developed in isolation without a big picture. In this sense, it's akin to the NTF document and we believe it fits in OPSAWG for the same reason NTF was adopted.

But certainly IFIT does not repeat NTF.  NTF is a very high-level architectural view covering all of the issues and aspects of telemetry. In contrast, IFIT "zooms in" to look just at the on-path telemetry tools in the category of forwarding-plane telemetry. These are the "new" telemetry tools in the IETF and are not so widely understood. Many are still in development and some are getting some focus. Moreover,  IFIT covers many data-plane specific issues and challenges that weren't discussed in NTF. For these reasons, we believe the framework is useful to help network operators and developers to understand and apply this relatively new branch of telemetry techniques.  

In the past two years, the document has evolved a lot with a clearer scope and architecture now. We ask the OPSAWG chairs and OPS ADs to review the latest version of the document again and consider to adopt it. We would continue to carefully address the issues raised by the colleagues.  

Thank you very much!

Best regards,
Haoyu

-----Original Message-----
From: Rob Wilton (rwilton) <[e-mail]> 
Sent: Monday, February 21, 2022 11:07 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

Hi Adrian, authors, WG,

Warren, Martin Duke, and I looked at this document almost 2 years back, noted that the work that it is describing seemed to be close to work chartered in IPPM WG, and hence recommended to the authors, via Tianran, that this work should be presented to IPPM to see if there is interest on working on any protocols or protocol changes related to the framework.  Authors, do you know if that has happened?  And if so, what was the feedback reviewed from IPPM please?

If IPPM doesn't want to take up this work, or doesn't think that it falls within their charter, and if the authors are still interested then I would encourage the proponents to consider doing side meetings or a BOF on the solution to see if they can build is wider interest for standardizing it within the IETF.

Finally, when reading this document, I find the document content to be very abstract, and I struggle to get to the meat of what it is actually describing or defining beyond what is already described in the NTF draft related to general telemetry and full lifecycle monitoring.  As it stands, I struggle to see how this document fits into the OPSAWG charter.  It may be that standardizing some of the concrete protocol parts first, or in parallel to the framework document may end up with a more widely applicable standard.

Thanks,
Rob


-----Original Message-----
From: OPSAWG <[e-mail]> On Behalf Of Adrian Farrel
Sent: 19 February 2022 15:55
To: [e-mail]
Cc: [e-mail]
Subject: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

Hi,

I reviewed -09 of this draft at the time of the inconclusive adoption poll back in December 2019. A lot of changes have been made since then, including updates for my previous comments.

As the document appears to be somewhat stalled, I asked the chairs what they thought the status was, and they said that the work is not shut down, but they noted that the mailing list has been very quiet on the subject. This is possibly because we're all waiting to find out what happens next.

Anyway, as a way of showing my continued interest in this document, I have reviewed the current revision (-16). I hope these comments prove useful to the authors.

I have shown my edits and comments in line with the document, attached.
While there are a lot of comments, I don't think any of these couldn't have been worked on for a working group draft. But let's continue the work with this draft and get it into a better shape.

One comment here rather than in the document: You talk about adding in-situ OAM to IPv4 encapsulations. I can, of course, see the benefit of this for operators carrying IPv4 traffic. But I wonder how that runs into the IETF's policy with regard to extending IPv4. Certainly your reference to draft-herbert-ipv4-eh is a bit dubious given how that work appears to have been abandoned. Of course, encapsulations under the IPv4 header are a totally different thing.

Best,
Adrian