Thank you very much Dhruv, the text you proposed has been included.
Best regards,
Haoyu
From: Dhruv Dhody <dhruv.ietf@xxxxxxxxx>
Sent: Sunday, November 21, 2021 8:22 PM
To: Haoyu Song <haoyu.song@xxxxxxxxxxxxx>
Cc: rtg-dir@xxxxxxxx; last-call@xxxxxxxx; draft-ietf-opsawg-ntf.all@xxxxxxxx; rtgdir-chairs@xxxxxxxx; rtgdir-ads@xxxxxxxx; opsawg <opsawg@xxxxxxxx>
Subject: Re: RtgDir Last Call review: draft-ietf-opsawg-ntf-10
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,
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.
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
