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, 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
