Re: [OPSAWG] Call for Adoption "draft-song-opsawg-ifit-framework"

["Joe Clarke (jclarke)" <[e-mail]>]

On Oct 23, 2019, at 05:42, Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:

Hi Joe,

Thank you for the detailed comments!

Let me try to explain the purpose of this draft better. Given the recent on-path data plane telemetry techniques and standard works, in this draft we discuss the deployment challenges and potential opportunities for applications. There is no such a document in IETF AFAIK and we feel it’s needed (also confirmed by some network operators who are interested in such techniques)

Tianran and I emailed on the chairs list, and I agree a deployment guide would be beneficial that shares practical experiences, operator considerations, and best practices.  However, the iFIT document does not read that way.  It reads more like a very specific architecture that is not fully fleshed out.  It leaves one (well, it leaves me) guessing as to what iFIT really is and how can I really be compliant to it.  What do I _really implement_ in this?


Most related standard proposals so far only defines the data plane protocol and lack considerations for a complete solution. To this end, we discuss various points that a solution should pay attention to and how these can be composed to support applications. Along with the discussion, we provide some examples and use cases to trigger new ideas.

I haven’t participated in IPPM, so I can’t comment.  But in general, yes, having at least deployment considerations for things like IOAM and PBT would benefit operators.

Your comment about applications is one area where I find iFIT nebulous, though.  I don’t get a clear picture from the draft as to what an iFIT application is, and thus if I read this as a guide to help me implement, say, IOAM end-to-end, I’m still left wondering about specific things I may want to do in terms of where to export, what type of IOAM tracing to use, and what pitfalls to be aware of.

That said, you do cover things like a need for sampling as well as impact to devices.  Those are helpful but incomplete.  I’d love to get a more detailed understanding as to the impact I could expect from using IOAM and operating on packets versus the overhead incurred by something like PBT which still entails on-box processing.


We deliberately make iFIT an open framework and avoid introducing any new protocol and enforcing any specific approaches, because otherwise we are in danger to put unnecessary constraints on implementation approaches and hurt the possibility of innovation. While we mean to keep this document informational, we may consider to add more discussions on reference designs, operational experiences,  and best practices as you suggested.

It is this latter thing which I think is needed more.


Some points you raised below also deserves more detailed explanation, such as how to make an iFIT closed loop and how architecture and algorithm components can be composed to form such a loop. Perhaps a complete example can help to explain that. I’ll consider all this in future revisions.

In a sense, this document indeed aims to discuss the implementation, operational experiences, and best practices  of PBT, IOAM, and other similar techniques. We hope this document will trigger new drafts on management plane/control plane and innovative solutions.

Ultimately, I think what I’m saying is that it sounds like today we need a guide on practical deployment considerations around various OAM solutions, but we don’t yet need a noun to call such a thing.  I’d like to see such a document as I think it would be very useful outside opsawg and very useful to operators globally.

Joe