[OPSAWG] new draft on dynamic network probes for interactive query

[Haoyu song]

Dear all,

We have submitted a draft describing the use case and requirements for dynamic 
network probes. Please kindly provide any comments and suggestions to help us 
improve the work. Thank you very much!

https://datatracker.ietf.org/doc/draft-song-opsawg-dnp4iq/

Abstract: This document discusses the motivation and requirements for
   supporting interactive network queries and data collection through a
   mechanism called Dynamic Network Probes (DNP).  Network applications
   and OAM have various data requirements from the data plane.  The
   unpredictable and interactive nature of the query for network data
   analytics asks for dynamic and on-demand data collection
   capabilities.  As user programmable and configurable data plane is
   becoming a reality, it can be extended to support interactive query
   through DNPs.  DNP supports node, path, and flow-based data
   preprocessing and collection.  For example, in-situ OAM (iOAM) with
   user-defined flow-based data collection can be programmed and
   configured through DNP.  DNPs serve as a building block of an
   integrated network data telemetry and analytics platform which
   involves the network data plane as an active component for user-
   defined data collection and preparation.

Haoyu
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] FW: New Version Notification for draft-song-ntf-02.txt

[Haoyu song]

Hi Folks,

We uploaded a new version of the network telemetry framework draft.
This version reflects the joint contribution from several new coauthors.
In specific, we make clear distinction between conventional OAM and telemetry. 
We update the related works. We add one more module (external data source) in 
the framework.
We welcome your review, comments, and suggestions to continue improve this 
document. 

Thanks!

Haoyu

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, July 02, 2018 11:03 AM
To: Laurent Ciavaglia ; Zhenqiang Li 
; Giuseppe Fioccola 
; Lizhenbin ; Haoyu 
song ; Laurent Ciavaglia ; 
Tianran Zhou ; Aijun Wang ; 
Pedro Martinez-Julia 
Subject: New Version Notification for draft-song-ntf-02.txt


A new version of I-D, draft-song-ntf-02.txt has been successfully submitted by 
Haoyu Song and posted to the IETF repository.

Name:   draft-song-ntf
Revision:   02
Title:  Toward a Network Telemetry Framework
Document date:  2018-07-02
Group:  Individual Submission
Pages:  24
URL:https://www.ietf.org/internet-drafts/draft-song-ntf-02.txt
Status: https://datatracker.ietf.org/doc/draft-song-ntf/
Htmlized:   https://tools.ietf.org/html/draft-song-ntf-02
Htmlized:   https://datatracker.ietf.org/doc/html/draft-song-ntf
Diff:   https://www.ietf.org/rfcdiff?url2=draft-song-ntf-02

Abstract:
   This document suggests the necessity of an architectural framework
   for network telemetry in order to meet the current and future network
   operation requirements.  The defining characteristics of network
   telemetry shows a clear distinction from the conventional network OAM
   concept; hence the network telemetry demands new techniques and
   protocols.  This document clarifies the terminologies and classifies
   the categories and components of a network telemetry framework.  The
   requirements, challenges, existing solutions, and future directions
   are discussed for each category.  The network telemetry framework and
   the taxonomy help to set a common ground for the collection of
   related works and put future technique and standard developments into
   perspective.



  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Haoyu song]

Hi Randy,

Thank you for comments on draft-song-ntf.
I'm not sure I understand your second point. Could you please clarify it?
Please note we didn't enforce any specific model on the telemetry yet. This doc 
only concerns the aspect on how to acquire data from networks. It does support 
the dynamic and interactive configuration for data acquirement. But control is 
out of scope of this document, although we confirm that telemetry plus control 
complete the closed control loop. Maybe I misunderstood your point.
Thanks!

Haoyu

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Randy Bush
Sent: Saturday, July 07, 2018 8:25 PM
To: Lizhenbin 
Cc: l...@ietf.org; GMO Crops ; opsawg@ietf.org; rt...@ietf.org
Subject: Re: [OPSAWG] [GROW] [Lsr] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

robin,

i am not ignoring you.  i did not want to write unless i had something possibly 
useful to say; and that requires pretending to think, always difficult.

> I would also like to propose following draft for your reference which 
> trigger us to move forward for better network maintenance with 
> multiple tools in which gRPC/NETCOF and NMP/BMP may play different
> roles: https://datatracker.ietf.org/doc/draft-song-ntf/

[ warning: my memory is likely fuzzy, and the glass is dark ]

at an ietf in the late '90s[0], there was a hastily called meeting of the snmp 
standards bearers and a bunch of operators.  the snmp folk were shocked to 
learn that no operators used snmp for other than monitoring; no one had snmp 
write enabled on devices; ops configured with the cli[1].  from this was born 
netconf and the xml path.  credit where due:
phil eng was already well down this path at the time of that meeting.

but netconf/xml was a mechanism and lacked a model.  snmp had models, whether 
we thought they were pretty or not.  thus yang was born, and , of course, a new 
generation wants to use the latest modern toys such as restconf, openconfig, 
json, ...

draft-song-ntf yearns for an "architectural framework for network telemetry," a 
lofty and worthwhile goal not, a priori, a bad one.  but a few comments from a 
jaded old dog.

for a new paradigm to gain traction, it must be *significantly* better than the 
old one, or the old paradigm must be clearly failing.  in the story above, snmp 
was clearly failing, aside from using an unfashionable encoding.  and yang 
clearly provided something needed and missing from netconf.  note that this 
paradigm shift has taken over 20 years; and we dis the itu et alia.

second, draft-song-ntf is an export-only model.  while telemetry is extremely 
important, i will be very frustrated if i can only hear and may not speak.  and 
the more it evolves to a really attractive paradigm and model, the more annoyed 
i will be that i can not use it for control.

and lastly, to quote don knuth, "premature optimization is the root of all 
evil."  do not get distracted by squeezing bits out of an encoding.
focus on things such as simple, clear, securable, extensible ...

randy

---

0 - i would love help pinning down which meeting

1 - i still have the "it's the cli, stupid" tee shirt.  an american
political slogan of the era was "it's the economy, stupid."

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] request a presentation slot

[Haoyu song]

Dear OPSAWG chairs,

I'm writing to request a slot to present the updates of the following document. 
Thank you very much!
https://tools.ietf.org/html/draft-song-ntf-02

Best regards,

Haoyu

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] network telemetry framework

[Haoyu song]

Hi Joe,

Thanks for the comment!
Yes it's clear our first step would be to set up the common taxonomy in this 
area and help people to understand the status quo as well as the technical 
gaps. 

We do believe there are something unique to IBN/IDN in terms of the network 
telemetry. We have heard people expressed the desire to 
1) normalize the data collection means
2) be able to interactively refine the data collection
3) be able to collect customized data on the on-demand basis
4) be able to directly collect data from the data plane forwarding path

Some existing work shows the potentials to meet some of the requirements, but I 
feel we are still far from that.
So I think this document at least can partially serve the purpose to clear the 
path.  

We welcome collaborations on this topic because we believe this work needs the 
contributions from the entire community.

Best,
Haoyu 

-Original Message-
From: Joe Clarke [mailto:jcla...@cisco.com] 
Sent: Monday, April 02, 2018 11:52 AM
To: Haoyu song <haoyu.s...@huawei.com>; opsawg <opsawg@ietf.org>
Subject: Re: [OPSAWG] network telemetry framework

On 3/21/18 04:01, Haoyu song wrote:
> Dear all,
> 
>  
> 
> The WG presentation triggered a lot warm discussions on this topic.
> 
> While we agree that at present it's too aggressive to try to unify the 
> telemetry protocols, we feel it is needed to formalize the 
> terminologies and clarify the technique classifications from multiple 
> dimensions so to ensure we have a common language in addressing such 
> issues for the upcoming network architectures such intent driven network.

Thanks for continuing to work on this document, Haoyu.  The idea of a "common 
taxonomy" is a good one.  However, the current draft mentions a desire to 
"[integrate] multiple telemetry approaches" into a framework.
I think the comments stated in London were of the vein that given the amount of 
work involved (and the use cases and solutions that have been put forward thus 
far), this is a monumental undertaking.

As a contributor, perhaps there is something unique to the IBN/IDN
architecture(s) that need a well-defined, common framework to how telemetry is 
approached.  That would at least refine scope a bit more.

> 
>  
> 
> The latest version can be found at:
> 
> https://tools.ietf.org/html/draft-song-ntf-01
> 
> The document is still at its early stage. Please continue to provide 
> your comments and suggestions to scope it and contribute to it.

The -01 modifications do help with readability, and I do encourage others to 
read and comment.

Joe



> 
> Thank you very much!
> 
>  
> 
> Best regards,
> 
> Haoyu
> 
> 
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
> 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Asking for a slot

[Haoyu song]

Dear OPSAWG Chairs,
I’m writing to ask for a presentation slot for the draft of “Toward a Network 
Telemetry Framework” (https://datatracker.ietf.org/doc/draft-song-ntf/)
Thank you very much for the consideration!
Best regards,
Haoyu Song



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf

[Haoyu song]

Hi Uri,

Thanks for the comments. I'd like to clarify there's no black and white 
separation between conventional OAM and telemetry. Conventional OAM is also 
indispensable in many cases and some tools is also evolving to bear more 
characteristics of a typical telemetry system. I'll make the modification and 
clarification accordingly.

Haoyu

-Original Message-
From: Blumenthal, Uri - 0553 - MITLL [mailto:u...@ll.mit.edu] 
Sent: Wednesday, October 17, 2018 5:55 AM
To: adr...@olddog.co.uk
Cc: Tianran Zhou ; opsawg@ietf.org; 
draft-song-opsawg-...@ietf.org
Subject: Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf

SNMP is a management protocol, not a data transfer one. 

SNMP Trap is like a UDP message - send and forget.

SNMP Notify can require confirmation, so you can make sure it reaches it's 
destination (or know that it could not).

I rather disagree with the characterization "low data rate and high overhead" - 
compared to what, and by what criteria?

P.S. IMHO, SNMP Traps are perfect for telemetry.

Regards,
Uri

Sent from my iPhone

> On Oct 17, 2018, at 04:27, Adrian Farrel  wrote:
> 
> Hi Tianran,
> 
> Yes, I mean the "Trap" which is now called "Notification."
> 
> You're right in your assessment of the drawbacks, and you should add to that
> list the drawback of the low data rat and high overhead that come with the
> protocol.
> 
> I didn't mention the Notification to propose it as a mechanism for telemetry,
> but just so that your introductory text has a complete description of the
> pre-existing environment.
> 
> Best,
> Adrian
> 
>> -Original Message-
>> From: Tianran Zhou [mailto:zhoutian...@huawei.com]
>> Sent: 17 October 2018 04:09
>> To: adr...@olddog.co.uk; opsawg@ietf.org
>> Cc: draft-song-opsawg-...@ietf.org
>> Subject: RE: Thoughts on draft-song-opsawg-ntf
>> 
>> Hi Adrian,
>> 
>> Thank you very much for your careful review and comments.
>> 
>> On this discussion:
>> "In 1.4 you have
>>   Since SNMP is poll-based, it incurs
>>   low data rate and high processing overhead.
>> I don't think this is quite fair on SNMP. The protocol also includes
> Notifications
>> allowing information to be output by a device. Your main point about low data
>> rates and high overhead, still stand, but with a different slant."
>> 
>> Do you mean the SNMP trap, which is used for alarm and event?
>> I agree, it's push based notification with binary encoding. However,
>> 1. no easy CRUD operations
>> 2. no customizable periodical and on-change export. So have to use poll
>> operation.
>> 3. need special definition and support, not apply for any mib data.
>> 
>> Do you think the above are the SNMP defeat for telemetry use?
>> 
>> Or what your thoughts?
>> 
>> Thanks,
>> Tianran
>> 
>>> -Original Message-
>>> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
>>> Sent: Wednesday, October 17, 2018 3:40 AM
>>> To: opsawg@ietf.org
>>> Cc: draft-song-opsawg-...@ietf.org
>>> Subject: Thoughts on draft-song-opsawg-ntf
>>> 
>>> Hi authors and working group.
>>> 
>>> I just had cause to read this document and thought I would share my comments
>>> on the list.
>>> 
>>> The draft appears as -00, but it is a little more mature than that implies
>>> because it replaces draft-song-ntf-02.
>>> 
>>> I think a foundation document on telemetry would be useful for the IETF, and
>>> the OPSAWG may be a good place to discuss and progress that work.
>>> This document seems like a reasonable starting point for that work although
>>> there will inevitably need to be some additions and modifications. Actually,
>>> I found this document pretty complete.
>>> 
>>> My comments are a combination of substantive issues and nits.
>>> 
>>> Hope this helps.
>>> 
>>> Regards,
>>> Adrian
>>> 
>>> == Discussion points ==
>>> 
>>> In 1.4 you have
>>>   Since SNMP is poll-based, it incurs
>>>   low data rate and high processing overhead.
>>> I don't think this is quite fair on SNMP. The protocol also includes
>>> Notifications allowing information to be output by a device. Your main point
>>> about low data rates and high overhead, still stand, but with a different
>>> slant.
>>> 
>>> ---
>>> 
>>> Although you talk about IPFIX quite a bit later in the document, I think
> that,
>>> as part of the scene setting, you might include a paragraph about it early
>>> in 1.4.
>>> 
>>> ---
>>> 
>>> The text after Figure 1 did not completely convince me of the need for
>>> interaction between the three "telemetry planes". Perhaps you could expand
>>> the examples and discussion to highlight/clarify this?
>>> 
>>> ---
>>> 
>>> Clearly you are going to have to write some Security Considerations.
>>> There is quite a lot to say about what is a layered security model with
> plenty
>>> of attack vectors, and substantial risks as the telemetry data can result
>>> in operational changes that could harm data delivery and even bring the
>>> network down. Furthermore, examination of telemetry data can reveal
>>> weaknesses in the network.
>>> 
>>> 

Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf

[Haoyu song]

I don't think we are trying anything "re-inventing the wheel".
First, we didn't invent anything in this draft. Rather, we are providing an 
overview and summary of existing stuff.
Second, even SNMP notification can do data push, it is still insufficient. 
Google has deprecated SNMP for a reason. Many other companies hold the similar 
view.
Here are a few reasons: SNMP is for management plane, but we still need data 
directly from other planes, that's why we have IOAM and IPFIX. Also, SNMP can't 
support high bandwidth streaming, that's why we have gPRC.
Sure, SNMP can bear some characteristics of telemetry and it can also continue 
to evolve to be more like it. But as I said, there's nothing black or white and 
SNMP is not sufficient and we need many more things and we already have many 
good and better stuff.

Regards,
Haoyu  

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Blumenthal, Uri - 
0553 - MITLL
Sent: Thursday, October 18, 2018 12:20 PM
To: Randy Presuhn 
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf

I, as a reader, still wonder about re-inventing the wheel - even with the 1st 
paragraph of 1.4 untouched.

Regards,
Uri

Sent from my iPhone

> On Oct 18, 2018, at 14:12, Randy Presuhn  
> wrote:
> 
> Hi -
> 
>> On 10/18/2018 12:58 AM, Tianran Zhou wrote:
>> Well, the first paragraph in section 1.4 is neither clear nor necessary.
>> I would suggest to remove this paragraph. Is that OK for you?
> 
> The paragraph does seem clear, but is (in my opinion) incorrect.
> However, it appears to be an integral part of the rationale for doing 
> the proposed work.  Removing the paragraph would leave the reader 
> wondering "why re-invent the wheel?"
> 
> Randy
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] New version of Network Telemetry Framework

[Haoyu song]

Dear all,

We have uploaded a new version of the Network Telemetry Framework draft which 
reflects the modifications based on comments and suggestions from Adrian 
Farrel, Daniel King, Randy Presuhn, Uri Blumenthal and others.

https://datatracker.ietf.org/doc/draft-song-opsawg-ntf/

We add new reference to SNMP and indicate it is also evolving to support 
telemetry.
Compared to the version presented in IETF102, this version also includes a 
description of the evolution of the network telemetry system.
Please review the draft and provide any comments and suggestions. Thank you 
very much!

Haoyu
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Request for presentation slots in IETF103

[Haoyu song]

Dear OPSAWG chairs,

I'm writing to request two presentation slots to cover the following two drafts:


1.  Newly submitted: In-situ Flow Information Telemetry Framework
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/
   Abstract: In-situ Flow Information Telemetry (iFIT) is a framework for 
applying
   techniques such as In-situ OAM (iOAM) and Postcard-Based Telemetry
   (PBT) in networks.  It enumerates several key components and
   describes how these components can be assembled to achieve a complete
   working solution for user traffic telemetry in carrier networks.


2.  New version: Network Telemetry Framework
https://datatracker.ietf.org/doc/draft-song-ntf/

We'll address the comments and suggestions from reviewers and presentation we 
made
in this latest version.

Thank you very much for considerations!

Best regards,
Haoyu
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Request for presentation slots in IETF103

[Haoyu song]

Thanks Joe. 10 to 15 minutes each will be enough. I'll be the presenter.

As for the NTF draft, I don't recall there was general concern in 102 that this 
work may not be relevant to the IETF. If anybody think so, please be specific 
why. We have talked about the motivation in the draft and wish we can provide 
something useful to IETF, so we are open to hear any comments and opinions. 
Thanks!

Haoyu 

-Original Message-
From: Joe Clarke [mailto:jcla...@cisco.com] 
Sent: Monday, October 22, 2018 2:20 PM
To: Haoyu song ; opsawg-cha...@ietf.org
Cc: opsawg@ietf.org
Subject: Re: Request for presentation slots in IETF103

On 10/22/18 16:42, Haoyu song wrote:
> Dear OPSAWG chairs,
> 
>  
> 
> I'm writing to request two presentation slots to cover the following 
> two
> drafts:
> 
>  
> 
> 1.  Newly submitted: In-situ Flow Information Telemetry Framework
> 
> https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/
> 
>    Abstract: In-situ Flow Information Telemetry (iFIT) is a framework 
> for applying
> 
>    techniques such as In-situ OAM (iOAM) and Postcard-Based Telemetry
> 
>    (PBT) in networks.  It enumerates several key components and
> 
>    describes how these components can be assembled to achieve a 
> complete
> 
>    working solution for user traffic telemetry in carrier networks.
> 
>  
> 
> 2.  New version: Network Telemetry Framework
> 
> https://datatracker.ietf.org/doc/draft-song-ntf/
> 
>  
> 
> We'll address the comments and suggestions from reviewers and 
> presentation we made
> 
> in this latest version.
> 
>  
> 
> Thank you very much for considerations!

Good news.  The ADs have granted us some of the Ops Area time.  Given that, we 
can add timeslots for your drafts.  How much time will you need (max 15 minutes 
per draft)?  Who will present?  Will the presenter be in BKK?

Remember, we're looking for presentations that focus on open issues and 
questions for the WG.  Do not walk through the draft.  Pre-seed the WG with 
questions so that people can come prepared to contribute.

Specifically with NTF, there has been some comments on list of late (which is 
good), but there was general concern in 102 that this work may not be relevant 
to the IETF.  I would appreciate you addressing the relevance question.

Thanks.

Joe


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf

[Haoyu song]

Hi Adrian,

Thank you very much for the comments. I'll try to address all your comments in 
the new revisions. Given the time and bandwidth, I may leave some parts (e.g., 
security concern) to future revisions. 

Yes, gRPC is a recursive acronym and "g" doesn't mean google although we all 
know where it comes from ;)

Haoyu
-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: Tuesday, October 16, 2018 12:40 PM
To: opsawg@ietf.org
Cc: draft-song-opsawg-...@ietf.org
Subject: Thoughts on draft-song-opsawg-ntf

Hi authors and working group.

I just had cause to read this document and thought I would share my comments on 
the list.

The draft appears as -00, but it is a little more mature than that implies 
because it replaces draft-song-ntf-02.

I think a foundation document on telemetry would be useful for the IETF, and 
the OPSAWG may be a good place to discuss and progress that work. 
This document seems like a reasonable starting point for that work although 
there will inevitably need to be some additions and modifications. Actually, I 
found this document pretty complete.

My comments are a combination of substantive issues and nits.

Hope this helps.

Regards,
Adrian

== Discussion points ==

In 1.4 you have
   Since SNMP is poll-based, it incurs
   low data rate and high processing overhead.
I don't think this is quite fair on SNMP. The protocol also includes 
Notifications allowing information to be output by a device. Your main point 
about low data rates and high overhead, still stand, but with a different slant.

---

Although you talk about IPFIX quite a bit later in the document, I think that, 
as part of the scene setting, you might include a paragraph about it early in 
1.4.

---

The text after Figure 1 did not completely convince me of the need for 
interaction between the three "telemetry planes". Perhaps you could expand the 
examples and discussion to highlight/clarify this?

---

Clearly you are going to have to write some Security Considerations. 
There is quite a lot to say about what is a layered security model with plenty 
of attack vectors, and substantial risks as the telemetry data can result in 
operational changes that could harm data delivery and even bring the network 
down. Furthermore, examination of telemetry data can reveal weaknesses in the 
network.

== Nits ==

The authors will need to reduce the number of front page names to 5.
Move the others to a Contributors section. Might as well do this sooner rather 
than later.

---

Abstract

   This document suggests the necessity of an architectural framework
   for network telemetry in order to meet the current and future network
   operation requirements.

Suggest you change this a little because you actually provide the framework. 
How about...

   This document provides an architectural framework for network
   telemetry in order to meet the current and future network operation 
   requirements.

---

You need to write an Introduction section and present it as Section 1.
You don't need a lot of text: start with the Abstract and expand it a little.

---

The Requirements Language text should move to a new Section 1.1

---

You should expand the abbreviations on first use. I see:
AI
ARCA
ML
OAM
SDN

---

A couple of the terms in 1.3 are confusing.

> gNMI:  gPRC Network Management Interface
Should that be gRPC?

> gRPC:  gRPC Remote Procedure Call
This seems circular.

---

Not sure that RFC 1157 is the best reference for SNMP in section 1.4.
How about 3416?

---

Figure 3
Does gPRC mean gRPC?

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] EARLY CALL: Agenda topics for IETF 103

[Haoyu song]

Hi Joe,

I'd like to apply a presentation slot for the draft song-opsawg-ntf-01. In the 
talk, I'll presents the updates of the draft and address the issues raised 
during the email discussion. Thanks!

Best,
Haoyu

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Joe Clarke
Sent: Tuesday, September 11, 2018 10:06 AM
To: opsawg@ietf.org
Subject: [OPSAWG] EARLY CALL: Agenda topics for IETF 103

Hello, opsawg.  We have requested a meeting slot for IETF 103 in Bangkok.  Like 
previous meetings, we have requested a 2.5 hour meeting combining opsawg and 
Ops Area.

We'd like to get people to start thinking about presentation topics and to 
start working on their slides.

If you are thinking about proposing a presentation, keep in mind that your 
presentation should _NOT_ simply present your document section-by-section.  In 
fact, it shouldn't present your document section-by-section at all.

A good presentation will discuss the problem briefly, describe the solution, 
and then ask questions of the WG as to what is needed to proceed with the 
document.  That is, what areas do you need specific input?  Where might you 
need help to fully form a viable solution?  What additional considerations 
should WG be aware of?

In addition to proposing your presentation, email the list ahead of the meeting 
requesting a review of your document and seeding your questions so the WG can 
prepare good answers for you.

Remember, we want a discussion both in the room and on the list.

Finally, keep your time in mind.  Many slots are 10 minutes, which should 
likely have a max of four slides to allow for some discussion.

Presentations that simply go section-by-section through documents will not be 
accepted.

Please send requests for presentation slots to opsawg-cha...@ietf.org.
The final cut off for presentations will be October 31, 2018 to ensure the list 
has time to review documents.

Thanks.

Joe on behalf of the co-chairs

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] presentation on ifit framework draft

[Haoyu song]

Dear all,

As Joe suggested, I would like to request you to take a look at the following 
draft before the meeting so we can have some good discussion during the meeting.

https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/

Basically we want to address the challenges of data plane telemetry for carrier 
networks.

The questions we want to discuss are
l  What other challenges for carrier network data plane telemetry?
l  What other suggestions to make the framework more complete?

Or if you have any other question, please let us know.

Thank you very much!

Best regards,
Haoyu

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf

[Haoyu song]

Hi Juergen,

Thank you very much for your very detailed comments. Your feedback shows 
exactly we need to engage with the entire community to improve this document.

Your two questions are very good. Here's my high level response first:

a) Does the IETF need a network telemetry framework?

I strongly believe so. Given the facts that the telemetry is very active and 
important topic, the area is already crowded, yet many misunderstandings and 
confusions exist, 
we do need such an informational document. Many world largest operators and 
OTTs have shared the same opinion.  
In fact, the comments and opinions you provided exactly show that so many 
things about telemetry need to be clearly clarified and well defined.

b) Is this document a suitable starting point for such a framework?

This is a working document. We don't expect at this point every statement in 
this document is accurate and reaches consensus. 
Yet the document has gone through many revisions which absorbed all the 
comments and suggestions we gathered from several working group (including 
OPSAWG, RTGWG, and NMRG).
We agree there are still a lot of work to do (e.g., add new content, address 
inconsistencies, fix mistakes, clarify concepts, etc.) but at same time it has 
also laid out the foundation and major pieces of the framework.  
So I believe this is qualified as a "suitable starting point".

More response please see inline.

Best regards,
Haoyu

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, March 13, 2019 10:16 AM
To: Tianran Zhou 
Cc: opsawg@ietf.org; opsawg-cha...@ietf.org
Subject: Re: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf

