|
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 <dhruv.ietf@xxxxxxxxx>
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
Summary:
·
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 IDNits
·
Section 2
o
Add reference for
§
GPB - https://developers.google.com/protocol-buffers
§
IOAM - draft-ietf-ippm-ioam-data
§
NetFlow - reference is incorrect, it should be RFC 3954
§
SNMP - for the sake of covering all versions, we should mention v3 as well - RFC 3414
·
Section 3.3
o
Add reference for
§
Syslog - RFC 5424
§
sFlow - RFC 3176
o
Expand PSAMP - Packet Sampling
·
Section 4.1
o
The list of 6 angles in the text and the 1st column in the table do not match.
o
Expand ASICs - Application-Specific Integrated Circuits
·
Section 4.1.1
o
The use of the term “server” can be confusing here. Would you consider using “data source”?
·
Section 4.1.2
o
I am unaware of the term “video fluency”. Is it a term of art that I am unaware of?
o
Add reference to Y.1731 - “ITU-T, “OAM Functions and Mechanisms for Ethernet based networks”, ITU-T Y.1731, 2006.”
·
Section A.1.2
o
gNMI reference is marked as [I-D.openconfig-rtgwg-gnmi-spec] whereas, in the main body, it is [gnmi] “gNMI - gRPC Network
Management Interface”, https://github.com/openconfig/reference/tree/master/rpc/gnmi.
Any reason for different references?
o
same for gRPC!
·
Section A.3.6
o
Expand L2VPN, NVO3, BIER, SFC, DETNET
o
Is there anything about SR and Multicast worth adding to the list? [HS] Thanks for catching the nits. All these will be fixed in the new revision.
Thanks!
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
