Subject: [OPSAWG] Comments to draft-song-opsawg-ifit-framework-04

From: "[email-masked]" <[email-masked]>
Date: Mon, 16 Sep 2019 10:21:35 +0800

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.
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.
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.
 
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-masked]
   [email-masked]

---

From: Haoyu Song <[email-masked]>
Date: Mon, 16 Sep 2019 17:48:31 +0000

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-masked]> On Behalf Of [email-masked]
Sent: Sunday, September 15, 2019 7:22 PM
To: opsawg <[email-masked]>
Cc: draft-song-opsawg-ifit-framework <[email-masked]>
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.

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.

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.

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-masked]<mailto:[email-masked]>
   [email-masked]<mailto:[email-masked]>

---

From: Haoyu Song <[email-masked]>
Date: Wed, 18 Sep 2019 18:16:44 +0000

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-masked]; opsawg <[email-masked]>
Cc: draft-song-opsawg-ifit-framework <[email-masked]>
Subject: RE: [OPSAWG] Comments to draft-song-opsawg-ifit-framework-04

Hi Huanan,

Best regards,
Haoyu

From: OPSAWG <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Sunday, September 15, 2019 7:22 PM
To: opsawg <[email-masked]<mailto:[email-masked]>>
Cc: draft-song-opsawg-ifit-framework <[email-masked]<mailto:[email-masked]>>
Subject: [OPSAWG] Comments to draft-song-opsawg-ifit-framework-04

Hi Haoyu,

[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.

[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>.

[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.

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 19 Sep 2019 09:22:07 +0800

Hi Haoyu,

Thank you very much for replying. The enhancements are good for my team to udnerstand the ifit.
1.It will clear to add the new figure to the draft, then we would get the key point together.
2.Passport and postcard mode comparement is useful for us to list device requirements, and choose suitable mode for differant service.
3.It is helpful for us to depoly ifit, then we will do some bandwidth reservation for ifit.

Best regards,
Huanan Chen

From: Haoyu Song
Date: 2019-09-19 02:16
To: [email-masked]; opsawg
CC: draft-song-opsawg-ifit-framework
Subject: RE: [OPSAWG] Comments to draft-song-opsawg-ifit-framework-04
Hi Huanan,

Thanks!
 
Haoyu
 
From: Haoyu Song 
 
Hi Huanan,

Best regards,
Haoyu

Hi Haoyu,

 
                           +---------------------+
                           |                     |
 
   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.

 
[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>.

 
      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（陈华南）