On Mon, Mar 11, 2019 at 02:39:44AM +, Tianran Zhou wrote:
> Hi WG,
> 
> As you may have seen, the authors have posted an update to 
> draft-song-opsawg-ntf-03 to address discussions in Bangkok and after.
> https://datatracker.ietf.org/doc/draft-song-opsawg-ntf/
> https://mailarchive.ietf.org/arch/msg/opsawg/g338UPfVAtOhVhdDzhJcR2nS7
> 6E
> 
> In Bangkok there seemed to some interest in working on this topic and the 
> chairs believe it is in scope for this working group.
> 
> This email starts a poll for adoption. 
> If you support adopting this document please say so, and please give an 
> indication of why you think it is important. Also please say if you will be 
> willing to review and help the draft.
> If you do not support adopting this document as a starting point for work on 
> this topic, please say why.
> This poll will run until 9am in Prague on Monday 25th March.

I think there are two main questions to answer:

a) Does the IETF need a Network Telemetry Framework?
b) Is this document a suitable starting point for such a framework?

I am not sure about a) and I assume that may need more WG discussion time to 
find out and concerning b) I believe the current document needs major work and 
hence I would not recommend to adopt it yet even if there is a need for a).

For the details of my reasoning, see the longer text below. Disclaimer: I have 
not physically participated in the last IETF meetings, so I only comment on 
what I read today and what I recall from the mailing list.  It may not be 
useful to start a discussion on each of the points I am making, I suggest you 
rather take this as general input to think about in preparation of a possible 
discussion in Prague.

Details follow for those interested in them...

a) Does the IETF need a Network Telemetry Framework? Which problems does
   such an architectural framework help to solve?

   For me, an architectural framework needs to serve a clear purpose.
   Possible clear purposes can be:

   - The architectural framework guides future work in the IETF.
   - The architectural framework defines concepts and terminology
 that help simplifying communication.

   The abstract and the introduction kind of indicate that this is the
   goal of this document. Section 3 goes into more details why an
   architectural framework is needed. The main arguments (leaving
   out things where I failed to see the argument):

   - A telemetry framework can help to normalize the technique developments.
   - Applications require network telemetry to be elastic.
   - Efficient data fusion is critical.
   - The lack of coherence (of the work in the IETF) makes it difficult
 to assemble a comprehensive network telemetry system and causes
 repetitive and redundant work.

   The goal seems to be to guide future work in the IETF. But what is
   the work to be guided in the IETF? The IPFIX work has concluded,
   YANG push is likely soon reaching conclusion in NETCONF, gRPC is
   not really happening within the IETF.

HS>  Some works are still going on (e.g., data plane telemetry, YANG PUSH)
  and we can't conclude that we've done and no new things (or 
  updates to the existing things) are needed in the future. 
  We also need to study how to consolidate and 

[OPSAWG] Network Telemetry Framework - new updates and request for adoption

[Haoyu song]

Dear OPSAWG members,

We have update the Network Telemetry Framework draft significantly in the 
latest revision to address the issues and concerns raised in previous meetings 
and supplement some new material.

The major updates are:


1. To address the concern that some techniques might go obsolete, we  move 
all the introductions of the related techniques to the appendix. We believe the 
survey is useful for the community and the appendix can be maintained to be up 
to date.

2. We articulate why we need to partition the telemetry into different 
network planes through more discussions and tabulated comparisons. We highlight 
that due to the difference of the data sources and objects, the required 
technique can be very different. There's no on-size-fit-all solution. Our 
partition can show a much clearer picture and help network operator to 
understand the full domain.

3. To resolve the relationship between network telemetry and conventional 
network OAM, we introduce another framework dimension to classify the telemetry 
technologies: data acquiring mechanism. It clearly show that conventional OAM 
techniques can be a part of telemetry in some cases but network telemetry 
covers much more.

4. We add text address the security issues of network telemetry

5. We add text to show the evolving stages of network telemetry

There are numerous minus updates throughout the draft.

In the past one year, we have done seven major revisions and we believe it's 
now mature enough for a call for adoption and we believe OPSAWG is the right WG 
to host it.
We therefore request the adoption of the draft by OPSAWG.

Network telemetry is a critical area for network operation not only for today 
but also for tomorrow. IETF needs such an "informational" document to 
articulate the concept, share common understandings, and summarize  the best 
industry practice. We have communicated this work with numerous network 
operators and they all think this is eye-opening and help them learn the 
state-of-art and clarify some misunderstandings about network telemetry.

We believe it's time to engage the entire WG to keep improving the work, to 
cover an important technical area in IETF, and to make positive contributions 
to the industry.

We urge the WG members and anyone who is interested in this work to read this 
draft and provide your valuable and constructive suggestions for further 
improvement. We'll surely address them in future revisions. Network telemetry 
is an exciting technology and a big thing in networks so let's start to tackle 
it. You support is important, please don't hesitate to voice it. Thank you very 
much!

Best regards,
Haoyu

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf

[Haoyu song]

Hi Thomas,

Thank you very much for your support! I'm glad to see that the vision of the 
draft is well aligned with yours.
You pointed out a very important issue (metrics correlation) that definitely 
needs to be addressed by IETF. We'll articulate this based on your comments.
Schema conversion is also a real issue and solid requirement. My only concern 
is if this is in the working scope of IETF. Maybe for the completeness of the 
work, we should also mention it at least. Or we should think about how to make 
the conversion easier.

We are looking forward to your further help  and contribution!

Best regards,
Haoyu

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of 
thomas.g...@swisscom.com
Sent: Sunday, March 17, 2019 3:09 AM
To: Tianran Zhou ; opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: Re: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf


Hi Tianran and co-authors,



I support the adoption from a network operator perspective. Thank you very much 
that you driving this important topic at IETF.



I agree with the authors that IETF needs to ensure that all activities covered 
by Network Telemetry has to be coordinated to allow metric correlation and Big 
Data integration to gain visibility into our networks. Without visibility into 
our networks, networks and automation won't reach maturity levels we know from 
other industries..



I like to add the following input:



Section 3, "The Necessity of a Network Telemetry Framework", paragraph "Network 
visibility presents multiple viewpoints"

--

In section 4.2 "Data Objects" you lay out nicely the 3 different areas metrics 
can be collected. Control-Plane, Forwarding-Plane and Management (device, 
physical topology). It is important to describe that if metrics are correlated 
between these 3 areas, metrics can be viewed from these 3 different viewpoints. 
Examples:



Traffic Impact:From 
forwarding-plane perspective we can verify if traffic impact was caused due to 
a control-plane or a management plane change or not.

Service Provisioning:From a control-plane 
perspective we can verify if service provisioning was successful and undesired 
traffic or device impact was caused.

Physical Topology Modification:   From a device/physical topology 
perspective, we can verify when new devices are introduced or existing are 
changed or upgraded, if control-plane worked, forwarding path was adjusted to 
redundant device and no traffic impact is visible from a customer/service 
perspective.



For a automated closed loop operation this is essential. Same as an autopilot 
in an modern airplane works, it needs sensors covering multiple aspects. When 
change is performed, it has to verify if desired outcome is achieved.



These metric correlation between control-plane, forwarding-plane and management 
(device, physical topology) can only be achieved when:



1.   Each area has key fields which contain the same values

2.   These time series metrics have same timestamps



In those areas, IETF and this NTF draft needs to play an important role by not 
only point out which key metrics exists (find the right amount is key), it also 
has to ensure that within RFC's covering metric collection, enrichment and 
correlation, this aspects are fostered.



Example1: With "if-index" field in ietf-interfaces.yang  model (A YANG Data 
Model for Interface Management, RFC 7223) we are able to correlate to IPFIX 
(RFC 7011) entity 10 (ingressInterface) and 14 (egressInterface).

Example2: With "ip address" field in ietf-ip.yang model (A YANG Data Model for 
IP Management, RFC 8344) we are able to correlate BGP next-hop attribute in BMP 
(BGP Monitoring Protocol, RFC 7854).

Example3: With IPFIX entity 90 (mplsVpnRouteDistinguisher) we are able to 
correlate to BGP route-distinguisher in BMP (BGP Monitoring Protocol, RFC 7854).



If you look at the last example and the following IETF draft which wants to 
enrich forwarding-plane with BGP metrics on the flow exporter, we have to ask 
ourselves if IPFIX entity 90 is a key field and should be part of any RFC which 
correlates between BGP control-plane and forwarding-plane.



Export BGP community information in IP Flow Information Export (IPFIX)

https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-12



Another aspect which is currently not covered is schema conversion.. Network 
metrics have schema definitions (YANG, IPFIX template, BMP message format) 
which are currently not supported in Big Data environment. Widely used in 
Hadoop environments is AVRO (https://en.wikipedia.org/wiki/Apache_Avro). We 
need to describe and allow that schema conversion is possible.



[cid:image002.jpg@01D4DD77.649C7950]





Further, IETF should take the step towards Big Data and standardize a schema 
language which can be used at Big Data and network metric schema's can be 
easily converted to. Without 

Re: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf

[Haoyu song]

Hi Daniel,

Thank you very much for the support! Your comments and suggestions are all 
noted and we look forward your contributions. 

We couldn't find a tight definition of network telemetry anywhere else although 
the term has been widely used. That's why I think we should take the 
responsibility. Of course if anybody is aware of that, please feel free to let 
us know.
Our current definition is intended to be loose enough to cover a wide range of 
techniques yet to catch the essence of the term. We believe the WG can help to 
make it well defined and widely accepted. 

Best regards,
Haoyu 

-Original Message-
From: Daniel King [mailto:d...@danielking.net] On Behalf Of dan...@olddog.co.uk
Sent: Monday, March 18, 2019 11:54 AM
To: opsawg@ietf.org; Haoyu song 
Cc: opsawg-cha...@ietf.org
Subject: RE: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf

Hi All, 

Yes, I fully support the adoption of the I-D. 

The OPSAWG is a great home for the I-D. Thomas, Juergen and Adrian, and others 
have all made excellent observations and suggestions to develop the document. 
It is refreshing to see polls where it is not just a binary yes/no flag. :-)

A few general observations:

o Having a clear definition of "network telemetry" is good, and this document 
goes a long way to help clarify the role of telemetry and differences from 
traditional OAM in current networks. For completeness it may be worth including 
references to other formal SDOs that also have network telemetry definitions;

o It may be useful to expand on the Data Objects (section 4.2) and add a column 
in figure 3 that highlights the various types of data
(event/metric/route) and query functions. You could even have a short 
sub-section that highlights the various combinations of management functions, 
roles, queries and data types:

Fault Management (event data)
Performance Management (metric data)
Billing Management (event data and metric data) Capacity Management (metric 
data) Security Management (metric data and route data)

o The security section in the I-D contains some useful high-level discussion 
text. The section needs further development, and I will be glad to make more 
detailed contributions. 

BR, Dan. 

From: OPSAWG  On Behalf Of Haoyu song
Sent: 18 March 2019 17:49
To: thomas.g...@swisscom.com; Tianran Zhou ; 
opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: Re: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf

Hi Thomas,

Thank you very much for your support! I'm glad to see that the vision of the 
draft is well aligned with yours.
You pointed out a very important issue (metrics correlation) that definitely 
needs to be addressed by IETF. We'll articulate this based on your comments.
Schema conversion is also a real issue and solid requirement. My only concern 
is if this is in the working scope of IETF. Maybe for the completeness of the 
work, we should also mention it at least. Or we should think about how to make 
the conversion easier. 

We are looking forward to your further help  and contribution!

Best regards,
Haoyu

-Original Message-
From: OPSAWG <mailto:opsawg-boun...@ietf.org> On Behalf Of Tianran Zhou
Sent: Monday, March 11, 2019 3:40 AM
To: mailto:opsawg@ietf.org
Cc: mailto:opsawg-cha...@ietf.org
Subject: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf

Hi WG,

As you may have seen, the authors have posted an update to
draft-song-opsawg-ntf-03 to address discussions in Bangkok and after.
https://datatracker.ietf.org/doc/draft-song-opsawg-ntf/
https://mailarchive.ietf.org/arch/msg/opsawg/g338UPfVAtOhVhdDzhJcR2nS76E

In Bangkok there seemed to some interest in working on this topic and the 
chairs believe it is in scope for this working group.

This email starts a poll for adoption. 
If you support adopting this document please say so, and please give an 
indication of why you think it is important. Also please say if you will be 
willing to review and help the draft.
If you do not support adopting this document as a starting point for work on 
this topic, please say why..
This poll will run until 9am in Prague on Monday 25th March.

Regards,
Tianran, OPSAWG Co-Chair

___
OPSAWG mailing list
mailto:OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] IPR poll on draft-song-opsawg-ntf-03

[Haoyu song]

I'm not aware of any IPR for this draft. Thanks!

Best regards,
Haoyu

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Sunday, March 10, 2019 7:55 PM
To: opsawg@ietf.org
Cc: draft-song-opsawg-...@ietf.org
Subject: [OPSAWG] IPR poll on draft-song-opsawg-ntf-03

Hi WG,

Accompany with the adoption poll, this mail starts the IPR poll.

Are you aware of any IPR that applies to draft-song-opsawg-ntf-03?

If you own or are aware of any IPR that applies to the 
draft-song-opsawg-ntf-03, please clarify whether this IPR been disclosed in 
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more 
details).

If you are listed as a document author or contributor please respond to this 
email in OPSAWG mailing list regardless of whether or not you are aware of any 
relevant IPR. The document will not advance to the next stage until a response 
has been received from each author and contributor.

If you are not listed as an author or contributor but are on OPSAWG mailing 
list, then please explicitly respond if you are aware of any IPR that has not 
yet been disclosed in conformance with IETF rules.

Thank you for kind support.

Regards,
Tianran, OPSAWG co-chair

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf

[Haoyu song]

Hi Qin,

Thanks for the comments. We'll provide more description about this issue and 
make reference to the existing work. 
Your second observation is also right. There are different meanings when 
talking about correlation. I think "data correlation" can serve as a high level 
term to cover both cases.

Best,
Haoyu

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Qin Wu
Sent: Thursday, March 21, 2019 3:43 AM
To: Tianran Zhou ; opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: Re: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf

Event,defect correlation at different layer is a challenging issue we try 
tackle in LIME WG, see charter scope:
" The absence of a common approach to OAM management has made it difficult for 
operators to:
  - Suppress large numbers of unnecessary alarms and notifications related to 
defects and failures arising in lower layers and visible in each higher layer
  - Quickly identify root causes of network failures
  - Coordinate end-to-end performance measurement with the results of 
performance monitoring at different layers in the network
  - Correlate defects, faults, and network failures between the different 
layers to improve efficiency of defect and fault localization and provide 
better OAM visibility.
"
If this issue can be further addressed by NTF, that will be great. I would 
recommend to reference LIME work as basis which will be published soon.
Also I think KPI correlation rely on big data analytics technology, data 
correlation from different source and KPI correlation are two different things.

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2019年3月11日 10:40
收件人: opsawg@ietf.org
抄送: opsawg-cha...@ietf.org
主题: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf

Hi WG,

As you may have seen, the authors have posted an update to 
draft-song-opsawg-ntf-03 to address discussions in Bangkok and after.
https://datatracker.ietf.org/doc/draft-song-opsawg-ntf/
https://mailarchive.ietf.org/arch/msg/opsawg/g338UPfVAtOhVhdDzhJcR2nS76E

In Bangkok there seemed to some interest in working on this topic and the 
chairs believe it is in scope for this working group.

This email starts a poll for adoption. 
If you support adopting this document please say so, and please give an 
indication of why you think it is important. Also please say if you will be 
willing to review and help the draft.
If you do not support adopting this document as a starting point for work on 
this topic, please say why.
This poll will run until 9am in Prague on Monday 25th March.

Regards,
Tianran, OPSAWG Co-Chair

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Review of draft-song-opsawg-ntf-03

[Haoyu song]

Hi Joe,

I'm working on revising the draft. 

Below are some thoughts on the issues you raised about Section 2:

1) I'll position AI a more forward looking technique that can take advantage of 
network telemetry.

2) NMRG is working on  provide a formal definition of "intent" so I think we 
can use that as a reference to clarify the buzz word.

3) When I say "the system bottleneck is shifting from data consumption to data 
supply",  what I mean is  that now the data processing capability is greatly 
improved and many applications are hungry for more data yet the network  lags 
behind in providing enough high quality data in a timely manner. I agree we 
must have a way to translate that data into useful, actionable information. I 
think this is also a part of job of network telemetry. Network telemetry is not 
just supplying raw data, but supplying useful and actionable data.

Best regards,
Haoyu
 
-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Joe Clarke
Sent: Monday, April 08, 2019 7:31 AM
To: opsawg@ietf.org
Subject: [OPSAWG] Review of draft-song-opsawg-ntf-03

As I promised at the mic at 104, I have a more comprehensive review of this 
draft.

I'll tackle this section-by-section.  These are a combination of nits and more 
substantive comments.

===

In the abstract, you have a sentence:

Network telemetry promises better flexibility, scalability, accuracy, coverage, 
and performance...

This left me wondering, "than what?"  That is, I think you’re trying to say 
that with respect to traditional poll-based network monitoring, telemetry 
provides these advantages.  If you're going to say something is better, it 
would help to compare that to something else in order to provide better 
clarity.pr

===

Section 1:

s/ideal mean/ideal means/

s/telemetry remain/telemetry remains/

===

Section 2:

The first sentence of your motivation bothers me.  I don’t buy it.  Yes, some 
are using machine learning to pull insights out of “big data,” but the way this 
reads, AI is commonplace in networking.  I would say this is still very much in 
niche areas and research.  One key issue with the vast amounts of data that 
some networks produce is sorting through it to find useful information.  Large 
operators may have the means to do ML, but others struggle to make sense of 
this data.

You use the term "intent-driven autonomous network."  I asked around with some 
operators and other vendors, and this is 100% buzz word.
People either don't know what it means or define it using even more buzzwords.  
I know each vendor has their own meaning for this, but these terms on not 
widely known.  Your document aims to clarify taxonomy.  I would clarify this 
buzzy phrase.

In your third paragraph, you say, "the system bottleneck is shifting from data 
consumption to data supply."  I disagree.  Telemetry is furthering the data 
consumption problem.  More data doesn't mean more insight.  More data means 
more headache.  In addition to getting more data more easily, we _must_ have a 
way to translate that data into useful, actionable information.  This goes to 
Benoit's talk on telemetry on Thursday at 104.  How do we up-level the value of 
telemetry?

===

Section 2.1:

s/An intents/An intent/

===

Section 2.2:

The sentence "These convention techniques are not sufficient to support the 
above use cases for the following reasons:" doesn't make sense.
There are some grammatical issues here.  Consider rephrasing.  Maybe, "These 
conventional techniques".

===

Section 2.3:

You define IDN as Intent-Driven Network, but I would again say you need to 
define this in its entirety so the reader is clear.  You do define, "an intent" 
but IDN/IBN is more comprehensive than that.

===

Section 4.1:

s/avaiable/available/

You define different types of telemetry data as "Simple Data" and then "Custom 
Data".  Might I suggest you rename Custom Data to Complex Data as "complex" 
tends to typically refer to some level of multiple combination or aggregation.

===

Section 4.2:

Can you talk more about what you mean by social data and why environmental is 
defined to be external?  I can have on-board sensors that relay internal 
environmental data.

Why is external data not offered over HTTP?  I imagine "social" would be HTTP, 
but without more definition, I'm not sure.

===

Section 4.4:

Why isn't gRPC listed in the Simple Data query?

Under Custom Data Query, there is a “YANG FSM” draft as an individual draft in 
netmod, but it’s not clear what the future is.  There seems to be a general 
thought that event-driven YANG is useful, but if that will be an FSM per se is 
yet to be seen.

What is PBT?  I didn't see it in glossary.

===

That's it for now.  I think this will give you a lot to chew on.

Joe

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list

Re: [OPSAWG] Review of draft-song-opsawg-ntf-03

[Haoyu song]

Hi Joe,

Thank you very much for the review! I'll update the draft according to your 
comments.

Best regards,
Haoyu

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Joe Clarke
Sent: Monday, April 08, 2019 7:31 AM
To: opsawg@ietf.org
Subject: [OPSAWG] Review of draft-song-opsawg-ntf-03

As I promised at the mic at 104, I have a more comprehensive review of this 
draft.

I'll tackle this section-by-section.  These are a combination of nits and more 
substantive comments.

===

In the abstract, you have a sentence:

Network telemetry promises better flexibility, scalability, accuracy, coverage, 
and performance...

This left me wondering, "than what?"  That is, I think you’re trying to say 
that with respect to traditional poll-based network monitoring, telemetry 
provides these advantages.  If you're going to say something is better, it 
would help to compare that to something else in order to provide better clarity.

===

Section 1:

s/ideal mean/ideal means/

s/telemetry remain/telemetry remains/

===

Section 2:

The first sentence of your motivation bothers me.  I don’t buy it.  Yes, some 
are using machine learning to pull insights out of “big data,” but the way this 
reads, AI is commonplace in networking.  I would say this is still very much in 
niche areas and research.  One key issue with the vast amounts of data that 
some networks produce is sorting through it to find useful information.  Large 
operators may have the means to do ML, but others struggle to make sense of 
this data.

You use the term "intent-driven autonomous network."  I asked around with some 
operators and other vendors, and this is 100% buzz word.
People either don't know what it means or define it using even more buzzwords.  
I know each vendor has their own meaning for this, but these terms on not 
widely known.  Your document aims to clarify taxonomy.  I would clarify this 
buzzy phrase.

In your third paragraph, you say, "the system bottleneck is shifting from data 
consumption to data supply."  I disagree.  Telemetry is furthering the data 
consumption problem.  More data doesn't mean more insight.  More data means 
more headache.  In addition to getting more data more easily, we _must_ have a 
way to translate that data into useful, actionable information.  This goes to 
Benoit's talk on telemetry on Thursday at 104.  How do we up-level the value of 
telemetry?

===

Section 2.1:

s/An intents/An intent/

===

Section 2.2:

The sentence "These convention techniques are not sufficient to support the 
above use cases for the following reasons:" doesn't make sense.
There are some grammatical issues here.  Consider rephrasing.  Maybe, "These 
conventional techniques".

===

Section 2.3:

You define IDN as Intent-Driven Network, but I would again say you need to 
define this in its entirety so the reader is clear.  You do define, "an intent" 
but IDN/IBN is more comprehensive than that.

===

Section 4.1:

s/avaiable/available/

You define different types of telemetry data as "Simple Data" and then "Custom 
Data".  Might I suggest you rename Custom Data to Complex Data as "complex" 
tends to typically refer to some level of multiple combination or aggregation.

===

Section 4.2:

Can you talk more about what you mean by social data and why environmental is 
defined to be external?  I can have on-board sensors that relay internal 
environmental data.

Why is external data not offered over HTTP?  I imagine "social" would be HTTP, 
but without more definition, I'm not sure.

===

Section 4.4:

Why isn't gRPC listed in the Simple Data query?

Under Custom Data Query, there is a “YANG FSM” draft as an individual draft in 
netmod, but it’s not clear what the future is.  There seems to be a general 
thought that event-driven YANG is useful, but if that will be an FSM per se is 
yet to be seen.

What is PBT?  I didn't see it in glossary.

===

That's it for now.  I think this will give you a lot to chew on.

Joe

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] IOAM export through IPFIX

[Haoyu Song]

I support to discuss this work in OPSAWG. I also think the scope of the work 
may need to be extended. It only covers the raw export format which is not 
flexible enough and put all the data parsing complexity on the data collector. 
As we suggested in the iFIT framework, a flexible solution should allow the 
device to customize the IOAM data export. In that sense, a generic IPFIX-based 
export scheme is more proper.   If the author agree, we could extend the 
current draft; otherwise, I think another proposal draft is needed to 
complement this solution. 

Haoyu

-Original Message-
From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: Tuesday, September 03, 2019 9:40 AM
To: opsawg@ietf.org
Subject: [OPSAWG] IOAM export through IPFIX

At opsawg 105, the draft 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-spiegel-ippm-ioam-rawexport-02data=02%7C01%7Chaoyu.song%40futurewei.com%7C0bf2cbd995724004483f08d7308d7f3f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637031256600129445sdata=qvQKbXOkaERYB%2BmaawAkE5euiWEpGngzDYAIVlN04Ys%3Dreserved=0
 was presented describing how to use IPFIX to export IOAM data.

A question was raised at the end as to whether or not the work should be done 
in opsawg or ippm?  Where would this work get more reviews?

In my reading of the draft (as a contributor), I think it would probably do 
well in opsawg as it describes how existing IEs will be used for IOAM and what 
new IEs will be required.  I think the IPFIX expertise is more likely here than 
in ippm.

Other thoughts and comments on this work?

Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawgdata=02%7C01%7Chaoyu.song%40futurewei.com%7C0bf2cbd995724004483f08d7308d7f3f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637031256600129445sdata=gRB4%2Fc6jfdMVUbpH3NX%2FgKvflV7cSJtQWr8nC776nJI%3Dreserved=0

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] iFIT framework draft

[Haoyu Song]

Hi Giuseppe,

Thank you very much for the very good suggestion. Indeed, the closed-loop 
nature of the framework allows numerous new applications which I believe is 
indispensable in future's network operation architecture.
If you have any suggested section or text available, I'll be happy to include 
it in the draft. That way, you can fully construe your thought. Otherwise, I'll 
add some text by myself later. What do you  think?

Best,
Haoyu

From: Giuseppe Fioccola 
Sent: Thursday, September 12, 2019 7:38 AM
To: Haoyu Song ; opsawg@ietf.org; 
draft-song-opsawg-ifit-framew...@ietf.org
Subject: RE: iFIT framework draft

