Hi Huanan, I’ve made proposed changes to address each of your comments (see below). Please take a look and let me know what you think.
Thanks! Haoyu From: Haoyu Song Sent: Monday, September 16, 2019 10:49 AM To: [email protected]; opsawg <[email protected]> Cc: draft-song-opsawg-ifit-framework <[email protected]> Subject: RE: [OPSAWG] Comments to draft-song-opsawg-ifit-framework-04 Hi Huanan, Thanks for the suggestion! I’ll make corresponding enhancements in the next revision. See more comments inline. Best regards, Haoyu From: OPSAWG <[email protected]<mailto:[email protected]>> On Behalf Of [email protected]<mailto:[email protected]> Sent: Sunday, September 15, 2019 7:22 PM To: opsawg <[email protected]<mailto:[email protected]>> Cc: draft-song-opsawg-ifit-framework <[email protected]<mailto:[email protected]>> Subject: [OPSAWG] Comments to draft-song-opsawg-ifit-framework-04 Hi Haoyu, I think this work is useful that can help operators to understand the IFIT capabilities and choose among different technologies for the deployment. It’s invaluable for application-aware network operations. Some thoughts after going through the document. 1. I fail to see the whole picture of the IFIT framework with Figure 1. You listed several functional components in section 2. But I cannot see where they sit in the figure and how they interact to accomplish a close loop. So my suggestion is to revise figure 1 with more information. [HS] It’s challenging to put too much information in a txt based figure. Probably I’ll add another figure to show how the components work together. [HS2] I add a new figure and some description to show how the components work together to form a closed loop. +---------------------+ | | +------+ iFIT Applications |<------+ | | | | | +---------------------+ | | Technique Selection | | and Integration | | | |Smart Flow Smart | |and Data closed-loop Data | |Selection Export| | | | +----+----+ V +---------+| +----------+ Encapsulation +---------+|| | iFIT | and Tunneling | iFIT ||| | Head |----------------------->| ||+ | Node | | Nodes |+ +----------+ +---------+ DNP DNP An iFIT application would pick a suite of telemetry techniques based on its requirements and apply an initial technique to the data plane. It then configures the iFIT head nodes to decide the initial target flows/packets and telemetry data set, the encapsulation and tunneling scheme based on the underlying network architecture, and the iFIT- capable nodes to decide the initial telemetry data export policy. Based on the network condition and the analysis results of the telemetry data, the iFIT application can change the telemetry technique, the flow/data selection policy, and the data export approach in realtime without breaking the normal network operation. Many of such dynamic changes can be done through loading and unloading DNPs. 2. In section 2, overview, you mentioned two basic on-path telemetry data collection modes, i.e., passport and postcard. I did not see more details but one definition. It would be really useful for the operators to understand the pros and cons, and when to use which. So that it can guide the operators to choose the right solution in their network. So maybe one section on this is welcome. [HS] Some of comparisons have been discussed in other drafts, but it’s a good idea to cover it here. [HS2] 2.1. Passport vs. Postcard [passport-postcard] first uses the analogy of passport and postcard to describe how the packet trace data can be collected and exported. In the passport mode, each node on the path adds the telemetry data to the user packets. The accumulated data trace is exported at a configured end node. In the postcard mode, each node directly exports the telemetry data using an independent packet while the user packets are intact. A prominent advantage of the passport mode is that it naturally retains the telemetry data correlation along the entire path. The passport mode also reduces the number of data export packets and the bandwidth consumed by the data export packets. These can help to make the data collector and analyzer's work easier. On the other hand, the passport mode requires more processing on the user packets and increases the size of user packets, which can cause various problems. Some other issues are documented in [I-D.song-ippm-postcard-based-telemetry]. The postcard mode provides a perfect complement to the passport mode. It addresses most of the issues faced by the passport mode, at a cost of needing extra efforts to correlate the postcard packets. [passport-postcard] Handigol, N., Heller, B., Jeyakumar, V., Mazieres, D., and N. McKeown, "Where is the debugger for my software-defined network?", 2012, <https://doi.org/10.1145/2342441.2342453>. 3. I can smell that the C2 challenge is critical, and the export data reduction should be useful. But I do not have a direct feeling on the impact to the network. That is to say, I cannot evaluate if I can accept the amount of data export in my network or not from the existing text. It would be valuable if you can give a simple evaluation with numbers somewhere in the document, maybe section 4. [HS] We did have some evaluations. We can include such information into the documents if it’s valuable to operators. [HS2] I added some rough estimation. If we get more tangible data in future, we will add it. C2: On-path flow telemetry can generate a huge amount of OAM data which may claim too much transport bandwidth and inundate the servers for data collection, storage, and analysis. Increasing the data handling capacity is technically viable but expensive. For example, assume IOAM is applied to all the traffic. One node will collect a few tens of bytes as telemetry data for each packets. The whole forwarding path might accumulate a data trace with a size similar to the average size of the original packets. Exporting the telemetry data will consume almost half of the network bandwidth. Cheers. ________________________________ HUANAN CHEN（陈华南） Data Communication Research Department Guangdong Research Institute of China Telecom Co.,Ltd. Tel：020-3863-9346 PH：133-1609-7163 QQ：17335837 Mail：[email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]>
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
