idnits 2.17.1 draft-farinacci-lisp-telemetry-08.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 171: '... a RLOC-probe Map-Reply, it SHOULD NOT...' RFC 2119 keyword, line 174: '... RLOC-record MUST be set to 255 and ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 112 has weird spacing: '... Record a tel...' -- The document date (9 May 2022) is 718 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-lisp-ecdsa-auth-07 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-25 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental S. Ouissal 5 Expires: 10 November 2022 E. Nordmark 6 Zededa 7 9 May 2022 9 LISP Data-Plane Telemetry 10 draft-farinacci-lisp-telemetry-08 12 Abstract 14 This draft specs a JSON formatted RLOC-record for telemetry data 15 which decapsulating xTRs include in RLOC-probe Map Reply messages. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 10 November 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 52 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Telemetry Record Encoding . . . . . . . . . . . . . . . . . . 4 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 58 7.2. Informative References . . . . . . . . . . . . . . . . . 7 59 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 60 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 8 61 B.1. Changes to draft-farinacci-lisp-telemetry-08 . . . . . . 8 62 B.2. Changes to draft-farinacci-lisp-telemetry-07 . . . . . . 8 63 B.3. Changes to draft-farinacci-lisp-telemetry-06 . . . . . . 8 64 B.4. Changes to draft-farinacci-lisp-telemetry-05 . . . . . . 8 65 B.5. Changes to draft-farinacci-lisp-telemetry-04 . . . . . . 8 66 B.6. Changes to draft-farinacci-lisp-telemetry-03 . . . . . . 8 67 B.7. Changes to draft-farinacci-lisp-telemetry-02 . . . . . . 8 68 B.8. Changes to draft-farinacci-lisp-telemetry-01 . . . . . . 9 69 B.9. Changes to draft-farinacci-lisp-telemetry-00 . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 This document describes how the Locator/Identifier Separation 75 Protocol (LISP) can obtain, measure, and distribute data-plane 76 telemetry information. LISP is an encapsulation protocol built 77 around the fundamental idea of separating the topological location of 78 a network attachment point from the node's identity 79 [I-D.ietf-lisp-rfc6830bis]. As a result LISP creates two namespaces: 80 Endpoint Identifiers (EIDs), that are used to identify end-hosts and 81 routable Routing Locators (RLOCs), used to identify network 82 attachment points. LISP then defines functions for mapping between 83 the two namespaces and for encapsulating traffic originated by 84 devices using non-routable EIDs for transport across a network 85 infrastructure that routes and forwards using RLOCs. 87 This document specifies how a decapsulating xTR returns telemetry 88 data to an encapsulating xTR using RLOC-probe messages defined in 89 [I-D.ietf-lisp-rfc6833bis]. 91 Early versions of this document will define the type and format of 92 the telemetry data and how it will be distributed. Later versions of 93 this document will describe how telemetry measurement will be 94 performed. 96 2. Definition of Terms 98 Encapsulating xTR is a LISP ITR, RTR, or PITR data-plane network 99 element [I-D.ietf-lisp-rfc6830bis]. An encapsulating xTR 100 typically sends RLOC-probe Map-Request messages to decapsulating 101 xTRs to test for reachability of RLOC addresses. For the design 102 scope of this specification, RLOC-probes are also sent to obtain 103 LISP telemetry data measured by a decapsulating xTR. 105 Decapsulating xTR is a LISP ETR, RTR, or PETR data-plane network 106 element [I-D.ietf-lisp-rfc6830bis]. A decapsulating xTR typically 107 RLOC-probe replies with a Map-Reply message to an RLOC-probe Map- 108 Request sent by an encapsulating xTR. When a decapsulating xTR 109 does data-plane telemetry measurement, it returns measurement data 110 in RLOC-probe Map-Reply messages to an encapsulating xTR. 112 Telemetry Record a telemetry record is an RLOC-record that contains 113 telemetry data specified in this document. The telemetry data is 114 encoded as an LCAF JSON Type specified in [RFC8060]. 116 3. Overview 118 The following list of telemetry data has been identified as being 119 useful to obtain: 121 * Packet Count - the number of packets received within a given time 122 window between the encapsulating xTR and decapsulating xTR. 124 * Byte Count - the number bytes summed from all packets received 125 within a given time window between the encapsulating xTR and 126 decapsulating xTR. 128 * Packet Rate - the rate in packets per second an encapsulating xTR 129 is sending encapsulated packets to a decapsulating xTR. 131 * Bit Rate - the bit rate per second an encapsulating xTR is sending 132 encapsulated packets to a decapsulating xTR. 134 * Bandwidth - the amount of bandwidth used between encapsulating xTR 135 and decapsulating xTR in bytes per second. 137 * Packet Loss - the number of packets lost within a given time 138 window between the encapsulating xTR and decapsulating xTR. 140 * Packet Jitter - the amount of inter-packet time for a train of 141 packets within a given time window between the encapsulating xTR 142 and decapsulating xTR. 144 * Forward Hop-Count - the number underlay router hops from the 145 encapsulating xTR to the decapsulating xTR. 147 * Forward One-Way Latency - the amount of time from the 148 encapsulating xTR to the decapsulating xTR. Available when a 149 universal clock and rough time synchronization is available. 151 * Reverse TTL - the TTL value a decapsulating xTR is using for the 152 RLOC-probe Map-Reply. This is used to compute the return or 153 Reverse Hop-Count or number of underlay router hops between the 154 decapsulating xTR and encapsulating xTR. 156 * Reverse Timestamp - the universal clock timestamp when the 157 decapsulating xTR sent the RLOC-probe Map-Reply message. This is 158 used to compute the return or Reverse One-Way Latency between the 159 decapsulating xTR to the encapsulating xTR. 161 4. Telemetry Record Encoding 163 A Telemetry Record is an RLOC-record encoded in LCAF JSON Type format 164 [RFC8060] within the EID-record inserted in a RLOC-probe Map-Reply 165 message. The RLOC-record is appended to the existing RLOC-records 166 for the EID being probed. 168 An encapsulating xTR does not need to request telemetry data so the 169 decapsulating xTR can provide it unilaterally by default or via 170 configuration to enable the feature. When an encapsulating xTR 171 receives a Telemetry Record in a RLOC-probe Map-Reply, it SHOULD NOT 172 store it in the map-cache and not use the RLOC-record for forwarding 173 (since there are no RLOCs in this record). The priority for this 174 RLOC-record MUST be set to 255 and the weight MUST be set to 0. 176 The JSON key values imply directionality. The directionality is from 177 encapsulating xTR to decapsulating xTR. That is, the same direction 178 of RLOC-probe Map-Requests and encapsulated packet flow. The JSON 179 string format is defined to be: 181 { "type" : "telemetry", 182 "packet-count" : "", 183 "packet-loss" : "", 184 "byte-count" : "", 185 "packet-rate" : "", 186 "bit-rate" : "
", 187 "bandwidth" : "", 188 "packet-jitter" : "", 189 "forward-latency" : "", 190 "forward-hop-count" : "", 191 "reverse-ttl" : "", 192 "reverse-timestamp" : "" 193 } 195 JSON data values: 197 +============+====================================================+ 198 | JSON Value | Encoding Description | 199 +============+====================================================+ 200 | | Number of packets encoded as an integer value | 201 | | within a string. | 202 +------------+----------------------------------------------------+ 203 | | Number of lost packets encoded as an integer value | 204 | | within a string. | 205 +------------+----------------------------------------------------+ 206 | | Number of bytes encoded as an integer value within | 207 | | a string. | 208 +------------+----------------------------------------------------+ 209 | | Packet rate in packets per second encoded as an | 210 | | integer value within a string. | 211 +------------+----------------------------------------------------+ 212 |
| Bit rate in kilobits per second encoded as an | 213 | | integer value within a string. | 214 +------------+----------------------------------------------------+ 215 | | Bandwidth in kilobytes encoded as an integer value | 216 | | within a string. | 217 +------------+----------------------------------------------------+ 218 | | Packet jitter in milliseconds encoded as an | 219 | | integer value within a string. | 220 +------------+----------------------------------------------------+ 221 | | Latency in milliseconds encoded as an integer | 222 | | value within a string. | 223 +------------+----------------------------------------------------+ 224 | | Hop count encoded as an integer value within a | 225 | | string. | 226 +------------+----------------------------------------------------+ 227 | | Map-Reply IP header TTL encoded as an integer | 228 | | value within a string. | 229 +------------+----------------------------------------------------+ 230 | | Timestamp encoded in Linux UTC format as an within | 231 | | a string (i.e. Tue Jun 26 16:27:25 UTC 2018). | 232 +------------+----------------------------------------------------+ 234 Table 1 236 5. Security Considerations 238 RLOC-probe Map-Reply messages are signed to protect and authenticate 239 the Telemetry Record according to details in [I-D.ietf-lisp-sec]. 240 Telemetry Records can be kept confidential by encrypting RLOC-probe 241 Map-Reply message with the asymmetric keys described in 242 [I-D.ietf-lisp-ecdsa-auth] or the symmetric keys computed by the key 243 exchange detailed in [RFC8061]. 245 6. IANA Considerations 247 At this time there are no specific requests for IANA. 249 7. References 251 7.1. Normative References 253 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 254 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 255 February 2017, . 257 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 258 (LISP) Data-Plane Confidentiality", RFC 8061, 259 DOI 10.17487/RFC8061, February 2017, 260 . 262 7.2. Informative References 264 [I-D.ietf-lisp-ecdsa-auth] 265 Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA 266 Authentication and Authorization", Work in Progress, 267 Internet-Draft, draft-ietf-lisp-ecdsa-auth-07, 21 February 268 2022, . 271 [I-D.ietf-lisp-rfc6830bis] 272 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 273 Cabellos, "The Locator/ID Separation Protocol (LISP)", 274 Work in Progress, Internet-Draft, draft-ietf-lisp- 275 rfc6830bis-38, 7 May 2022, 276 . 279 [I-D.ietf-lisp-rfc6833bis] 280 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 281 "Locator/ID Separation Protocol (LISP) Control-Plane", 282 Work in Progress, Internet-Draft, draft-ietf-lisp- 283 rfc6833bis-31, 2 May 2022, 284 . 287 [I-D.ietf-lisp-sec] 288 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 289 "LISP-Security (LISP-SEC)", Work in Progress, Internet- 290 Draft, draft-ietf-lisp-sec-25, 9 December 2021, 291 . 294 Appendix A. Acknowledgments 296 The authors would like to thank the LISP WG for their review and 297 acceptance of this draft. A special thanks to Colin Cantrell for his 298 review, commentary and guidance. 300 Appendix B. Document Change Log 302 [RFC Editor: Please delete this section on publication as RFC.] 304 B.1. Changes to draft-farinacci-lisp-telemetry-08 306 * Posted May 2022. 308 * Document timer and reference update. 310 B.2. Changes to draft-farinacci-lisp-telemetry-07 312 * Posted November 2021. 314 * Document timer and reference update. 316 B.3. Changes to draft-farinacci-lisp-telemetry-06 318 * Posted May 2021. 320 * Document timer and reference update. 322 B.4. Changes to draft-farinacci-lisp-telemetry-05 324 * Posted November 2020. 326 * Document timer and reference update. 328 B.5. Changes to draft-farinacci-lisp-telemetry-04 330 * Posted June 2020. 332 * Document timer and reference update. 334 B.6. Changes to draft-farinacci-lisp-telemetry-03 336 * Posted December 2019. 338 * Document timer and reference update. 340 B.7. Changes to draft-farinacci-lisp-telemetry-02 341 * Posted June 2019. 343 * Document timer and reference update. 345 B.8. Changes to draft-farinacci-lisp-telemetry-01 347 * Posted December 2018. 349 * Document timer and reference update. 351 B.9. Changes to draft-farinacci-lisp-telemetry-00 353 * Initial draft posted June 2018. 355 Authors' Addresses 357 Dino Farinacci 358 lispers.net 359 San Jose, CA 360 United States of America 361 Email: farinacci@gmail.com 363 Said Ouissal 364 Zededa 365 Santa Clara, CA 366 United States of America 367 Email: said@zededa.com 369 Erik Nordmark 370 Zededa 371 Santa Clara, CA 372 United States of America 373 Email: erik@zededa.com