Dear All,
I have read the draft and, I think it is a very good framework, in particular 
with reference to the real practical challenges.
My suggestion is to highlight a bit more the enabled closed-loop approach that 
is a great added value in my opinion.
A possible way can be to introduce a new Section named "Intelligent Network 
telemetry" about the flexible and dynamic monitoring. Some concepts like the 
interactive query with dynamic network probes can be included.
An example could also be in draft-ietf-ippm-multipoint-alt-mark, that describes 
a flexible performance monitoring approach based on the network condition and 
an iFIT Application on top of the Controllers could apply this intelligent 
mechanism. Or, also, other examples can be reported.

Let me know what you think.

Best Regards,

Giuseppe


From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Haoyu Song
Sent: Wednesday, July 17, 2019 8:06 PM
To: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>
Subject: [OPSAWG] iFIT framework draft

Hi all,

We recently uploaded a newer version of the iFIT framework draft.
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=02%7C01%7Chaoyu.song%40futurewei.com%7C8c5d65776ddb4158c64508d7378ebeef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637038958551827671=Iufu9kamS5%2BV5dWoa9G8MhK7Bw%2FIzZipm9w6z3jj8f8%3D=0>

The purposes of the drafts are:


  1.  Clarify the terms and underlying techniques for data plane on-path 
telemetry
  2.  Present a framework that addresses the practical implementation and 
deployment issues
  3.  Identify the open issues and directions for related standard development

Given the wide industry interests on adopting such techniques, we believe this 
informational draft is useful and
In the scope of OPSAWG.  Please review the draft and provide your opinions, 
suggestions, and comments.

Thank you very much!

Haoyu
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Haoyu Song]

Hi Huanan,

Thanks for the suggestion! I’ll make corresponding enhancements in the next 
revision. See more comments inline.

Best regards,
Haoyu

From: OPSAWG  On Behalf Of chenhu...@chinatelecom.cn
Sent: Sunday, September 15, 2019 7:22 PM
To: opsawg 
Cc: draft-song-opsawg-ifit-framework 
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：chenhu...@chinatelecom.cn
   13316097...@chinatelecom.cn
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] iFIT framework draft

[Haoyu Song]

Hi Giuseppe,

Thank you very much for your contribution! I'll merge it into our next revision 
of the draft.
Indeed, I hope the framework can inspire more applications.

Best,
Haoyu

From: Giuseppe Fioccola 
Sent: Wednesday, September 18, 2019 5:57 AM
To: Haoyu Song ; opsawg@ietf.org; 
draft-song-opsawg-ifit-framew...@ietf.org
Subject: RE: iFIT framework draft

Dear Haoyu, All,
As promised, here is the proposed new section.
Feel free to edit and let me know your opinion.

"
#.  Intelligent Network Telemetry applications

   The closed-loop nature of the IFIT framework allows numerous new
   applications which enable future network operation architecture.

   In general, it is resource consuming to monitor continuously all
   the flows and all the paths of the network. So a flexible and
   dynamic performance monitoring approach is desired. Some concepts
   like the Interactive Query with Dynamic Network Probes, as
   previously described, go in this direction.

   A good example could be in [I-D.ietf-ippm-multipoint-alt-mark]
   that describes an intelligent performance management based on the
   network condition. The idea is to split the monitoring network
   into Clusters. The Cluster partition that can be applied to every
   type of network graph and the possibility to combine Clusters at
   different levels enable the so called Network Zooming. It allows
   a Controller to calibrate the network telemetry, so that it can
   start without examining in depth and monitor the network as a
   whole. In case of necessity (packet loss or too high delay), an
   immediate detailed analysis can be reconfigured. In particular,
   the Controller, that is aware of the network topology, can set up
   the most suited Cluster partition by changing the traffic filter
   or activate new measurement points and the problem can be localized
  with a step-by-step process.

   To apply this mechanism an IFIT Application on top of the Controllers
   can manage and the IFIT closed loop allows its dynamic and flexible
   operation.
"

Best Regards,

Giuseppe


From: Giuseppe Fioccola
Sent: Friday, September 13, 2019 1:51 PM
To: 'Haoyu Song' mailto:haoyu.s...@futurewei.com>>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>
Subject: RE: iFIT framework draft

Dear Haoyu,
Yes, I'm happy to send you some text in the coming days, so you can include it 
in the draft.

Best Regards,

Giuseppe

From: Haoyu Song [mailto:haoyu.s...@futurewei.com]
Sent: Thursday, September 12, 2019 7:57 PM
To: Giuseppe Fioccola 
mailto:giuseppe.fiocc...@huawei.com>>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>
Subject: RE: iFIT framework draft

Hi Giuseppe,

Thank you very much for the very good suggestion. Indeed, the closed-loop 
nature of the framework allows numerous new applications which I believe is 
indispensable in future's network operation architecture.
If you have any suggested section or text available, I'll be happy to include 
it in the draft. That way, you can fully construe your thought. Otherwise, I'll 
add some text by myself later. What do you  think?

Best,
Haoyu

From: Giuseppe Fioccola 
mailto:giuseppe.fiocc...@huawei.com>>
Sent: Thursday, September 12, 2019 7:38 AM
To: Haoyu Song mailto:haoyu.s...@futurewei.com>>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>
Subject: RE: iFIT framework draft

Dear All,
I have read the draft and, I think it is a very good framework, in particular 
with reference to the real practical challenges.
My suggestion is to highlight a bit more the enabled closed-loop approach that 
is a great added value in my opinion.
A possible way can be to introduce a new Section named "Intelligent Network 
telemetry" about the flexible and dynamic monitoring. Some concepts like the 
interactive query with dynamic network probes can be included.
An example could also be in draft-ietf-ippm-multipoint-alt-mark, that describes 
a flexible performance monitoring approach based on the network condition and 
an iFIT Application on top of the Controllers could apply this intelligent 
mechanism. Or, also, other examples can be reported.

Let me know what you think.

Best Regards,

Giuseppe


From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Haoyu Song
Sent: Wednesday, July 17, 2019 8:06 PM
To: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>
Subject: [OPSAWG] iFIT framework draft

Hi all,

We recently uploaded a newer version of the iFIT framework draft.
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/<https://nam03.safelinks.protection.outlook.com/?url=http

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

[Haoyu Song]

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: chenhu...@chinatelecom.cn; opsawg 
Cc: draft-song-opsawg-ifit-framework 
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 mailto:opsawg-boun...@ietf.org>> On 
Behalf Of chenhu...@chinatelecom.cn<mailto:chenhu...@chinatelecom.cn>
Sent: Sunday, September 15, 2019 7:22 PM
To: opsawg mailto:opsawg@ietf.org>>
Cc: draft-song-opsawg-ifit-framework 
mailto:draft-song-opsawg-ifit-framew...@ietf.org>>
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 FlowSmart |
|and Data closed-loop  Data  |
|Selection Export|
||
|   +++
V  +-+|
  +--+ Encapsulation  +-+||
  |  iFIT| and Tunneling  |  iFIT   |||
  |  Head|--->| ||+
  |  Node||  Nodes  |+
  +--++-+
  DNPDNP


   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 collec

[OPSAWG] iFIT framework draft

[Haoyu Song]

Hi all,

We recently uploaded a newer version of the iFIT framework draft.
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/

The purposes of the drafts are:


  1.  Clarify the terms and underlying techniques for data plane on-path 
telemetry
  2.  Present a framework that addresses the practical implementation and 
deployment issues
  3.  Identify the open issues and directions for related standard development

Given the wide industry interests on adopting such techniques, we believe this 
informational draft is useful and
In the scope of OPSAWG.  Please review the draft and provide your opinions, 
suggestions, and comments.

Thank you very much!

Haoyu
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] iFIT framework draft

[Haoyu Song]

Hi Fengwei,

Thanks for the feedback. My understanding is that there are two types of closed 
loops. In our draft, iFIT’s closed loop is for changing the telemetry 
requirements based on previous telemetry results, so the whole loop is still 
for the telemetry purpose. Another type of closed loop is so called closed 
control loop, which means, based on the telemetry results, the application will 
automatically change the network policy or configuration. For this type, iFIT 
is just part of the loop and we may not want to cover that because it might 
belong to a bigger topic (such as automatic network) . But I think it’s useful 
to clarify this point in the draft.

The “self-healing” case you mentioned might belong to the second type, but the 
“precision location of silent failures” case might belong to the first type, 
depending on a better understanding of the case, i.e., what kind of failures 
and how data-path telemetry can help to detect. If you and anybody else have 
such information, I would like to hear and include the discussion in the draft.

Thanks!

Haoyu

From: qinfengwei 
Sent: Friday, September 20, 2019 7:09 AM
To: Haoyu Song ; opsawg@ietf.org; 
draft-song-opsawg-ifit-framew...@ietf.org
Subject: 答复: [OPSAWG] iFIT framework draft

Hi Haoyu,
I have read the draft and think the iFIT is useful for operators to identify 
the issue quickly. You know that the silent failures are our biggest pain 
points, the precision location and network self-healing are our rigid demand. 
You say that iFIT is a closed-loop framework, in my opinion, it should include 
how to diagnose and restore the network, but I haven't seen either. Do I not 
understand or would you have explained it in other draft?



Beat Regard,
Fengwei Qin

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Haoyu Song
发送时间: 2019年7月18日 02:06
收件人: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>
主题: [OPSAWG] iFIT framework draft

Hi all,

We recently uploaded a newer version of the iFIT framework draft.
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=02%7C01%7Chaoyu.song%40futurewei.com%7C22e31da5670b48dcbbea08d73dd43232%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637045853915262328=7dKlBcMx%2FyrDVSPNUOmG%2BaC0x4AfRGVQvgoAWmmyEYc%3D=0>

The purposes of the drafts are:


  1.  Clarify the terms and underlying techniques for data plane on-path 
telemetry
  2.  Present a framework that addresses the practical implementation and 
deployment issues
  3.  Identify the open issues and directions for related standard development

Given the wide industry interests on adopting such techniques, we believe this 
informational draft is useful and
In the scope of OPSAWG.  Please review the draft and provide your opinions, 
suggestions, and comments.

Thank you very much!

Haoyu
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] iFIT framework draft

[Haoyu Song]

Yes, exactly. The closed loop for telemetry is interactive and dynamic. Under 
such a framework, we are expecting many interesting applications that solve 
various network monitoring and measurement problems.

Haoyu

From: qinfengwei 
Sent: Wednesday, September 25, 2019 6:25 PM
To: Haoyu Song ; opsawg@ietf.org; 
draft-song-opsawg-ifit-framew...@ietf.org
Subject: 答复: [OPSAWG] iFIT framework draft

Hi Haoyu,

I am interested in your thoughts on the two closed loops. I agree with you. I 
think it's useful to clarify this point in the draft.

The per packet hop by hop monitoring will cost too much resource. So the 
solution we are looking for is iterative. Spatially, we can monitor selected 
services or tunnels at one time, and switch to other monitoring objects then. 
Temporally, we can do the end to end or sampled monitoring, and switch to the 
fine grained monitoring once the SLA degrade.

And so the telemetry could be interactive. For example, when we detect the end 
to end packet loss, we firstly evaluate the frequency, the pattern and see if 
it's caused by some obvious reason (e.g., the power failure). Then we decide 
whether to apply the fine grained monitoring and locate the fault.

I think these could all be implemented in a closed loop telemetry.




Best Regards,
Fengwei Qin

发件人: Haoyu Song [mailto:haoyu.s...@futurewei.com]
发送时间: 2019年9月21日 01:30
收件人: qinfengwei; opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>
主题: RE: [OPSAWG] iFIT framework draft

Hi Fengwei,

Thanks for the feedback. My understanding is that there are two types of closed 
loops. In our draft, iFIT’s closed loop is for changing the telemetry 
requirements based on previous telemetry results, so the whole loop is still 
for the telemetry purpose. Another type of closed loop is so called closed 
control loop, which means, based on the telemetry results, the application will 
automatically change the network policy or configuration. For this type, iFIT 
is just part of the loop and we may not want to cover that because it might 
belong to a bigger topic (such as automatic network) . But I think it’s useful 
to clarify this point in the draft.

The “self-healing” case you mentioned might belong to the second type, but the 
“precision location of silent failures” case might belong to the first type, 
depending on a better understanding of the case, i.e., what kind of failures 
and how data-path telemetry can help to detect. If you and anybody else have 
such information, I would like to hear and include the discussion in the draft.

Thanks!

Haoyu

From: qinfengwei mailto:qinfeng...@chinamobile.com>>
Sent: Friday, September 20, 2019 7:09 AM
To: Haoyu Song mailto:haoyu.s...@futurewei.com>>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>
Subject: 答复: [OPSAWG] iFIT framework draft

Hi Haoyu,
I have read the draft and think the iFIT is useful for operators to identify 
the issue quickly. You know that the silent failures are our biggest pain 
points, the precision location and network self-healing are our rigid demand. 
You say that iFIT is a closed-loop framework, in my opinion, it should include 
how to diagnose and restore the network, but I haven't seen either. Do I not 
understand or would you have explained it in other draft?



Beat Regard,
Fengwei Qin

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Haoyu Song
发送时间: 2019年7月18日 02:06
收件人: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>
主题: [OPSAWG] iFIT framework draft

Hi all,

We recently uploaded a newer version of the iFIT framework draft.
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=02%7C01%7Chaoyu.song%40futurewei.com%7Cb638388e15014220332e08d742207823%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637050579561924462=XxOdDdZoW99S7afDtwZMlB5aMuLBJyy46B7DaJOXK0I%3D=0>

The purposes of the drafts are:


  1.  Clarify the terms and underlying techniques for data plane on-path 
telemetry
  2.  Present a framework that addresses the practical implementation and 
deployment issues
  3.  Identify the open issues and directions for related standard development

Given the wide industry interests on adopting such techniques, we believe this 
informational draft is useful and
In the scope of OPSAWG.  Please review the draft and provide your opinions, 
suggestions, and comments.

Thank you very much!

Haoyu
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Review of draft-ietf-opsawg-ntf

[Haoyu Song]

Hi Adrian,

Thanks for the detailed review. I'll update the draft accordingly. Meanwhile 
I'd like to also request all the other authors and WG members to help review 
and improve this document, so we can have a new version before next IETF 
meeting.

Haoyu

-Original Message-
From: Adrian Farrel  
Sent: Friday, September 27, 2019 11:30 AM
To: draft-ietf-opsawg-...@ietf.org; opsawg@ietf.org
Subject: Review of draft-ietf-opsawg-ntf

Hi authors, WG,

I needed to read this document to check out a couple of things, and so here is 
a review that I collected along the way. I hope it is useful.

In general, I found the document a help collection of thoughts on the space and 
I encourage more work to refine it.

Best regards,

Adrian

===

I think that the Introduction launches in with the use of two terms that could 
use just a little more explanation. They are "Network Visibility"
and "Network Telemetry".

You don't need pages of text to explain them, but just very quick 
context-setting text. Such as...

   Network visibility is the ability of management tools to see the
   state and behavior of a network.  It is essential for successful
   network operation.

   Network telemetry is the process of measuring, recording, and
   distributing information about the behavior of a network.  Network
   telemetry has been considered as an ideal means to gain sufficient
   network visibility with better flexibility, scalability, accuracy,
   coverage, and performance than conventional OAM technologies.

---

Although you expand "OAM" in the Abstract, you need to also expand it on first 
use in the body of the text.

---

Section 1

s/technique/techniques/

---

I don't think you use any normative language, so you can drop section
1.1 and the two references.

---

The start of Section 2 is a bit abrupt.

   Thanks to the advance of the computing and storage technologies,
   today's big data analytics gives network operators an unprecedented
   opportunity to gain network insights and move towards network
   autonomy.

While this is sort of true, it steps over the fact that "big data" has to be 
collected (where collection means both recorded and moved into a single 
dataset).

So, I would break this down into:
- what is big data?
- what development in analytic tools is now meaning can be done with
  big data
- how this might be applicable to networks if the right data can be
  recorded, collected, and analysed.

You get to this last point nicely in paragraph 3, so you only need to set that 
up.

---
   
You need to check for all abbreviations being expanded on first use.   
I found:
ROI
CAPEX
RIB
ACL
MIB
QoS
CPU
GPB

---
   
2.2

s/are lack of formal/lack a formal/

---

2.3

This is a good collection of terms and explanations. Thanks. It would be even 
better if you were able to add (informative) references to point the reader at 
places to go for more background information.

Maybe the explanation of "YANG" should include an expansion of the abbreviation.

---

I don't find the inclusion of "YANG FSM" in this document convincing.
You only include it in the terminology section and in Figures 5 and 6.
But you don't have any explanation of what the term means, nor any indication 
of how it is relevant to this document.

---

2.4

draft-kumar-rtgwg-grpc-protocol may not be the best reference for gRPC.
I know you're only looking for an informative reference, but this draft expired 
30 months ago.

I don't have any suggestions for a better reference, but there is probably 
something on 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrpc.iodata=02%7C01%7Chaoyu.song%40futurewei.com%7C5cabc98d38124de1042908d74378b3b4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637052058022774410sdata=mdqzSprio5yJNZbDP6NHid437Olw54YJMT9qy5mYwVY%3Dreserved=0

---

2.4

I think I would add to the second list of bullets in this section to describe 
"in-network data aggregation/correlation". One of the applications AI and other 
"smart algorithmics" is to improve the collection and reporting of data from 
the network. That is, network devices and aggregation points can work out which 
events and what data needs to be stored, reported, or discarded thus reducing 
the load on the central collection and processing points while still ensuring 
that the right information is ready to be processed in a timely way.

I might also add "in-network processing". That is, there is not a necessary 
step to gather all information to a central point so that it can be processed 
and actions taken - it is possible for some processing to be done in the 
network, and actions taken more locally and more responsively.

This might link in to section 4.3 for the discussion of "Data Query, Analysis, 
and Storage" because it is not inconceivable that the analysis and storage will 
be distributed, and that the queries may be hierarchical.  That wouldn't 
require a change to the structure of Figure 4.

---

Section 3

   So far, some telemetry 

[OPSAWG] presentation slot request RE: Call for Adoption "draft-song-opsawg-ifit-framework"

[Haoyu Song]

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) 
Sent: Thursday, October 24, 2019 3:21 PM
To: Haoyu Song 
Cc: opsawg-cha...@ietf.org; opsawg@ietf.org
Subject: Re: Call for Adoption "draft-song-opsawg-ifit-framework"




On Oct 23, 2019, at 05:42, Haoyu Song 
mailto:haoyu.s...@futurewei.com>> 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 nee

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

[Haoyu Song]

Sorry, forgot to CC the WG.

发件人: Haoyu Song 
发送时间: 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) 
发送时间: 2019年10月27日星期日 下午7:20
收件人: Haoyu Song; Joe Clarke (jclarke)
抄送: opsawg@ietf.org; opsawg-cha...@ietf.org
主题: 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=02%7C01%7Chaoyu.song%40futurewei.com%7C64e6623973044759dea608d75acfa3ce%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637077720210393363=7Pe%2FoxzkB8BLKy%2B3A4liJy5tATDBoBkxg1EJcana5tU%3D=0>?

Thanks, Frank

From: Haoyu Song 
Sent: Freitag, 25. Oktober 2019 20:25
To: Frank Brockners (fbrockne) ; Joe Clarke (jclarke) 

Cc: opsawg@ietf.org; opsawg-cha...@ietf.org
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) mailto:fbroc...@cisco.com>>
Sent: Thursday, October 24, 2019 9:42 AM
To: Haoyu Song mailto:haoyu.s...@futurewei.com>>; Joe 
Clarke (jclarke) mailto:jcla...@cisco.com>>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
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 mailto:opsawg-boun...@ietf.org>> On 
Behalf Of Haoyu Song
Sent: Mittwoch, 23. Oktober 2019 11:43
To: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
opsawg-cha...@ietf.org<mailto:opsawg-cha.

Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

[Haoyu Song]

Hi Benoit,

Did you read my summary email? In it I summarized all the questions raised 
during the meeting and I asked if there was anything missed and promised to 
address or clarify them in draft revisions.

I have updated the draft two times since then and I believe I have addressed 
all the issues.  Please take a look at it and specifically point out why you 
think some issues are still not addressed. If you have other concerns, please 
also be specific. Thank you very much!

Haoyu

获取 Outlook for Android


发件人: Benoit Claise 
发送时间: 2019年12月17日星期二 上午4:56
收件人: Tianran Zhou; opsawg@ietf.org; 
draft-song-opsawg-ifit-framework.auth...@ietf.org
抄送: opsawg-cha...@ietf.org
主题: Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Dear all,

After reviewing the meeting 
minutes,
 I was a little bit puzzled. From my recollection, Joe and Frank had some good 
feedback on the draft.
Also, in the minutes, I did not see any mention of Joe's feedback. And Frank's 
feedback on the draft is summarized as 4 words: "the scope is large"
So I went back and reviewed the youtube 
video.

I support Frank's feedback that this document scope is too large: a mix of an 
inventory of what exists, a set of requirements, and specifications/framework. 
I'm wondering: what is the scope of this document? Before we clarify this, I 
don't think we should adopt this document.

The OPSAWG chair questions at the end of the presentation were:

Chair: How many of you have read this document? quite a lot.
Chair: How many of you think this is a useful work and the working 
group could
work on it? still many, 20+.

I was waiting for the negative question but to my surprise, it never came...

Chair: How many of you don't think ...


If that question would have been asked, I would have come to mic. or at least 
raised my hand.

It's important to make a distinction between the interest to solve those 
problems (I believe we have full agreement) and whether this document is a good 
starting point. I object to the latter, with the document in the current form.

Regards, Benoit
Hi WG,

On IETF 106 meeting, we saw predominant interest and support to this draft, 
especially from operators. The authors then resolved all the open issues.
As requested by the authors, this email starts a 2 weeks working group adoption 
call for draft-song-opsawg-ifit-framework-09.
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/

If you support adopting this document please say so, and please give an 
indication of why you think it is important. Also please say if you will be 
willing to review and help the draft.
If you do not support adopting this document as a starting point to work on, 
please say why.
This poll will run until Dec 23..

Thanks,
Tianran as co-chair



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] open issue discussion for the IFIT draft

[Haoyu Song]

Hi Joe,

So far we have received Diego's feedback on the issue #1 and we'll make 
modification according to his suggestion. Since there's no other comments on 
the issues, I consider they are all resolved. Therefore, I'd like to request 
the WG adoption of this draft. Thank you very much!

Best regards,
Haoyu

From: Haoyu Song
Sent: Wednesday, November 20, 2019 6:32 PM
To: opsawg-cha...@ietf.org; opsawg@ietf.org
Subject: open issue discussion for the IFIT draft

Hi OPSAWG chairs and participants,

https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/

In today's meeting I saw predominant interest and support to this draft, 
especially from operators. At the end of the presentation, Joe said there are 
still some open issues needed to be addressed before considering adoption. 
Below I list several open issues raised during the meeting and propose possible 
resolution. Please read the latest v08 version and feel free to add to the list 
if I missed anything or provide clarification if I misunderstood your concerns. 
Hopefully all these issues are addressed timely. Thank you very much!


1. The term of "closed-loop telemetry" is confusing. May consider to change it.

A: Although in the draft we have tried to clarify the difference between this 
term and the closed control loop in the context of network automation, there 
might still be confusions. Maybe "interactive telemtry" or"dyanmic telemtry" 
are better? We are open for suggestions.

2. The scope of the draft is too large to be covered by one draft.

A: There might be some misunderstandings about the purpose and scope of this 
draft. We think the message of this draft is simple. First, from a high level 
view, it discusses the possible applications of a class of related dataplane 
telemetry techniques. Second, the scope is quite limited and the discussion 
follow a simple logic: clarify and categorize the underlying techniques, then 
describe the application challenges from a system perspective, then describe a 
high level framework with a series possible points which can help address these 
challenges, and finally provide a summary of standard status and gaps in order 
to implement a standard-based solution. We have no intent to specify any 
implementation and interface.

We'll polish the writing to make the logic and flow clearer. If we don't catch 
any specific concerns, please spell out and we'll consider how to clarify them.

3. What's the difference between this draft and NTF draft?

A. Good question.  We should clarify this explicitly in the draft.  IFIT is 
specific to data plane while NTF is one level higher than it and covers all the 
three planes.  IFIT complies with NTF and provide more specific and detailed 
information.

4. The draft looks like a system solution. If so, it lacks details to guide the 
deployment and ensure compliance.

A. It shouldn't be considered as a mandatory specification or detailed 
deployment guide. It's just a high level framework with a few recommend 
components, without any constraints on specific implementation and interface, 
wheras we believe an actual implementation will more or less use the components 
in order to address the challenges. We will further polish the text to 
eliminate such confusion.

Haoyu
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

[Haoyu Song]

Hi Adrian,

Thank you for your support! Your suggestions for improvement are noted and will 
be reflected in the next revision.

Best,
Haoyu

From: Adrian Farrel 
Sent: Wednesday, December 11, 2019 6:33 AM
To: 'Tianran Zhou' ; opsawg@ietf.org; 
draft-song-opsawg-ifit-framework.auth...@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Hi,

I sent the authors comments on a previous version of the document and
the authors made updates to address my concerns.

Considering this adoption poll, I have done another review of the draft.
I think it provides a useful overview of in-situ telemetry approaches and
Will serve the WG well. I'm glad that the authors have included section
3.2 because draft-ietf-opsawg-ntf is also important work and we need to
progress the two documents in close relationship. I am also glad there
are good and clear references to the iOAM work.

I support adoption of the draft and commit to review it during WG
progress. I also have a few comments below: I don't think they need to
be addressed before adoption so long as they are picked up some time.

Thanks,
Adrian

===

The Abstract is about 10 lines too long. We should be aiming at no more
than 25 lines.

I would remove the first sentence. It is out of place and begs the
question of what "telemetry" means.

---

The style guide says that the "Requirements Language" should be placed
in the body of the document. I suggest you create Section 2.1 for it.

---

