| < draft-claise-opsawg-collected-data-manifest-01.txt | draft-claise-opsawg-collected-data-manifest-02.txt > | |||
|---|---|---|---|---|
| OPSAWG B. Claise | OPSAWG B. Claise | |||
| Internet-Draft J. Quilbeuf | Internet-Draft J. Quilbeuf | |||
| Intended status: Standards Track Huawei | Intended status: Standards Track Huawei | |||
| Expires: 8 September 2022 D. Lopez | Expires: 21 September 2022 D. Lopez | |||
| Telefonica I+D | Telefonica I+D | |||
| I. Dominguez | I. Dominguez | |||
| Universidad Politecnica de Madrid | Universidad Politecnica de Madrid | |||
| T. Graf | T. Graf | |||
| Swisscom | Swisscom | |||
| 7 March 2022 | 20 March 2022 | |||
| A Data Manifest for Contextualized Telemetry Data | A Data Manifest for Contextualized Telemetry Data | |||
| draft-claise-opsawg-collected-data-manifest-01 | draft-claise-opsawg-collected-data-manifest-02 | |||
| Abstract | Abstract | |||
| Most network equipment feature telemetry as a mean to monitoring | Most network equipment feature telemetry as a mean to monitoring | |||
| their status. Several protocols exist to this end, for example, the | their status. Several protocols exist to this end, for example, the | |||
| model-driven telemetry governed by YANG models. Some of these | model-driven telemetry governed by YANG models. Some of these | |||
| protocols provide the data itself, without any contextual information | protocols provide the data itself, without any contextual information | |||
| about the collection method. This can render the data unusable if | about the collection method. This can render the data unusable if | |||
| that context is lost, for instance when the data is stored without | that context is lost, for instance when the data is stored without | |||
| the relevant information. This document proposes a YANG data model | the relevant information. This document proposes a data manifest, | |||
| to store that contextual information along with the collected data in | composed of two YANG data models, to store that contextual | |||
| order to keep the collected data exploitable in the future. | information along with the collected data, in order to keep the | |||
| collected data exploitable in the future. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 8 September 2022. | This Internet-Draft will expire on 21 September 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 21 ¶ | skipping to change at page 2, line 26 ¶ | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Platform Manifest . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Platform Manifest . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.1. Overview of the model . . . . . . . . . . . . . . . . . . 4 | 3.1. Overview of the model . . . . . . . . . . . . . . . . . . 4 | |||
| 3.2. YANG module ietf-collected-data-platform-manifest . . . . 6 | 3.2. YANG module ietf-collected-data-platform-manifest . . . . 6 | |||
| 4. Data Collection Manifest . . . . . . . . . . . . . . . . . . 8 | 4. Data Collection Manifest . . . . . . . . . . . . . . . . . . 9 | |||
| 4.1. Overview of the model . . . . . . . . . . . . . . . . . . 9 | 4.1. Overview of the model . . . . . . . . . . . . . . . . . . 9 | |||
| 4.2. YANG module ietf-collected-data-manifest . . . . . . . . 10 | 4.2. YANG module ietf-collected-data-manifest . . . . . . . . 10 | |||
| 5. Collecting Data Manifest and Mapping Data to Data Manifest . 13 | 5. Collecting Data Manifest and Mapping Data to Data Manifest . 13 | |||
| 5.1. Mapping Collected Data to the Data Manifest . . . . . . . 14 | 5.1. Mapping Collected Data to the Data Manifest . . . . . . . 14 | |||
| 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 17 | 11.2. Informative References . . . . . . . . . . . . . . . . . 17 | |||
| Appendix A. Changes between revisions . . . . . . . . . . . . . 18 | Appendix A. Changes between revisions . . . . . . . . . . . . . 18 | |||
| Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 1. Terminology | 1. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| Data Manifest: all the necessary data required to interpret the | Data Manifest: all the necessary data required to interpret the | |||
| skipping to change at page 3, line 22 ¶ | skipping to change at page 3, line 25 ¶ | |||
| This streamed information is used for network monitoring or closed- | This streamed information is used for network monitoring or closed- | |||
| loop automation. This streamed data can also be stored in a database | loop automation. This streamed data can also be stored in a database | |||
| (sometimes called a big data lake) for further analysis. | (sometimes called a big data lake) for further analysis. | |||
| When streaming YANG-structured data with YANG-Push [RFC8641], there | When streaming YANG-structured data with YANG-Push [RFC8641], there | |||
| is a semantic definition in the corresponding YANG module definition. | is a semantic definition in the corresponding YANG module definition. | |||
| On top of that definition, it is also important to maintain | On top of that definition, it is also important to maintain | |||
| contextual information about the collection environment. | contextual information about the collection environment. | |||
| As an example, a database could store a time series representing the | As an example, a database could store a time series representing the | |||
| evolution of a specific counter. When analyzing the data, it's | evolution of a specific counter. When analyzing the data, it is | |||
| important to understand that this counter was requested from the | important to understand that this counter was requested from the | |||
| network element at specific cadence, as this exact cadence might not | network element at specific cadence, as this exact cadence might not | |||
| be observed in the time series, potentially implying that the network | be observed in the time series, potentially implying that the network | |||
| element was under stress. The same time series might report some | element was under stress. The same time series might report some | |||
| values as 0 or might even omit some values. This might be explained | values as 0 or might even omit some values. This might be explained | |||
| by a too small observation period, compared to the minimum-observed- | by a too small observation period, compared to the minimum-observed- | |||
| period [I-D.claise-netconf-metadata-for-collection]. Again, knowing | period [I-D.claise-netconf-metadata-for-collection]. Again, knowing | |||
| the conditions under which the counter was collected and streamed is | the conditions under which the counter was collected and streamed is | |||
| crucial. Indeed, taking into account the value of 0 might lead to a | crucial. Indeed, taking into account the value of 0 might lead to a | |||
| wrong conclusion that the counter dropped to zero. This document | wrong conclusion that the counter dropped to zero. This document | |||
| specifies the data collection manifest, which contains the required | specifies the data collection manifest, which contains the required | |||
| information to characterize how and when the telemetry information | information to characterize how and when the telemetry information | |||
| was metered. | was metered. | |||
| Precisely characterizing the source used for producing the data (that | Precisely characterizing the source used for producing the data (that | |||
| is the platform manifest) may also be useful to complete the data | is the platform manifest) may also be useful to complete the data | |||
| collection context. As an example, knowing the exact device software | collection context. As an example, knowing the exact data source | |||
| specification might reveal a particularity in the observed data, | software specification might reveal a particularity in the observed | |||
| explained by a specific bug, or a specific bug fix. This is also | data, explained by a specific bug, or a specific bug fix. This is | |||
| necessary to ensure the reliability of the collected data. On top of | also necessary to ensure the reliability of the collected data. On | |||
| that, in particular for MDT, it is crucial to know the set of YANG | top of that, in particular for MDT, it is crucial to know the set of | |||
| modules supported by the device, along with their deviations. In | YANG modules supported by the device, along with their deviations. | |||
| some cases, there might even be some backwards incompatible changes | In some cases, there might even be some backwards incompatible | |||
| in native modules between one OS version to the next one. This | changes in native modules between one OS version to the next one. | |||
| information must be compiled in a platform manifest that must be | This information must be compiled in a platform manifest. | |||
| included in the data manifest. | ||||
| Some related YANG modules have been specified to retrieve the device | Some related YANG modules have been specified to retrieve the device | |||
| capabilities: | capabilities: | |||
| * [RFC9196] which models the device capabilities regarding the | * [RFC9196] which models the device capabilities regarding the | |||
| production and export of telemetry data. | production and export of telemetry data. | |||
| * [I-D.claise-netconf-metadata-for-collection], which is based on | * [I-D.claise-netconf-metadata-for-collection], which is based on | |||
| the previous draft to define the optimal settings to stream | the previous draft to define the optimal settings to stream | |||
| specific items (i.e., per path). | specific items (i.e., per path). | |||
| While these related YANG modules are important to discover the | While these related YANG modules are important to discover the | |||
| capabilities before applying the telemetry configuration (such as on- | capabilities before applying the telemetry configuration (such as on- | |||
| change), some of their content is part of the context for the | change), some of their content is part of the context for the | |||
| streamed data. Our goal is to compile the data manifest for a given | streamed data. The goal behind this specification is not to expose | |||
| device. This manifest contains two parts, the platform manifest and | new information via YANG objects but rather to define what needs to | |||
| the data collection manifest. The platform manifest is "pretty" | be kept as metadata (the data manifest) to ensure that the collected | |||
| stable and should change only when the device is updated or patched. | data can still be interpreted correctly, even if the source device is | |||
| On the other hand, the data collection manifest is likely to change | not accesible (from the collection system), or if the device has been | |||
| each time a new MDT subscription is requested and might even change | updated (new operating system or new configuration). This manifest | |||
| if the device load increases and collection periods are updated. To | contains two parts, the platform manifest and the data collection | |||
| separate these two parts, we enclose each of them in its own module. | manifest. The platform manifest is "pretty" stable and should change | |||
| only when the device is updated or patched. On the other hand, the | ||||
| data collection manifest is likely to change each time a new MDT | ||||
| subscription is requested and might even change if the device load | ||||
| increases and collection periods are updated. To separate these two | ||||
| parts, we enclose each of them in its own module. | ||||
| We first present the module for the platform manifest in Section 3 | We first present the module for the platform manifest in Section 3 | |||
| and then the module for the data collection manifest in Section 4. | and then the module for the data collection manifest in Section 4. | |||
| The full data manifest is obtained by combining these two modules. | The full data manifest is obtained by combining these two modules. | |||
| We explain in Section 5 how the data-manifest can be collected and | We explain in Section 5 how the data-manifest can be collected and | |||
| how collected data is mapped to the data manifest. | how collected data is mapped to the data manifest. | |||
| 3. Platform Manifest | 3. Platform Manifest | |||
| 3.1. Overview of the model | 3.1. Overview of the model | |||
| Figure 1 contains the YANG tree diagram [RFC8340] of the ietf- | Figure 1 contains the YANG tree diagram [RFC8340] of the ietf- | |||
| collected-data-platform-manifest module. | collected-data-platform-manifest module. | |||
| module: ietf-collected-data-platform-manifest | module: ietf-collected-data-platform-manifest | |||
| +--ro platform | +--ro platform | |||
| +--ro platform? string | +--ro name? string | |||
| +--ro vendor? string | ||||
| +--ro software-version? string | +--ro software-version? string | |||
| +--ro software-flavor? string | +--ro software-flavor? string | |||
| +--ro os-version? string | +--ro os-version? string | |||
| +--ro os-type? string | +--ro os-type? string | |||
| +--ro yang-library | +--ro yang-library | |||
| | +--ro module-set* [name] | | +--ro module-set* [name] | |||
| | | +--ro name string | | | +--ro name string | |||
| | | +--ro module* [name] | | | +--ro module* [name] | |||
| | | | +--ro name yang:yang-identifier | | | | +--ro name yang:yang-identifier | |||
| | | | +--ro revision? revision-identifier | | | | +--ro revision? revision-identifier | |||
| skipping to change at page 5, line 52 ¶ | skipping to change at page 6, line 7 ¶ | |||
| +--ro package* [name version] | +--ro package* [name version] | |||
| +--ro name -> /pkgs:packages/package/name | +--ro name -> /pkgs:packages/package/name | |||
| +--ro version -> /pkgs:packages/package[pkgs:name = current()/../name]/version | +--ro version -> /pkgs:packages/package[pkgs:name = current()/../name]/version | |||
| +--ro checksum? -> /pkgs:packages/package[pkgs:name = current()/../name][pkgs:version = current()/../version]/pkgs:checksum | +--ro checksum? -> /pkgs:packages/package[pkgs:name = current()/../name][pkgs:version = current()/../version]/pkgs:checksum | |||
| Figure 1: YANG tree diagram for ietf-collected-data-platform- | Figure 1: YANG tree diagram for ietf-collected-data-platform- | |||
| manifest module | manifest module | |||
| The platform manifest contains a comprehensive set of information | The platform manifest contains a comprehensive set of information | |||
| characterize a data source. The platform is identified by a set of | characterize a data source. The platform is identified by a set of | |||
| parameters ('platform', 'software-version', 'software-flavor', 'os- | parameters ('name', 'software-version', 'software-flavor', 'os- | |||
| version', 'os-type') that are aligned with the YANG Catalog | version', 'os-type') that are aligned with the YANG Catalog | |||
| www.yangcatalog.org [I-D.clacla-netmod-model-catalog] so that the | www.yangcatalog.org [I-D.clacla-netmod-model-catalog] so that the | |||
| YANG catalog could be used to retrieve the YANG modules a posteriori. | YANG catalog could be used to retrieve the YANG modules a posteriori. | |||
| The platform manifest also includes the contents of the YANG Library | The platform manifest also includes the contents of the YANG Library | |||
| [RFC8525]. That module set is particularly useful to define the | [RFC8525]. That module set is particularly useful to define the | |||
| paths, as they are based on module names. Similarly, this module | paths, as they are based on module names. Similarly, this module | |||
| defines the available datastores, which can be referred to from the | defines the available datastores, which can be referred to from the | |||
| data-manifest, if necessary. If supported by the device, fetching | data-manifest, if necessary. If supported by the device, fetching | |||
| metrics from a specific datastore could enable some specific | metrics from a specific datastore could enable some specific use | |||
| usecases: monitoring configuration before it is committed, comparing | cases: monitoring configuration before it is committed, comparing | |||
| between the configuration and operational datastore. | between the configuration and operational datastore. | |||
| Alternatively, the set of available YANG modules on the device can be | Alternatively, the set of available YANG modules on the device can be | |||
| described via packages-set which contains a list of references to | described via packages-set which contains a list of references to | |||
| YANG Packages [I-D.ietf-netmod-yang-packages]. | YANG Packages [I-D.ietf-netmod-yang-packages]. | |||
| 3.2. YANG module ietf-collected-data-platform-manifest | 3.2. YANG module ietf-collected-data-platform-manifest | |||
| <CODE BEGINS> file "ietf-collected-data-platform- | <CODE BEGINS> file "ietf-collected-data-platform- | |||
| manifest@2021-10-15.yang" | manifest@2021-10-15.yang" | |||
| skipping to change at page 7, line 42 ¶ | skipping to change at page 7, line 46 ¶ | |||
| "Initial revision"; | "Initial revision"; | |||
| reference | reference | |||
| "RFC xxxx: Title to be completed"; | "RFC xxxx: Title to be completed"; | |||
| } | } | |||
| container platform { | container platform { | |||
| config false; | config false; | |||
| description | description | |||
| "Contains information about the platform that allows to identify | "Contains information about the platform that allows to identify | |||
| and understand the individual data collection information. "; | and understand the individual data collection information. "; | |||
| leaf platform { | leaf name { | |||
| type string; | type string; | |||
| description | description | |||
| "Platform on which this module is implemented."; | "Platform on which this module is implemented."; | |||
| } | } | |||
| leaf vendor { | ||||
| type string; | ||||
| description | ||||
| "Organization that implements that platform."; | ||||
| } | ||||
| leaf software-version { | leaf software-version { | |||
| type string; | type string; | |||
| description | description | |||
| "Name of the version of software. With respect to most network | "Name of the version of software. With respect to most network | |||
| device appliances, this will be the operating system version. | device appliances, this will be the operating system version. | |||
| But for other YANG module implementation, this would be a | But for other YANG module implementation, this would be a | |||
| version of appliance software. Ultimately, this should | version of appliance software. Ultimately, this should | |||
| correspond to a version string that will be recognizable by the | correspond to a version string that will be recognizable by the | |||
| consumers of the platform."; | consumers of the platform."; | |||
| } | } | |||
| leaf software-flavor { | leaf software-flavor { | |||
| type string; | type string; | |||
| description | description | |||
| "A variation of a specific version where YANG model support | "A variation of a specific version where YANG model support | |||
| may be different. Depending on the vendor, this could be a | may be different. Depending on the vendor, this could be a | |||
| skipping to change at page 9, line 48 ¶ | skipping to change at page 10, line 6 ¶ | |||
| paths that it needs in subscription A. Once it has the subscription | paths that it needs in subscription A. Once it has the subscription | |||
| id for A, it will need an additional subscription B for the data | id for A, it will need an additional subscription B for the data | |||
| manifest of paths in A. Then, it would need another subscription C | manifest of paths in A. Then, it would need another subscription C | |||
| to fetch the data manifest for the subscription B and so on... A | to fetch the data manifest for the subscription B and so on... A | |||
| possible solution would be adding in the "mdt" container an | possible solution would be adding in the "mdt" container an | |||
| additional list in that contains the data manifest for every path | additional list in that contains the data manifest for every path | |||
| that is a data manifest. By including that list in subscription B, | that is a data manifest. By including that list in subscription B, | |||
| the collector would have the information about subscription B here. | the collector would have the information about subscription B here. | |||
| The "datastore" leaf of the subscription container specifies from | The "datastore" leaf of the subscription container specifies from | |||
| which datastore the yang paths are streamed. | which datastore the YANG paths are streamed. | |||
| Within a given collection subscription, the granularity of the | Within a given collection subscription, the granularity of the | |||
| collection is defined by the path. Note that all devices do not | collection is defined by the path. Note that all devices do not | |||
| support an arbitrary granularity up to the leaf, usually for | support an arbitrary granularity up to the leaf, usually for | |||
| performance reasons. Each path currently collected by the device | performance reasons. Each path currently collected by the device | |||
| should show up in the mdt-path-data-manifest list. | should show up in the mdt-path-data-manifest list. | |||
| For each path, the collection context must be specified including: | For each path, the collection context must be specified including: | |||
| * 'on-change': when set to true, an update is sent as soon as and | * 'on-change': when set to true, an update is sent as soon as and | |||
| skipping to change at page 13, line 32 ¶ | skipping to change at page 13, line 35 ¶ | |||
| } | } | |||
| // we could augment here with other kind of collection items | // we could augment here with other kind of collection items | |||
| } | } | |||
| } | } | |||
| } | } | |||
| <CODE ENDS> | <CODE ENDS> | |||
| 5. Collecting Data Manifest and Mapping Data to Data Manifest | 5. Collecting Data Manifest and Mapping Data to Data Manifest | |||
| This data manifest instance file MUST be streamed all with the data | The data manifest MUST be streamed all with the data and stored along | |||
| and stored along with the collected data. In case the collected data | with the collected data. In case the collected data are moved to a | |||
| are moved to a different place (typically a database), the data | different place (typically a database), the data manifest MUST follow | |||
| manifest MUST follow the collected data. This can render the data | the collected data. This can render the data unusable if that | |||
| unusable if that context is lost, for instance when the data is | context is lost, for instance when the data is stored without the | |||
| stored without the relevant information. The data manifest MUST be | relevant information. The data manifest MUST be updated when the | |||
| updated when the data manifest information changes (for example, when | data manifest information changes (for example, when a router is | |||
| a router is upgraded), when a new telemetry subscription is | upgraded), when a new telemetry subscription is configured, or when | |||
| configured, or when the telemetry subscription paremeters change. | the telemetry subscription paremeters change. | |||
| The data should be mapped to the data manifest. Since the data | The data should be mapped to the data manifest. Since the data | |||
| manifest will not change as frequently as the data itself, it makes | manifest will not change as frequently as the data itself, it makes | |||
| sense to map several data to the same data manifest. Somehow, the | sense to map several data to the same data manifest. Somehow, the | |||
| collected data must include a metadata pointing to the corresponding | collected data must include a metadata pointing to the corresponding | |||
| data manifest. | data manifest. | |||
| The platform manifest is likely to remain the same until the device | The platform manifest is likely to remain the same until the device | |||
| is updated. So, the platform manifest only needs to be collected | is updated. So, the platform manifest only needs to be collected | |||
| once per streaming session and updated after a device reboot. | once per streaming session and updated after a device reboot. | |||
| As this draft specifically focuses on giving context on data | As this draft specifically focuses on giving context on data | |||
| collected via streamed telemetry, we can assume that a streaming | collected via streamed telemetry, we can assume that a streaming | |||
| telemetry system is available. Collecting the data and platform | telemetry system is available. Collecting the data and platform | |||
| manifests can be done either by reusing that streaming telemetry | manifests can be done either by reusing that streaming telemetry | |||
| system (in-band) or using another system (out-of-band), for instance | system (in-band) or using another system (out-of-band), for instance | |||
| by adding headers or saving manifests into files. | by adding headers or saving manifests into a YANG instace file | |||
| [RFC9195]. | ||||
| We propose to reuse the existing telemetry system (in-band approach) | We propose to reuse the existing telemetry system (in-band approach) | |||
| in order to lower the efforts for implementing this draft. To enable | in order to lower the efforts for implementing this draft. To enable | |||
| a platform supporting streaming telemetry to also support data | a platform supporting streaming telemetry to also support data | |||
| collection manifests, it is sufficient that this device supports the | collection manifests, it is sufficient that this device supports the | |||
| models from Section 3 and Section 4. Recall that each type of | models from Section 3 and Section 4. Recall that each type of | |||
| manifest has its own rough frequency update, i.e. at reboot for the | manifest has its own rough frequency update, i.e. at reboot for the | |||
| platform manifest and at new subscription or CPU load variation for | platform manifest and at new subscription or CPU load variation for | |||
| the data manifest. The data manifest MUST be streamed with the YANG- | the data collection manifest. The data manifest MUST be streamed | |||
| Push on-change feature [RFC8641] (also called event-driven | with the YANG-Push on-change feature [RFC8641] (also called event- | |||
| telemetry). | driven telemetry). | |||
| 5.1. Mapping Collected Data to the Data Manifest | 5.1. Mapping Collected Data to the Data Manifest | |||
| With MDT, a particular datapoint is always associated to a path that | With MDT, a particular datapoint is always associated to a path that | |||
| is itself part of a subscription. In order to enable a posteriori | is itself part of a subscription. In order to enable a posteriori | |||
| retrieval of the data manifest associated to a datapoint, the | retrieval of the data manifest associated to a datapoint, the | |||
| collector must: | collector must: | |||
| * keep the path in the metadata of the collected values | * keep the path in the metadata of the collected values | |||
| skipping to change at page 16, line 48 ¶ | skipping to change at page 17, line 4 ¶ | |||
| * Better explain the on-change example. | * Better explain the on-change example. | |||
| * Regarding the inclusion of ietf-yang-library in our module, do we | * Regarding the inclusion of ietf-yang-library in our module, do we | |||
| want to include as well the changes from ietf-yang-library- | want to include as well the changes from ietf-yang-library- | |||
| revisions? What if other information are present in the yang- | revisions? What if other information are present in the yang- | |||
| libary from the platform? Should we use a YANG mount to capture | libary from the platform? Should we use a YANG mount to capture | |||
| them as well (they would not be captured with our use of the main | them as well (they would not be captured with our use of the main | |||
| yang-library grouping). | yang-library grouping). | |||
| * Henk: how does this interact with SBOM effort? | * Henk: how does this interact with SBOM effort? | |||
| * Eliot: important to give integrity of the information a lot of | * Eliot: important to give integrity of the information a lot of | |||
| thought | thought. Threat model to be considered. | |||
| * Attacker model to be considered. | ||||
| 11. References | 11. References | |||
| 11.1. Normative References | 11.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| skipping to change at page 17, line 31 ¶ | skipping to change at page 17, line 33 ¶ | |||
| [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., | [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., | |||
| and R. Wilton, "YANG Library", RFC 8525, | and R. Wilton, "YANG Library", RFC 8525, | |||
| DOI 10.17487/RFC8525, March 2019, | DOI 10.17487/RFC8525, March 2019, | |||
| <https://www.rfc-editor.org/info/rfc8525>. | <https://www.rfc-editor.org/info/rfc8525>. | |||
| [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications | [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications | |||
| for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, | for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, | |||
| September 2019, <https://www.rfc-editor.org/info/rfc8641>. | September 2019, <https://www.rfc-editor.org/info/rfc8641>. | |||
| [RFC9195] Lengyel, B. and B. Claise, "A File Format for YANG | ||||
| Instance Data", RFC 9195, DOI 10.17487/RFC9195, February | ||||
| 2022, <https://www.rfc-editor.org/info/rfc9195>. | ||||
| 11.2. Informative References | 11.2. Informative References | |||
| [I-D.clacla-netmod-model-catalog] | [I-D.clacla-netmod-model-catalog] | |||
| Clarke, J. and B. Claise, "YANG module for | Clarke, J. and B. Claise, "YANG module for | |||
| yangcatalog.org", Work in Progress, Internet-Draft, draft- | yangcatalog.org", Work in Progress, Internet-Draft, draft- | |||
| clacla-netmod-model-catalog-03, 3 April 2018, | clacla-netmod-model-catalog-03, 3 April 2018, | |||
| <http://www.ietf.org/internet-drafts/draft-clacla-netmod- | <http://www.ietf.org/internet-drafts/draft-clacla-netmod- | |||
| model-catalog-03.txt>. | model-catalog-03.txt>. | |||
| [I-D.claise-netconf-metadata-for-collection] | [I-D.claise-netconf-metadata-for-collection] | |||
| skipping to change at page 18, line 19 ¶ | skipping to change at page 18, line 27 ¶ | |||
| <https://www.ietf.org/archive/id/draft-ietf-netmod-yang- | <https://www.ietf.org/archive/id/draft-ietf-netmod-yang- | |||
| packages-03.txt>. | packages-03.txt>. | |||
| [RFC9196] Lengyel, B., Clemm, A., and B. Claise, "YANG Modules | [RFC9196] Lengyel, B., Clemm, A., and B. Claise, "YANG Modules | |||
| Describing Capabilities for Systems and Datastore Update | Describing Capabilities for Systems and Datastore Update | |||
| Notifications", RFC 9196, DOI 10.17487/RFC9196, February | Notifications", RFC 9196, DOI 10.17487/RFC9196, February | |||
| 2022, <https://www.rfc-editor.org/info/rfc9196>. | 2022, <https://www.rfc-editor.org/info/rfc9196>. | |||
| Appendix A. Changes between revisions | Appendix A. Changes between revisions | |||
| Version 2 | ||||
| Alignment with YANGCatalog YANG module: name, vendor | ||||
| Clarify the use of YANG instance file | ||||
| Editorial improvements | ||||
| Version 1 | Version 1 | |||
| Adding more into data platform: yang packages, whole yanglib | Adding more into data platform: yang packages, whole yanglib | |||
| module to specify datastores | module to specify datastores | |||
| Setting the right type for periods: int64 -> uint64 | Setting the right type for periods: int64 -> uint64 | |||
| Specify the origin datastore for mdt subscription | Specify the origin datastore for mdt subscription | |||
| Set both models to config false | Set both models to config false | |||
| skipping to change at page 18, line 36 ¶ | skipping to change at page 19, line 4 ¶ | |||
| Specify the origin datastore for mdt subscription | Specify the origin datastore for mdt subscription | |||
| Set both models to config false | Set both models to config false | |||
| Applying text comments from Mohamed Boucadair | Applying text comments from Mohamed Boucadair | |||
| Adding an example of data-manifest file | Adding an example of data-manifest file | |||
| Adding rationale for reusing telemetry system for collection of | Adding rationale for reusing telemetry system for collection of | |||
| the manifests | the manifests | |||
| Export manifest with on change telemetry as opposed to YANG | Export manifest with on change telemetry as opposed to YANG | |||
| instance file | instance file | |||
| Version 0 | Version 0 | |||
| Initial version | Initial version | |||
| Acknowledgements | Acknowledgements | |||
| Thanks to Mohamed Boucadair for his review and comments. | Thanks to Mohamed Boucadair and Tianran Zhou for their reviews and | |||
| comments. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Benoit Claise | Benoit Claise | |||
| Huawei | Huawei | |||
| Email: benoit.claise@huawei.com | Email: benoit.claise@huawei.com | |||
| Jean Quilbeuf | Jean Quilbeuf | |||
| Huawei | Huawei | |||
| Email: jean.quilbeuf@huawei.com | Email: jean.quilbeuf@huawei.com | |||
| Diego R. Lopez | Diego R. Lopez | |||
| Telefonica I+D | Telefonica I+D | |||
| End of changes. 28 change blocks. | ||||
| 56 lines changed or deleted | 78 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||