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

Haoyu song <haoyu.song@huawei.com> Tue, 09 April 2019 16:09 UTC

Return-Path: <haoyu.song@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442AE120144 for <opsawg@ietfa.amsl.com>; Tue, 9 Apr 2019 09:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFOUzGr0du3z for <opsawg@ietfa.amsl.com>; Tue, 9 Apr 2019 09:09:44 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA9191200EB for <opsawg@ietf.org>; Tue, 9 Apr 2019 09:09:44 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 9B8BBE13B312FA3A9E46 for <opsawg@ietf.org>; Tue, 9 Apr 2019 17:09:42 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 9 Apr 2019 17:09:42 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.52]) by SJCEML701-CHM.china.huawei.com ([169.254.3.61]) with mapi id 14.03.0439.000; Tue, 9 Apr 2019 09:09:35 -0700
From: Haoyu song <haoyu.song@huawei.com>
To: Joe Clarke <jclarke@cisco.com>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: [OPSAWG] Review of draft-song-opsawg-ntf-03
Thread-Index: AQHU7hgGqHGbb5saEkunx/Ok2oZqjqY0AKsg
Date: Tue, 09 Apr 2019 16:09:34 +0000
Message-ID: <78A2745BE9B57D4F9D27F86655EB87F9376961CF@sjceml521-mbs.china.huawei.com>
References: <c8d48489-e34e-6854-f3a1-f447f913dab0@cisco.com>
In-Reply-To: <c8d48489-e34e-6854-f3a1-f447f913dab0@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.66.200]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/ryPCAvCwZ5FwyuQ-zF0rn76RQas>
Subject: Re: [OPSAWG] Review of draft-song-opsawg-ntf-03
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2019 16:09:47 -0000

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-bounces@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