A couple of things with Section 4.4 worry me. Proposing new extension
headers for IPv4 is unlikely to go down well in the IETF where new work
on IPv4 is now frowned upon, and where IPv4 extension headers are
considered somewhat fragile. Additionally, I think you need to be very
careful with proposals around the Router Alert, and you shouldn't
mention it or RFC 2113 without also mentioning RFC 6398. Lastly, I think
that you may be giving too much attention to individual drafts that
possibly do not yet have a body of support in the IETF: in particular,
referencing draft-herbert-ipv4-eh may be premature.

---

I think we will need to give more attention to discussing security in
section 8. It is true that the details of the security for different
mechanisms are contained in the individual referenced documents. Our
focus in this document should be considering the overall security of
IFIT approaches. This should serve as a guide to the developers of the
various referenced documents, and it should provide observations on how
(or even if) to use IFIT systems.

From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of Tianran Zhou
Sent: 09 December 2019 05:27
To: opsawg@ietf.org; 
draft-song-opsawg-ifit-framework.auth...@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Hi WG,

On IETF 106 meeting, we saw predominant interest and support to this draft, 
especially from operators. The authors then resolved all the open issues.
As requested by the authors, this email starts a 2 weeks working group adoption 
call for draft-song-opsawg-ifit-framework-09.
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/

If you support adopting this document please say so, and please give an 
indication of why you think it is important. Also please say if you will be 
willing to review and help the draft.
If you do not support adopting this document as a starting point to work on, 
please say why.
This poll will run until Dec 23..

Thanks,
Tianran as co-chair
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Comments on draft-song-opsawg-ifit-framework-09

[Haoyu Song]

Hi Alex,

Thank you very much for your support and detailed review. We'll consider your 
suggestions in the next revision. They'll definitely help improve the quality 
of the draft. 

Best regards,
Haoyu

-Original Message-
From: Alexander L Clemm  
Sent: Tuesday, December 10, 2019 9:42 AM
To: draft-song-opsawg-ifit-framework.auth...@ietf.org
Cc: opsawg@ietf.org
Subject: Comments on draft-song-opsawg-ifit-framework-09

Hi Haoyu, Draft Authors,

after reading draft-song-ifit-framework-09, whose adoption I support, FWIW I 
have a few comments that I think should be addressed in future revisions of the 
draft:

Section 1, 2nd paragraph: line of argumentation why "radical rethinking of 
existing methods" needs to be strengthened.  While reasoning is given that the 
importance of monitoring and troubleshooting continues to grow, I don't think 
there are convincing arguments given why rethinking and new methods would be 
required, and the framework itself does not really propose such methods.

Section 1, C2: It should be mentioned that the growing OAM data can also 
negatively affect service levels.  For example, if telemetry data keeps getting 
added at each hop, not only does the packet grow but also its serialization 
delay, which could be detrimental in some cases. (Possibly this could even be 
listed as additional challenge C.2.5)

Section 3, in particular Figure 1: (I consider this my most important
comment):  I don't think the Figure and the introductory text that surrounds it 
does a framework justice.  What is being depicted in the figure seems to be a 
fairly generic monitoring/telemetry collection architecture, not a new 
framework, and made me even question why we would produce a document just for 
that?  Importantly, the key components of iFIT which are listed in section 4 
are not depicted in the Figure, nor are they mentioned as part of the framework 
in section 3.  I do think that those key components are important and their 
integration with the framework crucial.  A framework that explains how things 
like smart data export, smart flow selection, a choice of different probing 
techniques, etc complement each other and work in concert makes a lot of sense. 
 I think section 3 needs to be updated to make sure that it does not sell iFIT 
short.

Section 4 (or 3?):  The document should explain better why iFIT is called iFIT, 
not iPIT.  In other words, that it does not limit itself to packet telemetry, 
but indeed flow telemetry (which includes, for example, the aspects of probing 
and smart flow selection, which aim at getting a picture of flows in their 
entirety.  This aspect is important but easily lost on the reader.

Section 4.2 cannot be addressed by iFIT as it is currently stated, as it is 
missing an aggregation function.  I suggest that such a function is added and 
explicitly listed as a key component at the onset of section 4.

Section 4.5 likewise does not make it clear how its topic (on-demand technique 
selection and integration) gets addressed using the framework.  I think what 
section 4.5 is super important but some editing will be needed to make clear 
how these important aspects are being accomplished using the framework and its 
component.  As is, the framework and some of these aspects stand too much 
side-by-side.

Kind regards

--- Alex

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Comments for draft-song-opsawg-ifit-framework-05.txt

[Haoyu Song]

elkinguk%2Fdraft-song-opsawg-ifit-framework%2Fblob%2Fmasterdata=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=MKuRxT18X8EY%2BiuQ6y1eiB8G9n4mT1XVkJvvaq3AYME%3Dreserved=0
/draft-song-opsawg-ifit-framework-05-review-diff.html

I hope this helps. 
BR, Dan. 

-Original Message-
From: I-D-Announce  On Behalf Of 
internet-dra...@ietf.org
Sent: 26 September 2019 18:29
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-song-opsawg-ifit-framework-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : In-situ Flow Information Telemetry Framework
Authors : Haoyu Song
  Zhenbin Li
  Tianran Zhou
  Fengwei Qin
  Huanan Chen
  Jaewhan Jin
  Jongyoon Shin
Filename: draft-song-opsawg-ifit-framework-05.txt
Pages   : 16
Date: 2019-09-26

Abstract:
   Unlike the existing active and passive OAM techniques, the emerging
   on-path flow telemetry techniques provide unmatched visibility into
   user traffic, showing great application potential not only for
   today's network OAM but also for future's automatic network
   operation.  Summarizing the current industry practices that addresses
   the deployment challenges and application requirements, we provide a
   closed-loop framework, named In-situ Flow Information Telemetry
   (iFIT), for efficiently applying a family of underlying on-path flow
   telemetry techniques in various network environments.  The framework
   enumerates several key architectural components and describes how
   these components are assembled together to achieve a complete and
   closed-loop working solution for on-path flow telemetry.  Following
   such a framework allows better scalability, fosters application
   innovations, and promotes both vertical and horizontal
   interoperability.



The IETF datatracker status page for this draft is:
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-framework%2Fdata=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=tGinrvPEyB2d5Cb9eZE2HUPblxjEyW0Ej%2F9VLPIH%2F%2BA%3Dreserved=0

There are also htmlized versions available at:
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-song-opsawg-ifit-framework-05data=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=zQGoZucgrTGuHKS0M2H5bUF%2F%2Fqr6kbN%2B9h0ZnQWtKwk%3Dreserved=0
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-song-opsawg-ifit-framework-05data=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=wRFvnHU1BrLfN1PKr7dfBLFc07dG2fc%2FfuKKpZ0YMWI%3Dreserved=0

A diff from the previous version is available at:
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-song-opsawg-ifit-framework-05data=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=dHzyr3fAtL2ipwlX80Ppo%2FCm5OjQn%2BHtTc%2FDxjMFShA%3Dreserved=0


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announcedata=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=UxHbAlLC%2F9llj1lt%2FkEmztCNpdogm%2B%2Bxlayw1FFKtso%3Dreserved=0
Internet-Draft directories: 
https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ietf.org%2Fshadow.htmldata=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=IgxxFOuX%2Fl0DD%2Fu%2Fmiqsn%2BQ0mRMWP%2BXJjl7J9H%2Fb8CI%3Dreserved=0
 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
OPSAWG mailing list
OPSAWG@ietf.org
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawgdata=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095

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

[Haoyu Song]

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/

Best regards,
Haoyu
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Haoyu Song]

Hi Frank,

IOAM is one of the techniques covered by iFIT, although an important one. In 
the draft, we include many others (we may omit some but we’ll include them once 
we are aware of them), the reason for that is also discussed in the draft: we 
don’t expect one technique can meet all the data plane telemetry requirements. 
In the future, it’s very likely we’ll end up with multiple options, each with 
its own applicability and advantages.

Also, this draft doesn’t meant to summarize such techniques. Rather, it 
provides a solution framework which may apply one or more such underlying 
techniques. While we have listed all the issues and challenges we know so far, 
we do want to add more operational experiences as the draft progresses. To this 
end, we request collaborations and contributions from all the operators and 
vendors. We believe this will benefit the entire community.

Best,
Haoyu

From: Frank Brockners (fbrockne) 
Sent: Friday, October 25, 2019 7:03 AM
To: qinfengwei ; Haoyu Song 
; Joe Clarke (jclarke) 
Cc: opsawg@ietf.org; opsawg-cha...@ietf.org
Subject: RE: [OPSAWG] Call for Adoption "draft-song-opsawg-ifit-framework"

Hi Fengwei Qin,

thanks a lot for the additional context. You confirm that “iFIT nodes” etc. are 
indeed new functions with data plane and control plane functionality that refer 
to a specific deployment that you’ve done. BTW/ - as a side note: It was 
surprising to me that despite your deployment seems to be based on 
draft-cheng-mpls-inband-pm-encapsulation – the draft-song-opsawg-ifit-framework 
does not even mention it.
We’re all aware that there are several proprietary solutions that resemble 
IOAM.  We started the IOAM effort several years ago in IETF to jointly arrive 
at a standard that allows for multivendor interoperable solutions.  Focusing on 
yet another variant of IOAM isn’t really moving the industry forward.

Rather than trying to write a generic document which seems to try to provide an 
overview of “what is out there” it would be much more helpful, if you could 
provide a detailed description of the issues and experiences (more specific and 
detailed than what you have in section 1 of draft-song-opsawg-ifit-framework) 
that you encountered in your deployment. Based on that understanding, we could 
jointly explore how to evolve the existing standardization effort on IOAM.

Thanks, Frank

From: qinfengwei mailto:qinfeng...@chinamobile.com>>
Sent: Freitag, 25. Oktober 2019 07:35
To: Frank Brockners (fbrockne) mailto:fbroc...@cisco.com>>; 
'Haoyu Song' mailto:haoyu.s...@futurewei.com>>; Joe 
Clarke (jclarke) mailto:jcla...@cisco.com>>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
Subject: 答复: [OPSAWG] Call for Adoption "draft-song-opsawg-ifit-framework"

Hi Frank,

Speaking as the co-author, I think the abstraction described well the scope:

   In-situ Flow Information Telemetry (iFIT) provides a method for
   efficiently applying underlying on-path flow telemetry techniques,
   applicable across various network environments.

   This document outlines the iFIT framework, which enumerates several
   critical functional components and describes how these components are
   assembled together to achieve a complete and closed-loop working
   solution for on-path flow telemetry.

We, China Mobile, have deployed one IFIT data plane with many vendor supports.
https://datatracker.ietf.org/doc/draft-cheng-mpls-inband-pm-encapsulation/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cheng-mpls-inband-pm-encapsulation%2F=02%7C01%7Chaoyu.song%40futurewei.com%7C1138aa61827241949d1a08d75954129d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637076089965871536=IrxMLx0vMPvvXoOuRTdly2C0V%2FndlZDzzM8YP%2FKQFeE%3D=0>

We compared and chose the suitable data plane. We considered the forwarding 
performance.
We also considered how to reduce the data export to the controller. And so on.
Data plane is not the only thing as in a complete solution.
We want to see this be generalized in a framework to achieve a complete and 
closed-loop working solution for on-path flow telemetry.

The document is not complete yet, some parts like section 3.6 and 4 are newly 
added into the draft according to the comments from the mailing list.
Your contributions are welcome.

Thanks,
Fengwei Qin

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Frank Brockners (fbrockne)
发送时间: 2019年10月25日 00:42
收件人: Haoyu Song; Joe Clarke (jclarke)
抄送: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
主题: Re: [OPSAWG] Call for Adoption "draft-song-opsawg-ifit-framework"

Just took a read through the document as well – 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 se

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

[Haoyu Song]

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) 
Sent: Thursday, October 24, 2019 9:42 AM
To: Haoyu Song ; Joe Clarke (jclarke) 

Cc: opsawg@ietf.org; opsawg-cha...@ietf.org
Subject: RE: Call for Adoption "draft-song-opsawg-ifit-framework"

Just took a read through the document as well – 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. – 
but none of things are defined in the document.

Cheers, Frank

From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of Haoyu Song
Sent: Mittwoch, 23. Oktober 2019 11:43
To: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
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) mailto:jcla...@cisco.com>>
Sent: Tuesday, October 22, 2019 3:48 PM
To: Haoyu Song mailto:haoyu.s...@futurewei.com>>
Cc: opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>
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”?

Ultimate

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

[Haoyu Song]

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) 
Sent: Tuesday, October 22, 2019 3:48 PM
To: Haoyu Song 
Cc: opsawg-cha...@ietf.org; opsawg@ietf.org
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 
mailto:haoyu.s...@futurewei.com>> 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=02%7C01%7Chaoyu.song%40futurewei.com%7Cda0fc97e527c49ed97ff08d75741e18d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637073812783772433=rDJ4qcmsAD2IqXhKMGOh%2BEFnxFFdsxHHXGANBzcv0uI%3D=0>

Best regards,
Haoyu

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Substitutes for the term "closed-loop telemetry"

[Haoyu Song]

Hi Diego,

Thanks for the suggestion! I have summarized the feedback in our open issue 
list. I’ll make modifications in our next revision.

Best regards,
Haoyu

From: OPSAWG  On Behalf Of Diego R. Lopez
Sent: Sunday, December 01, 2019 4:54 PM
To: opsawg@ietf.org
Subject: [OPSAWG] Substitutes for the term "closed-loop telemetry"

Hi,

As you surely recall, I expressed serious concerns about the use of 
“closed-loop telemetry” in draft-song-opsawg-ifit-framework and related docs.  
The term seems to me highly misleading, as “closed-loop” is usually applied to 
network control and orchestration, and it would be difficult to distinguish 
when we are talking of one “closed-loop” or another. I’d propose to use 
“just-in-time telemetry” or “reflective telemetry” to indicate how the 
telemetry is provided according to concrete and present needs (thus just in 
time), or as a result of an action based on self-knowledge (hence reflective)

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] open issue discussion for the IFIT draft

[Haoyu Song]

Hi OPSAWG chairs and participants,

https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/

In today's meeting I saw predominant interest and support to this draft, 
especially from operators. At the end of the presentation, Joe said there are 
still some open issues needed to be addressed before considering adoption. 
Below I list several open issues raised during the meeting and propose possible 
resolution. Please read the latest v08 version and feel free to add to the list 
if I missed anything or provide clarification if I misunderstood your concerns. 
Hopefully all these issues are addressed timely. Thank you very much!


1. The term of "closed-loop telemetry" is confusing. May consider to change it.

A: Although in the draft we have tried to clarify the difference between this 
term and the closed control loop in the context of network automation, there 
might still be confusions. Maybe "interactive telemtry" or"dyanmic telemtry" 
are better? We are open for suggestions.

2. The scope of the draft is too large to be covered by one draft.

A: There might be some misunderstandings about the purpose and scope of this 
draft. We think the message of this draft is simple. First, from a high level 
view, it discusses the possible applications of a class of related dataplane 
telemetry techniques. Second, the scope is quite limited and the discussion 
follow a simple logic: clarify and categorize the underlying techniques, then 
describe the application challenges from a system perspective, then describe a 
high level framework with a series possible points which can help address these 
challenges, and finally provide a summary of standard status and gaps in order 
to implement a standard-based solution. We have no intent to specify any 
implementation and interface.

We'll polish the writing to make the logic and flow clearer. If we don't catch 
any specific concerns, please spell out and we'll consider how to clarify them.

3. What's the difference between this draft and NTF draft?

A. Good question.  We should clarify this explicitly in the draft.  IFIT is 
specific to data plane while NTF is one level higher than it and covers all the 
three planes.  IFIT complies with NTF and provide more specific and detailed 
information.

4. The draft looks like a system solution. If so, it lacks details to guide the 
deployment and ensure compliance.

A. It shouldn't be considered as a mandatory specification or detailed 
deployment guide. It's just a high level framework with a few recommend 
components, without any constraints on specific implementation and interface, 
wheras we believe an actual implementation will more or less use the components 
in order to address the challenges. We will further polish the text to 
eliminate such confusion.

Haoyu
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Comments for draft-song-opsawg-ifit-framework-05.txt

[Haoyu Song]

0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=MKuRxT18X8EY%2BiuQ6y1eiB8G9n4mT1XVkJvvaq3AYME%3Dreserved=0
/draft-song-opsawg-ifit-framework-05-review-diff.html

I hope this helps. 
BR, Dan. 

-Original Message-
From: I-D-Announce  On Behalf Of 
internet-dra...@ietf.org
Sent: 26 September 2019 18:29
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-song-opsawg-ifit-framework-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : In-situ Flow Information Telemetry Framework
Authors : Haoyu Song
  Zhenbin Li
  Tianran Zhou
  Fengwei Qin
  Huanan Chen
  Jaewhan Jin
  Jongyoon Shin
Filename: draft-song-opsawg-ifit-framework-05.txt
Pages   : 16
Date: 2019-09-26

Abstract:
   Unlike the existing active and passive OAM techniques, the emerging
   on-path flow telemetry techniques provide unmatched visibility into
   user traffic, showing great application potential not only for
   today's network OAM but also for future's automatic network
   operation.  Summarizing the current industry practices that addresses
   the deployment challenges and application requirements, we provide a
   closed-loop framework, named In-situ Flow Information Telemetry
   (iFIT), for efficiently applying a family of underlying on-path flow
   telemetry techniques in various network environments.  The framework
   enumerates several key architectural components and describes how
   these components are assembled together to achieve a complete and
   closed-loop working solution for on-path flow telemetry.  Following
   such a framework allows better scalability, fosters application
   innovations, and promotes both vertical and horizontal
   interoperability.



The IETF datatracker status page for this draft is:
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-framework%2Fdata=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=tGinrvPEyB2d5Cb9eZE2HUPblxjEyW0Ej%2F9VLPIH%2F%2BA%3Dreserved=0

There are also htmlized versions available at:
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-song-opsawg-ifit-framework-05data=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=zQGoZucgrTGuHKS0M2H5bUF%2F%2Fqr6kbN%2B9h0ZnQWtKwk%3Dreserved=0
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-song-opsawg-ifit-framework-05data=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=wRFvnHU1BrLfN1PKr7dfBLFc07dG2fc%2FfuKKpZ0YMWI%3Dreserved=0

A diff from the previous version is available at:
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-song-opsawg-ifit-framework-05data=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=dHzyr3fAtL2ipwlX80Ppo%2FCm5OjQn%2BHtTc%2FDxjMFShA%3Dreserved=0


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announcedata=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=UxHbAlLC%2F9llj1lt%2FkEmztCNpdogm%2B%2Bxlayw1FFKtso%3Dreserved=0
Internet-Draft directories: 
https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ietf.org%2Fshadow.htmldata=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=IgxxFOuX%2Fl0DD%2Fu%2Fmiqsn%2BQ0mRMWP%2BXJjl7J9H%2Fb8CI%3Dreserved=0
 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
OPSAWG mailing list
OPSAWG@ietf.org
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawgdata=02%7C01%7Chaoyu.song%40futurewei.com%7Cf4f7a57161ce480043f008d74bc3e46c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637061177051023095sdata=fSTqkuPTaO2ts2wksNO5k%2Fb3rMKN5D%2BW51RZPBqjgFM%3Dreserved=0

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

[Haoyu Song]

Hi Frank,

Thank you very much for the feedback. However I want to clarify a few things.

The core of the draft is a framework for data plane on-path telemetry. It's not 
a dedicated requirement document, neither a survey. The challenges we described 
are just used to motivate the framework. The standard gap analysis is also 
necessary to show how this framework can be implemented in the future.  While I 
agree the document is not perfect and still need to improve, I think the main 
information and logic flow are clear. I also think the document is 
self-sufficient. It's just a high level guide for future development but 
doesn't intend to put any constraints. 

I said “Other documents might also be needed but they are out of scope of this 
one”, not to reference some non-existing document, but to respond to your 
previous email in which you suggest other documents like survey and deployment 
experience etc.  This document does not server those purpose.

While you ask for detailed specification (up to the level about how the 
controller to configure the nodes and what data to export, etc.) , you may 
still think from a perspective that this document is a solution specification, 
but it's not. I'm very sorry for that impression. We already emphasized in the 
document that we don’t intend to specify any interface and implementation 
details, but to describe high level functions. To server that purpose, a loose 
definition for the terms is enough and proper.

For example, we define iFIT Node as "a network node that is in an iFIT domain 
and is capable of iFIT-specific functions." So yes it forwards and processes 
traffic. I don't think anybody will misunderstand this. You ask how,  for which 
we can only provide high level function descriptions but won't specify any 
detail because we have made it very clear that's not the intention of this 
document.

So let's just focus on the current scope and content of the document, to see if 
it's useful and valuable to the community as a whole. From the majority 
responses, mostly from real network operators, the feedbacks are so far very 
positive and they all support the adoption of this document. I think that says 
something.

Best regards,
Haoyu  



-Original Message-
From: Frank Brockners (fbrockne)  
Sent: Thursday, December 19, 2019 6:23 AM
To: Haoyu Song ; opsawg ; 
draft-song-opsawg-ifit-framework.authors 

Cc: opsawg-chairs 
Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Haoyu,

you and your co-authors need to decide what the document is intended to be: A 
requirements document, an industry implementation survey, or a specification? 
Right now the document is a bit of everything – with nothing is appropriately 
spelled out and detailed for a standards document.

Depending on that decision, here is how you could evolve the document:
If the document is intended as a requirements document:
 - expand the requirements part of section 1
 - remove all references to iFIT and similar – none of this is needed to 
articulate requirements If the document is intended as an industry survey:
 - provide comprehensive inventory of available implementation
 - focus on what is available / deployed and discuss experiences
 - remove all references to iFIT and similar that try to specify things – none 
of this is needed to for an industry survey If the document is intended as a 
specification or case study
 - provide technical specifications for IFIT node, IFIT application, IFIT Head 
Node, IFIT End Node, etc. I.e. explain how these “things” work and operate. 
What is their control plane, what is their data plane, etc.? Make sure that 
you’re not creating “empty shells” that are to be defined at a later stage. An 
approach to create forward references to currently non existing documents like 
“Other documents might also be needed but they are out of scope of this one” 
(see your message below) are not appropriate for a specification.
 - if you believe that your IFIT specification has nothing to do with Huawei’s 
IFIT proprietary implementation (i.e. 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-ctc.huawei.com%2Fke%2Fpress-events%2Fnews%2F2019%2F6%2Ffirst-ifit-pilot-5g-transport-network-beijing-unicom-huaweidata=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155305143sdata=vlsft6Tj%2BuI2rH6NCdZO0qf2O7%2BR9KSI0b%2FF0bjEkoY%3Dreserved=0)
 then I strongly suggest that you choose a different name for your 
implementation. 

Just to highlight that different from what you say, the specification of IFIT 
elements neither helps in articulating requirements nor does it support 
different industry solutions: If you take the example of an “IFIT Node” – there 
is a total of 8 occurrences in the document, with 5 of them in the main part of 
the document. The document defines “iFIT Node” as “a network node that is in an 
iFIT domain and 

Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

[Haoyu Song]

Again, I need to point out the fact that I have listed all the questions raised 
during the meeting (including Frank's and Joe's) and I asked if I missed 
anything or misunderstood anything in an email to the list. But I didn't got 
any feedback from the queationers, so I believed  I had correctly understood 
the questions and then made updates accordingly. So, I don't understand why 
Frank still use the meeting video to question the draft. Please read and answer 
my email and draft, and let me know what you are not agree with based on that.

Alos, we have specified all the terms we used in the draft. Please take time to 
read it.

IFIT is NOT a proprietary solution.  Period.  I  don't think anybody can gain 
such a feeling from reading it.   There's no solution but requirement, 
challenges, a high level framework, examples, and standard gap analysis. How 
can it be a solution?


Other documents might also be needed but they are out of scope of this one.  I 
firmly believe this one is also needed for the reason we clearly stated in the 
draft.

Thanks!

Haoyu


获取 Outlook for Android


发件人: Frank Brockners (fbrockne) 
发送时间: 2019年12月18日星期三 下午1:01
收件人: opsawg; draft-song-opsawg-ifit-framework.authors
抄送: opsawg-chairs
主题: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Are we following our practices and procedures properly? For the record, in case 
others are equally puzzled about this call for adoption:

* Different from what the co-chair states in his WG adoption call below (“The 
authors then resolved all the open issues”), 
draft-song-opsawg-ifit-framework-09 does NOT resolve all open issues nor does 
the document reflect all the WG feedback received at IETF 106.

* The WG minutes 
(https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F106%2Fmaterials%2Fminutes-106-opsawg-01data=02%7C01%7Chaoyu.song%40futurewei.com%7Cd612052cb289412e17f208d783fd63b3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637122996651740817sdata=i%2F4PXRzCKeMFFazIxZID0MAg6rvAUmK6VcY8vZiEbcg%3Dreserved=0)
 miss a significant portion of comments and feedback as Benoit rightly points 
out below. E.g. Joe Clarke’s (as individual) comments are NOT mentioned at all, 
my comments are misrepresented.

* The authors did NOT reflect any of the comments made by myself (see 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2FrY-u8177wpU%3Ft%3D3785data=02%7C01%7Chaoyu.song%40futurewei.com%7Cd612052cb289412e17f208d783fd63b3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637122996651740817sdata=sSqjl1ZmiBhcwyxiFb%2B1dXsti4ChmS%2BXBuZ0HoWqlj0%3Dreserved=0)
 or by Joe Clarke. IMHO this is NOT appropriate for editors of a “soon to be” 
WG document.

