Sorry, forgot to CC the WG. ________________________________ 发件人: Haoyu Song <[email protected]> 发送时间: 2019年11月18日星期一 下午3:05 收件人: Frank Brockners (fbrockne) 主题: Re: Call for Adoption "draft-song-opsawg-ifit-framework"
Hi Frank, We have updated the draft which clarified our scope and defined the terms used. l'm Woking on a new revision and l'm thinking to add a reference to your latest "ioam deployment" draft because I think it's a good example on how such a system can be deployed by showing the existing and ongoing related works. But I'd like to point out that, compared to the ioam deployment draft, our draft is a high level framework which covers not only ioam but also the other data plane telemetry techniques. So far ioam is the most mature one (thanks to your hard working) and I believe the related work (e.g., encapsulation and export) listed in your draft are also helpful to inspire the future standard work as suggested by ifit framework. But such works are still not complete and they are largely missing for the other underlying techniques. Our goal is consider dataplane telemetry system as a whole and find standard gaps not limited to any specific underlying technique. The PoC and proprietary solutions we have right now also abide to the standard proposals to the best. Unfortunately, the whole field is still at its early stage and the standard ecosystem is not complete yet. That's exactly one reason we need this draft: to help people understand the high level architecture and identify what are missing. Next, we will also work on open source solutions based on standard and standard proposals. Please let us know if you have any other questions. Thanks! Best regards, Haoyu ________________________________ 发件人: Frank Brockners (fbrockne) <[email protected]> 发送时间: 2019年10月27日星期日 下午7:20 收件人: Haoyu Song; Joe Clarke (jclarke) 抄送: [email protected]; [email protected] 主题: RE: Call for Adoption "draft-song-opsawg-ifit-framework" Hi Haoyu, Thanks. Per what I said below, neither do I understand what the document tries to solve nor do I understand the scope of the document. The document introduces specific functions like iFIT nodes and iFIT applications but does not specify those. Fengwei Qin described that those indeed refer to a specific proprietary solution (i.e. draft-cheng-mpls-inband-pm-encapsulation): Is it this one https://www.huawei.com/en/press-events/news/2019/6/first-ifit-pilot-5g-transport-network-beijing-unicom-huawei<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.huawei.com%2Fen%2Fpress-events%2Fnews%2F2019%2F6%2Ffirst-ifit-pilot-5g-transport-network-beijing-unicom-huawei&data=02%7C01%7Chaoyu.song%40futurewei.com%7C64e6623973044759dea608d75acfa3ce%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637077720210393363&sdata=7Pe%2FoxzkB8BLKy%2B3A4liJy5tATDBoBkxg1EJcana5tU%3D&reserved=0>? Thanks, Frank From: Haoyu Song <[email protected]> Sent: Freitag, 25. Oktober 2019 20:25 To: Frank Brockners (fbrockne) <[email protected]>; Joe Clarke (jclarke) <[email protected]> Cc: [email protected]; [email protected] Subject: RE: Call for Adoption "draft-song-opsawg-ifit-framework" Hi Frank, The document specifically lists some issues and challenges when deploying the data plane on path telemetry techniques. Do you have any question on them and do you think anything is missing? Also, I don’t agree that we have a very specific implementation in mind. Actually, we just discuss a very loose framework about it but we think a reasonable application would somehow follow such an architecture from high level. Do you find any unrealistic part or too specific part about this framework? Do think any specific topic should also be discussed in this draft? We appreciate any feedbacks at this level of details which will help us substantially. Thanks for pointing out some terms that we haven’t clearly defined. We’ll fix that in the next revision. Best, Haoyu From: Frank Brockners (fbrockne) <[email protected]<mailto:[email protected]>> Sent: Thursday, October 24, 2019 9:42 AM To: Haoyu Song <[email protected]<mailto:[email protected]>>; Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: Call for Adoption "draft-song-opsawg-ifit-framework" Just took a read through the document as well �C and I can echo Joe’s comments. The scope of the document is not clear, nor does one understand what problem iFIT would address and solve. That said, the document seems to have a very specific implementation in mind, as it refers to specific things such “iFIT Applications”, “iFIT Nodes”, etc. �C but none of things are defined in the document. Cheers, Frank From: OPSAWG <[email protected]<mailto:[email protected]>> On Behalf Of Haoyu Song Sent: Mittwoch, 23. Oktober 2019 11:43 To: Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [OPSAWG] Call for Adoption "draft-song-opsawg-ifit-framework" 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) 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. 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. 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. Best regards, Haoyu From: Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>> Sent: Tuesday, October 22, 2019 3:48 PM To: Haoyu Song <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: Call for Adoption "draft-song-opsawg-ifit-framework" The comments below are from me as an individual contributor. I have read the latest revision of this document. I still do not have a clear idea of what it is solving, TBH. It doesn’t define a new protocol, yet it makes claims about an architecture that implies a protocol between devices, a controller, and applications (see the figure in section 2). In Section 3.2, iFIT is referenced as having an ability to cache or send accumulated data. I don’t see how a framework can do this. Nor do I see how a framework can dynamically load new data probes as mentioned in Section 3.3. If this were a controller with an application architecture and specifications for component interoperability, perhaps, but I do not see that in this document. In Section4, the document mentions a closed-loop for iFIT applications whereby applications can manage iFIT closed loops on top of a controller. But again, I don’t see how. Do the applications make API calls? What calls do they make? What makes it an “iFIT closed loop”? Ultimately, the summary says that iFIT combines algorithmic and architectural schemes into the framework, but I don’t see where that is done in a specific, implementable way (e.g., in Section 3.1.2 you begin to describe how you can adaptively sample packets, but you talk about abstract signals to/from the controller). Nor do I see how one would implement iFIT. When I read the iFIT draft, I feel like I’m missing a normative chunk that explains how the various pieces of this framework are to interact in a well-specified manner. It seems to me that perhaps a more useful document is one that focus on the implementation of PBT and/or IOAM, operational experiences, best practices, etc. Joe On Oct 21, 2019, at 14:34, Haoyu Song <[email protected]<mailto:[email protected]>> wrote: Dear OPSAWG chairs, The following draft has been extensively discussed and gone through six revisions. Network operators confirmed it is useful. We believe the draft is mature enough to be adopted by the WG therefore we request the chairs to initiate the adoption call for this draft. Thank you very much for the consideration! https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-framework%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7C64e6623973044759dea608d75acfa3ce%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637077720210403357&sdata=y4puDBWLmprFSM0twoTN1tlZH7StxZq2er44taptPLw%3D&reserved=0> Best regards, Haoyu
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
