idnits 2.17.1 draft-asechoud-rtgwg-qos-telemetry-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.asechoud-rtgwg-qos-model], [I-D.asechoud-rtgwg-qos-oper-model]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 12, 2018) is 2175 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-asechoud-rtgwg-qos-model-05 == Outdated reference: A later version (-10) exists of draft-asechoud-rtgwg-qos-oper-model-01 ** Downref: Normative reference to an Informational RFC: RFC 2697 ** Downref: Normative reference to an Informational RFC: RFC 2698 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Choudhary 2 Internet-Draft Cisco Systems 3 Intended status: Standards Track May 12, 2018 4 Expires: November 13, 2018 6 QoS Telemetry Requirements 7 draft-asechoud-rtgwg-qos-telemetry-req-00 9 Abstract 11 This document discusses QoS requirements for data model based network 12 telemetry. QoS configuration and operational models have been 13 defined as part of [I-D.asechoud-rtgwg-qos-model] and 14 [I-D.asechoud-rtgwg-qos-oper-model] respectively. This document 15 describes the requirement to extend the models to support QoS 16 Telemetry. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 13, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3.1. Granularity and Completeness . . . . . . . . . . . . . . 2 56 3.2. Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.3. Cadence . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.4. Time-stamping . . . . . . . . . . . . . . . . . . . . . . 3 59 3.5. Grouping . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.6. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.7. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.8. Threshold . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 65 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Motivation 70 Network visibility is an important aspect of Network availability. 71 QoS counters provide good insight into network device performance, 72 congestion and security. Continuous monitoring of each QoS resource 73 may not be always desired. Mechanism to monitor data set of QoS 74 resources is needed. The motivation of this document is to come up 75 with the set of requirements of such a mechanism. 77 2. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 3. Requirements 85 3.1. Granularity and Completeness 87 Statistics passed for a QoS resource should be complete at the same 88 time granular to avoid sending undesired information. A particular 89 counter in isolation may not provide sufficient information about a 90 QoS resource. E.g tail-drop counter of a queue is not sufficient to 91 define state of a Queue unless some other counters like maximum queue 92 size and average queue size is known. Hence, it is important to get 93 complete context of a resource based on device capability. 95 3.2. Scale 97 It is important to have visibility into vast number of QoS resources 98 in a network device on a regular basis. Some of the devices, e.g., 99 may support millions of queues in a single device. To be able to 100 scale, it is desired to have data sets of important resources and 101 monitor based on the need. 103 3.3. Cadence 105 Cadence defines the frequency of data collection from the forwarding 106 path. Cadence can be limited by device capability as well as based 107 on the amount of data requested. It can also be desired to have 108 higher cadence of a resource in critical condition versus when it is 109 not in critical condition. 111 3.4. Time-stamping 113 Time stamping defines the time when the data was collected from the 114 data path. Time stamping helps in calculating various traffic rates 115 and draw right patterns. 117 3.5. Grouping 119 There may be multiple collectors of same telemetry data. The purpose 120 and focus of each collector may be different. By defining the right 121 set of groupings, a collector may be able to easily fetch the desired 122 data. E.g A network slice may define set of QoS resources on each 123 interface. A collector may be interested in a particular network 124 slice may request the data accordingly. Similarly, queues data on an 125 interfaces or set of interfaces can be defined as group. 127 3.6. Filtering 129 Many times a collector is interested in specific data, e.g. Real- 130 time queue on an egress interface or metering ([RFC2697] and 131 [RFC2698]) data on a best-effort traffic of an ingress interface. An 132 effective filtering mechanism can be done in the network device or by 133 the collector. 135 3.7. Aggregation 137 Sometime aggregation of data becomes important to define meaning of 138 the data. E.g. Consider a QoS policy applied on various ingress 139 interfaces. An underway DDOS attack can be better understood when 140 all the traffic to a particular destination coming through various 141 interfaces is summed up. Aggregation can also be done for multiple 142 QoS resources within a Policy to save important hardware counter 143 resources. 145 3.8. Threshold 147 Collector may not be interested in a QoS resource data till it is 148 in critical condition. E.g. a tail-drop is seen on a particular 149 best-effort queue or queue is built up on a critical data of WFQ. 150 Many times it follows a pattern, like 9 am in the morning when 151 the trading starts, drops are seen on a particular queue but 152 otherwise there are no drops. So, it becomes important to observe a 153 resource in a critical condition and avoid otherwise. Defining a 154 threshold helps collector and device alike. Also, it is important to 155 define how long a resource will be monitored once it is out of 156 critical condition. 158 4. Security Considerations 160 5. Acknowledgement 162 6. Normative References 164 [I-D.asechoud-rtgwg-qos-model] 165 Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., 166 and I. Chen, "YANG Model for QoS", draft-asechoud-rtgwg- 167 qos-model-05 (work in progress), March 2018. 169 [I-D.asechoud-rtgwg-qos-oper-model] 170 Choudhary, A. and I. Chen, "YANG Model for QoS Operational 171 Parameters", draft-asechoud-rtgwg-qos-oper-model-01 (work 172 in progress), May 2018. 174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 175 Requirement Levels", BCP 14, RFC 2119, 176 DOI 10.17487/RFC2119, March 1997, 177 . 179 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 180 Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, 181 . 183 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 184 Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, 185 . 187 Author's Address 189 Aseem Choudhary 190 Cisco Systems 191 170 W. Tasman Drive 192 San Jose, CA 95134 193 US 195 Email: asechoud@cisco.com