* draft-song-opsawg-ifit-framework-09 introduces a lot of new entities, e.g. 
IFIT Applications, IFIT Domain, IFIT Node, IFIT End-Node, etc. None of these 
entities are specified in the document, which means that the IETF would endorse 
a framework without even understanding the components/entities of the 
framework. The presenter responded 
(https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2FrY-u8177wpU%3Ft%3D3867data=02%7C01%7Chaoyu.song%40futurewei.com%7Cd612052cb289412e17f208d783fd63b3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637122996651740817sdata=HUmKp9GhOKybPjVCjCqcMBG3iRv6pyeUq93JR%2FHNMGQ%3Dreserved=0
 ) that it would be just a “very high level framework” that should fit any 
existing solution. If everything fits, i.e. “I FIT”, “You FIT”, “We all Fit”, … 
then why do we even need the definition of new entities? There is NO need to 
define “empty shells” for a lot of new entities, if all what the authors intend 
to do is compare different solutions.

* Different from what the presenter claimed, IFIT is NOT just “a high-level 
framework”, but IFIT is a proprietary Huawei technology, see e.g. 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-ctc.huawei.com%2Fke%2Fpress-events%2Fnews%2F2019%2F6%2Ffirst-ifit-pilot-5g-transport-network-beijing-unicom-huaweidata=02%7C01%7Chaoyu.song%40futurewei.com%7Cd612052cb289412e17f208d783fd63b3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637122996651740817sdata=qeAPmV9PDxmq%2FeJ07mQO1%2BYc7bCdfrkfYF4peyhzqUw%3Dreserved=0.
 Public specifications for IFIT don’t seem to be available, with the exception 
of draft-li-6man-ipv6-sfc-ifit-02 which introduces new encapsulations. I.e. 
IFIT-Nodes, IFIT-End-Nodes etc. do exist �C we just don’t know what they do. 
Looking at the people who responded to the adoption thread so far, one could 
also read the responses as a desire for a detailed documentation of the 
specification and lessons learned from deployments of Huawei’s IFIT.

Different from draft-song-opsawg-ifit-framework-09, which I do NOT support the 
adoption of, the following documents might be worthwhile documents (especially 
given the broad interest) to create/share:

Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

[Haoyu Song]

Frank,

This status of this document is "informational", not "standard". Please show me 
what's and what's not appropriate for an informational document. 

Haoyu
-Original Message-
From: Frank Brockners (fbrockne)  
Sent: Thursday, December 19, 2019 11:10 PM
To: Haoyu Song ; opsawg ; 
draft-song-opsawg-ifit-framework.authors 

Cc: opsawg-chairs 
Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Haoyu,

Thanks. Reading through your response below, you still don't seem to follow 
what I say. The document in its current form isn't appropriate as a standards 
document. That is why I suggested a couple of options to make it one - which 
you seem to ignore. The fact that several people find it useful does make it an 
appropriate standards document. E.g. a Huawei whitepaper might also be 
considered useful by several people, still a whitepaper is not a standards 
document. 

And per what I said earlier, if you decide to evolve your document towards a 
properly scoped specification, make sure that you choose a proper and 
non-confusing name. If your IFIT is really different from Huawei's IFIT, then 
just call it something else. Even your co-worker Alex Clemm was suggesting a 
name change.

Happy holidays.

Frank

> -Original Message-
> From: Haoyu Song 
> Sent: Donnerstag, 19. Dezember 2019 19:01
> To: Frank Brockners (fbrockne) ; opsawg 
> ; draft-song-opsawg-ifit-framework.authors 
> 
> Cc: opsawg-chairs 
> Subject: RE: [OPSAWG] WG adoption call for 
> draft-song-opsawg-ifit-framework-
> 09
> 
> Hi Frank,
> 
> Thank you very much for the feedback. However I want to clarify a few things.
> 
> The core of the draft is a framework for data plane on-path telemetry. 
> It's not a dedicated requirement document, neither a survey. The 
> challenges we described are just used to motivate the framework. The 
> standard gap analysis is also necessary to show how this framework can 
> be implemented in the future.  While I agree the document is not 
> perfect and still need to improve, I think the main information and logic 
> flow are clear. I also think the document is self-sufficient.
> It's just a high level guide for future development but doesn't intend 
> to put any constraints.
> 
> I said “Other documents might also be needed but they are out of scope 
> of this one”, not to reference some non-existing document, but to 
> respond to your previous email in which you suggest other documents 
> like survey and deployment experience etc.  This document does not server 
> those purpose.
> 
> While you ask for detailed specification (up to the level about how 
> the controller to configure the nodes and what data to export, etc.) , 
> you may still think from a perspective that this document is a 
> solution specification, but it's not. I'm very sorry for that 
> impression. We already emphasized in the document that we don’t intend 
> to specify any interface and implementation details, but to describe 
> high level functions. To server that purpose, a loose definition for the 
> terms is enough and proper.
> 
> For example, we define iFIT Node as "a network node that is in an iFIT 
> domain and is capable of iFIT-specific functions." So yes it forwards 
> and processes traffic. I don't think anybody will misunderstand this. 
> You ask how,  for which we can only provide high level function 
> descriptions but won't specify any detail because we have made it very clear 
> that's not the intention of this document.
> 
> So let's just focus on the current scope and content of the document, 
> to see if it's useful and valuable to the community as a whole. From 
> the majority responses, mostly from real network operators, the 
> feedbacks are so far very positive and they all support the adoption 
> of this document. I think that says something.
> 
> Best regards,
> Haoyu
> 
> 
> 
> -Original Message-
> From: Frank Brockners (fbrockne) 
> Sent: Thursday, December 19, 2019 6:23 AM
> To: Haoyu Song ; opsawg ; 
> draft-song-opsawg-ifit-framework.authors  framework.auth...@ietf.org>
> Cc: opsawg-chairs 
> Subject: RE: [OPSAWG] WG adoption call for 
> draft-song-opsawg-ifit-framework-
> 09
> 
> Haoyu,
> 
> you and your co-authors need to decide what the document is intended 
> to be: A requirements document, an industry implementation survey, or a 
> specification?
> Right now the document is a bit of everything – with nothing is 
> appropriately spelled out and detailed for a standards document.
> 
> Depending on that decision, here is how you could evolve the document:
> If the document is intended as a requirements document:
>  - expand the requirements part of section 1
>  - remove all references 

Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

[Haoyu Song]

FYI,  the text below is quoted form RFC2026:
"
An "Informational" specification is published for the general information of 
the Internet community, and does not represent an Internet community consensus 
or recommendation. The Informational designation is intended to provide for the 
timely publication of a very broad range of responsible informational documents 
from many sources, subject only to editorial considerations and to verification 
that there has been adequate coordination with the standards process (see 
section 4.2.3).

Specifications that have been prepared outside of the Internet community and 
are not incorporated into the Internet Standards Process by any of the 
provisions of section 10 may be published as Informational RFCs, with the 
permission of the owner and the concurrence of the RFC Editor.
"
-Original Message-----
From: Haoyu Song 
Sent: Friday, December 20, 2019 9:45 AM
To: Frank Brockners (fbrockne) ; opsawg ; 
draft-song-opsawg-ifit-framework.authors 

Cc: opsawg-chairs 
Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Frank,

This status of this document is "informational", not "standard". Please show me 
what's and what's not appropriate for an informational document. 

Haoyu
-Original Message-
From: Frank Brockners (fbrockne) 
Sent: Thursday, December 19, 2019 11:10 PM
To: Haoyu Song ; opsawg ; 
draft-song-opsawg-ifit-framework.authors 

Cc: opsawg-chairs 
Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Haoyu,

Thanks. Reading through your response below, you still don't seem to follow 
what I say. The document in its current form isn't appropriate as a standards 
document. That is why I suggested a couple of options to make it one - which 
you seem to ignore. The fact that several people find it useful does make it an 
appropriate standards document. E.g. a Huawei whitepaper might also be 
considered useful by several people, still a whitepaper is not a standards 
document. 

And per what I said earlier, if you decide to evolve your document towards a 
properly scoped specification, make sure that you choose a proper and 
non-confusing name. If your IFIT is really different from Huawei's IFIT, then 
just call it something else. Even your co-worker Alex Clemm was suggesting a 
name change.

Happy holidays.

Frank

> -----Original Message-
> From: Haoyu Song 
> Sent: Donnerstag, 19. Dezember 2019 19:01
> To: Frank Brockners (fbrockne) ; opsawg 
> ; draft-song-opsawg-ifit-framework.authors
> 
> Cc: opsawg-chairs 
> Subject: RE: [OPSAWG] WG adoption call for
> draft-song-opsawg-ifit-framework-
> 09
> 
> Hi Frank,
> 
> Thank you very much for the feedback. However I want to clarify a few things.
> 
> The core of the draft is a framework for data plane on-path telemetry. 
> It's not a dedicated requirement document, neither a survey. The 
> challenges we described are just used to motivate the framework. The 
> standard gap analysis is also necessary to show how this framework can 
> be implemented in the future.  While I agree the document is not 
> perfect and still need to improve, I think the main information and logic 
> flow are clear. I also think the document is self-sufficient.
> It's just a high level guide for future development but doesn't intend 
> to put any constraints.
> 
> I said “Other documents might also be needed but they are out of scope 
> of this one”, not to reference some non-existing document, but to 
> respond to your previous email in which you suggest other documents 
> like survey and deployment experience etc.  This document does not server 
> those purpose.
> 
> While you ask for detailed specification (up to the level about how 
> the controller to configure the nodes and what data to export, etc.) , 
> you may still think from a perspective that this document is a 
> solution specification, but it's not. I'm very sorry for that 
> impression. We already emphasized in the document that we don’t intend 
> to specify any interface and implementation details, but to describe 
> high level functions. To server that purpose, a loose definition for the 
> terms is enough and proper.
> 
> For example, we define iFIT Node as "a network node that is in an iFIT 
> domain and is capable of iFIT-specific functions." So yes it forwards 
> and processes traffic. I don't think anybody will misunderstand this.
> You ask how,  for which we can only provide high level function 
> descriptions but won't specify any detail because we have made it very clear 
> that's not the intention of this document.
> 
> So let's just focus on the current scope and content of the document, 
> to see if it's useful and valuable to the community as a whole. From 
> the majority responses, mostly from r

Re: [OPSAWG] extend the call//RE: WG adoption call for draft-song-opsawg-ifit-framework-09

[Haoyu Song]

OPSAWG,

Based on the feedbacks from Frank, Al, Adrian, Alex, and others,  I have 
updated the draft with modifications and new text/figures. The major 
modifications are summarized as follows.  Please let me know if these addressed 
your concerns.


  1.  Add a Scope subsection to clarify the scope of the draft.  Basically, the 
proposed informational framework is nonmandatory. It suggests a high-level 
framework to address some practical deployment challenges for a class of 
on-path telemetry techniques. It doesn't define the component and interface 
specifications and implementation details.
  2.  Categorize the on-path telemetry techniques discussed in the draft as 
Hybrid Type I, conforming to RFC7799.
  3.  Detail the description of the framework with clearer term definitions and 
block diagrams. Add a framework architecture figure. A block diagram is added 
for each component. Match each component to the corresponding component in 
Network Telemetry Framework.
  4.  Clarify this work doesn't conflict or overlap with existing works in 
other WGs such as IPPM.
  5.  Remove the references to some premature or expired drafts.
  6.  Some document structure adjustments and numerous other modification in 
response to the detail comments.
Happy New Year!

Best,
Haoyu

From: OPSAWG  On Behalf Of Tianran Zhou
Sent: Wednesday, December 25, 2019 10:14 PM
To: opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: [OPSAWG] extend the call//RE: WG adoption call for 
draft-song-opsawg-ifit-framework-09

Working Group,

Thank you for all of your emails related to draft-song-opsawg-ifit-framework.
It seems there are a lot of interested people. I hope the authors will be 
encouraged by that.
But there were also some strong concerns about the scope of the draft. What is 
it trying to achieve? How does that match the charter? Does it include material 
that is outside its scope? Thanks specially to Frank and Al for saying their 
concerns.
We are going to extend the adoption call for another two weeks to Jan 8. And we 
encourage the inter-working group discussion.
Please continue to discuss on the mailing list.

Merry Christmas!
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Monday, December 9, 2019 1:27 PM
To: opsawg@ietf.org; 
draft-song-opsawg-ifit-framework.auth...@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Hi WG,

On IETF 106 meeting, we saw predominant interest and support to this draft, 
especially from operators. The authors then resolved all the open issues.
As requested by the authors, this email starts a 2 weeks working group adoption 
call for draft-song-opsawg-ifit-framework-09.
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/

If you support adopting this document please say so, and please give an 
indication of why you think it is important. Also please say if you will be 
willing to review and help the draft.
If you do not support adopting this document as a starting point to work on, 
please say why.
This poll will run until Dec 23..

Thanks,
Tianran as co-chair
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

[Haoyu Song]

Hi Al,

Thank you very much for the comments. Please see my inline response marked with 
[HSong]. Happy Holidays!

Best regards,
Haoyu

-Original Message-
From: ippm  On Behalf Of MORTON, ALFRED C (AL)
Sent: Saturday, December 21, 2019 5:13 PM
To: adr...@olddog.co.uk; 'Frank Brockners (fbrockne)' ; 
'opsawg' 
Cc: ibagd...@gmail.com; i...@ietf.org; 'opsawg-chairs' 
; Mirja Kühlewind (IETF) ; Warren 
Kumari 
Subject: Re: [ippm] [OPSAWG] WG adoption call for 
draft-song-opsawg-ifit-framework-09

Hi OPSAWG, and IPPM WG,

The adoption call for this draft is somewhat controversial, so I looked into a 
few details and background discussions, especially the e-mail thread for the 
call for adoption and the draft itself.

I have read messages expressing concern over the scope of this work, and note 
that the draft does not have a Scope section (or material that fulfils this 
need concisely).
It would certainly be easier for the WG to reach consensus whether to adopt or 
not if the scope was clear.

From the OPSAWG Charter:
The focus of the work will be on topics that govern the behavior or WGs
in the O area (e.g., manageability requirements) and on *small,
highly focused projects that don't merit a WG of their own* or belong
to WGs that have already concluded (e.g. advancement of documents on
the standards track, application statements, extensions of MIB
modules).
This seems to be the relevant paragraph under which the draft might be 
considered as in-scope, but I don't see a direct match here, especially 
recognizing the additional work to fill gaps described in Section 6. A draft 
with wide scope seems better positioned as a new WG-level effort, if it is 
undertaken by IETF, IMO.

[HSong]  I'll add a scope section to clearly define the scope of the draft. 
Although the draft discussed some potential standard gaps but the draft itself 
won't serve to fill the gap but to inspire possible future works. 

I have cross-posted this message to the IPPM WG, where work-in-progress 
includes 4 IOAM-related drafts. The topic origins go back to 2016, with the 
first IPPM WG adoption almost
3 years ago. Later, this general Framework draft appears (2018) having overlap 
with the IPPM work and discussing some of the same problems (even hinting at 
solutions in various places).
IMO, there is more coordination needed here before another IETF Area adopts 
work with clear relevance/overlap (see the 4th paragraph of Section 1, 
Requirements and Challenges and its many references).

[HSong] This draft describes a high level framework and doesn't introduce any 
new underlying measurement technique. It's akin to the NTF draft which was 
adopted by OPSAWG. It just discuss in a general way how to apply a specific set 
of techniques developed in IPPM WG.  

Also, I note this draft's attempt to define a new category of methods of 
measurement (4th paragraph of Section 1, last 2 sentences):

   ... These on-path telemetry techniques are
   very different from the previous active and passive OAM schemes in
   that they directly modify the user packets and can guarantee 100%
   accuracy.  These on-path telemetry techniques can be classified as
   the hybrid OAM type III, supplementing the classification defined in
   [RFC7799].

There isn't enough information supplied to make such a decision, especially 
since the RFC 7799 categories were agreed to be fairly exhaustive, and IOAM 
discussions agreed on one of the existing classifications (Hybrid Type I).

[HSong] After carefully reading  RFC7799, I think it is very likely these 
techniques should be categorized as Hybrid Type I  
“With respect to a *single* stream of interest, Hybrid Type I methods fit in 
the continuum as follows, in terms of what happens at the Source (or 
Observation Point nearby): Augmentation or modification of the stream of 
interest, or employment of methods that modify the treatment of the stream =>  
Hybrid Type I”. 
If we have consensus on this, since this draft covers a class of closely 
related techniques, I think we should document it here.   

For these reasons, I support further discussion of this draft and cannot 
recommend OPSAWG adoption at this point in time. I believe this topic needs 
wider coordination now.

Finally, I echo Adrian's wishes for peace and goodwill as the holidays approach.

Al


> -Original Message-
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Adrian 
> Farrel
> Sent: Saturday, December 21, 2019 5:47 PM
> To: 'Frank Brockners (fbrockne)' ; 'Haoyu Song'
> ; 'opsawg' ; 'draft-song- 
> opsawg-ifit-framework.authors'  framework.auth...@ietf.org>
> Cc: 'opsawg-chairs' 
> Subject: Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-
> framework-09
> 
> I think this discussion might have gotten a little out of hand!
> 
> Frank is clearly upset that his comments at the microphone did not 
> make it into the minutes. I think we all have 

Re: [OPSAWG] extend the call//RE: WG adoption call for draft-song-opsawg-ifit-framework-09

[Haoyu Song]

Hi Warren,

Thanks for the review and comments. Please see my inline response. 

Haoyu

-Original Message-
From: OPSAWG  On Behalf Of Warren Kumari
Sent: Sunday, January 05, 2020 12:04 PM
To: Tianran Zhou 
Cc: opsawg@ietf.org; opsawg-cha...@ietf.org
Subject: Re: [OPSAWG] extend the call//RE: WG adoption call for 
draft-song-opsawg-ifit-framework-09

On Thu, Dec 26, 2019 at 1:14 AM Tianran Zhou  wrote:
>
> Working Group,
>
>
>
> Thank you for all of your emails related to draft-song-opsawg-ifit-framework.
>
> It seems there are a lot of interested people. I hope the authors will be 
> encouraged by that.
>
> But there were also some strong concerns about the scope of the draft. What 
> is it trying to achieve? How does that match the charter? Does it include 
> material that is outside its scope? Thanks specially to Frank and Al for 
> saying their concerns.
>
> We are going to extend the adoption call for another two weeks to Jan 8. And 
> we encourage the inter-working group discussion.



I've just (re)read this, and have some concerns -- I found it somewhat hard to 
dig into the actual technical "meat" of the document (channeling Randy Bush 
"Where's the protein?") - it feels like it describes a bunch of benefits and 
features of a solution, but without actually describing the solution itself. 
The Abstract says that in the document "a high-level framework, In-situ Flow 
Information Telemetry (iFIT), is outlined.", but I couldn't really find it. 
Section 2 ("iFIT Framework Overview") is so very level that it doesn't really 
seem to say much at all.

I assumed that I'd just missed a bunch of other documents which actually 
describe some of the details behind ifit, like what exactly an iFIT node 
*does*, or what exactly an "On-demand Flow Sketch" is[0].
Basically, if I wanted to implement this myself, how would I do so?

[HS] I've added more details in the latest version but as I said, this draft is 
not a standard specification, so I just described the high level function 
modules and how they can be assembled to form a complete solution. I've talked 
with many people and they told me they had no difficulty to understand this and 
found many of the components are already common practices. For the flow sketch, 
we provided a reference in the draft but we didn't describe it extensively, 
because it's just used as an example in our discussion and interested readers 
should directly read the reference for more information. As for how to deploy 
such data structure, we actually consider this as a standard gap. We briefly 
discussed it in the gap analysis and will release several other drafts to cover 
those issues. 


The main thing I found was:
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-ctc.huawei.com%2Fke%2Fpress-events%2Fnews%2F2019%2F6%2Ffirst-ifit-pilot-5g-transport-network-beijing-unicom-huaweidata=02%7C01%7Chaoyu.song%40futurewei.com%7Cb89e7d80cf84400ac8d308d7921a9334%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637138515165652629sdata=5MK%2BVY7QAyPZupkYMYLDijyLAqSxQhbG%2FUPVVq6mkTI%3Dreserved=0
"In October 2018, Huawei submitted the draft of iFIT — "In-situ Flow 
Information Telemetry Framework" — to the Internet Engineering Task Force 
(IETF). Huawei's iFIT is the industry's first in-band flow measurement solution 
to have been deployed commercially. In June 2019, Huawei's iFIT solution won 
the Best of Show Award Special Prize at Interop Tokyo 2019 — one of the most 
prestigious events in the industry." and "Huawei's innovative iFIT solution 
takes a hardware approach...", etc.

This, and the general tone of the document, feels like a marketing driven 
exercise - the document describes a bunch of features and benefits of a 
solution, but without the detail needed to implement it.

Without a full description of iFIT itself and a serious scrubbing of the 
marketing tone, I do not think that the document should be adopted.

[HS] We write this draft from purely neutral and technical perspective. I don't 
know from where you sense the marketing tone. If so, please kindly point it out 
specifically so we can improve it. 

W

[0]: "A flow sketch is a compact online data
  structure for approximate flow statistics which can be used to
  facilitate flow selection.  The aforementioned CountMin Sketch is
  such an example.  Since a sketch consumes data plane resources, it
  should only be deployed when needed." -- this doesn't really say 
anything. Where is the format for the datastructure defined? How do I write 
one, how do I deploy it?.

[HS] The reference [CMSketch]  Cormode, G. and S. Muthukrishnan, "An improved 
data stream summary: the count-min sketch and its applications", 2005,
 provides a good overview on 
sketch. In the next revision, I'll add some more description to help understand 
it. 

" iFIT Head Node:  A special iFIT node.  It is the entry node to an
  iFIT domain.  Usually the instruction 

Re: [OPSAWG] extend the call//RE: WG adoption call for draft-song-opsawg-ifit-framework-09

[Haoyu Song]

Hi Alan,

Thanks for the response. Please see inline. 

Haoyu

-Original Message-
From: Alan DeKok  
Sent: Monday, January 06, 2020 5:44 PM
To: Haoyu Song 
Cc: Warren Kumari ; Tianran Zhou ; 
opsawg@ietf.org; opsawg-cha...@ietf.org
Subject: Re: [OPSAWG] extend the call//RE: WG adoption call for 
draft-song-opsawg-ifit-framework-09

On Jan 6, 2020, at 1:31 PM, Haoyu Song  wrote:
> [HS] I've added more details in the latest version but as I said, this draft 
> is not a standard specification, so I just described the high level function 
> modules and how they can be assembled to form a complete solution.

  If the draft is a "solution", it should describe how to implement that 
solution.  This draft does not do that.  it describes *motivation* for a 
solution.

> I've talked with many people and they told me they had no difficulty to 
> understand this and found many of the components are already common 
> practices. For the flow sketch, we provided a reference in the draft but we 
> didn't describe it extensively, because it's just used as an example in our 
> discussion and interested readers should directly read the reference for more 
> information. As for how to deploy such data structure, we actually consider 
> this as a standard gap. We briefly discussed it in the gap analysis and will 
> release several other drafts to cover those issues. 

  Then this draft should be titled "architecture" or "motivation".  And it 
should explicitly say that it does not describe a solution.  Instead, it should 
describe a problem, and a proposed architecture.

[HS] Indeed I tried to describe some practical problems on applying a specific 
set of techniques and then to propose an architecture (we call it a framework). 
A solution can be based on it, but itself cannot be used as a solution 
directly. 

> [HS] We write this draft from purely neutral and technical perspective. I 
> don't know from where you sense the marketing tone. If so, please kindly 
> point it out specifically so we can improve it. 

  From the abstract:

   With the advent of
   programmable data-plane, emerging on-path telemetry techniques
   provide unprecedented flow insight and realtime notification of
   network issues.

  This is 100% marketing speak.  IETF standards typically do not talk about how 
the technology is wonderful, or is "unprecedented".  The documents instead 
describe a technical problem, followed by a technical solution.

[HS] What I want to express here is that, as far as I know, no other OAM 
technique provides the same capability as this new type of technique such as 
IOAM. I can change the word if it sounds improper. 

  Further, the "programmable data plane" has been standardized extensively in 
the ForCES working group since at least 2003:

https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fwg%2Fforces%2Fdocuments%2Fdata=02%7C01%7Chaoyu.song%40futurewei.com%7C90ac59d12b5041fc5ba108d793131d9d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637139582662175583sdata=%2FDgnRZ7FEukQMj9YGJD9NroNUu7jv0I8cZRAkc4k55g%3Dreserved=0

 The first ForCES BoF was held at IETF 49, in December 2000.  That work 
standardized prior discussions in  CPIX / CSIX (then Network Processing Forum, 
now defunct).  I was involved in that work for many years before moving on to 
other things.

[HS] I'm fully aware of the existence of ForCES, I just didn't see its wide 
application in real products. Only recently, some programmable chips start to 
enable functions like INT which is basically an on-path telemetry technique we 
talked in this draft. Actually, I thought about using ForCES to implement the 
dynamic network probes discussed in this draft. I think it's a promising 
standard way to do that.  

  Quoting further from the abstract of this document:

   iFIT includes several
   essential functional components that can be materialized and
   assembled to implement a complete solution for on-path telemetry.

  There is no need to say "materialized and assembled".  It's fine to just say 
"used".

  The common practice in the IETF (and in other science and engineering 
disciplines) is to avoid "enthusiastic" words.  Keep the words simple.  i.e. 
"used" versus "materialized and assembled".

  The more complex the words, the less trustworthy the document appears.  

  Quoting again:

   It also helps to inspire innovative network
   telemetry applications supporting advanced network operations. 

  Words like "inspire" are again marketing excitement, and not boring technical 
engineering.

[HS] Fair enough. I would use simple words instead. After reading the document, 
I hope the reader can recognize the issues and agree that our proposed 
framework or architecture makes sense for practical deployments, and start to 
think about how to fill the standard

