Hi Joe and WG chairs, We have updated the draft and uploaded the v07. https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/ I’m writing to request a presentation slot in the upcoming IETF WG session.
In this version, we explicitly assert that any specific component and interface implementations are out of the scope of this draft. In this draft, we dedicate on listing all the challenges on deploying data plane on-path telemetry techniques, providing a high level architectural framework with a few key components to address those challenges, providing several examples on what can be done for each component, and finally, laying out the potential to support closed-loop telemetry applications based on this framework. To clarify the discussion, we also include a taxonomy of the data plane on-path telemetry techniques and define the terms used in this draft. We think the content covered already makes contribution to the community and the industry, which will inspire not only innovative implementations but also new standard works that actually specify the interfaces. Many of our operator customers appreciated that we summarize the deployment challenges in carrier networks and point out the possible solution directions. Thanks for the consideration. Best regards, Haoyu From: Joe Clarke (jclarke) <[email protected]> Sent: Thursday, October 24, 2019 3:21 PM To: Haoyu Song <[email protected]> Cc: [email protected]; [email protected] Subject: Re: Call for Adoption "draft-song-opsawg-ifit-framework" On Oct 23, 2019, at 05:42, Haoyu Song <[email protected]<mailto:[email protected]>> 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
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