[OPSAWG] IFIT draft updated

[Haoyu Song]

Hi OPSAWG and WG chairs,

Based on the feedback from the WG virtual meeting, we have updated the IFIT 
draft to -12
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/

The main changes are:

  1.  We change "smart" to "flexible" in the framework component names
  2.  We provide a clear and detailed description of the on-path telemetry 
technique classification and modes
  3.  We update the references to the latest working drafts

We insist that IFIT is a neutral and proper name for the framework which is 
applicable to the on-path telemetry technique. So the name won't change.

We welcome any contributions to further improve the document and we request the 
WG to adopt it.
Thank you very much!

Best regards,
Haoyu


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] updated ifit framework draft

[Haoyu Song]

Hi WG,

According to the comments and suggestions from Frank, Alan, Warren, and many 
others, we have updated the draft to v11.

https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/

The major updates are listed as follows.


  1.  We move the "encapsulation and tunneling" to the "standard status and 
gaps" section. Now the framework only contains four components: "technology 
selection (in controller)", "configuration", "data export", and "data 
collection (in device)"
  2.  We remove most unnecessary definitions and specifications to keep the 
framework loose and open. The framework can be considered as an application 
optimization framework and from which we can identify the standard gaps.
  3.  We remove the words that sound "marketing"
  4.  We enhance the requirement and  scope discussion and the standard gap 
analysis.

Thank you for the comments and suggestions. Please review the document again 
and let us know if your concerns have been addressed or any new comments and 
suggestions.
Hope everybody stay healthy during this difficult time and let's continue the 
discussion in email list and the upcoming virtual meeting.  Thank you very much!

Haoyu

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC: Comments on draft-opsawg-ntf

[Haoyu Song]

Hi Greg,

Thank you very much for the review and comments!
We agree that network telemetry doesn’t contradict with OAM, and in fact, OAM 
is an important part of network telemetry. We will take your insight and reword 
the corresponding paragraphs for clarification. Please see inline for more 
response.

Best regards,
Haoyu

From: OPSAWG  On Behalf Of Greg Mirsky
Sent: Tuesday, October 6, 2020 6:05 PM
To: draft-opsawg-...@ietf.org; opsawg@ietf.org
Subject: [OPSAWG] WGLC: Comments on draft-opsawg-ntf

Dear Authors,
thank you for your work on this document. I believe that it is important to 
analyze and explain what is network telemetry, how it relates to the 
established tools that support network operations, administration, and 
maintenance (OAM).

Traditionally, OAM tools support two components of the FCAPS network management 
model - Fault Management (FM) and Performance Monitoring (PM). The former, FM, 
in addition to a failure detection tool, may include, for example, a protection 
switchover coordination protocol. Both FM and PM, when in use, produce 
information that reflects the state of the network.

Network telemetry may be viewed in two aspects - telemetry information that 
reflects the state of the network and methods used to collect and transport 
telemetry information.

At this point, I believe, we see that OAM and telemetry have something in 
common - information that characterizes the state of the network, a part of the 
network. If that is the case, then I think that statements about the 
relationship between OAM and telemetry:
   As evidenced by the defining
   characteristics and industry practice, network telemetry covers
   technologies and protocols beyond the conventional network
   Operations, Administration, and Management (OAM).  Network telemetry
   promises better flexibility, scalability, accuracy, coverage, and
   performance and allows automated control loops to suit both today's
   and tomorrow's network operation requirements.
or
   One difference between the network telemetry and the network OAM is
   that the network telemetry assumes machines as data consumer, while
   the conventional network OAM usually assumes human operators.
are arguable, at the minimum. I believe that there's no contradiction between 
OAM protocols and telemetry collection methods. On the contrary, each is 
essential and is complementary to the other, especially when detecting a 
network failure. To illustrate the latter, I can offer a case of monitoring a 
standby path that protects a working path. While an on-path method of 
collecting information can be used to monitor the condition of the working 
path, the standby can be monitored, in my opinion, only using an active OAM 
method injecting specially constructed test probes.

Another, rather general comment I have is on using RFC 7799 classification of 
PM methods. I think that the first reference to RFC 7799 is appropriate in or 
before Section 2.4.

[HS] will do.

Further, in Section 3, the document differentiates between Event-triggered Data 
and Streaming Data. I think that, based on the current definitions, there's 
little if anything that differentiates these two. Consider the definition of 
Streaming Data:
   Streaming Data:  The data are continuously or periodically generated.
  It can be time series or the dump of databases.  The streaming
  data reflect realtime network states and metrics and require large
  bandwidth and processing power.
Can timer expiration be viewed as an event? Also, If the timer that defines the 
frequency of data set export is long, is the information truly real-time? Or, 
doesn't Event-triggered Data reflects the state in real-time?

[HS] I think I see your point. Timer expiration is an event for sure. I think 
the difference is subtle.  For example, event-triggered data can be actively 
pushed (so it’s real-time) or passively polled (so it’s not real-time), but 
streaming data are always pushed. I’ll make the definition and description of 
streaming data more rigid to differentiate it from the event-triggered data.

Information collected in Figure 3 (could be tagged as a table) is very 
interesting. I think that it would be beneficial to add more explanation to the 
content of the table.

[HS] Do you really mean Figure 3 or some other figure?

Regards,
Greg







___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-ntf [CORRECT]

[Haoyu Song]

Qin,
Thanks for the suggestion! We have updated the text.

Haoyu

From: Qin Wu 
Sent: Tuesday, September 29, 2020 7:00 PM
To: Tianran Zhou ; opsawg 
Cc: draft-ietf-opsawg-...@ietf.org
Subject: RE: [OPSAWG] WGLC for draft-ietf-opsawg-ntf [CORRECT]

Support for publication.
A quick comment, regarding event triggered data, I think FSM is just one 
example of how event is modelled, but not the only way.
Suggest to make this clear in the text.
-Qin
From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Sent: Thursday, September 24, 2020 08:39
To: opsawg mailto:opsawg@ietf.org>>
Cc: draft-ietf-opsawg-...@ietf.org
Subject: WGLC for draft-ietf-opsawg-ntf [CORRECT]


Sorry for attaching a wrong link to the draft. Please see as follows.



Hi WG,



This email starts a working group last call for draft-ietf-opsawg-ntf.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntf/



Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
welcome.



The WG LC will end on 9st Oct 2020.



Thanks,

Tianran

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] IPR Poll for draft-ietf-opsawg-ntf [CORRECT]

[Haoyu Song]

I'm not aware of any IPR that applies to this document.

Haoyu

From: Tianran Zhou 
Sent: Wednesday, September 23, 2020 11:43 PM
To: opsawg 
Cc: draft-ietf-opsawg-...@ietf.org
Subject: IPR Poll for draft-ietf-opsawg-ntf [CORRECT]


Sorry for attaching a wrong link to the draft. Please see as follows.



Hi Authors,



Accompany with the WG LC, this mail starts the IPR poll.



Are you aware of any IPR that applies to draft-ietf-opsawg-ntf-04?



If you own or are aware of any IPR that applies to draft-ietf-opsawg-ntf-04, 
please clarify whether this IPR been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as a document author or contributor please respond to this 
email in OPSAWG mailing list regardless of whether or not you are aware of any 
relevant IPR. The document will not advance to the next stage until a response 
has been received from each author and contributor.



If you are not listed as an author or contributor but are on OPSAWG mailing 
list, then please explicitly respond if you are aware of any IPR that has not 
yet been disclosed in conformance with IETF rules.



Thanks,

Tianran

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-opsawg-ntf

[Haoyu Song]

Hi Juergen,

Thank you for pointing out it. Our understanding is that all versions of SNMP 
share the same design spirit while V3 provides enhance security. We'll add a 
reference to V3 when mentioning SNMP. 

Best regards,
Haoyu

-Original Message-
From: Juergen Schoenwaelder  
Sent: Wednesday, September 23, 2020 11:27 PM
To: Tianran Zhou 
Cc: opsawg ; draft-ietf-opsawg-...@ietf.org
Subject: Re: [OPSAWG] WGLC for draft-opsawg-ntf

SNMPv3 (RFC 3411 etc.) become STD 62 about 18 years ago. This document 
specifically talks about SNMP version 1 and 2 (note that 'protocol version 2' 
is ambiguous, likely the authors mean version 2c). I wonder whether this is by 
intention (i.e., the authors want to make a point that SNMPv3 is not used) or 
whether this is an oversight.

Note: I have _not_ reviewed this document, I only skimmed it and stumbled 
across this.

/js

On Thu, Sep 24, 2020 at 02:41:37AM +, Tianran Zhou wrote:
> Hi WG,
> 
> 
> 
> This email starts a working group last call for draft-opsawg-ntf.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-opsawg-ntf%2Fdata=02%7C01%7Chaoyu.
> song%40futurewei.com%7C26cb118a9dfd43a0228b08d86052d1c4%7C0fee8ff2a3b2
> 40189c753a1d5591fedc%7C1%7C1%7C637365256125959558sdata=7TPtzFwix1
> 5kbIrn08Phpi11puPZkSfmwGoXxAKlh7Y%3Dreserved=0
> 
> 
> 
> Please indicate your support or concern for this draft. If you are opposed to 
> the progression of the draft to RFC, please articulate your concern. If you 
> support it, please indicate that you have read the latest version and it is 
> ready for publication in your opinion. As always, review comments and nits 
> are welcome.
> 
> 
> 
> The WG LC will end on 9st Oct 2020.
> 
> 
> 
> Thanks,
> 
> Tianran

> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fopsawgdata=02%7C01%7Chaoyu.song%4
> 0futurewei.com%7C26cb118a9dfd43a0228b08d86052d1c4%7C0fee8ff2a3b240189c
> 753a1d5591fedc%7C1%7C1%7C637365256125959558sdata=CVOq93zAoG%2Fr2%
> 2B8CbAK3LbAlPUy%2FW309yoSWoENI%2FWM%3Dreserved=0


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Review comments (Re: I-D Action: draft-ietf-opsawg-ntf-03.txt)

[Haoyu Song]

tion 4.2.1

There is no section 4.2.2.  Having a single subsection looks a bit strange.  
Suggest to either remove 4.2.1 as a separate subsection, or to elevate it to a 
second-level section, or to add a 4.2.2. 

[HS] I removed the subsection level as suggested.

- Section 4.2.1.3.1

Your discussion of methods active, passive, and hybrid covers very different 
types of information - anything from sampled packet to flow records to 
measurements to OAM.  I think it would be good to differentiate by type of 
information.  Also, please consider mentioning RFC 6812 (IPSLA) in addition to 
OWAMP/TWAMP. 

[HS] The information type can be used as another axis for technique 
classification, which is mentioned in the last point.

- Section 4.3 and Figure 4

While per se there is nothing wrong with what you describe here, and perhaps it 
is best to keep things simple and to the basics as there will be myriads of 
implementation variations, I think expectations for what the framework actually 
entails should be framed a bit better earlier in the document.  After all this 
leadup, finally seeing the proposed framework appears a bit anti-climactic. 
This pretty much describes best current practice today, pretty much describing 
a generic management agent on a node will provide.  It does not cover aspects 
such as end-to-end measurements (covering multiple nodes), any security 
components (signing of data to prevent tampering, perhaps), integration with 
the real resources and data sources (this starts at the "data object", what 
about collecting data across multiple line card etc etc). At a minimum, it 
would be good to state what it is in scope and out of scope.   

[HS] We adjusted the order slightly.  The frameworks follows a two-level 
architecture. The first level is a module for each plane, and the second level 
is five components in each module. The data acquiring mechanism and data type 
are described as abstractions to be used by the framework. 

In the tables of the section, as Netconf and YANG are mentioned, SMIv2 should 
probably be mentioned and referenced along with SNMP as well. 

[HS] Reference to SMIv2 is added.

- Section 5

The difference betwen level 1 (dynamic) and level 2 (interactive) telemetry is 
not very clear.  Any telemetry data can be used in a closed loop; it is not 
clear why this is called level 3 (you can use level 0 telemetry data for plenty 
of closed loops). 

[HS] Level 2 is more about automatic real-time change of telemetry tasks. A 
higher level is built upon a lower level. The text is modified.

- Section 6

For the security considerations, there are a number of additional possible 
telemetry attack vectors that could be mentioned here.  E.g., attacks aiming at 
generating telemetry data to exhaust network resources as well as resources on 
the node, attacks aimed at falsifying results and tampering with telemetry, 
swamping of receivers (for streaming data).  

[HS] The cases are added in the first paragraph.

--- Alex

On 4/13/2020 11:59 AM, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Operations and Management Area Working Group 
> WG of the IETF.
>
> Title   : Network Telemetry Framework
> Authors : Haoyu Song
>   Fengwei Qin
>   Pedro Martinez-Julia
>   Laurent Ciavaglia
>   Aijun Wang
>   Filename: draft-ietf-opsawg-ntf-03.txt
>   Pages   : 34
>   Date: 2020-04-13
>
> Abstract:
>Network telemetry is the technology for gaining network insight and
>facilitating efficient and automated network management.  It engages
>various techniques for remote data collection, correlation, and
>consumption.  This document provides an architectural framework for
>network telemetry, motivated by the network operation challenges and
>requirements.  As evidenced by some key characteristics and industry
>practices, network telemetry covers technologies and protocols beyond
>the conventional network Operations, Administration, and Management
>(OAM).  It promises better flexibility, scalability, accuracy,
>coverage, and performance and allows automated control loops to suit
>both today's and tomorrow's network operation.  This document
>clarifies the terminologies and classifies the modules and components
>of a network telemetry system from several different perspectives.
>The framework and taxonomy help to set a common ground for the
>collection of related work and provide guidance for related technique
>and standard developments.
>
>
> The IETF datatracker status page for this draft is:
> https://nam11.safelinks.protection.outlook.com/?url=htt

Re: [OPSAWG] IPR Poll for draft-ietf-opsawg-ntf [CORRECT]

[Haoyu Song]

I'm not aware of any IPR for this draft.

Haoyu

From: opsawg-boun...@ietf.org 
[mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Thursday, September 24, 2020 2:43 PM
To: opsawg mailto:opsawg@ietf.org>>
Cc: draft-ietf-opsawg-...@ietf.org
Subject: [OPSAWG] IPR Poll for draft-ietf-opsawg-ntf [CORRECT]


Sorry for attaching a wrong link to the draft. Please see as follows.



Hi Authors,



Accompany with the WG LC, this mail starts the IPR poll.



Are you aware of any IPR that applies to draft-ietf-opsawg-ntf-04?



If you own or are aware of any IPR that applies to draft-ietf-opsawg-ntf-04, 
please clarify whether this IPR been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as a document author or contributor please respond to this 
email in OPSAWG mailing list regardless of whether or not you are aware of any 
relevant IPR. The document will not advance to the next stage until a response 
has been received from each author and contributor.



If you are not listed as an author or contributor but are on OPSAWG mailing 
list, then please explicitly respond if you are aware of any IPR that has not 
yet been disclosed in conformance with IETF rules.



Thanks,

Tianran

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Review of draft-ietf-opsawg-ntf-06

[Haoyu Song]

Hi Alex，

Thank you very much for your review and your help on progressing it! We’ll 
revise the draft and submit a new version.

Best regards,
Haoyu

From: Alexander Clemm 
Sent: Wednesday, February 17, 2021 6:31 PM
To: draft-ietf-opsawg-...@ietf.org
Cc: opsawg-cha...@ietf.org; opsawg@ietf.org
Subject: Review of draft-ietf-opsawg-ntf-06

Dear Haoyu and coauthors,

Thank you very much for your new revision.  IMHO, the document has greatly 
improved; you clearly put significant work into it!  I still have a few 
comments, but those are fewer and in most cases only minor (a few requiring a 
bit more consideration towards the end).  FWIW, I am enclosing those comments 
as a marked up PDF of the draft, attached.  While I hope you can accommodate 
them in a future revision, that should not hold up progressing the document.

Thanks
--- Alex
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Review of draft-ietf-opsawg-ntf-06

[Haoyu Song]

Hi Alex,

The 07 version of the draft has been submitted, which addresses all of your 
comments in your last review.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntf/
Thanks again for your help on improving the work!

Best regards,
Haoyu
From: Alexander Clemm 
Sent: Wednesday, February 17, 2021 6:31 PM
To: draft-ietf-opsawg-...@ietf.org
Cc: opsawg-cha...@ietf.org; opsawg@ietf.org
Subject: Review of draft-ietf-opsawg-ntf-06

Dear Haoyu and coauthors,

Thank you very much for your new revision.  IMHO, the document has greatly 
improved; you clearly put significant work into it!  I still have a few 
comments, but those are fewer and in most cases only minor (a few requiring a 
bit more consideration towards the end).  FWIW, I am enclosing those comments 
as a marked up PDF of the draft, attached.  While I hope you can accommodate 
them in a future revision, that should not hold up progressing the document.

Thanks
--- Alex
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] AD review of draft-ietf-opsawg-ntf-07 [2]

[Haoyu Song]

Hi Rob, 

We have updated the draft according to your review suggestions and uploaded the 
-08 version. In the new revision we believe all your suggestions/questions have 
been addressed. Please let me know if you have further questions. Thank you 
very much!

Best regards,
Haoyu 


-
A new version of I-D, draft-ietf-opsawg-ntf-08.txt has been successfully 
submitted by Haoyu Song and posted to the IETF repository.

Name:   draft-ietf-opsawg-ntf
Revision:   08
Title:  Network Telemetry Framework
Document date:  2021-10-07
Group:  opsawg
Pages:  40
URL:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-ntf-08.txtdata=04%7C01%7Chaoyu.song%40futurewei.com%7C96249f77ce0246132c2608d989e79553%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637692450027508042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=fm%2FeutvtbKzZN7c%2BvZzlzmZzSWQs0I52sn68EQ1bSv0%3Dreserved=0
Status: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ntf%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C96249f77ce0246132c2608d989e79553%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637692450027508042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=mPDw6Gz2JqqJ%2F6X0ISjEH5MH1nL%2Bgn5MK4VnbaBAfRs%3Dreserved=0
Htmlized:   
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-opsawg-ntfdata=04%7C01%7Chaoyu.song%40futurewei.com%7C96249f77ce0246132c2608d989e79553%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637692450027508042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=x8mxaK3UugiiTtDDX1YCrs3a9%2FjhdUXBPMetNuoR1SM%3Dreserved=0
Diff:   
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-opsawg-ntf-08data=04%7C01%7Chaoyu.song%40futurewei.com%7C96249f77ce0246132c2608d989e79553%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637692450027508042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=3QV9pT%2Fzs5xj6WxMLqIwGr2%2F4cD7xqclE3uznclsZfA%3Dreserved=0


-Original Message-
From: Haoyu Song 
Sent: Wednesday, October 6, 2021 9:14 AM
To: Rob Wilton (rwilton) ; draft-ietf-opsawg-ntf@ietf.org
Cc: opsawg@ietf.org
Subject: RE: AD review of draft-ietf-opsawg-ntf-07 [2]

Hi Rob,

Thank you very much for the review! We'll update the draft as you suggested. 

Best regards,
Haoyu

-Original Message-
From: Rob Wilton (rwilton)  
Sent: Wednesday, October 6, 2021 3:55 AM
To: draft-ietf-opsawg-ntf@ietf.org
Cc: opsawg@ietf.org
Subject: RE: AD review of draft-ietf-opsawg-ntf-07 [2]

Sigh, this also appears to be truncated in my email client.

To be sure that you see all the comments (i.e., to the end of the document), 
please either see the previous attachment. The full email can also be seen in 
the archives at 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fopsawg%2FWDnVtM_vLm15X28OTEwI9Q6gfx0%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7Cf1e7980d22be45a356e608d988b7d5ba%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637691145441218654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=d3NH7iwGu4T99Y%2Fwh9jft0oWofQeKyfWhcuBCQSZcJM%3Dreserved=0

Regards,
Rob


-Original Message-
From: Rob Wilton (rwilton)  
Sent: 06 October 2021 11:48
To: draft-ietf-opsawg-ntf@ietf.org
Cc: opsawg@ietf.org
Subject: AD review of draft-ietf-opsawg-ntf-07 [2]

Hi,



Here is my belated AD review of draft-ietf-opsawg-ntf-07.txt.  [Text file with 
comments attached in case this also gets truncated.]



I would like to thank you for the effort that you have put into this document, 
and apologise for my long delay in reviewing it.



Broadly, I think that this is a good and useful framework, but in some of the 
latter parts of the document it seems to give prominence to protocols that I 
don't think have IETF consensus behind them yet (particularly DNP).  I have 
flagged specific comments in comments inline within the document, but I think 
that the document will have been accuracy/longevity if text about the potential 
technologies is mostly kept to the appendices.



There were quite a lot of cases where the text doesn't scan, or read easily, 
particularly in the latter sections of this document, although I acknowledge 
that none of the authors appear to be native English speakers.  Ideally, these 
sorts of issues would have been highlighted and addressed during WG LC.  
Although the RFC editor will improve the language of the documents, making the 
improvements now before IESG review

Re: [OPSAWG] AD review of draft-ietf-opsawg-ntf-07 [2]

[Haoyu Song]

Hi Rob, 

Thank you very much for your second review! We have made all the modifications 
you pointed out. 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntf/09/
Please help to move it forward. Thanks again!

Best regards,
Haoyu

-Original Message-
From: Rob Wilton (rwilton)  
Sent: Tuesday, October 12, 2021 2:08 PM
To: Haoyu Song ; draft-ietf-opsawg-ntf@ietf.org
Cc: opsawg@ietf.org; 'opsawg-chairs' 
Subject: RE: AD review of draft-ietf-opsawg-ntf-07 [2]

Hi Haoyu,

Thanks for applying the markups.

I've given -08 another read through, and I think that there are still some 
tweaks to the grammar that I would recommend.  I've also included some 
automated warnings from a grammar tool that a probably also worth fixing (you 
would get similar warnings during IESG review anyway).  I think that once you 
have fixed these we should be ready to go.

3.2.  Use Cases

   *  Security: Network intrusion detection and prevention systems need
  to monitor network traffic and activities and act upon anomalies.
  Given increasingly sophisticated attack vector coupled with
  increasingly severe consequences of security breaches, new tools
  and techniques need to be developed, relying on wider and deeper
  visibility into networks.  The ultimate goal is to achieve the
  ideal security with no or minimal human intervention.
  
RW: suggest
no or minimal human => no, or only minimal, human intervention
  
  
* Last sentence suggest:

The ultimate goal is to achieve the ideal security with no, or only minimal, 
human intervention.

  networks.  While a policy or an intent is enforced, the compliance
  needs to be verified and monitored continuously relying on
  visibility that is provided through network telemetry data, any
  violation needs to be reported immediately, and updates need to be
  applied to ensure the intent remains in force.
  
RW: Suggest:

While a policy or intent is enforced, the compliance
needs to be verified and monitored continuously by relying on
visibility that is provided through network telemetry data.  Any
violation must be notified immediately, potentially resulting in
updates to how the policy or intent is applied in the network to ensure
that it remains in force, or otherwise alerting the network administrator
to the policy or intent violation.

   *  ...
  overwhelming.  While machine learning technologies can be used for
  root cause analysis, it up to the network to sense and provide the
  relevant diagnostic data which are either actively fed into or
  passively retrieved by machine learning applications.
  
RW: Suggest:
actively fed into or passively retrieved by => actively fed into, or passively 
retrieved, by 


4.  Network Telemetry Framework

RW: (Section 4.3)are applied. => (Section 4.3) are applied.


4.1.  Top Level Modules, diagram:

RW:
1. I still not sure that I would list "ACL" under a control plane object.
2. Thinking about it, I think that this table would be more consistent if the 
columns were ordered with management plane before control plane, e.g.,:
   +-+--+--+---+---+
   | Module  | Management   | Control  | Forwarding| External  |
   | | Plane| Plane| Plane | Data  |   


4.1.1.  Management Plane Telemetry

   *  Convenient Data Subscription: An application should have the
  freedom to choose the data export means such as the data types (as
  described in Figure 4) and the export means and frequency (e.g.,
  on-change or periodic subscription).
  
RW:
I don't think that the client is really choosing the data types, but
instead choosing which data to export, and how it is exported.  How about:

Convenient Data Subscription: An application should have the
freedom to choose which data is exported (see section 4.3) and the
means and frequency of how that data is exported (e.g.,
on-change or periodic subscription).

   *  High Speed Data Transport: In order to keep up with the velocity
  of information, a server needs to be able to send large amounts of
  data at high frequency.  Compact encoding formats or data
  compression schemes are needed to compress the data and improve
  the data transport efficiency.  The subscription mode, by
  replacing the query mode, reduces the interactions between clients
  and servers and helps to improve the server's efficiency.
  
RW:
are needed to compress the data => are needed to reduce the quantity of data


4.1.2.  Control Plane Telemetry

RW:
(e.g., the IGP monitoring => (e.g., IGP monitoring


4.1.3.  Forwarding Plane Telemetry

RW: Perhaps:
between forwarding and telemetry => between forwarding performance and telemetry

RW:
described in Appendix => Please add a reference to the section where postcard 
telemetry is described, perhaps A3.5?

Very minor nit:

Re: [OPSAWG] AD review of draft-ietf-opsawg-ntf-07 [2]

[Haoyu Song]

Hi Rob,

Thank you very much for the review! We'll update the draft as you suggested. 

Best regards,
Haoyu

-Original Message-
From: Rob Wilton (rwilton)  
Sent: Wednesday, October 6, 2021 3:55 AM
To: draft-ietf-opsawg-ntf@ietf.org
Cc: opsawg@ietf.org
Subject: RE: AD review of draft-ietf-opsawg-ntf-07 [2]

Sigh, this also appears to be truncated in my email client.

To be sure that you see all the comments (i.e., to the end of the document), 
please either see the previous attachment. The full email can also be seen in 
the archives at 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fopsawg%2FWDnVtM_vLm15X28OTEwI9Q6gfx0%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7Cf1e7980d22be45a356e608d988b7d5ba%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637691145441218654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=d3NH7iwGu4T99Y%2Fwh9jft0oWofQeKyfWhcuBCQSZcJM%3Dreserved=0

Regards,
Rob


-Original Message-
From: Rob Wilton (rwilton)  
Sent: 06 October 2021 11:48
To: draft-ietf-opsawg-ntf@ietf.org
Cc: opsawg@ietf.org
Subject: AD review of draft-ietf-opsawg-ntf-07 [2]

Hi,



Here is my belated AD review of draft-ietf-opsawg-ntf-07.txt.  [Text file with 
comments attached in case this also gets truncated.]



I would like to thank you for the effort that you have put into this document, 
and apologise for my long delay in reviewing it.



Broadly, I think that this is a good and useful framework, but in some of the 
latter parts of the document it seems to give prominence to protocols that I 
don't think have IETF consensus behind them yet (particularly DNP).  I have 
flagged specific comments in comments inline within the document, but I think 
that the document will have been accuracy/longevity if text about the potential 
technologies is mostly kept to the appendices.



There were quite a lot of cases where the text doesn't scan, or read easily, 
particularly in the latter sections of this document, although I acknowledge 
that none of the authors appear to be native English speakers.  Ideally, these 
sorts of issues would have been highlighted and addressed during WG LC.  
Although the RFC editor will improve the language of the documents, making the 
improvements now before IESG review will aid its passage, and hopefully result 
in a better document when it is published.  I have flagged and proposed 
alternative text/grammar where possible.  Once you have made the markups and 
resolved the issues/questions that I have raised then I can run it through a 
grammar checking tool (Lar's will run an equivalent tool during IESG review 
anyway ...)



All of my comments are directly inline, please search for "RW" or "RW:"









OPSAWG   H. Song

Internet-Draft Futurewei

Intended status: InformationalF. Qin

Expires: August 23, 2021China Mobile

   P. Martinez-Julia

NICT

L. Ciavaglia

   Nokia

 A. Wang

  China Telecom

   February 19, 2021





  Network Telemetry Framework

draft-ietf-opsawg-ntf-07



Abstract



   Network telemetry is a technology for gaining network insight and

   facilitating efficient and automated network management.  It

   encompasses various techniques for remote data generation,

   collection, correlation, and consumption.  This document describes an

   architectural framework for network telemetry, motivated by

   challenges that are encountered as part of the operation of networks

   and by the requirements that ensue.  Network telemetry, as

   necessitated by best industry practices, covers technologies and

   protocols that extend beyond conventional network Operations,



   Administration, and Management (OAM).  The presented network

   telemetry framework promises flexibility, scalability, accuracy,

   coverage, and performance.  In addition, it facilitates the

   implementation of automated control loops to address both today's and

   tomorrow's network operational needs.  This document clarifies the

   terminologies and classifies the modules and components of a network

   telemetry system from several different perspectives.  The framework

   and taxonomy help to set a common ground for the collection of

   related work and provide guidance for related technique and standard

   developments.



RW:

I 

Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-ntf-10: (with COMMENT)

[Haoyu Song]

Hi Éric,

Thank you very much for the review. Please find some response in line (marked 
as HS>). We'll publish the updated draft soon. Thanks!

Best regards,
Haoyu

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: Friday, November 26, 2021 5:20 AM
To: The IESG 
Cc: draft-ietf-opsawg-...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org; 
lud...@clemm.org; lud...@clemm.org; jeanmichel.com...@orange.com
Subject: Éric Vyncke's No Objection on draft-ietf-opsawg-ntf-10: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-ntf-10: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C55cf9efa9b20491fb28708d9b0df7dca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637735296220900165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=SzTLwFyLAXFwT8X5P5sQN%2Bqsk%2FJ5P%2B9wQVy5e8VkiXg%3Dreserved=0
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ntf%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C55cf9efa9b20491fb28708d9b0df7dca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637735296220900165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=MOuvJ%2BgSbiyFGWw6qJuOhsL2FvpN87kC3NZ8BQwU4LQ%3Dreserved=0



--
COMMENT:
--

Thank you for the work put into this document. All in all, this is a very good 
introduction document to telemetry but I am unsure whether it is a 'framework'
(and this is a real concern of mine). Due to the amount of documents on the 
next IESG telecast agenda, I did not review the appendixes.

Please find below some non-blocking COMMENT points (but replies would be 
appreciated even if only for my own education), and some nits.

Special thanks to Alexander Clemm for the shepherd's write-up about the WG 
consensus.

Thanks also to Jean-Michel Combes for his Internet directorate review at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Freview-ietf-opsawg-ntf-10-intdir-telechat-combes-2021-11-24%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C55cf9efa9b20491fb28708d9b0df7dca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637735296220900165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=fxvlOsv%2Bpe5Ipxhc8u5fRKnBuE1SOQTmPK2QBReipC0%3Dreserved=0

I believe that Jean-Michel spotted a serious issue in the security section but 
I trust the Security Area Directors on this specific topic and will not raise a 
block DISCUSS on this point especially as Haoyu Song has taken some actions.

I hope that this helps to improve the document,

Regards,

-éric

As a non-English speaker, the document title is a little ambiguous at first
sight: is it about telemetry about network data or about using the network to 
get some telemetry ? Unsure whether this ambiguity can be removed.

HS> The document is about telemetry on network data. The ambiguity should be 
cleared by the abstract and introduction.  

BTW, I like the sections on use cases and challenges but I am ambivalent 
whether they are useful in this document.

HS> We introduce the use cases and challenges as the motivation to the work. 

A lot of the concepts in this framework could be used for other applications 
beyond network layer telemetry. Was this extension considered by the authors ?

HS> We limit our scope to network layer in this document. 

There are several informative references to IRTF & IETF drafts, which is OK of 
course but those drafts may never be published. Perhaps, is it premature to 
publish this document ?

HS> Some of such references (mostly in appendix) refer to specific techniques. 
Even if they will not become standard in the future, the technique will still 
be useful.  

-- Section 2 --
Suggest to rely on 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fmaterials%2Fabbrev.expansion.txtdata=04%7C01%7Chaoyu.song%40futurewei.com%7C55cf9efa9b20491fb28708d9b0df7dca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637735296220900165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=eD5qDhL7%2B%2FmW%2FTBIoAeeg98cFF2AjGK9zHtD1anFyuc%3Dreserved=0
 to avoid redefining well-known terms as JSON or MIB.

HS> Thank you for the suggest

Re: [OPSAWG] Martin Duke's No Objection on draft-ietf-opsawg-ntf-10: (with COMMENT)

[Haoyu Song]

Hi Martin,

Thank you very much for the review. In revision -11, we will add the reference 
to IOAM DEX and update the status of multipoint-alt-mark to RFC8889. 

Best regards, 
Haoyu

-Original Message-
From: Martin Duke via Datatracker  
Sent: Thursday, November 18, 2021 9:17 PM
To: The IESG 
Cc: draft-ietf-opsawg-...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org; 
lud...@clemm.org; lud...@clemm.org
Subject: Martin Duke's No Objection on draft-ietf-opsawg-ntf-10: (with COMMENT)

Martin Duke has entered the following ballot position for
draft-ietf-opsawg-ntf-10: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7Cc254ac7d65e74614e34b08d9ab1bd7fb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637728958355317130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=K0fBYi7thTK2o%2FXvdG%2BVI55%2BQ7DcyRLErz%2FmYBROpFw%3Dreserved=0
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ntf%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7Cc254ac7d65e74614e34b08d9ab1bd7fb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637728958355327035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=WSuDjdYvJ78yVxv5almpee30tledABx8x1Jw67PrCEQ%3Dreserved=0



--
COMMENT:
--

A.3.4 and A.3.5. Note that IOAM has a direct export mode in an adopted draft 
with similar properties to PBT.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-direct-export%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7Cc254ac7d65e74614e34b08d9ab1bd7fb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637728958355327035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=kaugJYLTHtOHs0Pbs4bHz0hMSDj7w%2FvaNdke3jhuvqI%3Dreserved=0

The reference to draft-ippm-multipoint-alt-mark is now RFC8889.

Thanks to Michael Scharf for the TSVART review.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] RtgDir Last Call review: draft-ietf-opsawg-ntf-10

[Haoyu Song]

Hi Dhruv,

Thank you very much for the review! Please see inline for our response and 
proposed modifications. We'll update the document once we hear back from you. 
Thanks!

Best regards,
Haoyu

From: Dhruv Dhody 
Sent: Friday, November 19, 2021 5:25 AM
To: rtg-...@ietf.org; last-c...@ietf.org; draft-ietf-opsawg-ntf@ietf.org
Cc: rtgdir-cha...@ietf.org; rtgdir-...@ietf.org; opsawg 
Subject: RtgDir Last Call review: draft-ietf-opsawg-ntf-10


Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-opsawg-ntf-10
Reviewer: Dhruv Dhody
Review Date: 2021-11-19
IETF LC End Date: over
Intended Status: Informational

Summary:
Choose from this list...
* I have some minor concerns about this document that I think should be 
resolved before publication.

Comments:
* I find the document to be useful. It is well structured and easy to read. 
Since the aim of the document is to clarify the taxonomy and framework, I hope 
to see more drafts to refer to it when describing network telemetry. I have a 
few suggestions of things that are missing, some queries and nits that are easy 
to resolve, and hopefully improve the document further.

Minor Issues:
* Well almost Major :)
o   Something that I find missing in the document is that the network 
controller could be a valuable source of network telemetry as well. Consider a 
PCE, the controller could be a source of network-wide data, such as the 
association between network paths, cumulative network metrics, global network 
utilization, etc. The document is currently very network-device-specific (as a 
data source). My suggestion would be to handle the centralized controller 
either as a separate section or part of the control plane and management plane 
telemetry.
[HS] We hold a view on a telemetry system that it collects data from different 
network planes, in which a centralized controller, if exists,  is the host for 
the telemetry  applications and a consumer for the data. In a sense, a 
controller acquires the original data from various network planes and it might 
further process the data and even generate new data based on telemetry data for 
applications. We summarize this process as "network operation applications" in 
the framework. Is this an acceptable view?
o   Something else that I find missing is the multi-domain aspects. You could 
mark it as out of scope or better yet do talk about it how there could possibly 
be a hierarchy and recursive nature in your framework to handle multi-domain. 
Currently, it is mentioned in passing while describing data fusion in section 
3.4.
[HS] Multi-domain has many particular issues we think we should leave out of 
scope, although the general framework would still fit. We will make it clear in 
the new revision.
* Query
o   Section 4.1
?  In figure 2, why MIB is mentioned in the management plane only, why not 
control plane when various control plane protocols have MIBs? Similarly, there 
are forwarding statistics MIB that might work in the forwarding plane? Also, 
add SNMP and ASN.1(?) in the table corresponding to MIB.
[HS] In the text we "note that the  selected techniques [in the figure] just 
reflect the de facto state of the art and are by no means exhaustive." Here we 
only mean to provide some representatives in each category.
?  What is a 'mirror'? Maybe expand it or put a * and expand it at the bottom
[HS] We'll expand it as suggested.
?  All external data coming from gRPC only?
[HS] No necessarily. Note that this is just a representative. We don't mean to 
provide an exhaustive list.
* Others
o   Section 6
?  The Independent management network is mentioned only in passing. Shouldn't 
there be a much stronger recommendation for this instead?
[HS] In this section we just list the security considerations and the 
recommended solution is out of scope of this document. If you have some mature 
practices to recommend, we'd like to add a few sentences on this.

Nits:
* From 

Re: [OPSAWG] Intdir telechat review of draft-ietf-opsawg-ntf-10

[Haoyu Song]

Hi Jean,

Thank you very much for the review! Based on your suggestion,  we'll move the 
disclaimer to the beginning of the document and provide more clarification. 

Best regards,
Haoyu


-Original Message-
From: Jean-Michel Combes via Datatracker  
Sent: Wednesday, November 24, 2021 3:41 AM
To: int-...@ietf.org
Cc: draft-ietf-opsawg-ntf@ietf.org; last-c...@ietf.org; opsawg@ietf.org
Subject: Intdir telechat review of draft-ietf-opsawg-ntf-10

Reviewer: Jean-Michel Combes
Review result: Almost Ready

Hi,

I am an assigned INT directorate reviewer for draft-ietf-opsawg-ntf-10. These 
comments were written primarily for the benefit of the Internet Area Directors.
Document editors and shepherd(s) should treat these comments just like they 
would treat comments from any other IETF contributors and resolve them along 
with any other Last Call comments that have been received. For more details on 
the INT Directorate, see 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fgroup%2Fintdir%2Fabout%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C77ca751175644cd8d80108d9af3f5b17%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637733508927650895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Sqcy5PJgbAQouh7b49rlIOvrGhOAA4tF5wpNf1bE9UM%3Dreserved=0
.

Based on my review, if I was on the IESG I would ballot this document as 
DISCUSS.

I have the following DISCUSS:

The document is well written and gives a good overview of the telemetry 
"environment". But, I am really embarrassed by a sentence - hidden in a section 
not always read at the end of the document: "6.  Security Considerations ...
The Network Telemetry Framework is not applicable to networks whose endpoints 
represent individual users, such as general-purpose access networks."

Here are the reasons regarding this DISCUSS
(1) I assume next IETF works on Telemetry will be based on this document;
(2) Such a disclaimer should be clearly mentioned at the beginning of the
document to avoid any future IETF proposal, based on this document, in the
scope of this disclaimer; (3) A clarification of this disclaimer is needed.
Indeed, this disclaimer is closing many useful use-cases like E2E telemetry 
(i.e., between customer device/application and provided service) for a service 
provider or, if I understand correctly this disclaimer, Telemetry based 
management of a personal IoT network (e.g., at home) by an end-user.

The following are minor issues (typos, misspelling, minor text improvements) 
with the document:

Some references need to be updated but this should be done during the RFC 
Editor process.

Best regards,

JMC.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] RtgDir Last Call review: draft-ietf-opsawg-ntf-10

[Haoyu Song]

Thank you very much Dhruv, the text you proposed has been included.

Best regards,
Haoyu

From: Dhruv Dhody 
Sent: Sunday, November 21, 2021 8:22 PM
To: Haoyu Song 
Cc: rtg-...@ietf.org; last-c...@ietf.org; draft-ietf-opsawg-ntf@ietf.org; 
rtgdir-cha...@ietf.org; rtgdir-...@ietf.org; opsawg 
Subject: Re: RtgDir Last Call review: draft-ietf-opsawg-ntf-10

Hi Haoyu,

Thanks for taking my comments into consideration. Focusing on the open points...


o   Something that I find missing in the document is that the network 
controller could be a valuable source of network telemetry as well. Consider a 
PCE, the controller could be a source of network-wide data, such as the 
association between network paths, cumulative network metrics, global network 
utilization, etc. The document is currently very network-device-specific (as a 
data source). My suggestion would be to handle the centralized controller 
either as a separate section or part of the control plane and management plane 
telemetry.
[HS] We hold a view on a telemetry system that it collects data from different 
network planes, in which a centralized controller, if exists,  is the host for 
the telemetry  applications and a consumer for the data. In a sense, a 
controller acquires the original data from various network planes and it might 
further process the data and even generate new data based on telemetry data for 
applications. We summarize this process as "network operation applications" in 
the framework. Is this an acceptable view?

Dhruv: In most cases that could be true. I do find it limiting to assume all 
such applications are hosted at a single central controller. Looking at figure 
3 in RFC 8309 - 
https://www.rfc-editor.org/rfc/rfc8309.html#section-4<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8309.html%23section-4=04%7C01%7Chaoyu.song%40futurewei.com%7Cf87d7c629ea14c2188ee08d9ad6fbced%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637731517699454988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=phgAdnLv9stOKAz5kQq0Kxq5Ga30Ik5cVd1V9rh5fV8%3D=0>,
 it is possible that the bottom controller does the telemetry handling but the 
analysis and application happen at the orchestrator level.

Anyways, maybe you could add some version of the below text -

Note that in some cases the controller itself may be the source of telemetry 
data that is unique to it or derived from the telemetry data collected from the 
network elements. Some of the principles and taxonomy specific to the control 
plane and management plane telemetry could also be applied to the controller 
when it is required to provide the telemetry data to Network Operation 
Applications hosted outside. The scope of the document is focused on the 
network elements telemetry and further details related to controllers are thus 
out of scope.

o   Something else that I find missing is the multi-domain aspects. You could 
mark it as out of scope or better yet do talk about it how there could possibly 
be a hierarchy and recursive nature in your framework to handle multi-domain. 
Currently, it is mentioned in passing while describing data fusion in section 
3.4.
[HS] Multi-domain has many particular issues we think we should leave out of 
scope, although the general framework would still fit. We will make it clear in 
the new revision.

Dhruv: Looking forward to the text!


* Query
o   Section 4.1
*  In figure 2, why MIB is mentioned in the management plane only, why not 
control plane when various control plane protocols have MIBs? Similarly, there 
are forwarding statistics MIB that might work in the forwarding plane? Also, 
add SNMP and ASN.1(?) in the table corresponding to MIB.
[HS] In the text we "note that the  selected techniques [in the figure] just 
reflect the de facto state of the art and are by no means exhaustive." Here we 
only mean to provide some representatives in each category.

Dhruv: I understand that, it stood out to me because YANG was mentioned in 
other planes but not MIB.

Thanks!
Dhruv


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Tsvart last call review of draft-ietf-opsawg-ntf-09

[Haoyu Song]

Hi Michael,

Thank you very much for the review! 
According to your suggestion, we explicitly list the congestion avoidance as a 
requirement at each plane and add RFC8085 as BCP reference. 
We also take your suggestions on the precise terms used in the table. 
I have just one question:  While IPFIX can run over TCP/UDP/SCTP, for 
forwarding plane, we recommend to used it over UDP only for simplicity. Is this 
acceptable?
I'll upload a new version of the document as soon as the submission website is 
reopened. Thanks!

Best regards,
Haoyu

-Original Message-
From: Michael Scharf via Datatracker  
Sent: Sunday, October 31, 2021 4:24 PM
To: tsv-...@ietf.org
Cc: draft-ietf-opsawg-ntf@ietf.org; last-c...@ietf.org; opsawg@ietf.org
Subject: Tsvart last call review of draft-ietf-opsawg-ntf-09

Reviewer: Michael Scharf
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's 
ongoing effort to review key IETF documents. These comments were written 
primarily for the transport area directors, but are copied to the document's 
authors and WG to allow them to address any issues raised and also to the IETF 
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this 
review as part of the last-call comments they receive. Please always CC 
tsv-...@ietf.org if you reply to or forward this review.

This informational document describes an architectural framework for network 
telemetry and the main components of corresponding systems.

It has two issues related to TSV topics:

First, the document lacks a discussion of the importance of congestion control 
for telemetry traffic as well as corresponding references, e.g., to RFC 8085.
High-volume telemetry traffic can overload a network unless proper 
counter-measures are in place (i.e., at minimum "circuit breakers"). It doesn't 
seem appropriate to entirely ignore that issue.

Second, language regarding the ambigous term "transport" and the references to 
Internet transport protocols must be improved to be consistent with IETF 
standards.

Below are some examples for sections in which these issues are obvious.

Section 3.4

   It is worth noting that a network telemetry system should not be
   intrusive to normal network operations by avoiding the pitfall of the
   "observer effect".  That is, it should not change the network
   behavior and affect the forwarding performance.  Otherwise, the whole
   purpose of network telemetry is compromised.

=> This statement should be extended to be very explicit about the risk of 
causing network congestion by high-volume telemetry traffic unless proper 
isolation or traffic engineering techniques are in place, or congestion control 
mechanisms ensure that telemetry traffic backs off if it exceeds the network 
capacity. RFC 8085 is a relevant BCP in this space. As a side note, RFC 8085 
discusses other relevant challenges as well, but the issues caused by 
potentially inelastic high-volume telemetry traffic seem particularly relevant 
for ensuring network stability when telemetry solutions get deployed.

4.1.  Top Level Modules

   +-+--+--+---+---+
   | Module  | Management   | Control  | Forwarding| External  |
   | | Plane| Plane| Plane | Data  |
   +-+--+--+---+---+
   |Object   | config. &| control  | flow & packet | terminal, |
   | | operation| protocol &   | QoS, traffic  | social &  |
   | | state| signaling,   | stat., buffer | environ-  |
   | |  | RIB  | & queue stat.,| mental|
   | |  |  | ACL, FIB  |   |
   +-+--+--+---+---+
   |Export   | main control | main control | fwding chip   | various   |
   |Location | CPU  | CPU, | or linecard   |   |
   | |  | linecard CPU | CPU; main |   |
   | |  | or forwarding| control CPU   |   |
   | |  | chip | unlikely  |   |
   +-+--+--+---+---+
   |Data | YANG, MIB,   | YANG,| template, | YANG, |
   |Model| syslog   | custom   | YANG, | custom|
   | |  |  | custom|   |
   +-+--+--+---+---+
   |Data | GPB, JSON,   | GPB, JSON,   | plain | GPB, JSON |
   |Encoding | XML  | XML, plain   |   | XML, plain|
   +-+--+--+---+---+
   |Protocol | gRPC,NETCONF,| gRPC,NETCONF,| IPFIX, mirror,| gRPC  |
   | |  | IPFIX, mirror| gRPC, NETFLOW |   |
   

Re: [OPSAWG] Tsvart last call review of draft-ietf-opsawg-ntf-09

[Haoyu Song]

Got it. We will make it explicit that what's included in the table are by no 
means exhaustive rather than some examples. Thanks!

Haoyu

-Original Message-
From: Scharf, Michael  
Sent: Monday, November 1, 2021 4:21 PM
To: Haoyu Song ; tsv-...@ietf.org
Cc: draft-ietf-opsawg-ntf@ietf.org; last-c...@ietf.org; opsawg@ietf.org
Subject: RE: Tsvart last call review of draft-ietf-opsawg-ntf-09



> -Original Message-
> From: Haoyu Song 
> Sent: Monday, November 1, 2021 9:22 PM
> To: Scharf, Michael ; tsv-...@ietf.org
> Cc: draft-ietf-opsawg-ntf@ietf.org; last-c...@ietf.org; opsawg@ietf.org
> Subject: RE: Tsvart last call review of draft-ietf-opsawg-ntf-09
>
> Hi Michael,
>
> Thank you very much for the review!
> According to your suggestion, we explicitly list the congestion avoidance as
> a
> requirement at each plane and add RFC8085 as BCP reference.

If a reference for network circuit breakers is needed in addition to RFC 8085,
the other reference would be RFC 8084. I just mention this because I have used
the term "circuit breakers", but forgot to mention that there is a BCP fort
hat, too.

> We also take your suggestions on the precise terms used in the table.
> I have just one question:  While IPFIX can run over TCP/UDP/SCTP, for
> forwarding plane, we recommend to used it over UDP only for simplicity. Is
> this
> acceptable?

According to RFC 7011, SCTP "MUST be implemented by all compliant 
implementations." As a result, such a recommendation might be inconsistent 
with RFC 7011. I am not an IPFIX expert and I am not sure if RFC 7011 is 
indeed fully aligned with running code. But if the document mentions IPFIX and 
lists *only* UDP as corresponding transport protocol, that would require at 
least some explanation in the text, because clearly IPFIX could be implemented 
over transport protocols other than UDP as well.

Note that there may be other simple solutions to work around that issue, e.g., 
by using in the table row a label such as "example data transport" or the 
like, which would make implicitly clear that options other than UDP could 
exist.

As long as there is some reasonable explanation of how to read the table, I'll 
be fine.

Michael

> I'll upload a new version of the document as soon as the submission website
> is
> reopened. Thanks!
>
> Best regards,
> Haoyu
>
> -Original Message-
> From: Michael Scharf via Datatracker 
> Sent: Sunday, October 31, 2021 4:24 PM
> To: tsv-...@ietf.org
> Cc: draft-ietf-opsawg-ntf@ietf.org; last-c...@ietf.org; opsawg@ietf.org
> Subject: Tsvart last call review of draft-ietf-opsawg-ntf-09
>
> Reviewer: Michael Scharf
> Review result: Ready with Issues
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review
> as part of the last-call comments they receive. Please always CC tsv-
> a...@ietf.org if you reply to or forward this review.
>
> This informational document describes an architectural framework for network
> telemetry and the main components of corresponding systems.
>
> It has two issues related to TSV topics:
>
> First, the document lacks a discussion of the importance of congestion
> control
> for telemetry traffic as well as corresponding references, e.g., to RFC
> 8085.
> High-volume telemetry traffic can overload a network unless proper counter-
> measures are in place (i.e., at minimum "circuit breakers"). It doesn't seem
> appropriate to entirely ignore that issue.
>
> Second, language regarding the ambigous term "transport" and the references
> to Internet transport protocols must be improved to be consistent with IETF
> standards.
>
> Below are some examples for sections in which these issues are obvious.
>
> Section 3.4
>
>It is worth noting that a network telemetry system should not be
>intrusive to normal network operations by avoiding the pitfall of the
>"observer effect".  That is, it should not change the network
>behavior and affect the forwarding performance.  Otherwise, the whole
>purpose of network telemetry is compromised.
>
> => This statement should be extended to be very explicit about the risk of
> causing network congestion by high-volume telemetry traffic unless proper
> isolation or traffic engineering techniques are in place, or congestion
> control
> mechanisms ensure that telemetry traffic back

Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-ntf-09

[Haoyu Song]

Hi Gyan,

Thank you very much for your review and feedback!

I have added reference to STAMP and RESTCONF as you suggested. 
I'm a little confused by the difference between OAM-based ping and non 
OAM-based ping. Could you please elaborate on this?
Please also note that we don't intend to provide an exhaustive survey on all 
existing OAM tools and proposals, rather we just give some typical 
representative for each category. Also, we focus more on the underlying 
techniques (e.g., ping) rather than their adaptation to various dataplanes. Of 
course, if you think it's important to include those, I'll add a paragraph in 
the dataplane telemetry subsection.

Best regards,
Haoyu  

-Original Message-
From: Gyan Mishra via Datatracker  
Sent: Saturday, October 23, 2021 5:45 PM
To: gen-...@ietf.org
Cc: draft-ietf-opsawg-ntf@ietf.org; last-c...@ietf.org; opsawg@ietf.org
Subject: Genart last call review of draft-ietf-opsawg-ntf-09

Reviewer: Gyan Mishra
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-opsawg-ntf-??
Reviewer: Gyan Mishra
Review Date: 2021-10-23
IETF LC End Date: 2021-10-27
IESG Telechat date: Not scheduled for a telechat

Summary:
This draft analyzes the overall framework of network telemetry technologies 
that exist today and future evolution of telemetry technology and data 
gathering from a control plane, data plane and management plane perspective. 
Document is well written.

Major issues:
None

Minor issues:
None
Nits/editorial comments:

Section 4.1.3 Forwarding plane telemetry does not include STAMP RFC 8762.  
Mention traditional non OAM based ping ICMP Echo snd Echo-Reply.

 Also for OAM based maybe list the variety of OAM based ping such as for all  
data planes such as MPLS, RSVP-TE,  L2 VPN pdeudowire OAM ping VCCV (Virtual  
Circuit Connection Verification) RFC 5085 RFC 7189, RFC 5586 GACH PW OAM.

Any of the RFCs listed here maybe include as informative references.

Also NVO3 VXLAN and BIER OAM.  SFC service plane RFC 8924 SFC OAM.

Also DETNET forwarding and service sub planes DETNET OAM.

SDN and SD-WAN, PCEP, BGP all centralized controller based architecture can 
also be used for network telemetry.

RESTCONF REST API is missing should be mentioned



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-ntf-10: (with COMMENT)

[Haoyu Song]

Hi Lars,

Thank you very much for the review! All the issues listed below have been 
addressed and will be reflected in the newer revision. 

Best regards,
Haoyu

-Original Message-
From: Lars Eggert via Datatracker  
Sent: Monday, November 29, 2021 7:10 AM
To: The IESG 
Cc: draft-ietf-opsawg-...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org; 
lud...@clemm.org; lud...@clemm.org
Subject: Lars Eggert's No Objection on draft-ietf-opsawg-ntf-10: (with COMMENT)

Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-ntf-10: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C8ceb85ad7c1a423a6f7908d9b34a413d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637737953776498295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=5FZTQQySXzyfwL45FOc%2FoGEBKuGepPFJ3mIxRu8oSG8%3Dreserved=0
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ntf%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C8ceb85ad7c1a423a6f7908d9b34a413d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637737953776498295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=p%2BitJcpqnfG1ruKNUDp0S7wfb%2BmiUZqZcf%2BuFO%2FSR0k%3Dreserved=0



--
COMMENT:
--

Found terminology that should be reviewed for inclusivity; see
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fpart2%2F%23inclusive_languagedata=04%7C01%7Chaoyu.song%40futurewei.com%7C8ceb85ad7c1a423a6f7908d9b34a413d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637737953776498295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=zphocVEFagdg%2BamrqYhhaqKKcrUxCv7lYKxUy393T3E%3Dreserved=0
 for background and more
guidance:

 * Term "his"; alternatives might be "they", "them", "their".

 * Term "traditional"; alternatives might be "classic", "classical",
   "common", "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread".

Thanks to Gyan S. Mishra for their General Area Review Team (Gen-ART) review 
(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fgen-art%2FItkS25VOVfDg8eLogFDMCtpeoFMdata=04%7C01%7Chaoyu.song%40futurewei.com%7C8ceb85ad7c1a423a6f7908d9b34a413d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637737953776498295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ftmKsfeQdDLSDKZyvguNWHl%2BgaKMcJTkJK20HJwmjGc%3Dreserved=0).

---
All comments below are about very minor potential issues that you may choose to 
address in some way - or ignore - as you see fit. Some were flagged by 
automated tools (via 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flarseggert%2Fietf-reviewtooldata=04%7C01%7Chaoyu.song%40futurewei.com%7C8ceb85ad7c1a423a6f7908d9b34a413d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637737953776498295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=5yEFMuoKYs1PBKdhb8JyeCf8Ya7izYDwh%2BFfhzW5BlQ%3Dreserved=0),
 so there will likely be some false positives. There is no need to let me know 
what you did with these suggestions.

Section 3.2. , paragraph 4, nit:
> ic manipulation. In some cases, micro-bursts need to be detected in a very sh
> 
This word is normally spelled as one.

Section 3.2. , paragraph 6, nit:
> ant to be warned of issues in advance so proactive actions can be taken to av
>  ^^^
Use a comma before "so" if it connects two independent clauses (unless they are 
closely connected and short).

Section 4.1. , paragraph 3, nit:
> lso be implemented over TCP and SCTP but that is not recommended for forward
> 
Use a comma before "but" if it connects two independent clauses (unless they 
are closely connected and short).

Section 10. , paragraph 19, nit:
> P/2 [RFC7540] based open-source micro-service communication framework. It pro
> ^
This word is 

Re: [OPSAWG] Warren Kumari's No Objection on draft-ietf-opsawg-ntf-11: (with COMMENT)

[Haoyu Song]

Hi Warren,

Thank you very much for the review and suggestions. The updates will be 
reflected in the next revision. 

Best regards,
Haoyu

-Original Message-
From: Warren Kumari via Datatracker  
Sent: Wednesday, December 1, 2021 8:48 AM
To: The IESG 
Cc: draft-ietf-opsawg-...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org; 
lud...@clemm.org; lud...@clemm.org; jiangsh...@huawei.com; ops...@ietf.org
Subject: Warren Kumari's No Objection on draft-ietf-opsawg-ntf-11: (with 
COMMENT)

Warren Kumari has entered the following ballot position for
draft-ietf-opsawg-ntf-11: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7Ce6ee493481e5413e70a808d9b4ea53a0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637739740803203416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Nhl%2BkeF2n0R5M2BaTTY%2B4HY9s%2F6W8p8Yy2hSktjWna4%3Dreserved=0
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ntf%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7Ce6ee493481e5413e70a808d9b4ea53a0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637739740803203416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=OiOy1DDu2%2BiXqomz4zNzqtXpMLkZYSDiafgCPVlH2J4%3Dreserved=0



--
COMMENT:
--

Firstly, thank you for writing this, and thanks to Sheng Jiang for the OpsDir 
review.

 I personally think that these sort of "overview" / framework documents are  
really useful; I've often had to get spun up on some new technology and  
reading an RFC which specifies the packet format without a good overview  
document (like this one ) is not helpful...

Anyway, with that soapbox rant over, I have 2 substantive comments and some 
nits to help make the document better / more readable. There is no need to 
reply to each comment (or at all) - these are non-blocking comments, but fixing 
them will help make the RFC Editor's job easier and help ensure that none sneak 
through...

1:S1 - Introduction
"All the modules are internally structured in the same way, including 
components that allow to configure data sources in ..." P: "that allow for the 
configuration" or "that allow the  to configure 
what data to..."

"The framework can also simplify the tasks for designing, maintaining, and 
understanding a network telemetry system." P:"the task of designing" (or just 
"simplify the design, maintenance and understanding of ..."

"At last, we outline the evolution stages of the network telemetry system and 
discuss the potential security concerns." P: "Finally, ..." or "Lastly, ...".
Actually, I think "In addition" would be even better.

S 2.2 Use Cases
"Intent, as defined in [I-D.irtf-nmrg-ibn-concepts-definitions], is a set of 
operational goal that a network ..." s/goal/goals/

"SLA Compliance: A Service-Level Agreement (SLA) defines the level of service a 
user expects from a network operator," I disagree with this -- an SLA is what a 
network operator has agreed to provide, usually with a contract and penalty to 
missing it. As a user I *expect* my network operator to always exceed the SLA - 
if the SLA specifies 95% uptime, I don't really expect 36 hours of downtime 
each month :-P. Also, in many cases I (sadly) *expect* much worse service than 
the SLA actually specifies... The Wikipedia
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FService-level_agreementdata=04%7C01%7Chaoyu.song%40futurewei.com%7Ce6ee493481e5413e70a808d9b4ea53a0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637739740803203416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=akdpqX9UKUSalGgZZOumuCeuZJnrP%2BiYLHE89HsVACg%3Dreserved=0
 page has some good text you could use...

"Root Cause Analysis: Any network failure can be the effect of a sequence of 
chained events." The use of "Any" here seems odd / wrong -- perhaps "Network 
failures are often ..." or "Many network failures..." or just drop the first 
sentence and start with "Troubleshooting and recovery require ..."

S 2.3
"The poll-based low-frequency data collection is ill-suited..."
Drop the "The", or s/The/This/

"Subscription-based streaming data directly pushed from the data source (e.g., 
the forwarding chip) is preferred to provide enough data quantity and precision 
at 

Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-ntf-11: (with DISCUSS and COMMENT)

[Haoyu Song]

Hi Roman,

Thank you very much for the review and comments! Please find inline my response 
and proposed modifications. The modifications will be reflected in the version 
-12. 

Best regards,
Haoyu

-Original Message-
From: Roman Danyliw via Datatracker  
Sent: Tuesday, November 30, 2021 6:10 PM
To: The IESG 
Cc: draft-ietf-opsawg-...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org; 
lud...@clemm.org; lud...@clemm.org
Subject: Roman Danyliw's Discuss on draft-ietf-opsawg-ntf-11: (with DISCUSS and 
COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-opsawg-ntf-11: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C44cefd5adab943c3365e08d9b46fa527%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637739213905186071%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=aiyR0NZZCOj8m9JfGw2RBnbYIje7oaROrZN%2BPj2ytMo%3Dreserved=0
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ntf%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C44cefd5adab943c3365e08d9b46fa527%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637739213905186071%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=jwSUX6LNW7mwPmYYILyM5gKEyHF5zKDfyddVBBlXvH4%3Dreserved=0



--
DISCUSS:
--

Thank you for being responsive to the SECDIR review threat to improve the 
security considerations text.  Specifically, 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fsecdir%2FGUvFWXP7n9IjXW8xlIdMS5ZE5u0%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C44cefd5adab943c3365e08d9b46fa527%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637739213905186071%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2FcZ2Ccch7Z24xce%2F8C4zEyHxMS9Dvb8HoG8HOAmGInU%3Dreserved=0.

Even after these edits, there are a few straightforward ambiguities to clear up.

(a) Section 2.  "When a network's endpoints do not represent individual users 
(e.g. in industrial, datacenter, and infrastructure contexts), network 
operations can often benefit from large-scale data collection without breaching 
user privacy."

Is network telemetry architecture being restricted to such a limited 
applicability?  To quote the original SECDIR thread, is this saying "The 
Network Telemetry Framework is not applicable to networks whose endpoints 
represent individual users, such as general-purpose access networks"?  If so, 
I'd recommend being that explicit.

HS> Thank you for pointing that out. We'll make it explicit. 


(b) Section 2.1.  "To preserve user privacy, the user packet content should not 
be collected." This is a great principle, but extremely nuanced and potentially 
complicated to implement.  Is this saying (using the words of this framework), 
"To preserve the privacy of end-users, no user packet content should be 
collected.  Specifically, the data objects generated, exported, and collected 
by the Network Telemetry Framework should not include any packet payload from 
traffic associated with end-users systems"?

HS> We will adopt the new wording you suggested above. 


(c) Section 2.5.  Please use stronger and consistent language.

OLD
Disclaimer: large-scale network data collection is a major threat to user 
privacy [RFC7258].  The network telemetry framework presented in this document 
should not be applied to collect and retain individual user data or any data 
that can identify end users without consent.
Any data collection or retention using the framework must be tightly limited to 
protect user privacy.

NEW
Large-scale network data collection is a major threat to user privacy and may 
be indistinguishable from pervasive monitoring [RFC7258].  The network 
telemetry framework presented in this document must not be applied to 
generating, exporting, collecting, analyzing or retaining individual user data 
or any data that can identify end users or characterize their behavior without 
consent.

The principles described in (a), (b) and (c) seems sufficiently important they 
shouldn't be scattered across the document.  Please either make an 
applicability statement section early in the document or a dedicated privacy 
consideration section.

HS> Thank you for the suggestion. The applicability statement is now 

Re: [OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-ntf-12: (with COMMENT)

[Haoyu Song]

Hi Erik,

Thank you very much for the review! Please find my inline response. 

Best regards,
Haoyu

-Original Message-
From: Erik Kline via Datatracker  
Sent: Wednesday, December 1, 2021 2:08 PM
To: The IESG 
Cc: draft-ietf-opsawg-...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org; 
lud...@clemm.org; lud...@clemm.org
Subject: Erik Kline's No Objection on draft-ietf-opsawg-ntf-12: (with COMMENT)

Erik Kline has entered the following ballot position for
draft-ietf-opsawg-ntf-12: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C9556f448ab40405bf01208d9b51718fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637739933072244321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=LzuHrDHHDtKfXNEaFcLtndgvhcNyBQZFDqhPbJoSTw8%3Dreserved=0
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ntf%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C9556f448ab40405bf01208d9b51718fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637739933072244321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=v5fCrIfFbL5yrV73M5QKNx0MXMKIJ3rgHS8PDwQtQCw%3Dreserved=0



--
COMMENT:
--

[S3.1; question]

* Figure 2: Is PCAP a possible Data Encoding for the Forwarding Plane?

[HS] We consider PCAP a format in host software. This document mainly concerns 
about the forwarding plane of network devices in which we haven't seen PCAP is 
used for data encoding.

* Figure 2: Should "plain text" be replaced by something like
  "proprietary"?

[HS] It's possible to have proprietary encoding but since we advocate for 
standard implementations, we don't list it here. "Plain text" means no special 
encoding of the data is applied.

  I suspect the intent was to communicate that custom/bespoke encodings
  may still be quite common.

[HS] Yes, understood. We explained that we don't intend to provide an 
exhaustive list for each case but  a few examples only.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

[Haoyu Song]

Hi Rob,

Thank you for the comments and questions. We just uploaded an update version of 
the draft based on the latest review comments. 
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/17/

We'd like to emphasize that this is  an architecture not a protocol solution. 
In fact, it pulls together the many existing and proposed protocol solutions to 
show how they fit together. The document itself doesn't propose any new 
techniques or protocols.  This is a kind of "cook book" to show why IETF 
solutions are important as part of a whole. Very often OAM solutions are 
developed in isolation without a big picture. In this sense, it's akin to the 
NTF document and we believe it fits in OPSAWG for the same reason NTF was 
adopted.

But certainly IFIT does not repeat NTF.  NTF is a very high-level architectural 
view covering all of the issues and aspects of telemetry. In contrast, IFIT 
"zooms in" to look just at the on-path telemetry tools in the category of 
forwarding-plane telemetry. These are the "new" telemetry tools in the IETF and 
are not so widely understood. Many are still in development and some are 
getting some focus. Moreover,  IFIT covers many data-plane specific issues and 
challenges that weren't discussed in NTF. For these reasons, we believe the 
framework is useful to help network operators and developers to understand and 
apply this relatively new branch of telemetry techniques.  

In the past two years, the document has evolved a lot with a clearer scope and 
architecture now. We ask the OPSAWG chairs and OPS ADs to review the latest 
version of the document again and consider to adopt it. We would continue to 
carefully address the issues raised by the colleagues.  

Thank you very much!

Best regards,
Haoyu

-Original Message-
From: Rob Wilton (rwilton)  
Sent: Monday, February 21, 2022 11:07 AM
To: adr...@olddog.co.uk; draft-song-opsawg-ifit-framew...@ietf.org
Cc: opsawg@ietf.org
Subject: RE: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

Hi Adrian, authors, WG,

Warren, Martin Duke, and I looked at this document almost 2 years back, noted 
that the work that it is describing seemed to be close to work chartered in 
IPPM WG, and hence recommended to the authors, via Tianran, that this work 
should be presented to IPPM to see if there is interest on working on any 
protocols or protocol changes related to the framework.  Authors, do you know 
if that has happened?  And if so, what was the feedback reviewed from IPPM 
please?

If IPPM doesn't want to take up this work, or doesn't think that it falls 
within their charter, and if the authors are still interested then I would 
encourage the proponents to consider doing side meetings or a BOF on the 
solution to see if they can build is wider interest for standardizing it within 
the IETF.

Finally, when reading this document, I find the document content to be very 
abstract, and I struggle to get to the meat of what it is actually describing 
or defining beyond what is already described in the NTF draft related to 
general telemetry and full lifecycle monitoring.  As it stands, I struggle to 
see how this document fits into the OPSAWG charter.  It may be that 
standardizing some of the concrete protocol parts first, or in parallel to the 
framework document may end up with a more widely applicable standard.

Thanks,
Rob


-Original Message-
From: OPSAWG  On Behalf Of Adrian Farrel
Sent: 19 February 2022 15:55
To: draft-song-opsawg-ifit-framew...@ietf.org
Cc: opsawg@ietf.org
Subject: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

Hi,

I reviewed -09 of this draft at the time of the inconclusive adoption poll back 
in December 2019. A lot of changes have been made since then, including updates 
for my previous comments.

As the document appears to be somewhat stalled, I asked the chairs what they 
thought the status was, and they said that the work is not shut down, but they 
noted that the mailing list has been very quiet on the subject. This is 
possibly because we're all waiting to find out what happens next.

Anyway, as a way of showing my continued interest in this document, I have 
reviewed the current revision (-16). I hope these comments prove useful to the 
authors.

I have shown my edits and comments in line with the document, attached.
While there are a lot of comments, I don't think any of these couldn't have 
been worked on for a working group draft. But let's continue the work with this 
draft and get it into a better shape.

One comment here rather than in the document: You talk about adding in-situ OAM 
to IPv4 encapsulations. I can, of course, see the benefit of this for operators 
carrying IPv4 traffic. But I wonder how that runs into the IETF's policy with 
regard to extending IPv4. Certainly your reference to draft-herbert-ipv4-eh is 
a bit dubious given how that work appears to have been abandoned. Of course, 
encapsulations under the IPv4 header are a totally 

Re: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

[Haoyu Song]

Hi Adrian,

Thank you very much for the review and editing! We'll update the draft to 
reflect the latest thoughts. I agree with you that the IPv4 extension is 
unlikely to happen so we'll remove that part in the new revision. 

Best regards,
Haoyu

-Original Message-
From: Adrian Farrel  
Sent: Saturday, February 19, 2022 7:55 AM
To: draft-song-opsawg-ifit-framew...@ietf.org
Cc: opsawg@ietf.org
Subject: A review of draft-song-opsawg-ifit-framework-16

Hi,

I reviewed -09 of this draft at the time of the inconclusive adoption poll back 
in December 2019. A lot of changes have been made since then, including updates 
for my previous comments.

As the document appears to be somewhat stalled, I asked the chairs what they 
thought the status was, and they said that the work is not shut down, but they 
noted that the mailing list has been very quiet on the subject. This is 
possibly because we're all waiting to find out what happens next.

Anyway, as a way of showing my continued interest in this document, I have 
reviewed the current revision (-16). I hope these comments prove useful to the 
authors.

I have shown my edits and comments in line with the document, attached.
While there are a lot of comments, I don't think any of these couldn't have 
been worked on for a working group draft. But let's continue the work with this 
draft and get it into a better shape.

One comment here rather than in the document: You talk about adding in-situ OAM 
to IPv4 encapsulations. I can, of course, see the benefit of this for operators 
carrying IPv4 traffic. But I wonder how that runs into the IETF's policy with 
regard to extending IPv4. Certainly your reference to draft-herbert-ipv4-eh is 
a bit dubious given how that work appears to have been abandoned. Of course, 
encapsulations under the IPv4 header are a totally different thing.

Best,
Adrian

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

[Haoyu Song]

I support the adoption of this draft. It’s good to see a single standard can be 
extended for telemetry data export in different networks and scenarios. I 
believe this is a valuable work and I’d like to review and contribute to this 
work in the future.

Best regards,
Haoyu

Get Outlook for iOS

From: ipv6  on behalf of thomas.g...@swisscom.com 

Sent: Friday, August 19, 2022 6:19 AM
To: 6...@ietf.org <6...@ietf.org>
Subject: FW: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Dear 6MAN wg,

I presented this draft at IETF 114 to you. The adoption call has now started at 
OPSAWG.

I believe for SRv6 it is important to obtain network visibility. I would 
appreciate your feedback and comments on the opsawg mailing list.

Export of Segment Routing IPv6 Information in IPFIX
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh
https://datatracker.ietf.org/meeting/114/materials/slides-114-opsawg-export-of-segment-routing-ipv6-information-in-ipfix-01.pdf

Best wishes
Thomas

From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: Thursday, August 18, 2022 10:14 PM
To: opsawg@ietf.org
Subject: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hello, WG.  We’d like to begin a two week call for adoption of this work.  Even 
as an individual draft it has already received some reviews and has iterated 
quite a bit.  Based on IETF 114 there does seem to be interest in adopting this 
in opsawg, but we need a formal adoption poll.

Please review and provide your adoption thoughts no later than September 1, 
2022.

Thanks.

Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG LC: Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)

[Haoyu Song]

Dear OPSAWG，

I support the WGLC for this document and believe it’s an important extension to 
IPFIX to address the emerging SRv6 use case. Thanks!

Haoyu

From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, November 30, 2022 2:54 PM
To: opsawg@ietf.org
Subject: [OPSAWG]  WG LC: Export of Segment Routing over IPv6 Information in 
IP Flow Information Export (IPFIX)

Hello, WG.  As discussed at IETF 115, we want to conduct a WG LC for 
draft-ietf-opsawg-ipfix-srv6-srh.  The authors believe this work is stable and 
moreover used the 115 hackathon to develop a interoperable implementations 
(linked in Data Tracker) .  Additionally, IANA has already weighed in on this 
work and agree with the considerations approach.

Therefore, we are calling for a two week LC.  We will conclude on December 14.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/

Please review the current -04 draft, post your comments and/or your thoughts on 
the current text.

Thanks.

Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] New revision of "Green Networking Metrics" (draft-cx-green-metrics)

[Haoyu Song]

Hi Alex,

This is an interesting read. Here I provide some comments and observations.
1. I think the energy consumption metrics on equipment is more meaningful when 
it's normalized to the device's capacity and capability. For example, energy 
per bit can be used to compare which is greener between two devices if they 
offer the same function. On the other hand, if a device does more processing 
(e.g., in network computing), it's likely it will consume more energy, but it 
also makes the overall solution more efficient, so it's still greener in this 
sense.   
2. The flow and path energy metrics is interesting but I wonder how it can be 
measured in reality? If this is doable, then perhaps application/job level 
energy consumption metrics should also be included (e.g., in HPC DCNs, a job 
may involves multiple flows and multiple paths). This level of granularity may 
be more preferred in evaluating  different solution architectures. 
3. In section 3.1.1, it seems unfair to attribute the cost to only the first 
bit. It's meaningless to send only one bit anyway so the cost should be shared 
by all the bits.:)

Best regards,
Haoyu   

-Original Message-
From: OPSAWG  On Behalf Of Alexander L Clemm
Sent: Wednesday, March 8, 2023 5:35 PM
To: opsawg@ietf.org; n...@irtf.org
Cc: draft-cx-green-metr...@ietf.org
Subject: [OPSAWG] New revision of "Green Networking Metrics" 
(draft-cx-green-metrics)

Hi,

we just posted an updated revision of "Green Networking Metrics" 
(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cx-green-metrics%2F=05%7C01%7Chaoyu.song%40futurewei.com%7C2643e0c419c1408dad4a08db203e9a42%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638139225483790907%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=USheN9sfG%2FwDm8Yy9aTy20SacMv%2B1Zd6hbiiPP63iHg%3D=0),
 including various editorial improvements and incorporating highly useful 
feedback and suggestions from a number of people including Eve Schooler, 
Alexandru Petrescu, and Michael Welzl.  The draft defines a set of "green" 
networking metrics that will be useful as basis for management and control 
applications that aim to reduce carbon footprint and hence require visibility 
into such metrics.

We believe that in terms of scope, this draft falls into the intersection of 
opsawg and nmrg interest and we hope to have the opportunity to present at IETF 
116 in Yokohama, hence we are crossposting to both groups.  Personally I 
believe that opsawg may be the most suitable landing spot as the draft can be 
easily operationalized and is not as much concerned with open-ended research 
questions, but that is of course where we would appreciate feedback from the 
groups.  Once a decision is made for the proper landing spot, hopefully 
immediately following IETF 116, we will post a new revision under the 
respective working group.

FYI, here is the abstract of the draft:
This document explains the need for network instrumentation that allows to 
assess the power consumption, energy efficiency, and carbon footprint 
associated with a network, its equipment, and the services that are provided 
over it.  It also suggests a set of related metrics that, when provided 
visibility into, can help to optimize a network's energy efficiency and 
"greenness".

On behalf of the coauthors
--- Alex

___
OPSAWG mailing list
OPSAWG@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg=05%7C01%7Chaoyu.song%40futurewei.com%7C2643e0c419c1408dad4a08db203e9a42%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638139225483790907%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0T83gXiOGuQnhKkuwbmZ7ex7KTilOComeVuP3XIkn44%3D=0

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg